Description of problem: been trying to track down commonalities; but it's time to at least report the symptoms in case someone is seeing this too... Some windows do not respond to mouse events until the mouse exits the window area. For example, scrolling the mouse does nothing; but when the mouse leaves the window area, the window acts on all the mouse events at once. When this starts in a window, the only way to scroll is to scroll the mouse, move out of the window, back in and repeat. The really strange part is that while a firefox window reacts this way, another does not. This is a general problem that I still can't attribute to kde, X, or other because it is not restricted to any particular application. As I write this, this firefox window scrolls; another firefox window ignores the scroll events until I move the mouse focus back to this one -- then the other window scroll events kick in. emacs, claws-mail, Just tried to check for keyboard events: clicked on web page search box, typed and nothing happened until I moved the mouse out of the window; then the mouse focus kicked in and the previously typed text appeared. Scrolling and click to focus seem to be handled separately: scrolling, then clicking in a textbox each require exiting the window to have each take effect... very aggravating... Version-Release number of selected component (if applicable): How reproducible: no idea yet how this starts or why it doesn't affect all windows of the same application. Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
What desktop are you using? looks like KDE but precise? What mice are you using? (USB, PS/2, ...)? Also attach (not paste) your /etc/X11/xorg.conf & /var/log/Xorg.0.log
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaud
KDE w/USB mouse off of Targus 4-port USB Hub. I've updated and rebooted several times over the holidays, and am not certain this bug is still there...
Created attachment 4707 [details] /etc/X11/xorg.conf
Created attachment 4708 [details] /var/log/Xorg.0.log
Today, gkrellm just sits, no updates, unless I move the mouse into or out of its window. Mouse entry/exit events cause some small number of updates (1 to ~3|4) based on visual observation of something that's set to happen 12 times per second.
Restarted gkrellm and it now updates automatically. Something randomly, on any window, prevents updates unless the mouse is moved in/out of the affected window. Seems to affect claws-mail notification plugin too (http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3063)
At the moment, I have 9 firefox (FF) windows open with many tabs each. On only ONE of these windows, FF suddenly started requiring that the mouse cross the window boundary to update anything. Examples: - typing into a text box will not appear until mouse crosses window boundary - [de]selecting checkboxes will not happen until... - scrolling the tabs barely starts scrolling (one or more tabs incomplete/joined -- partial screen update) until... - loading a new page only happens in spurts -- spinner moves for a fraction of a second (varies between ~1/2 and just over a full revolution of the spinner) until... On lengthy pages, requires many window boundary crossings to eventually display entire page. - scrolling a page does nothing until... then the new display snaps in. - grabbing and moving (ie, maps.google.com) does not move map until... - if portion of map is not cached and requires downloading, window exit(s) required to complete the page update - etc. However: - opening a new tab completes fast enough to avoid this issue - closing a tab also completes... Closing only that FF window and re-opening it via History->Recently Closed Windows->[window] restores normal operation. The summary of this bug (mouse events not consistently handled; sometimes stacked and processed on window exit) is not correct; but don't know how to reword it... Maybe: window updates which can't complete within a fraction of a second require one or more mouse crossings of the window boundary to complete. [Note: after having copied/pasted this bugs summary into previous paragraph, part of the pasted text (as it appears at the top of this page) appears near the top of this text box. If I barely move the mouse, it clears up. If I take a screenshot via PrintScr, it doesn't get captured. If the text I'm entering causes this textbox to scroll, it clears up. Happened several times as I type this...]
Also opened at https://bugs.kde.org/show_bug.cgi?id=331017
Summary: mouse events not consistently handled; sometimes stacked and processed on window exit => keyboard and mouse inputs ignored until mouse crosses window boundary
Created attachment 5032 [details] clock not updating Looks like this bug hits everything... clock is not updating unless mouse enters/leaves its screen real estate.
Installed mga4 on a brand new laptop; being careful not to bring over any X, KDE, plasma, or other settings -- because I suspected something from a long time ago might have been the cause. Today, gkrellm is the first to show the symptoms -- not updating unless the mouse moves across its edges... SIGH... and here I was hoping to be able to close most of the weird bug reports after this fresh/clean install on a new machine... :(
After a fresh install on a brand new Dell M6800, I'm beginning to suspect the gkrellm issue happens after about a week of logged-in time (not uptime). So far, I'm not seeing the firefox or clock issues.
Well... this bug is still there... I could deal with restarting gkrellm, clicking on the clock to get current time (screen saver clock does get updates), etc. However, now this bug has hit the screen saver, so the only way to resolve this one is to logout and back in. Something is causing a communication path to stall somewhere. This is the 2nd x86_64 system (both 4core/8thread) that exhibits these issues.
[Am downloading cauldron (mga5 beta) rpms (not ISOs) to see if this still exists.] This problem is beginning to smell like something has a hard-coded limit... To eliminate swapping issues, now have 32GB memory on Dell M6800 (4710MQ CPU -- 4 core/8 thread). Typically running: - 8 desktops w/multi-tab konsole on each - firefox with >500 tabs over 10-12 windows - firefox/wine for certain pages - 2 instances of claws-mail with 12 accounts - kvirc - several instances of blender - openoffice (due to bug 11996) s/s, doc, dwg - okular - lots of emacs sessions - gimp - gnucash - vlc - python - 3 external HDs connected - misc Today, one konsole is VERY slow -- widow-shading it momentarily forces updates. I can "emacs somefile &[Enter]" and get emacs window up plus window-shade konsole before a normal konsole redraw occurs. One suspicion is the number of results from "lsof". On reboot, I get just over 11MB of output and everything works. Over time, I see up to 35MB of lsof output... too much to analyze; but visual scanning, it appears to have crazy amounts of data. # ll lsof.201502031605 -rw-r--r-- 1 root root 34973143 Feb 3 16:04 lsof.201502031605 Random examples: # grep "socket" lsof.201502031605 | wc 6878 67959 765288 # grep "pipe" lsof.201502031605 | wc 22754 226296 2320908 # grep "TCP prf" lsof.201502031605 | wc 2835 31082 454101 # grep "\[eventfd\]" lsof.201502031605 | wc 3213 31729 343791 # grep "inotify" lsof.201502031605 | wc 548 5397 57540 # grep "/dev/pts/" lsof.201502031605 | wc 1746 17082 189764 # grep "/usr/lib64/libgcc_s-4.8.2.so.1" lsof.201502031605 | wc 666 6571 85248 With all this, gkrellm reports 24GB free. <=== reporting bug? Yet: top - 13:08:14 up 26 days, 23:56, 46 users, load average: 1.45, 1.24, 1.25 Tasks: 409 total, 3 running, 406 sleeping, 0 stopped, 0 zombie Cpu(s): 15.4%us, 0.8%sy, 0.0%ni, 83.5%id, 0.2%wa, 0.2%hi, 0.0%si, 0.0%st Mem: 32807680k total, 32274344k used, 533336k free, 830788k buffers Swap: 33630192k total, 177376k used, 33452816k free, 20538208k cached Am I running into some headroom issue(s) somewhere?
seems resolved after 13 days on mga5
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME