ports/131124: x11/xorg - New xorg 7.4 hangs until mouse is moved when AllowEmptyInput turned off

[Robert Noland]

The following reply was made to PR ports/131124; it has been noted by GNATS.

From: Robert Noland <rnoland at FreeBSD.org>
To: Joe Marcus Clarke <marcus at freebsd.org>
Cc: Jung-uk Kim <jkim at freebsd.org>, freebsd-x11 at freebsd.org,
        Serge Shilov <serguei.shilov at gmail.com>,
        Peter Zehm <Peter.Zehm at crush-net.de>, freebsd-gnome at freebsd.org,
        bug-followup at 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 at gmail.com>
 > >> To: bug-followup at freebsd.org,
 > >>  xelah-freebsd-pr at 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 at FreeBSD.org
 > FreeNode / #freebsd-gnome
 > http://www.FreeBSD.org/gnome
 --=20
 Robert Noland <rnoland at 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--