Summary: | x11-servers/xorg-server update breaks scroll wheel support on mouse | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | L. S. Colby <ls.colby> | ||||
Component: | Individual Port(s) | Assignee: | Jung-uk Kim <jkim> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | henrik | ||||
Priority: | Normal | ||||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
L. S. Colby
2008-04-03 11:10:02 UTC
Responsible Changed From-To: freebsd-ports-bugs->freebsd-x11 Over to maintainer (via the GNATS Auto Assign Tool) ls.colby@gwirynybyd.com wrote on Thu, 03 Apr 2008 12:03:07 +0200 (CEST): > After portupgrade to xorg-server and reboot mouse wheel no longer worked for scrolling in X on any application. GPM is disabled for non -X applications Same here. The magic delta (seen here identically) appears to be: 846,847c846,847 < (II) Mouse0: SetupAuto: hw.iftype is 3, hw.model is 4 < (II) Mouse0: SetupAuto: protocol is SysMouse --- > (II) Mouse0: SetupAuto: hw.iftype is 3, hw.model is 0 > (II) Mouse0: SetupAuto: protocol is PS/2, level is 0 Apparently mouse type detection is broken. I don't use moused. I've compiled xorg-server from ports, using the default OPTIONS - which includes support for HAL. However I have not installed HAL. Maybe it is worth testing with HAL support disabled. (Haven't done that.) Helge ls.colby@gwirynybyd.com wrote on Thu, 03 Apr 2008 12:03:07 +0200 (CEST): > After portupgrade to xorg-server and reboot mouse wheel no longer worked for scrolling in X on any application. GPM is disabled for non -X applications Same here. The magic delta (seen here identically) appears to be: 846,847c846,847 < (II) Mouse0: SetupAuto: hw.iftype is 3, hw.model is 4 < (II) Mouse0: SetupAuto: protocol is SysMouse --- > (II) Mouse0: SetupAuto: hw.iftype is 3, hw.model is 0 > (II) Mouse0: SetupAuto: protocol is PS/2, level is 0 Apparently mouse type detection is broken. I don't use moused. I've compiled xorg-server from ports, using the default OPTIONS - which includes support for HAL. However I have not installed HAL. Maybe it is worth testing with HAL support disabled. (Haven't done that.) Helge I can confirm this issue on a system with HAL disabled for all ports using ums0 and the following in /etc/rc.conf: moused_enable="NO" moused_nondefault_enable="NO" I would like to also point out that even if I force the correct protocol to SysMouse from auto, the mouse wheel is non-functional. In my case, almost all mouse movements and buttons are mapped to button 5 as noted by xev. Sean -- scf@FreeBSD.org Same problem here. I have found a quite dirty temporary solution : removing the patch file x11-servers/xorg-server/files/patch-Xserver-hw-xfree86-os-support-bsd-bsd_mouse.c. The problem seems to be linked to the sysmouse handling stuff contained in this patch. I hope this will help people until maintainers correct the patch file. -- Christophe E. Found trouble in x11-servers/xorg-server/files/patch-Xserver-hw-xfree86-os-support-bsd-bsd_mouse.c. patch. It was add 1 check what mouse driver are we using. + if ((dev = xf86FindOptionValue(pInfo->options, "Device")) && + !strcmp(dev, DEFAULT_SYSMOUSE_DEV)) { + i = 1; + ioctl(pInfo->fd, MOUSE_SETLEVEL, &i); + } BUT if we're using another driver MOUSE_SETLEVEL stays undefined. I commented those check and got wellworking mouse wheel. Resolve: or disable those check or add else state where set another value. according psm.c (kernel src) it can take 3 values: 0 (PSM_LEVEL_BASE ), 1(PSM_LEVEL_STANDARD ) and 2 (PSM_LEVEL_NATIVE). State Changed From-To: open->feedback Testing requested with a new patch. Responsible Changed From-To: freebsd-x11->jkim Testing requested with a new patch. In my case this patch works well. -- With The Best Regards, Kash. Same here. Please commit the patch. Helge Firstly, if everyone got a blank, or possibly two blank emails from me, I apologize, misconfiguration of opera. This patch worked for me as well. I don't use moused, and I have psm0 as my device. However, the scroll wheel wasn't working with it in FreeBSD 7. If I started moused, then used /dev/sysmouse in xorg.conf, rather than my preferred psm0, it would work. After applying the patch, both work. So, this patch worked quite well for me. Thanks for all your efforts. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 jkim 2008-04-15 18:01:15 UTC FreeBSD ports repository Modified files: x11-servers/xorg-server Makefile x11-servers/xorg-server/files patch-Xserver-hw-xfree86-os-support-bsd-bsd_mouse.c Added files: x11-servers/xorg-server/files patch-Xserver-hw-xfree86-os-support-xf86_OSlib.h Log: - Auto-detect and use native extended PS/2 protocols with the latest psm(4). Since psm has gained write(2) support, it can be directly driven by X.org input drivers without help of moused(8) or SysMouse protocol. - Fix regressions without moused running. PR: ports/122363, ports/122405 Revision Changes Path 1.56 +1 -1 ports/x11-servers/xorg-server/Makefile 1.2 +89 -32 ports/x11-servers/xorg-server/files/patch-Xserver-hw-xfree86-os-support-bsd-bsd_mouse.c 1.1 +12 -0 ports/x11-servers/xorg-server/files/patch-Xserver-hw-xfree86-os-support-xf86_OSlib.h (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" Still not working here. I tried with and without hal built into xorg-server. I have the most recent revision from ports installed. With and without moused. I am running 7.0-Stable. I have a wireless usb microsoft optical mouse. Attached is my current Xorg.0.log. I think something is being auto detected wrongly. It says my mouse type is Silken. I tried a simple imps/2 and intellimouse as the type and I have not control over the mouse. The wheel works everywhere else (knoppix and freesbie). Any help would be appreciated. State Changed From-To: feedback->closed Feedback timeout. The fix was committed long ago. *** Bug 122404 has been marked as a duplicate of this bug. *** |