Bug 102811 - ThinkPad Bluetooth Laser Mouse - Faulty Horizontal Scroll - Hardware Quirk?
Summary: ThinkPad Bluetooth Laser Mouse - Faulty Horizontal Scroll - Hardware Quirk?
Status: RESOLVED INVALID
Alias: None
Product: Wayland
Classification: Unclassified
Component: libinput (show other bugs)
Version: unspecified
Hardware: All All
: medium minor
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-16 21:56 UTC by Adam Hirst
Modified: 2017-12-18 05:02 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
evemu-record output (up, down, left, right scroll) (3.87 KB, text/plain)
2017-09-16 21:56 UTC, Adam Hirst
Details

Description Adam Hirst 2017-09-16 21:56:06 UTC
Created attachment 134282 [details]
evemu-record output (up, down, left, right scroll)

I initially reported this issue on the mailing list:
https://lists.freedesktop.org/archives/xorg/2017-August/058847.html

The hardware is "ThinkPad Bluetooth Laser Mouse", and has "4-way scroll" implemented via a normal scroll wheel which tilts left and right onto microswitches (similar to many other devices, including the ubiquitous Logitech B110).

I'll summarise it here:

--
#0 - The default button mapping has the scroll directions mixed up, sanity is only restored with the following line specified in an xorg.conf.d .conf file:

Option        "ButtonMapping" "1 2 3 4 5 0 0 6 7"

--

#1 - The sideways "clicks" of the wheel don't provide "repeating" events like on similar mice, but instead act like normal mouse buttons (giving a single Press event and a single Release event). This severely cripples the horizontal scroll feature. I was recommended in response to my mailing list post (by Peter Hutterer) to file a bug here along with some extra info, as a Quirk may be necessary.

I've attached (or will attach) output evemu-record (with the .conf Option above currently active). I scrolled once up, once down, then clicked once left, held, then released - and did the same once more for right.

If there's any more info which would be useful, please don't hesitate to ask.
Comment 1 Adam Hirst 2017-09-16 22:02:48 UTC
For clarification, I disabled the Option line I had set, as I wanted to double-check what the default mapping was.

The default mapping has the left and right scroll-wheel tilts act as "Forward" and "Back", and there are no more physical buttons remaining to act as the actual scroll. This explains why I effectively shift the mapping 2 buttons down.

I thought it best to do that before asked to.
Comment 2 Peter Hutterer 2017-09-17 11:37:01 UTC
Urgh, ok. we need to add a repeating timer to this one too, just a hwdb quirk won't be enough, this requires some code changes in libinput
Comment 3 Adam Hirst 2017-10-13 22:38:38 UTC
I see. Well, in that case, I'll hang tight and just be patient. I can't imagine there are that many others using this same device.
Comment 4 Peter Hutterer 2017-10-15 23:09:57 UTC
cc-ing benjamin in case the kernel already has infrastructure for this in place (I doubt it, but...). Please attach a dmesg though.

Benjamin: hwheel sends button side/extra and does not repeat, so tilting the wheel isnt' very useful - or at least doesn't do what it is supposed to do.
Comment 5 Benjamin Tissoires 2017-10-20 14:15:25 UTC
Can I get hid-recorder outputs of the wheel tilt events too? (install hid-replay from http://bentiss.github.io/hid-replay-docs/)
Comment 6 Peter Hutterer 2017-11-15 04:08:15 UTC
ping?
Comment 7 Adam Hirst 2017-11-15 07:27:17 UTC
Sorry, I've been wrapped up in other stuff, and let this slide. I'll try to get this info ASAP.
Comment 8 Peter Hutterer 2017-12-18 05:02:05 UTC
Closing after over a month in needinfo


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.