Date: Thu, 5 Feb 2009 13:52:05 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-x11@FreeBSD.org, Serge Shilov <serguei.shilov@gmail.com>, Peter Zehm <Peter.Zehm@crush-net.de> Cc: rnoland@FreeBSD.org, marcus@FreeBSD.org, freebsd-gnome@FreeBSD.org, bug-followup@freebsd.org Subject: Re: ports/131124: x11/xorg - New xorg 7.4 hangs until mouse is moved when AllowEmptyInput turned off Message-ID: <200902051352.08132.jkim@FreeBSD.org> In-Reply-To: <200902051650.n15Go2Ob074222@freefall.freebsd.org> References: <200902051650.n15Go2Ob074222@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[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@gmail.com> > To: bug-followup@freebsd.org, > xelah-freebsd-pr@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200902051352.08132.jkim>