X pausing until mouse move (collecting commonalities)

[Coleman Kane]

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?

--
Coleman