Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
[SOLVED] Any idea how to get around xinput regression?
[SOLVED] Any idea how to get around xinput regression?
I need to turn off mouse wheel and always did this via "xinput set-button-map".
This no longer works. I already filed a bug report.
When searched for other bugs around xinput, it looks like that on Debian xinput is (almost) completely broken due to a regression introduced in the last 2, 3 years.
Is there an other way I could deactivate the wheels software-wise?
(I would like to avoid being forced to open the mouse to cut a few PCB traces)
This no longer works. I already filed a bug report.
When searched for other bugs around xinput, it looks like that on Debian xinput is (almost) completely broken due to a regression introduced in the last 2, 3 years.
Is there an other way I could deactivate the wheels software-wise?
(I would like to avoid being forced to open the mouse to cut a few PCB traces)
Last edited by Meow on 2018-03-31 00:23, edited 1 time in total.
Re: Any idea how to get around xinput regression?
The xinput button mapping seems to work fine here. Setting the fourth button to zero disables scrolling up using the name or id number. I don't use libinput for mouse or touchpad anymore though, maybe that has something to do with it. I saw that your bug mentioned an error, but did not say what the error is.
Code: Select all
$ xinput --list 11 | grep labels
Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" None None None None None
$ xinput set-button-map 11 1 2 3 0 5 6 7 8 9 10 11 12
$ xinput get-button-map 'SynPS/2 Synaptics TouchPad' 1 2 3 0 5 6 7 8 9 10 11 12
$ xinput set-button-map 'SynPS/2 Synaptics TouchPad' 1 2 3 4 5 6 7 8 9 10 11 12
$ xinput get-button-map 11 1 2 3 4 5 6 7 8 9 10 11 12
$ xinput --version
xinput version 1.6.2
XI version on server: 2.3
Wow, sounds you really hate the wheel. If so, maybe a physical solution like that would be best? Or getting a mouse without a wheel?Meow wrote: (I would like to avoid being forced to open the mouse to cut a few PCB traces)
resigned by AI ChatGPT
Re: Any idea how to get around xinput regression?
Thank you for looking into that. The problem is that the settings are being stored, but seem not to be honored:
According to the output of xinput get-button-map I'd expect the wheel to be off, but is is not.
I must have miscopied/pasted the name.
If prepending pointer: to the name, it works.
Disabling the keyboard component didn't change the wheel problem, so this seems not the cause.
The problem is that the cat hairs in the mice make them "scroll" even without touching the wheel - highly annoying!
Before I take out the scalpel I'll look whether I can find a way to set the scroll increment to 0... maybe this could make for a conservative therapy...
Otherwise I'll do physical mouse surgery as last ditch...
Code: Select all
% perl -w wheeloff.pl
System mouse ID is: 8
Button labels are: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" "Button Side" "Button Extra"
Executed to turn wheel off: xinput set-button-map 8 1 2 3 0 0 0 0 8 9
% xinput get-button-map 8
1 2 3 0 0 0 0 8 9
%
Regarding the error, it was my bad.bw123 wrote:I saw that your bug mentioned an error, but did not say what the error is.
I must have miscopied/pasted the name.
If prepending pointer: to the name, it works.
Disabling the keyboard component didn't change the wheel problem, so this seems not the cause.
Code: Select all
% xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ MLK SPEEDLINK RF Snappy id=8 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=9 [slave keyboard (3)]
↳ lircd-uinput id=10 [slave keyboard (3)]
↳ HP WMI hotkeys id=11 [slave keyboard (3)]
↳ MLK SPEEDLINK RF Snappy id=12 [slave keyboard (3)]
% xinput list 'MLK SPEEDLINK RF Snappy'
Warning: There are multiple devices matching 'MLK SPEEDLINK RF Snappy'.
To ensure the correct one is selected, please use the device ID, or prefix the
device name with 'pointer:' or 'keyboard:' as appropriate.
unable to find device MLK SPEEDLINK RF Snappy
% xinput list pointer:'MLK SPEEDLINK RF Snappy'
MLK SPEEDLINK RF Snappy id=8 [slave pointer (2)]
Reporting 7 classes:
Class originated from: 8. Type: XIButtonClass
Buttons supported: 9
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 state:
Class originated from: 8. Type: XIValuatorClass
Detail for Valuator 0:
Label: Rel X
Range: -1.000000 - -1.000000
Resolution: 0 units/m
Mode: relative
Class originated from: 8. Type: XIValuatorClass
Detail for Valuator 1:
Label: Rel Y
Range: -1.000000 - -1.000000
Resolution: 0 units/m
Mode: relative
Class originated from: 8. Type: XIValuatorClass
Detail for Valuator 2:
Label: Rel Horiz Scroll
Range: -1.000000 - -1.000000
Resolution: 0 units/m
Mode: relative
Class originated from: 8. Type: XIValuatorClass
Detail for Valuator 3:
Label: Rel Vert Scroll
Range: -1.000000 - -1.000000
Resolution: 0 units/m
Mode: relative
Class originated from: 8. Type: XIScrollClass
Scroll info for Valuator 2
type: 2 (horizontal)
increment: 15.000000
flags: 0x0
Class originated from: 8. Type: XIScrollClass
Scroll info for Valuator 3
type: 1 (vertical)
increment: 15.000000
flags: 0x0
%
I guess you are right.bw123 wrote:Wow, sounds you really hate the wheel. If so, maybe a physical solution like that would be best?
The problem is that the cat hairs in the mice make them "scroll" even without touching the wheel - highly annoying!
Before I take out the scalpel I'll look whether I can find a way to set the scroll increment to 0... maybe this could make for a conservative therapy...
Otherwise I'll do physical mouse surgery as last ditch...
- Head_on_a_Stick
- Posts: 14114
- Joined: 2014-06-01 17:46
- Location: London, England
- Has thanked: 81 times
- Been thanked: 132 times
Re: Any idea how to get around xinput regression?
You could try
in /etc/X11/xorg.conf.d/40-libinput.conf — copy the template from /usr/share/X11/xorg.conf.d/ and add the Option line.
EDIT: untested, I still prefer synaptics
Code: Select all
Option "ScrollMethod" "none"
EDIT: untested, I still prefer synaptics
deadbang
Re: Any idea how to get around xinput regression?
Good idea to look into that direction!Head_on_a_Stick wrote:You could try ... in /etc/X11/xorg.conf.d/40-libinput.conf
— copy the template from /usr/share/X11/xorg.conf.d/ and add the Option line.
Will investigate this.
My xorg.conf now looks this:
Code: Select all
Section "InputClass"
Identifier "keyboard defaults"
MatchIsKeyboard "on"
Option "XKbOptions" "terminate:ctrl_alt_bksp"
Option "XkbVariant" ",alt-intl,"
EndSection
Section "InputClass"
Identifier "libinput pointer catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
Option "ScrollMethod" "none"
EndSection
I'll now move the file to /etc/X11/xorg.conf.d/40-libinput.conf and restart X to see whether this changes anything.
(Never tried this before, as my impression up to now was that it somehow appears sufficient to just put a rudimentary xorg.conf that overloads the defaults.)
Re: Any idea how to get around xinput regression?
I think it might depend where the xorg.conf is located, it confuses me also when I try to figure out exactly what the order is among the dozen? locations possible. I think the recommended way now is to keep configuration as minimal as possible, and do all your configuration with the number-ordered system in /etc/X11/xorg.conf.dMeow wrote: ...my impression up to now was that it somehow appears sufficient to just put a rudimentary xorg.conf that overloads the defaults.)
resigned by AI ChatGPT
Re: Any idea how to get around xinput regression?
I find this confusing compared to the former /etc/X11/xorg.conf location, too.bw123 wrote:I think it might depend where the xorg.conf is located, it confuses me also when I try to figure out exactly what the order is among the dozen? locations possible. I think the recommended way now is to keep configuration as minimal as possible, and do all your configuration with the number-ordered system in /etc/X11/xorg.conf.d
Seems the xorg devs have for some reason felt the need to set up sort of xorg init system...
Anyway, moving the file to the new location didn't change anything.
The reports about problems begin about the same time when libinput for wayland was introduced.
This blog post suggests that the first versions of libinput could be still without the regression that broke so many things that populate, for example, the xinput bug report lists.
(Personally I do not want Wayland, as FVWM is not compatible with it.)
Now I ask myself, what's the correct thing to do?
1. Ditch Wayland, and thus libinput, too - does there exist such a build/install/runtime option ?
2. revert to an older libinput version and stick with that one? (which one, where to obtain?) - would fix plenty of regression bugs/issues on https://bugs.debian.org
3. Lobotomize the mouse...
Code: Select all
# apt purge mutter
I am not happy about all this... I guess I'll pick the scalpel...
Re: Any idea how to get around xinput regression?
I think it's not a debian issue, debian doesn't control what freedesktop projects do, they just make the end results available in a way that goes along with their policies. From what I have seen, having some libs available that support wayland won't contaminate anything if you use X, you can still choose to set things up however you want.
Thanks for trying to find the solution, I hope you'll hang in there with it.
You don't have to use libinput if it doesn't handle your wheel the way you want. I'm not sure your trouble is libinput, but I think the bug against xinput may be unjustified? If it was me, I'd setup on stable instead of testing, forget the bsd-specific stuff, and relax with all the, "I'm mad at the world," crap.Meow wrote: Now I ask myself, what's the correct thing to do?
Thanks for trying to find the solution, I hope you'll hang in there with it.
resigned by AI ChatGPT
Re: Any idea how to get around xinput regression?
You are right.
The problem seems to lay deeper than xinput/buttonmap.c, as the return from XGetDeviceButtonMapping() matches what got set with XSetDeviceButtonMapping().
The problem is apparently in libinput, in my feeling probably near here or there..
I updated the bug report accordingly.
As BSDs reject Wayland, it's obvious that there this issue does not appear there.
Btw, is there an easy-to-browse source repository like Github for Debian?
The problem seems to lay deeper than xinput/buttonmap.c, as the return from XGetDeviceButtonMapping() matches what got set with XSetDeviceButtonMapping().
The problem is apparently in libinput, in my feeling probably near here or there..
I updated the bug report accordingly.
As BSDs reject Wayland, it's obvious that there this issue does not appear there.
Btw, is there an easy-to-browse source repository like Github for Debian?
Re: Any idea how to get around xinput regression?
FYI:
It was indeed a bug in libinput.
The bad thing about that was that libinput is being used on Debian xorg, no matter what driver you select
So I had to look deeper into the issue.
Report and fix are here: https://bugs.freedesktop.org/show_bug.cgi?id=105830
Thank you all for your input!
Edit: How can I mark the topic as "Solved"?
It was indeed a bug in libinput.
The bad thing about that was that libinput is being used on Debian xorg, no matter what driver you select
So I had to look deeper into the issue.
Report and fix are here: https://bugs.freedesktop.org/show_bug.cgi?id=105830
Thank you all for your input!
Edit: How can I mark the topic as "Solved"?
-
- Posts: 31
- Joined: 2018-03-26 15:38
Re: Any idea how to get around xinput regression?
Just edit the title of the OPMeow wrote:Edit: How can I mark the topic as "Solved"?