X pauses until mouse is moved (SOLVED!)

Coleman Kane cokane at FreeBSD.org
Tue Mar 25 19:30:22 PDT 2008


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.

--
Coleman Kane



More information about the freebsd-x11 mailing list