Bug 5224

Summary: the mouse-wheel on the device sysmouse does not work
Product: xorg Reporter: Andrew Muhametshin <inspirra>
Component: Input/MouseAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high    
Version: 6.8.99.902 (6.9 RC2)   
Hardware: x86 (IA32)   
OS: FreeBSD   
Whiteboard:
i915 platform: i915 features:

Description Andrew Muhametshin 2005-12-02 19:48:57 UTC
In version 6.8.99.902, if the device "/dev/sysmouse" is used - that does not
work mouse-scroll. 
On 6.8.2 / 6.8.99.16 - works, but after a upgrade up to 6.8.99.902 - not work.

Mouse - Logitech MX-300
moused_flags="-F 200 -r high -z 4 5 -a 1 -w 6 -l 1"
FreeBSD-6
Comment 1 Ben Woolley 2006-01-30 08:11:45 UTC
Ran into the same problem on DragonFly BSD, upgrading up to 6.9.0. My old,
perfectly working config just stopped working, and no matter what different
options I try, I can't get xev to show more than 3 mouse button events. 
Comment 2 Ben Woolley 2006-01-30 14:21:36 UTC
The first problem I had was that it was autodetecting the MouseSystems protocol,
instead of the SysMouse protocol. I did some research, and it appears that the
sysmouse drivers operate in two levels:
0: MouseSystems 5 byte protocol which handles x, y, and 3 buttons.
1: SysMouse protocol, which has 3 more bytes for z, and buttons 4-10.
My mouse has been running in leve 1 before I upgraded. I can be pretty sure of
this by the fact that z was working. I can even have moused direct z to x, and
that works. So my "ums" USB mouse driver is certainly working. I also know that
the level can be changed via ioctl. I tried to force the protocol to SysMouse,
and it was doing crazy stuff, so perhaps it was stuck in level 0, trying to
interpret it in level 1 when I did that. I am going to research this more, and
do some more controlled tests now that I know more about what is going on.
Comment 3 Ben Woolley 2006-01-30 15:01:30 UTC
Hmm. SetSysMouseRes forces level to 1 when the protocol is SysMouse, so my first
theory is probably wrong. The code that reads the protocol appears to have not
been changed in ages, too.
Comment 4 Ben Woolley 2006-01-30 16:24:11 UTC
This is interesting.

When:
(**) Mouse1: Device: "/dev/ums0"
(**) Mouse1: Protocol: "SysMouse"
Works

But when:
(**) Mouse1: Device: "/dev/sysmouse"
(**) Mouse1: Protocol: "SysMouse"
Doesn't work.

Only change.

The differences that I can see between them is that the ioctl() calls return
different information (just more generic for sysmouse), so it likely has to do
with code that branches based on that information.
Comment 5 Ben Woolley 2006-02-02 15:37:24 UTC
http://leaf.dragonflybsd.org/mailarchive/kernel/2006-02/msg00006.html

Looks like a fix was found.
Comment 6 Daniel Stone 2007-02-27 01:29:02 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 7 chemtech 2013-03-15 14:42:14 UTC
Andrew Muhametshin 
Do you still experience this issue with newer soft ?
Please check the status of your issue.
Comment 8 GitLab Migration User 2018-08-10 20:58:21 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-mouse/issues/6.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.