X pauses until mouse is moved (SOLVED!)

[Kevin Oberman]

> From: Joe Marcus Clarke <marcus at FreeBSD.org>
> Date: Tue, 25 Mar 2008 22:52:38 -0400
> 
> On Tue, 2008-03-25 at 22:25 -0400, Coleman Kane wrote:
> > Coleman Kane wrote:
> > > Kevin Oberman wrote:
> > >>> From: Joe Marcus Clarke <marcus at FreeBSD.org>
> > >>> Date: Tue, 25 Mar 2008 12:07:00 -0400
> > >>> Sender: owner-freebsd-x11 at freebsd.org
> > >>>
> > >>> This problem was originally reported on this list on March 5
> > >>> (http://lists.freebsd.org/pipermail/freebsd-x11/2008-March/006077.html). 
> > >>>
> > >>> I am now seeing this on my RELENG_7 and -CURRENT boxes.  Basically, all
> > >>> interaction with X is temporarily suspended until the mouse is moved.
> > >>> This only occurs when using /dev/sysmouse (thus when moused is 
> > >>> enabled).
> > >>> If I disabled moused, and use /dev/psm0 directly, the problem goes 
> > >>> away.
> > >>>
> > >>> My i386 RELENG_7 machine was working fine until I updated to:
> > >>>
> > >>> FreeBSD shumai.marcuscom.com 7.0-STABLE FreeBSD 7.0-STABLE #17: Mon Mar
> > >>> 24 15:32:39 EDT 2008
> > >>> marcus at shumai.marcuscom.com:/build/obj/build/src/sys/SHUMAI  i386
> > >>>
> > >>> Prior to that I was running FreeBSD 7.0-STABLE #16: Sat Mar  8 20:07:36
> > >>> EST 2008.
> > >>>
> > >>> Also prior to that I had the xorg-server update that was supposed to 
> > >>> fix
> > >>> jerky mouse movement.  That didn't seem to trigger this problem.  I
> > >>> thought it might have been related to the recent moused fix in 
> > >>> RELENG_7,
> > >>> so I backed out the moused.c changes, but the problem persists.  I also
> > >>> backed out the recent X mouse driver VT switch fix, but the problem
> > >>> persists.
> > >>>
> > >>> At least two other users have described similar problems.  Any
> > >>> suggestions on what may be causing this?  The only difference I spot in
> > >>> dmesg relates to CPU clock speed (off by 1/100 of a MHz).  The working
> > >>> version of FreeBSD had:
> > >>>
> > >>> CPU: Intel(R) Xeon(R) CPU            5140  @ 2.33GHz (2327.52-MHz
> > >>> 686-class CPU)
> > >>>
> > >>> The current version has:
> > >>>
> > >>> CPU: Intel(R) Xeon(R) CPU            5140  @ 2.33GHz (2327.51-MHz
> > >>> 686-class CPU)
> > >>>
> > >>> A full (current) dmesg can be found at
> > >>> http://www.marcuscom.com/downloads/dmesg.shumai .
> > >>>     
> > >>
> > >> I am seeing about the same thing here. My system is running:
> > >> FreeBSD slan.es.net 7.0-STABLE FreeBSD 7.0-STABLE #2: Mon Mar 17 
> > >> 21:39:01 PDT 2008     root at slan.es.net:/usr/obj/usr/src/sys/IBM-T43  
> > >> i386
> > >>
> > >> What is possibly notable is that I only started seeing this problem
> > >> yesterday, right after upgrading to Gnome 2.22. It looks like the Gnome
> > >> upgrade triggered something, possibly an interaction with the moused,
> > >> sysmouse, or xf86-input-mouse.
> > >>
> > >> The system is a T43 using the internal keyboard and TrackPoint(tm).
> > >>
> > >> The Gnome upgrade was pretty smooth with everything building, but
> > >> portupgrade complaining about some dependency loops. (I'll report about
> > >> this to the Gnome list.)
> > >>
> > >> This is more than a bit annoying. It also impacts menus and scroll
> > >> bars. I plan to drop back to my backup from before the Gnome upgrade.
> > >>
> > >> I can make config, xorg.conf, and dmesg available, but I can't see
> > >> anything odd there.
> > >>   
> > > I actually also began experiencing this after the GNOME2 update. Very 
> > > strange.
> > >
> > > -- 
> > > Coleman
> > I figured it out. Try going to System->Preferences->Keyboard Preferences
> > 
> > Then, go to the Accessibility tab and see if the "Only accept long 
> > keypresses" option is checked. If it is, then un-check it. I surmise 
> > that the accessibility options are related to any other input "bugs" 
> > too. I am guessing that these get wormed through dbus, hald, and/or 
> > system-tools-backends.
> > 
> > The annoying thing is I remember going through this hell *last time* I 
> > upgraded GNOME and I had completely forgotten how I fixed it. It's 
> > almost like a cruel joke (at my expense) that one of these accessibility 
> > options gets toggled every time I upgrade GNOME.
> 
> I don't think accessibility is the cause of this.  I had a different
> problem after upgrading one machine to 2.22.  I could not longer type
> into any input field (including gnome-terminal).  Every keystroke would
> result in a beep.  THIS was fixed by disabling accessibility.  The
> problem with the pausing remains.  One user tracked it down to hal.  I
> haven't dug deeper as to why hal would cause this yet.

Joe,

Is it possible that the "jerky mouse" fix is interacting with hald in
some way? It seem like many are updating without this problem and it is
clearly tied to the mouse. 

Just speculation, of course.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080326/5989cb4c/attachment.pgp