X pausing until mouse move (collecting commonalities)

[Jung-uk Kim]

On Friday 28 March 2008 12:43 pm, Joe Marcus Clarke wrote:
> On Fri, 2008-03-28 at 12:19 -0400, Coleman Kane wrote:
> > 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=47eb658e
> > >>>>802775021e3efec109f95431cca188ca
> > >>>>
> > >>>> 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?
>
> I'm trying to get with flz so that he can commit the xorg-server
> part. I will commit the hal patch soon.  I don't think a PR is
> necessary this point.  We're close to having all the players on
> board already.

Joe,

I am trying to fix 'everything is sysmouse' problem in bsd_mouse.c.  
You (or flz) can go ahead and commit the hal.c patch but I don't want 
two revision bumps.  I will post bsd_mouse.c patch when I am done 
with testing.

Thanks,

Jung-uk Kim