Bug 102811

Summary:	ThinkPad Bluetooth Laser Mouse - Faulty Horizontal Scroll - Hardware Quirk?
Product:	Wayland	Reporter:	Adam Hirst <adam>
Component:	libinput	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED INVALID	QA Contact:
Severity:	minor
Priority:	medium	CC:	adam, benjamin.tissoires, peter.hutterer
Version:	unspecified
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	evemu-record output (up, down, left, right scroll)

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.