Summary: | Logitech MX 1000 mouse: xorg does not see all 12 buttons | ||
---|---|---|---|
Product: | xorg | Reporter: | Sergey V. Udaltsov <svu> |
Component: | Input/Mouse | Assignee: | Xorg Project Team <xorg-team> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | highest | ||
Version: | 6.8.1 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
URL: | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140963 | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Sergey V. Udaltsov
2004-11-27 07:30:53 UTC
I've got the same or similar problems with a Logitech MX510. i can use up to seven buttons using the ExplorerPS/2 protocol by adding Option "ZAxisMapping" "6 7" to xorg.conf, and using xmodmap -e "pointer = 1 2 3 6 7 4 5" to remap events. One extra problem i'm seeing that's not described here is one of the "cruise control" buttons (button 4 or forward/upward scroll) produces simultaneous ButtonRelease events. Pressing it gives ButtonRelease events for both buttons 4 and 6. I did have all buttons working as ecpected with the evdev patches while using fedora's xorg 6.7.0. I've yet to bother adding them to fedora's xorg 6.8.1. Having just purchased a Logitech keyboard that is also giving me trouble, i'm hoping a driver(s) that can use the event interface will make it into upstream soon. I came across http://bugzilla.kernel.org/show_bug.cgi?id=1786 reported against a Logitech mx500 mouse quite a while ago. Can anyone say where this problem originates? Kernel input layer, or X input? That bug report seems to indicate it's not a kernel problem, and it does go away using debian's evdev patches. Use the evdev version 3 patch named 9000_all_6.7.99.2-lnx-evdev-core-v3.patch (In reply to comment #3) > Use the evdev version 3 patch named 9000_all_6.7.99.2-lnx-evdev-core-v3.patch Could you attach it please? |
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.