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
--
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
More information about the freebsd-x11
mailing list