Date: Sat, 7 Feb 2009 00:30:09 GMT From: Robert Noland <rnoland@FreeBSD.org> To: freebsd-x11@FreeBSD.org Subject: Re: ports/131124: x11/xorg - New xorg 7.4 hangs until mouse is moved when AllowEmptyInput turned off Message-ID: <200902070030.n170U97F039087@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/131124; it has been noted by GNATS.
From: Robert Noland <rnoland@FreeBSD.org>
To: Joe Marcus Clarke <marcus@freebsd.org>
Cc: Jung-uk Kim <jkim@freebsd.org>, freebsd-x11@freebsd.org,
Serge Shilov <serguei.shilov@gmail.com>,
Peter Zehm <Peter.Zehm@crush-net.de>, freebsd-gnome@freebsd.org,
bug-followup@freebsd.org
Subject: Re: ports/131124: x11/xorg - New xorg 7.4 hangs until mouse is
moved when AllowEmptyInput turned off
Date: Fri, 06 Feb 2009 19:21:18 -0500
--=-ochrBuFLMmqqvqx+Zp/J
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Fri, 2009-02-06 at 16:27 -0500, Joe Marcus Clarke wrote:
> Jung-uk Kim wrote:
> > [Sorry for spamming y'all but I thought it is very important that=20
> > everyone understands the situation clearly.]
> >=20
> > On Thursday 05 February 2009 11:50 am, Serge Shilov wrote:
> >> The following reply was made to PR ports/131124; it has been noted
> >> by GNATS.
> >>
> >> From: Serge Shilov <serguei.shilov@gmail.com>
> >> To: bug-followup@freebsd.org,
> >> xelah-freebsd-pr@xelah.com
> >> Cc:
> >> Subject: Re: ports/131124: x11/xorg - New xorg 7.4 hangs until
> >> mouse is moved when AllowEmptyInput turned off Date: Thu, 5 Feb
> >> 2009 19:40:29 +0300
> >>
> >> I perform some experiments. Results is here.
> >>
> >> I. Test other mice .
> >> The 1st is
> >> ums0: <A4Tech RF USB Mouse, class 0/0, rev 1.10/0.01, addr 2> on
> >> uhub0 ums0: 8 buttons and Z dir.
> >>
> >> and the 2nd is
> >> ums0: <Logitech Optical USB Mouse, class 0/0, rev 2.00/3.40, addr
> >> 2> on uhub0 ums0: 3 buttons and Z dir.
> >>
> >> Bug still exist
> >>
> >> II. Test direct connection mouse without hub.
> >>
> >> Bug still exist.
> >>
> >> Resume: It's not mice or hub or connection-via-hub problem. (But
> >> it may be some usb host problem)
> >>
> >> III. Hot plug out and plug in mouse in X environment
> >>
> >> After plug in mouse gehaviour BEGAN CONVENTIONAL. This can be
> >> recommended as workaround.
> >>
> >> Notice:
> >> 1. After plug out mouse cursor may still disappeared. In this case
> >> you can switch to VT0-VT7 terminals, move mouse and switch back to
> >> X session. 2. This advice is provided 'as is' without any
> >> warranties of usefulness, capacity to work with your hardware or
> >> software and other sorts of warranties.
> >>
> >> IV. After hot X session restart (without OS and hardware restart)
> >> mouse still work.
> >>
> >> V. Other cases:
> >> Hot plug out and plug in mouse in text mode environment before
> >> start X session.
> >> Start OS mouseless and plug in mouse before or after start X
> >> session. Hot OS restart after my workaround appliing.
> >>
> >> In all this cases mouse behaviour was still buggy.
> >>
> >> I'll be glad if my info help to resolve this problem.
> >=20
> >=20
> > A short answer:
> >=20
> > Please remove "AllowEmptyInput" from your xorg.conf.
> >=20
> > A longer answer:
> >=20
> > http://docs.freebsd.org/cgi/mid.cgi?200902041908.50270.jkim
> >=20
> > A technical answer:
> >=20
> > Some devices are safe to be opened multiple times and shared by=20
> > different input drivers (e.g., Linux evdev, I think) and some devices=20
> > are not (e.g., our sysmouse).
> >=20
> > Possible solutions (for ports maintainers):
> >=20
> > - When hald probes mice, exclude all moused users=20
> > (e.g., /dev/psm0, /dev/ums1, ...) from x11_driver and create a pseudo=20
> > device UDI for /dev/sysmouse and set x11_driver property if moused(8)=20
> > is running and /dev/sysmouse is not being used by Xserver. If=20
> > Xserver tries to open /dev/sysmouse, then the UDI has to be removed=20
> > immediately. When Xserver closes /dev/sysmouse, the fake UDI has to=20
> > be restored immediately.
> >=20
> > - Before Xserver starts auto-adding process, send a hint message to=20
> > hald that the device is configured and enabled by static user=20
> > configuration if CONFIG_HAL is defined and "AutoAddDevices" or=20
> > "AutoEnableDevices" is on. hald (i.e., FreeBSD mouse prober)=20
> > excludes all sysmouse users from x11_driver and sends ACK/NACK=20
> > message. Then, Xserver continues/stops auto-adding process depending=20
> > on it.
> >=20
> > - Implement an ioctl command for sysmouse to report actual devices=20
> > that it is controlling. Let each input driver veto automagic=20
> > configuration process if it is being used or unsafe.
> >=20
> > - Some combinations of the above...
> >=20
> > The first solution is the least intrusive but it is not bulletproof=20
> > because of an unavoidable race condition. The second solution is=20
> > IMHO, a correct way but it requires Xserver change first. The third=20
> > solution is too platform-specific and it requires significant (and=20
> > ugly) hacks for Xserver and input drivers, I think.
> >=20
> > Any more ideas?
>=20
> What about modifying the sysmouse driver to more gracefully handle
> multiple open attempts (e.g. fail on subsequent attempts). What effect
> would that have on X?
I think X would be fine with that... That is what happens now with the
psm and ums devices. At least if they are statically configured and
hald is in use.
robert.
> Joe
>=20
> --=20
> Joe Marcus Clarke
> FreeBSD GNOME Team :: gnome@FreeBSD.org
> FreeNode / #freebsd-gnome
> http://www.FreeBSD.org/gnome
--=20
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
--=-ochrBuFLMmqqvqx+Zp/J
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (FreeBSD)
iEYEABECAAYFAkmM0/4ACgkQM4TrQ4qfRONEVQCfcZutylPs/0YhQVEdL8SOCx5O
UGcAn2uxIBkjjxyX42fLq4L4fzH5P7c8
=Koy1
-----END PGP SIGNATURE-----
--=-ochrBuFLMmqqvqx+Zp/J--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200902070030.n170U97F039087>