I mostly use a Wacom tablet instead of a mouse in all applications. After a proper setup, with X11 it worked great. With Wayland it works sufficiently well, but I really miss the ability to scroll with the tablet’s stylus by pressing a stylus’s button and moving the stylus up/down/left/right to scroll up/down/left/right. Just like a scrolling emulation with a mouse or a trackball.
Fortunately, I found patches that implement a scroll emulation in libinput: GitHub - tux3/libinput-wacom-scroll: Scroll button support for Wacom tablets . After applying the patches, when I press
the stylus’s button and move the stylus, libinput generates a scroll
as can be seen in libinput debug-gui and verified with libinput debug-events: POINTER_SCROLL_CONTINUOUS (instead of TABLET_TOOL_AXIS / TABLET_TOOL_BUTTON when just moving the stylus / pressing the button).
Unfortunately, it doesn’t scroll in any app. When I try to scroll, the cursor doesn’t move (just like the scrolling emulation was working—great!), but nothing is scrolled ().
I don’t know the device-to-cursor stack well, but I assume the problem of no scroll is related to Gnome or mutter. Am I right?
Is it a bug or a missing feature? Can it be fixed/implemented? How? Where to look for it in the source of Gnome/mutter? …?
I have an old Wacom tablet, which has dedicated touch strips for scrolling with a finger. It also has a separate mouse with a wheel. When I noted in the past that the wheel was not working, I was told to open a bug report, but haven’t done that yet.
There are some known (focus-related) issues with emulating scrolling on tablets but in theory the wheel should work. Except that devices that have a wheel are very very niche so it’s quite likely no-one has tested and/or implemented this - either way best to file a separate bug for that so we can track it independently.
So, it could be a bug report with mutter, then? I assume that it decides how to process events from libinput. But you also say that the feature is not implemented in libinput yet.
So, without those patches, there are no scroll events in sudo libinput record? If there are none, then how would mutter be able to support them until they are merged to libinput? You would need that first. But, how do you know that there were no events?
In sudo libinput record output, I see some special REL_WHEEL events when I scroll the mouse wheel and there are also something when I swipe the touch strips. Still, scrolling doesn’t work.
My Wacom tablet doesn’t have dedicated touch strips or a wheel. Its surface is a touchpad, and I can scroll with 2 fingers – it works fine. However, I’d like to be able to scroll with my stylus by pressing a button and moving the stylus (as it was possible with Easystroke with X11). My tablet doesn’t emit any scroll or wheel event itself then; scrolling has to be emulated (in libinput, right?) just like you can enable it for a mouse (usually middle button+movement).
I assume so, but if anyone (any mutter developer here?) can point to a source where mutter processes scroll events from libinput, it would help confirm/deny this assumption.
No, because my tablet itself doesn’t emit any scroll or wheel events. I believe those patches implement scroll emulation in the same way as mouse scroll emulation.
These patches seem to be PoC and to require some polishing before merging. However, without a way to verify that they actually work as I expect, it’s difficult to proceed. I assume it would be best to have patches ready for both libinput and mutter before submitting them to both projects simultaneously.
I don’t see anything like scrolling in libinput debug-events before applying those patches. Only a button press and a stylus movement but I assume the scroll emulation in libinput should suppress them and emit some scroll event instead.
).