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

[Jung-uk Kim]

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

From: Jung-uk Kim <jkim at FreeBSD.org>
To: freebsd-x11 at FreeBSD.org,
 Serge Shilov <serguei.shilov at gmail.com>,
 Peter Zehm <Peter.Zehm at crush-net.de>
Cc: bug-followup at freebsd.org,
 freebsd-gnome at FreeBSD.org,
 marcus at FreeBSD.org,
 rnoland at FreeBSD.org
Subject: Re: ports/131124: x11/xorg - New xorg 7.4 hangs until mouse is moved when AllowEmptyInput turned off
Date: Thu, 5 Feb 2009 13:52:05 -0500

 [Sorry for spamming y'all but I thought it is very important that 
 everyone understands the situation clearly.]
 
 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.
 
 
 A short answer:
 
 Please remove "AllowEmptyInput" from your xorg.conf.
 
 A longer answer:
 
 http://docs.freebsd.org/cgi/mid.cgi?200902041908.50270.jkim
 
 A technical answer:
 
 Some devices are safe to be opened multiple times and shared by 
 different input drivers (e.g., Linux evdev, I think) and some devices 
 are not (e.g., our sysmouse).
 
 Possible solutions (for ports maintainers):
 
 - When hald probes mice, exclude all moused users 
 (e.g., /dev/psm0, /dev/ums1, ...) from x11_driver and create a pseudo 
 device UDI for /dev/sysmouse and set x11_driver property if moused(8) 
 is running and /dev/sysmouse is not being used by Xserver.  If 
 Xserver tries to open /dev/sysmouse, then the UDI has to be removed 
 immediately.  When Xserver closes /dev/sysmouse, the fake UDI has to 
 be restored immediately.
 
 - Before Xserver starts auto-adding process, send a hint message to 
 hald that the device is configured and enabled by static user 
 configuration if CONFIG_HAL is defined and "AutoAddDevices" or 
 "AutoEnableDevices" is on.  hald (i.e., FreeBSD mouse prober) 
 excludes all sysmouse users from x11_driver and sends ACK/NACK 
 message.  Then, Xserver continues/stops auto-adding process depending 
 on it.
 
 - Implement an ioctl command for sysmouse to report actual devices 
 that it is controlling.  Let each input driver veto automagic 
 configuration process if it is being used or unsafe.
 
 - Some combinations of the above...
 
 The first solution is the least intrusive but it is not bulletproof 
 because of an unavoidable race condition.  The second solution is 
 IMHO, a correct way but it requires Xserver change first.  The third 
 solution is too platform-specific and it requires significant (and 
 ugly) hacks for Xserver and input drivers, I think.
 
 Any more ideas?
 
 Jung-uk Kim