Talk:Mouse buttons

libinput ./. evdev

Anecdotally, libinput frankly sucks - at least when it comes to the wheel emulation button.

No only can you apparently not reverse the direction independently from the actual wheel (what "feels" weird) but the performance is abysmal. It occasionally responds and then often stops after a moment, the behavior is completely unpredictable.

I set up a new system and when for "clean install, no config copypasta" and after "oh no, my beloved rodent has died" and a whole rabbit hole of "is usb autosuspending for the device *actually* off?", I figured it would *have* to be the driver and low and behold, the wheel button works as good as ever w/ evdev (plus also in the right direction) Seth (talk) 07:02, 29 May 2025 (UTC)

Did you file a bug report? — Lahwaacz (talk) 11:29, 1 June 2025 (UTC)

The main point of the comment was to address the 4 year old notice about factual accuracy and highlight that while libinput might be the default, there maybe downsides to mention in case of an article rewrite.

I'm currently not interested in its flaws, which are partly design decisions (it always struck me as touchpad biased and the locked directions via natural scrolling alone would render it an almost uninteresting feature to me) - and since I only ran into that situation this week I cannot even tell whether this is some sort of regression or HW specific (though I actually did test a different mouse) or is a problem in libinput or xf86-input-libinput (in which case I guess upstream will care even less)

I also haven't seen any complaints about this on the forum so either this is some local problem or nobody else cares about that feature. Seth (talk) 13:22, 1 June 2025 (UTC)