Description of problem: The Microsoft Wireless Laser Mouse 6000 v2.0 has a high resolution wheel with left and right tilt for horizontal scrolling. In Fedora 16, tilting the wheel left and right would result in left and right horizontal scrolling. In Fedora 17, tilting the wheel left and right results in down and up vertical scrolling. Right and left wheel movements are not triggering button 6 or 7 presses, but, instead, appear to trigger button 4 & 5 presses but with a different valuator value changing. Valuators 0 & 1 are the X & Y axis. Valuator 2 is listed as Rel Horiz Wheel, though there is no horizontal scroll wheel, nothing appears to modify this value. Valuator 3 is listed as Rel Dial, and is marked as type of vertical, this is decremented on a left press of the wheel and incremented on a right press of the wheel. Valuator 4 is listed as Rel Vert Wheel, this does get decremented on scroll down and incremented on scroll up. It would appear that the type of vertical applied to valuator 3 is a problem, though I can't see how to change it. Version-Release number of selected component (if applicable): xorg-x11-drv-evdev-2.7.0-2.fc17 How reproducible: Always Steps to Reproduce: 1. Use a Microsoft mouse with horizontal tilt to scroll 2. Have a window with horizontal scroll bars 3. Watch it scroll vertically when pressing sideways on the wheel Actual results: Left push on wheel scrolls down. Right push on wheel scrolls up. Expected results: Left push on wheel scrolls left. Right push on wheel scrolls right. Additional info: $ xinput list-props 10 Device 'Microsoft Microsoft® 2.4GHz Transceiver V2.0': Device Enabled (127): 1 Coordinate Transformation Matrix (129): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (252): 0 Device Accel Constant Deceleration (253): 1.000000 Device Accel Adaptive Deceleration (254): 1.000000 Device Accel Velocity Scaling (255): 10.000000 Device Product ID (246): 1118, 1823 Device Node (247): "/dev/input/event4" Evdev Axis Inversion (256): 0, 0 Evdev Axes Swap (258): 0 Axis Labels (259): "Rel X" (137), "Rel Y" (138), "Rel Horiz Wheel" (251), "Rel Dial" (275), "Rel Vert Wheel" (276) Button Labels (260): "Button Left" (130), "Button Middle" (131), "Button Right" (132), "Button Wheel Up" (133), "Button Wheel Down" (134), "Button Horiz Wheel Left" (135), "Button Horiz Wheel Right" (136), "Button Side" (273), "Button Extra" (274), "Button Unknown" (249), "Button Unknown" (249), "Button Unknown" (249), "Button Unknown" (249) Evdev Middle Button Emulation (261): 0 Evdev Middle Button Timeout (262): 50 Evdev Third Button Emulation (263): 0 Evdev Third Button Emulation Timeout (264): 1000 Evdev Third Button Emulation Button (265): 3 Evdev Third Button Emulation Threshold (266): 20 Evdev Wheel Emulation (267): 0 Evdev Wheel Emulation Axes (268): 0, 0, 4, 5 Evdev Wheel Emulation Inertia (269): 10 Evdev Wheel Emulation Timeout (270): 200 Evdev Wheel Emulation Button (271): 4 Evdev Drag Lock Buttons (272): 0 $ xinput query-state 10 2 classes : ButtonClass button[1]=up button[2]=up button[3]=up button[4]=up button[5]=up button[6]=up button[7]=up button[8]=up button[9]=up button[10]=up button[11]=up button[12]=up button[13]=up ValuatorClass Mode=Relative Proximity=In valuator[0]=248 valuator[1]=799 valuator[2]=0 valuator[3]=-4 valuator[4]=-5879 $ xinput test 10 Scroll down: motion a[4]=-5895 button press 5 button release 5 Scroll up: motion a[4]=-5894 button press 4 button release 4 Scroll left: motion a[3]=-5 button press 5 button release 5 motion a[3]=-6 button press 5 button release 5 Scroll right: motion a[3]=-5 button press 4 button release 4 motion a[3]=-4 button press 4 button release 4 ⎜ ↳ Microsoft Microsoft® 2.4GHz Transceiver V2.0 id=10 [slave pointer (2)] Reporting 9 classes: Class originated from: 10. Type: XIButtonClass Buttons supported: 13 Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" "Button Side" "Button Extra" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown" Button state: Class originated from: 10. Type: XIValuatorClass Detail for Valuator 0: Label: Rel X Range: -1.000000 - -1.000000 Resolution: 1 units/m Mode: relative Class originated from: 10. Type: XIValuatorClass Detail for Valuator 1: Label: Rel Y Range: -1.000000 - -1.000000 Resolution: 1 units/m Mode: relative Class originated from: 10. Type: XIValuatorClass Detail for Valuator 2: Label: Rel Horiz Wheel Range: -1.000000 - -1.000000 Resolution: 1 units/m Mode: relative Class originated from: 10. Type: XIValuatorClass Detail for Valuator 3: Label: Rel Dial Range: -1.000000 - -1.000000 Resolution: 1 units/m Mode: relative Class originated from: 10. Type: XIValuatorClass Detail for Valuator 4: Label: Rel Vert Wheel Range: -1.000000 - -1.000000 Resolution: 1 units/m Mode: relative Class originated from: 10. Type: XIScrollClass Scroll info for Valuator 2 type: 2 (horizontal) increment: 1.000000 flags: 0x0 Class originated from: 10. Type: XIScrollClass Scroll info for Valuator 3 type: 1 (vertical) increment: -1.000000 flags: 0x0 Class originated from: 10. Type: XIScrollClass Scroll info for Valuator 4 type: 1 (vertical) increment: -1.000000 flags: 0x2 ( preferred )
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Please record your device with evemu and attach the output here http://www.freedesktop.org/wiki/Evemu/
Created attachment 782486 [details] evemu-describe output
Created attachment 782487 [details] evemu-record output, at top dial -1 is left press, dial 1 is right press
Created attachment 890274 [details] Evemu-describe output for mouse and keyboard (same USB device) Looks like I have just been hit by this bug as well since the new Evdev update that obsoleted xorg-x11-drv-mouse package. I am using Fedora 21 rawhide. Attached is the evemu output for both mouse and keyboard (on the same USB receiver device).
upstream bug http://bugs.freedesktop.org/73105, that's a bug in evdev.
Peter, I've added the patch posted upstream to the rawhide pkgs as part of my xorg-rebase for rawhide. I assume you're going to take care of getting this fixed for F-19 / F-20 ? Regards, Hans
(In reply to Hans de Goede from comment #7) > Peter, > > I've added the patch posted upstream to the rawhide pkgs as part of my > xorg-rebase for rawhide. I assume you're going to take care of getting this > fixed for F-19 / F-20 ? > > Regards, > > Hans I tried to install the new packages. Installation failed. I see dependency errors for something called "xserver-abi >= 0" but yum whatprovides does not list a package with that name.
The second time I tried to install the updated packages from koji I got a variant of the dependency error I saw before. YUM then said that it was "xserver-abi(xinput 21) >= 0". Searching for that dependency led me to a couple Mageia packages. I did not try to install those as that would have been a mistake and I would have paid for it later. So, I rebuilt the packages from source on my own machine and was able to install the patched binaries without dependency errors. The patches work. Thanks for making the patched source RPM available. I now have full horizontal scrolling back and working using the title wheel on a Microsoft Wireless Mouse 5000. Thanks again.
The second time I tried to install the updated packages from koji I got a variant of the dependency error I saw before. YUM then said that it was "xserver-abi(xinput 21) >= 0". Searching for that dependency led me to a couple Mageia packages. I did not try to install those as that would have been a mistake and I would have paid for it later. So, I rebuilt the packages from source on my own machine and was able to install the patched binaries without dependency errors. The patches work. Thanks for making the patched source RPM available. I now have full horizontal scrolling back and working using the tilt wheel on a Microsoft Wireless Mouse 5000. Thanks again.
Charles: don't install rawhide packages on anything but rawhide, they won't work because of ABI mismatches. And Hans is currently rebasing xorg in rawhide, so the ABI is all over the place until it's finished anyway. Please wait for f20/f19 packages which are on the way.
xorg-x11-drv-evdev-2.8.3-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/xorg-x11-drv-evdev-2.8.3-1.fc20
xorg-x11-drv-evdev-2.8.3-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/xorg-x11-drv-evdev-2.8.3-1.fc19
(In reply to Peter Hutterer from comment #11) > Charles: don't install rawhide packages on anything but rawhide, they won't > work because of ABI mismatches. And Hans is currently rebasing xorg in > rawhide, so the ABI is all over the place until it's finished anyway. Please > wait for f20/f19 packages which are on the way. I am using rawhide and only installed them on my rawhide system. I still got the dependency error even on rawhide.
oh, right. in that case the most likely issue is that you're hitting a state of repo where the rebase isn't done yet. Try to update xorg-x11-server-* and the dependencies and the new package should work. If you have the build-deps installed you can just download the src.rpm and rebuild that locally too.
Yes, I figured that might be the case, which is why I just rebuilt the packages locally from source. I plan to update the xorg-x11-server-* and other connected drivers soon, too. But the patched files themselves are working and the tilt-wheel functions as expected now.
Out of interest - which package did you end up testing? I pushed a fixed version in because the original patch should've had left/right swapped. Is this the case with the latest version or did I mess up the fix?
(In reply to Peter Hutterer from comment #17) > Out of interest - which package did you end up testing? I pushed a fixed > version in because the original patch should've had left/right swapped. Is > this the case with the latest version or did I mess up the fix? It is the one from here: http://koji.fedoraproject.org/koji/buildinfo?buildID=513754 I would not know whether the fix was wrong. Everything on my mouse seems to be working as expected sinc using the abovementioned package. I just had to reverse scrolling by putting a file named 20-natural-scrolling.conf in /usr/share/X11/xorg.conf.d directory. The contents of the file are as follows: Section "InputClass" Identifier "Natural Scrolling" MatchIsPointer "on" MatchDevicePath "/dev/input/event*" Option "VertScrollDelta" "-1" Option "HorizScrollDelta" "-1" EndSection I kept it a separate file in the event changes to the officially packaged files might remove my changes I might have put in the 10-evdev.conf file itself. I just saw another set of files posted over on Koji. Should I use the rawhide one or will these new packages not have your patch in them?
Those packages have the new patches in them. Update to those and test it without a InputClass section please. That section overwrites the defaults which are what I'm interested in. If the defaults are what you expect from a scroll wheel (not natural scrolling though), then all is good and you can pop the custom config back into place.
I tested the packages I mentioned above (http://koji.fedoraproject.org/koji/buildinfo?buildID=513754) and they are working as expected, without my custom InputClass file. Tilting the wheel causes the horizontal scrollbar to move in the direction of tilt of the tiltwheel, which is what it should do when natural scrolling/reverse scrolling is turned off. I'm about to install the newest ones and test those momentarily.
Just installed, rebooted, and tested the very latest packages from Koji. Everything seems to be working just fine now. Scrolling with the tiltwheel on my Microsoft Mouse works as it should with defaults. Horizontal scrollbar moves in the direction of the mousewheel tilt, which is exactly what it should do when natural scrolling is not set in the configuration. Hope this helps.
Hi, (In reply to D. Charles Pyle from comment #14) > (In reply to Peter Hutterer from comment #11) > > Charles: don't install rawhide packages on anything but rawhide, they won't > > work because of ABI mismatches. And Hans is currently rebasing xorg in > > rawhide, so the ABI is all over the place until it's finished anyway. Please > > wait for f20/f19 packages which are on the way. > > I am using rawhide and only installed them on my rawhide system. I still > got the dependency error even on rawhide. That is because we're in the middle of an xorg rebase, and I've been building all the new packages in a special f21-xorg koji tag to avoid breaking rawhide. So the new server with the new ABI is not in the rawhide repo yet, it only lives in the f21-xorg koji tag for now, and the new evdev pkg I build was build against that new server. Peter, your new evdev build for rawhide was against the old server, which is why Charles could install it. I've bumped the release and done another build against the new server in the f21-xorg koji tag. Once that build and tigervnc (which was the last hurdle) finish, I'll ask rel-eng to move all of the new package out of the f21-xorg tag and into rawhide proper in one go. Regards, Hans
Package xorg-x11-drv-evdev-2.8.3-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-evdev-2.8.3-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5788/xorg-x11-drv-evdev-2.8.3-1.fc19 then log in and leave karma (feedback).
Everything was working until a group of updates late this evening. Now, natural scrolling does not work on the tilt wheel in the proper direction. The HorizScrollDelta option no longer changes anything on my machine in rawhide. xinput now gives me the following: $ xinput list-props 9 | grep -i "scrolling distance" Evdev Scrolling Distance (273): -1, -1, 1 However, if I run /usr/bin/xinput set-prop 9 273 -1 -1 -1 natural scrolling will work again in the proper direction on the tilt wheel. I know what the first two options represented by negative numbers are on the above command line. The first two negative numbers are VertScrollDelta and HorizScrollDelta, respectively, but what is the third number?
Never mind. I just found out what the third number is. Now, I just need to figure out how to set that third option in my 20-natural-scrolling.conf file.
HorizScrollDelta is for a horizontal wheel, you have a dial (or at least it claims it's a REL_DIAL). Try DialDelta instead of HorizScrollDelta, that's the third number and it's still in normal mode.
Thanks. I'll try that.
(In reply to Peter Hutterer from comment #26) > HorizScrollDelta is for a horizontal wheel, you have a dial (or at least it > claims it's a REL_DIAL). Try DialDelta instead of HorizScrollDelta, that's > the third number and it's still in normal mode. That did the trick. Thanks again, and thanks for patching that. Happy as a clam... :-)
xorg-x11-drv-evdev-2.8.3-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
xorg-x11-drv-evdev-2.8.4-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/xorg-x11-drv-evdev-2.8.4-1.fc19