Bug 63509 - mouse event problems after system standby
Summary: mouse event problems after system standby
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
: 62678 63913 64466 65407 76126 77064 77189 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-15 09:03 UTC by Thomas M Steenholdt
Modified: 2007-04-18 16:42 UTC (History)
19 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-12-27 01:45:06 UTC
Embargoed:


Attachments (Terms of Use)
/etc/sysconfig/apm-scripts/apmcontinue to stop X in suspend/standy (1.53 KB, text/plain)
2002-08-02 07:53 UTC, Nils
no flags Details
Updated apmcontinue - multiple X servers supported (1.82 KB, text/plain)
2002-11-13 20:49 UTC, Bas Mevissen
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:067 0 high SHIPPED_LIVE : Updated XFree86 packages provide security and bug fixes 2003-06-25 04:00:00 UTC

Description Thomas M Steenholdt 2002-04-15 09:03:22 UTC
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.

Comment 1 Mike A. Harris 2002-04-15 17:09:33 UTC
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.


Comment 2 Thomas M Steenholdt 2002-04-15 21:14:02 UTC
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

Comment 3 Mark J. Cox 2002-05-03 07:35:07 UTC
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).

Comment 4 Thomas M Steenholdt 2002-05-08 10:47:33 UTC
Nothing changed, in ralation to this bug, in RH 7.3

Comment 5 Thomas M Steenholdt 2002-05-08 10:50:12 UTC
*** Bug 63913 has been marked as a duplicate of this bug. ***

Comment 6 Mark J. Cox 2002-05-10 16:59:28 UTC
confirmed as a sawfish issue (work around which works for me is 'killall
sawfish; sawfish&'

Comment 7 nicolas ferragu 2002-05-27 09:11:01 UTC
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.


Comment 8 Mark J. Cox 2002-05-27 09:31:13 UTC
agreed, sawfish was a red herring, switching window managers didn't help

Comment 9 Mark J. Cox 2002-05-27 09:37:01 UTC
*** Bug 64466 has been marked as a duplicate of this bug. ***

Comment 10 Need Real Name 2002-06-03 09:23:14 UTC
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.

Comment 11 Mark J. Cox 2002-06-03 09:27:41 UTC
Workaround: in /etc/sysconfig/apmd set CLOCK_SYNC="no", this cures the problem
for me - I can live without my clock getting synced

Comment 12 Need Real Name 2002-06-03 09:55:40 UTC
Thanks!
FYI: bug #65407 looks similar

Comment 13 Mark J. Cox 2002-06-03 10:01:14 UTC
*** Bug 65407 has been marked as a duplicate of this bug. ***

Comment 14 nicolas ferragu 2002-06-06 07:41:35 UTC
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.




Comment 15 Nils 2002-06-18 08:16:07 UTC
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).

Comment 16 Nils 2002-07-04 18:07:27 UTC
mharris, is there any more information you would need? Anything else we can try?

Comment 17 Mike A. Harris 2002-07-24 19:11:45 UTC
If the time goes backward at all on the machine, X is hosed.

Comment 18 Nils 2002-07-26 14:06:17 UTC
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.

Comment 19 pedro_rodriguez 2002-07-28 10:30:32 UTC
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

Comment 20 Nils 2002-08-02 07:51:48 UTC
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.

Comment 21 Nils 2002-08-02 07:53:18 UTC
Created attachment 68424 [details]
/etc/sysconfig/apm-scripts/apmcontinue to stop X in suspend/standy

Comment 22 Bas Mevissen 2002-08-11 14:35:04 UTC
I experience the same problems and have seen the same things with xev as Nils 
Ellmenreich <nils_un.uni-passau.de>

This only appears in RH 7.3 and not in 7.2!

My system is a Dell Inspiron 5000 notebook.



Comment 23 pedro_rodriguez 2002-08-13 10:02:53 UTC
- 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).

Comment 24 Bas Mevissen 2002-08-13 20:55:35 UTC
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 :-)



Comment 25 Jeff Pitman 2002-09-16 14:49:54 UTC
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.

Comment 26 Jeff Pitman 2002-09-16 15:28:04 UTC
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.

Comment 27 Jeremy Portzer 2002-10-29 01:50:43 UTC
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 28 Didier 2002-10-29 08:28:15 UTC
Comment #jeremyp :

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.



Comment 29 Mark Wilkinson 2002-10-29 10:07:10 UTC
> 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.

Comment 30 Mike A. Harris 2002-11-04 08:58:44 UTC
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.

Comment 31 Bas Mevissen 2002-11-13 20:49:35 UTC
Created attachment 84907 [details]
Updated apmcontinue - multiple X servers supported

Comment 32 Bas Mevissen 2002-11-13 20:52:29 UTC
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.

Comment 33 Mike A. Harris 2002-11-25 15:55:04 UTC
bruthasj) Well... for the record, bugzilla did not get filled
up with bug reports when the daylight savings time changed.



Comment 35 Mark Wilkinson 2002-11-26 16:49:02 UTC
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.

Comment 36 Mike A. Harris 2002-12-19 09:58:09 UTC
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.

Comment 37 Mark J. Cox 2002-12-19 10:06:17 UTC
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.

Comment 38 Mike A. Harris 2002-12-19 10:07:00 UTC
*** Bug 62678 has been marked as a duplicate of this bug. ***

Comment 39 Mike A. Harris 2002-12-19 10:11:10 UTC
*** Bug 64782 has been marked as a duplicate of this bug. ***

Comment 40 Mike A. Harris 2002-12-19 11:12:25 UTC
*** Bug 77189 has been marked as a duplicate of this bug. ***

Comment 41 Mike A. Harris 2002-12-19 11:17:15 UTC
*** Bug 77064 has been marked as a duplicate of this bug. ***

Comment 42 Mike A. Harris 2002-12-19 11:44:25 UTC
*** Bug 76126 has been marked as a duplicate of this bug. ***

Comment 43 Matthew Saltzman 2002-12-19 15:36:41 UTC
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.

Comment 44 Mike A. Harris 2002-12-27 01:45:06 UTC
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.

Comment 45 Mike A. Harris 2003-01-26 09:34:28 UTC
*** Bug 77189 has been marked as a duplicate of this bug. ***

Comment 46 Mike A. Harris 2003-07-01 23:20:58 UTC
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



Note You need to log in before you can comment on or make changes to this bug.