X pausing until mouse move (collecting commonalities)
Joe Marcus Clarke
marcus at FreeBSD.org
Fri Mar 28 09:43:13 PDT 2008
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=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?
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
--
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20080328/26ef3aef/attachment.pgp
More information about the freebsd-x11
mailing list