Red Hat Bugzilla – Bug 63509
mouse event problems after system standby
Last modified: 2007-04-18 12:42:00 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9) Gecko/20020311 Description of problem: in X/GNOME + Sawfish, mouse click events are not caught correctly after having run an apm -s command and having resumed the system. It seems that on some controls, only every third click is caught. Restarting X makes things work again. This is a rather annoying problem, as working with the system after a standby can be rather stressfull. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Start X/GNOME + Sawfish 2. Double click a window title-bar a couple of times to make sure the shading i working correctly 3. run apm -s, the resume the system 4. Try the window shading again Actual Results: After the system standby, shading doesn't work correctly... On a closer look, not only shading doesn't work, but thinks like selecting items from a list(a la bugzilla's bug search status list "ASSIGNED, CLOSED..." in Galeon only flips status on every third mouseclick. Expected Results: Everything should be working as it did before the apm -s was executed Additional info: I have not yet tested this with other that GNOME+SAWFISH+GALEON, but as I recall, the actual viewer in Galeon is not a GTK component, is it?!? I'm not sure where the problem is, but this is what is happening. Also I am not aware if the problem only occurs after apm -s or if it also shows after an apm -S. My mouse is a PS2 stype mouse using the IntelliMouse protocol.
This could be a BIOS bug, a kernel bug, a hardware bug, an XFree86 bug, or one of many other things. It's next to impossible to begin to debug without the actual hardware. Please attach your X server logs and config file, as well as your /var/log/messages so there is further data to look at that might provide clues.
The problem does not arise under KDE, nor does it arise under GNOME when using WindowMaker as Windows Manager, so my guess now is that we should probably suspect SawFish to have something to do with this
I can confirm the same issue with Sawfish/gnome on a Dell Latitude CS400 with default packages. After a suspend mouse events act strangely (left button can select menus but can no longer move windows).
Nothing changed, in ralation to this bug, in RH 7.3
*** Bug 63913 has been marked as a duplicate of this bug. ***
confirmed as a sawfish issue (work around which works for me is 'killall sawfish; sawfish&'
On my dell laptop : The problem is on apmd resume scripts : while syncing the sys clock, hwclock make the left button mouse dysfunction We can reproduce the the problem with "date" or "setclock" commands too, providing an anterior date. This bug is really annoying !! I haven't tried to recompile the kernel.
agreed, sawfish was a red herring, switching window managers didn't help
*** Bug 64466 has been marked as a duplicate of this bug. ***
Thinkpad 600E notebook. RH 7.3: apmd, XFree 4 (neomagic), WindowMaker The same problem after apm -s / resume or pressing 'suspend' button on notebook. Restarting WindowMaker does not help.
Workaround: in /etc/sysconfig/apmd set CLOCK_SYNC="no", this cures the problem for me - I can live without my clock getting synced
Thanks! FYI: bug #65407 looks similar
*** Bug 65407 has been marked as a duplicate of this bug. ***
No thanks ! What can i do when my laptops (dell and compaq) resume whith wrong time and date ! When i sync the sys date to the hw date, the mouse goes crazy. may be a path : sometimes this method can help. One suppose the date is 06061200 (hardware clock). The resume state shows 06061430. # hwclock --hctosys # date 06061430 # hwclock --hctosys nota : when i enter the date command, my X11 screen seems to do dpms things.
I can confirm the above effects on my IBM TP R30, RH 7.3. The effect was not present in RH 7.2. Without X11 (init state 3), the mouse events in gpm are OK after suspend, which is indeed hinting at the 4.2.0 X server rather than the kernel. One thing to note: the X server's timer is screwed up after suspend. This has the effects the first comment describes. If you do a ButtonPress and move (a.k.a. dragging, like when movin a window), usually the X server generates a ButtonPress , several MotionNotify and finally a ButtonRelease event. Now, after the timer being screwed up, I noticed a different order: first no ButtonPress event, then the usual MotionNotify's, and on release the ButtonPress *and* ButtonRelease event. The corresponding xev log is this: MotionNotify event, serial 22, synthetic NO, window 0x1a00001, root 0x3a, subw 0x0, time 2150638522, (145,153), root:(175,215), state 0x0, is_hint 0, same_screen YES MotionNotify event, serial 22, synthetic NO, window 0x1a00001, root 0x3a, subw 0x0, time 2150638522, (145,152), root:(175,214), state 0x0, is_hint 0, same_screen YES ButtonPress event, serial 22, synthetic NO, window 0x1a00001, root 0x3a, subw 0x0, time 2150638522, (145,152), root:(175,214), state 0x0, button 1, same_screen YES ButtonRelease event, serial 22, synthetic NO, window 0x1a00001, root 0x3a, subw 0x0, time 2150638522, (145,152), root:(175,214), state 0x100, button 1, same_screen YES Note that the time-in-ms is always the same, so X's internal timer is screwed up. That's probably the reason for the wrong event order. Before suspend, the event order is correct and the timer is ever increasing, as expected. (Funny thing is, event order is always fine for Button2, but not Button1 or 3. Probably a race condition).
mharris, is there any more information you would need? Anything else we can try?
If the time goes backward at all on the machine, X is hosed.
Why backward? Assuming GMT+0 timezone, by waking up from sleep the system time does a step forward, because the system time didn't advance in sleep mode whereas the hwclock did. Timezone offsets may make the matter more complicated, depending on when the timezone is taken into account. If the hwclock does not honor the TZ which then has be by adjusted by the system, the there actuelly may be a short period when the time has gone backwards. But this sounds like a general X issue, whereas the problem of this bug was (at least in my case) introduced by RH 7.3 and was definitely no present in RH 7.2.
Experimented the same problems on a Dell Inspiron 4100 with RH 7.3/XFree 4.2.0. I will add my guesses to nils_un comments : - by default the X server connects to "/dev/apm" in order to some clean up job before/after suspend (lnx_apm.c) - this option is on by default (option "NoPM" "no" by default) - when resuming, the X server is waken 'too fast', i.e. prior to apmscript finishing his job - so before the apmcontinue has performed its hwclock job, the XServer will peek an incorrect time, and will be stuck with it as long as the wallclock hasn't catched up with it (the difference is 7200 secs on my machine, just the delta from my timezone to UTC) This may explain why some application relying on the 'time' set in XEvent have problems (gtk related ones I guess). The problem seems to disapear (except for keyboard repeat mode ?) if you add Option "NoPM" "yes". But in this case I experimented the same problem with jerky mouse that I had in 4.1.x - the one that forced me to switch back to vt before toying with apm suspend. Another hint could be to have the hardware clock set to UTC time. But this may not be possible if your are using dual boot with another OS. To me, the problem is with APM resuming : when is the system ready ? Currently this should be "after apmd scripts have done their job" Unfortunately, the XFree server doesn't rely on this hypothesis. HTH
After some private mail with pedro on the subject, we both came up with the idea of stopping the X server at suspend and only continuing it in the apmcontinue script after the clock has been synched. This can only be considered a workaround as the real bug resides in XFree. But it works. For the benefit of others, I'll attach my apmcontinue script here. Two things to note: if your're not interested in logging the progress, you can shorten the script substantially. Also, for most laptops there's no reason to distinguish between standby and suspend, which can make the script even shorter. BTW, the reloading of usb-uhci has nothing to do with this bug.
Created attachment 68424 [details] /etc/sysconfig/apm-scripts/apmcontinue to stop X in suspend/standy
I experience the same problems and have seen the same things with xev as Nils Ellmenreich <nils_un@infosun.fmi.uni-passau.de> This only appears in RH 7.3 and not in 7.2! My system is a Dell Inspiron 5000 notebook.
- my remark on option "NoPM" didn't work - Nils' script works fine for me - since kill -SIGSTOP / kill -SIGCONT on the XServer prior and after suspending is a good workaround, this means that the problem remains in the XServer waking up prior the system is really ready to continue (in this case it is stopped until the system clock has been properly set) - I don't need the usb stuff, but I still need a : "kbdrate -r 10 < /dev/console" to restore keyboard repeat (in either X or console mode). I guess we need a mechanism ` la init.d to suspend and wake the system. This will allow more flexibility instead of hacking in one or two scripts (apmcontinue or apmscript).
The apmscript also works for me. Did someone already test to use the Red Hat 7.2 XFree86-* packages on their Red Hat 7.3 system? This might prove that the actual problem is not in something else than XFree. BTW. I reported the problem to XFree also. No response yet, but I don't expect one :-)
Problem confirmed with following setup: IBM T30 w/ Radeon Mobility M7 LW Redhat 7.3 KDE 3.0.0 KDE 3.0.1 KDE 3.0.2 XFree86 4.2.0-8 How to reproduce: 1. Suspend while in X Effects: 1. Causes mouse to double/triple click or something funky. Breaks: 1. Window resize 2. Window move (even Alt-left mouse click) 3. Shade 4. Icon hold-click 5. Highlight text 6. Chromium play sucks (most annoying) I know I didn't provide any help to fix the problem -- just wanted to say, "Hey! Me too!" Thanks for the apmcontinue script. That's a little better than kill. However, SIGKILL didn't always work for me even on my Linux-only GMT based laptop. Go figure... hopefully something can be found soon.
A little more blabbing and then I'll shut up. It's broken on a Toshiba Tecra 8100 too. And basically I provide nothing new here except to modify the steps to reproduce: 1. Run X 2. Execute date with a new time. No need to suspend. Also, the apmcontinue script didn't work. Yes, I did see 'logger' in /var/log/messages. So, the SIGSTOP and SIGCONT were getting executed. Even funnier, I changed the computer clock to non-GMT and vice versa, and this causes a hard crash on my systems when restoring from a suspend. You can sync the disk with SysRq-S, but SysRq-R doesn't get you a terminal -- the system is a goner. Again, this comment did nothing to contribute to the discussion... just chalk up another system and note that hacking these apm scripts will not cleanly fix the problem. Can you open X in DDD? ;-) I admire those guys. PS. While we are on the topic is there a FAQ somewhere that describes why timezones 8 hours *ahead* of GMT is TZ=GMT-8 ? That always struck me as funny. PSS. This bugtracker is going to be full of duplicates in a few weeks when the U.S. goes back to standard time!! HA HA! Poor guys.
I have duplicated this problem on Red Hat Linux 8.0, with the default of XFree86-4.2.0-72, and a Dell Latitude CPx J. Setting the time back causes the PS/2 mouse to fail to respond to anything requiring a "drag" operation - moving a scrollbar, moving windows, etc. However, this problem does NOT affect a USB mouse. It only affects the PS/2 mouse (either as an external mouse or the touchpad, which appear to be treated equally by Linux). I'm not sure if this is helpful or not, but I thought I would comment. The USB mouse is configured per RHL default: Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Device" "/dev/input/mice" Option "Protocol" "IMPS/2" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection The PS/2 mouse (touchpad) is configured as follows: Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "PS/2" Option "Device" "/dev/psaux" Option "ZAxisMapping" "4 5" Option "Emulate3Buttons" "yes" EndSection Hope this helps!
Comment #jeremyp@pobox.com : Running RHL 8.0 on an IBM ThinkPad A30p : I experience the problem on RHL 7.3/8.0 after a suspend/resume cycle both with the internal PS/2 mouse driver (TrackPoint) and with an external USB mouse.
> Did someone already test to use the Red Hat 7.2 > XFree86-* packages on their Red Hat 7.3 system? > This might prove that the actual problem is not > in something else than XFree. I've downgraded the XFree86 packages on my laptop's Red Hat 7.3 installation to those from Red Hat 7.2 updates (XFree86-4.1.0-25 and co.), and the (GlidePointPS/2) trackpad remains useable over suspend/resume cycles. With the 4.2.0 packages I had to log out, restart X and log back in again after a resume. From this I'd conclude that the bug was introduced somewhere between 4.1.0 and 4.2.0. I tried a recent rawhide build (XFree86-4.2.0-65), but that still exhibits the bug. I'm not going to risk upgrading to Red Hat 8.0 until this is resolved, because I'm not sure I'll still be able to downgrade to XFree86 4.1.0.
This bug is the same as bug #77247 Awaiting user to attach files to that report before closing it as a dupe, just so we have more info.
Created attachment 84907 [details] Updated apmcontinue - multiple X servers supported
Since kernel 2.4.18-10, I also had the problem that the screen didn't restore after suspend without the script. This appeared when the script didn't work anymore when I configured multiple X servers (:0 and :1) in gdm.conf I've extended the script to send signals to ALL X servers. Now suspend works OK again.
bruthasj@yahoo.com) Well... for the record, bugzilla did not get filled up with bug reports when the daylight savings time changed.
I've built a set of RPMs based on the XFree86-4.2.0-8 distribution, with the addition of this patch: http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86Io.c.diff?r1=3.49&r2=3.50 and this seems to resolve the problem. The comment from the commit log for that revision is: 290. Fixed GetTimeInMillis() to use deltas instead of absolute time returend by gettimeofday(). This ensures time is monotonic in X (Egbert Eich). or at least I assume it's that revision. It's part of a single commit containing lots of separate fixes, but the comment looks right. I also don't know if other files were affected by this change. I don't know XFree86's source management strategy well enough to find the original changeset. The good news is that this is on the trunk of the tree heading towards XFree86-4.3, so we can at least hope that things will improve when 4.3 is released. I have binary packages of 4.2.0-8 with this patch that other people could try, but they take up 54Mb and I don't have access to an FTP server with that kind of space free on it.
I've got packages of 4.1.0 for RHL 7.[12], 4.2.1 for 8.0 and CVS XFree86 for rawhide with this already included currently. I do not have packages for 7.3 for testing, nor would it be very easy for me to provide them currently, but if any of the people CC'd on this bug report can confirm that this works for them, I can ensure the fix goes into 7.3 also. Test fix packages are available at: ftp://people.redhat.com/mharris/testing/7.2/XFree86 (for 7.1, 7.2 - get latest build of 4.1.0-43 or later) ftp://people.redhat.com/mharris/testing/8.0/XFree86 (for RHL 8.0, get latest build of 4.2.1-10 or later) Or use the rawhide XFree86 on RHL 8.0 as well. Please give as much feedback of your testing as possible to let me know if this fixes the issues. Thanks.
I've been running with the patched version for over a week and it's working just great; X after a restore which changes the time behaves properly. I'm now seeing occasional complete system lock-ups when restoring (probably one time in every 20) but I don't think this is related.
*** Bug 62678 has been marked as a duplicate of this bug. ***
*** Bug 64782 has been marked as a duplicate of this bug. ***
*** Bug 77189 has been marked as a duplicate of this bug. ***
*** Bug 77064 has been marked as a duplicate of this bug. ***
*** Bug 76126 has been marked as a duplicate of this bug. ***
My test result notes: (1) This appears to fix the loss of key repeat when the clock goes back (can't recall which bug that is). (2) Re: Bug 64782. The behavior has changed but is not fixed. On resume from APM suspend-to-disk, the X screen is completely frozen and does not respond to mouse or keyboard (where I used to be able to move the mouse cursor but not click or keyboard). There is intermittent disk activity (where I don't recall having any before). I can ssh to the machine and see that X has run away and is taking almost 100% of CPU.
So far nothing but good reports back, so I'm closing this bug as fixed in RAWHIDE. After upgrading to the latest release(s) of everything, if people still experience problems, please open new bug reports for them with full details.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2003-067.html