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?

Graphical Environments, Managers, Multimedia & Desktop questions.
Post Reply
Message
Author
User avatar
Meow
Posts: 29
Joined: 2015-04-13 23:32
Has thanked: 5 times

[SOLVED] Any idea how to get around xinput regression?

#1 Post by Meow »

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)
Last edited by Meow on 2018-03-31 00:23, edited 1 time in total.

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Any idea how to get around xinput regression?

#2 Post by bw123 »

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
Meow wrote: (I would like to avoid being forced to open the mouse to cut a few PCB traces)
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?
resigned by AI ChatGPT

User avatar
Meow
Posts: 29
Joined: 2015-04-13 23:32
Has thanked: 5 times

Re: Any idea how to get around xinput regression?

#3 Post by Meow »

Thank you for looking into that. The problem is that the settings are being stored, but seem not to be honored:

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 
%
According to the output of xinput get-button-map I'd expect the wheel to be off, but is is not.
bw123 wrote:I saw that your bug mentioned an error, but did not say what the error is.
Regarding the error, it was my bad.
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

%
bw123 wrote:Wow, sounds you really hate the wheel. If so, maybe a physical solution like that would be best?
I guess you are right.
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...

User avatar
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?

#4 Post by Head_on_a_Stick »

You could try

Code: Select all

Option "ScrollMethod" "none"
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 :mrgreen:
deadbang

User avatar
Meow
Posts: 29
Joined: 2015-04-13 23:32
Has thanked: 5 times

Re: Any idea how to get around xinput regression?

#5 Post by Meow »

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.
Good idea to look into that direction! :idea:
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
But wheel is still active. :cry:
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.)

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Any idea how to get around xinput regression?

#6 Post by bw123 »

Meow wrote: ...my impression up to now was that it somehow appears sufficient to just put a rudimentary xorg.conf that overloads the defaults.)
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
resigned by AI ChatGPT

User avatar
Meow
Posts: 29
Joined: 2015-04-13 23:32
Has thanked: 5 times

Re: Any idea how to get around xinput regression?

#7 Post by Meow »

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
I find this confusing compared to the former /etc/X11/xorg.conf location, too.
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
showed that there is already some Wayland contamination in Debian :(
I am not happy about all this... I guess I'll pick the scalpel...

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: Any idea how to get around xinput regression?

#8 Post by bw123 »

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.
Meow wrote: Now I ask myself, what's the correct thing to do?
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.


Thanks for trying to find the solution, I hope you'll hang in there with it.
resigned by AI ChatGPT

User avatar
Meow
Posts: 29
Joined: 2015-04-13 23:32
Has thanked: 5 times

Re: Any idea how to get around xinput regression?

#9 Post by Meow »

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?

User avatar
Meow
Posts: 29
Joined: 2015-04-13 23:32
Has thanked: 5 times

Re: Any idea how to get around xinput regression?

#10 Post by Meow »

FYI:
It was indeed a bug in libinput. :roll:
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"?

SlidingHorn
Posts: 31
Joined: 2018-03-26 15:38

Re: Any idea how to get around xinput regression?

#11 Post by SlidingHorn »

Meow wrote:Edit: How can I mark the topic as "Solved"?
Just edit the title of the OP

Post Reply