From owner-freebsd-x11@FreeBSD.ORG Thu Feb 5 18:52:20 2009 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 6AEDB106566C; Thu, 5 Feb 2009 18:52:19 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-x11@FreeBSD.org, Serge Shilov , Peter Zehm Date: Thu, 5 Feb 2009 13:52:05 -0500 User-Agent: KMail/1.6.2 References: <200902051650.n15Go2Ob074222@freefall.freebsd.org> In-Reply-To: <200902051650.n15Go2Ob074222@freefall.freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200902051352.08132.jkim@FreeBSD.org> 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 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 18:52:21 -0000 [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 > 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: on > uhub0 ums0: 8 buttons and Z dir. > > and the 2nd is > ums0: 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