Date: Fri, 06 Feb 2009 19:21:18 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: Joe Marcus Clarke <marcus@freebsd.org> Cc: freebsd-x11@freebsd.org, freebsd-gnome@freebsd.org, bug-followup@freebsd.org, Serge Shilov <serguei.shilov@gmail.com> Subject: Re: ports/131124: x11/xorg - New xorg 7.4 hangs until mouse is moved when AllowEmptyInput turned off Message-ID: <1233966078.1562.28.camel@ferret.2hip.net> In-Reply-To: <498CAB46.7020408@freebsd.org> References: <200902051650.n15Go2Ob074222@freefall.freebsd.org> <200902051352.08132.jkim@FreeBSD.org> <498CAB46.7020408@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-ochrBuFLMmqqvqx+Zp/J Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-02-06 at 16:27 -0500, Joe Marcus Clarke wrote: > Jung-uk Kim wrote: > > [Sorry for spamming y'all but I thought it is very important that=20 > > everyone understands the situation clearly.] > >=20 > > 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. > >=20 > >=20 > > A short answer: > >=20 > > Please remove "AllowEmptyInput" from your xorg.conf. > >=20 > > A longer answer: > >=20 > > http://docs.freebsd.org/cgi/mid.cgi?200902041908.50270.jkim > >=20 > > A technical answer: > >=20 > > Some devices are safe to be opened multiple times and shared by=20 > > different input drivers (e.g., Linux evdev, I think) and some devices=20 > > are not (e.g., our sysmouse). > >=20 > > Possible solutions (for ports maintainers): > >=20 > > - When hald probes mice, exclude all moused users=20 > > (e.g., /dev/psm0, /dev/ums1, ...) from x11_driver and create a pseudo=20 > > device UDI for /dev/sysmouse and set x11_driver property if moused(8)=20 > > is running and /dev/sysmouse is not being used by Xserver. If=20 > > Xserver tries to open /dev/sysmouse, then the UDI has to be removed=20 > > immediately. When Xserver closes /dev/sysmouse, the fake UDI has to=20 > > be restored immediately. > >=20 > > - Before Xserver starts auto-adding process, send a hint message to=20 > > hald that the device is configured and enabled by static user=20 > > configuration if CONFIG_HAL is defined and "AutoAddDevices" or=20 > > "AutoEnableDevices" is on. hald (i.e., FreeBSD mouse prober)=20 > > excludes all sysmouse users from x11_driver and sends ACK/NACK=20 > > message. Then, Xserver continues/stops auto-adding process depending=20 > > on it. > >=20 > > - Implement an ioctl command for sysmouse to report actual devices=20 > > that it is controlling. Let each input driver veto automagic=20 > > configuration process if it is being used or unsafe. > >=20 > > - Some combinations of the above... > >=20 > > The first solution is the least intrusive but it is not bulletproof=20 > > because of an unavoidable race condition. The second solution is=20 > > IMHO, a correct way but it requires Xserver change first. The third=20 > > solution is too platform-specific and it requires significant (and=20 > > ugly) hacks for Xserver and input drivers, I think. > >=20 > > Any more ideas? >=20 > 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? I think X would be fine with that... That is what happens now with the psm and ums devices. At least if they are statically configured and hald is in use. robert. > Joe >=20 > --=20 > Joe Marcus Clarke > FreeBSD GNOME Team :: gnome@FreeBSD.org > FreeNode / #freebsd-gnome > http://www.FreeBSD.org/gnome --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD --=-ochrBuFLMmqqvqx+Zp/J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEABECAAYFAkmM0/4ACgkQM4TrQ4qfRONEVQCfcZutylPs/0YhQVEdL8SOCx5O UGcAn2uxIBkjjxyX42fLq4L4fzH5P7c8 =Koy1 -----END PGP SIGNATURE----- --=-ochrBuFLMmqqvqx+Zp/J--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1233966078.1562.28.camel>