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

Joe Marcus Clarke marcus at freebsd.org
Fri Feb 6 13:52:59 PST 2009

Jung-uk Kim wrote:
> [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?

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?


Joe Marcus Clarke
FreeBSD GNOME Team	::	gnome at FreeBSD.org
FreeNode / #freebsd-gnome

More information about the freebsd-x11 mailing list