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

[Jung-uk Kim]

[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