X pausing until mouse move (collecting commonalities)

Coleman Kane cokane at FreeBSD.org
Fri Mar 28 09:24:14 PDT 2008


Joe Marcus Clarke wrote:
> On Fri, 2008-03-28 at 09:02 -0400, Coleman Kane wrote:
>   
>> Joe Marcus Clarke wrote:
>>     
>>> On Thu, 2008-03-27 at 19:08 -0400, Jung-uk Kim wrote:
>>>   
>>>       
>>>> On Thursday 27 March 2008 12:44 pm, Joe Marcus Clarke wrote:
>>>>     
>>>>         
>>>>> Coleman Kane wrote:
>>>>>       
>>>>>           
>>>>>> Coleman Kane wrote:
>>>>>>         
>>>>>>             
>>>>>>> Joe Marcus Clarke wrote:
>>>>>>>           
>>>>>>>               
>>>>>>>> On Wed, 2008-03-26 at 16:54 -0400, Jung-uk Kim wrote:
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> On Wednesday 26 March 2008 12:50 pm, Joe Marcus Clarke wrote:
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>>> I'm trying to get a list of commonalities to better focus my
>>>>>>>>>> troubleshooting.  So far, my two machines that are affected
>>>>>>>>>> have the following in common:
>>>>>>>>>>
>>>>>>>>>> GNOME 2.22 (with hald)
>>>>>>>>>> nVidia graphics card (though different drivers)
>>>>>>>>>> PS/2 mouse
>>>>>>>>>> dual core
>>>>>>>>>> ULE scheduler
>>>>>>>>>>
>>>>>>>>>> My one machine that is not affected differs from this in that
>>>>>>>>>> it has an Intel graphics card, USB mouse, and is not dual
>>>>>>>>>> core (but HTT).
>>>>>>>>>>
>>>>>>>>>> It looks like Coleman has a PS/2 mouse as well.  It's
>>>>>>>>>> starting to look like the mouse technology might have
>>>>>>>>>> something to do with this.  Anyone seeing this problem with a
>>>>>>>>>> USB mouse?
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>> I think I know why.  Build xorg-server without HAL support
>>>>>>>>> option and the attached patch.  With HAL support (default) and
>>>>>>>>> hald running, xorg-server auto-detects individual ports with
>>>>>>>>> input.mouse capability even without configuration lines in
>>>>>>>>> xorg.conf.  If moused is enabled and USB mouse is used,
>>>>>>>>> /dev/ums0 is directly used because there is a problem in MD
>>>>>>>>> code (see attached patch).  If moused is enabled and PS/2
>>>>>>>>> mouse is used, you end up with two input devices via
>>>>>>>>> /dev/sysmouse and /dev/psm0.  I couldn't find a cleaner way to
>>>>>>>>> fix this problem, though. :-(
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> Thanks for finding this.  Here is a patch for hal which adds a
>>>>>>>> mouse addon.  The mouse addon polls to find whether or not
>>>>>>>> moused has a given mouse device open.  If it does, it sets the
>>>>>>>> input device to be /dev/sysmouse instead of the actual device. 
>>>>>>>> Hopefully it will fix the problem without needing to disable
>>>>>>>> hal support in X.  I have also merged your gettimeofday
>>>>>>>> patches, jkim.
>>>>>>>>
>>>>>>>> http://www.marcuscom.com/downloads/hal.diff
>>>>>>>>
>>>>>>>> Joe
>>>>>>>>             
>>>>>>>>                 
>>>>>>> I had to apply the attached change to your patch in order to get
>>>>>>> it to work (addon/ should be addons/). Attached is the diff to
>>>>>>> your diff that worked for me.
>>>>>>>
>>>>>>> --
>>>>>>> Coleman Kane
>>>>>>>           
>>>>>>>               
>>>>>> Unfortunately, I still experience the same mouse-blocked behavior
>>>>>> after applying this patch, reinstalling the port, and then
>>>>>> restarting my machine (and setting the mouse device back to
>>>>>> SysMouse and /dev/sysmouse in xorg.conf, and re-enabling moused).
>>>>>>         
>>>>>>             
>>>>> Yeah.  While the addon is doing its job, X now opens two instances
>>>>> of /dev/sysmouse :-(.  I still don't know why it does this when it
>>>>> doesn't open two instances of /dev/psm0.
>>>>>       
>>>>>           
>>>> I found why.  See config/hal.c in xorg-server.  It does not add Option
>>>> "Device" although Linux-specific and undocumented Option "Path" for
>>>> evdev is added.  Thus default mouse device /dev/sysmouse is picked up.
>>>> Fortunately the bug is fixed in the latest version with the following
>>>> commit:
>>>>
>>>> http://cgit.freedesktop.org/xorg/xserver/commit/?id=47eb658e802775021e3efec109f95431cca188ca
>>>>
>>>> This chunk:
>>>>
>>>> ---------
>>>> +   /* most drivers use device.. not path. evdev uses both however, but the
>>>> +    * path version isn't documented apparently. support both for now. */
>>>>     add_option(&options, "path", path);
>>>> +   add_option(&options, "device", path);
>>>> ---------
>>>>
>>>> See the attached patches.
>>>>     
>>>>         
>>> Ah, this explains a lot.  I have also updated my hal.diff with your
>>> correction, and some code to make sure that the mouse device is correct
>>> when moused is running.  Local tests indicate that it should do the job.
>>>
>>> Joe
>>>   
>>>       
>> So, does this mean we should upgrade the sysutils/hald port (and other 
>> related ones) again? Is this in a released version?
>>     
>
> Apply http://www.marcuscom.com/downloads/hal.diff and
> http://people.freebsd.org/~jkim/xorg-server.diff then rebuild hal and
> xorg-server.  Then reboot.  All should be well again with moused/hal/X.
>
> Joe
>   
Thanks,

If we submit a PR on this, to fix the problem, is there a version of 
hald that's released which already has the fix, or should we just submit 
a PR with patches to both ports?

--
Coleman




More information about the freebsd-x11 mailing list