X pausing until mouse move (collecting commonalities)

[Joe Marcus Clarke]

Jung-uk Kim wrote:
> On Thursday 27 March 2008 01:15 pm, 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.
>> /dev/sysmouse is a special case and it is done in OS-dependent
>> code. HAL support code in xorg-server is OS-independent naturally. 
>> Thus it does not care if it is pointing to the same /dev/sysmouse. 
>> Is there any way to set it disabled when moused is running instead
>> of replacing the device node with /dev/sysmouse?
> 
> I guess you can set "info.ignore"?  Or maybe you can save list of 
> devices controlled by moused, e.g., something like this in shell:
> 
> pgrep moused | xargs -L 1 ps -p | grep /dev/ | \
> sed -e 's/.*moused.*-p.*\/dev\///g' | awk '{ print $1 }'

I thought about using info.ignore, but in looking at the X code and the 
hal code, I do not think this will work.

> 
> I guess you can do better with glib's string manipulation functions.  
> Then toggle "info.ignore" depending on the owner of /dev/sysmouse.  
> Oh, the owner is Xorg, not moused, BTW. ;-)

If I check to see if the mouse is owned by Xorg, then hal will start, 
and the addon will run and see that the mouse is unowned.  Then, X will 
start, and it will grab the mouse twice still.  At least that's what 
I've gleaned from the code.  I'll have more time to test things later 
tonight.

Joe

-- 
Joe Marcus Clarke
FreeBSD GNOME Team	::	gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome