X pausing until mouse move (collecting commonalities)

[Jung-uk Kim]

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 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. ;-)

Jung-uk Kim