From owner-freebsd-x11@FreeBSD.ORG Fri Feb 6 21:52:58 2009 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0BEF1065670; Fri, 6 Feb 2009 21:52:58 +0000 (UTC) (envelope-from marcus@freebsd.org) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.freebsd.org (Postfix) with ESMTP id A424C8FC18; Fri, 6 Feb 2009 21:52:58 +0000 (UTC) (envelope-from marcus@freebsd.org) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n16LRgld005683; Fri, 6 Feb 2009 16:27:42 -0500 (EST) Received: from [64.102.220.135] (dhcp-64-102-220-135.cisco.com [64.102.220.135]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n16LRV7a023123; Fri, 6 Feb 2009 16:27:37 -0500 (EST) Message-ID: <498CAB46.7020408@freebsd.org> Date: Fri, 06 Feb 2009 16:27:34 -0500 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jung-uk Kim References: <200902051650.n15Go2Ob074222@freefall.freebsd.org> <200902051352.08132.jkim@FreeBSD.org> In-Reply-To: <200902051352.08132.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org, freebsd-gnome@freebsd.org, bug-followup@freebsd.org, Serge Shilov 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: Fri, 06 Feb 2009 21:52:59 -0000 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 >> 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? 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@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome