X pauses until mouse is moved (SOLVED!)

[Coleman Kane]

Joe Marcus Clarke wrote:
> 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
>   
I realized this after I got the accessibility issue resolved. I stopped 
moused and told Xorg to use /dev/psm0 instead and now I no longer have 
the "input waits for mouse" bug either. Seems to be some sort of moused 
vs. hald interaction?

--
Coleman