Wacom pen: panning/scrolling

[rubdos]

When using a Wacom tablet, it would be desirable to be able to pan/scroll through documents. X11 users have xsetwacom --set "Wacom Intuos S Pen stylus" Button 2 "pan" andxsetwacom --set "Wacom Intuos S Pen stylus" "PanScrollThreshold" 200, but I have not been able to find the equivalent command forswaymsg input, nor do I seem to find it insway-input(5)`.

[rubdos]

Panning actually seems to work in Evince with one button, but I would still expect Firefox and other native Wayland applications to understand these gestures. Firefox, Chromium and others seem to understand the same button as a right-mouse button.

Related to #4617.

[Xyene]

Does this behave differently in e.g. GNOME (Wayland session)? This isn't really Sway's ballpark; we (roughly) just marshal input events received from libinput to whatever application has focus, and it's up to the application to decide what to do with them. The issues from https://github.com/swaywm/sway/issues/4617 were resolved a while ago and are not related to this.

[Elnee]

I'm using Sway with ThinkPad Yoga 370 and have same issues. Scrolling with stylus works in GIMP and Evince, but I can't find any other applications that support it. I didn't any additional settings, right out of the box with libinput debug-events I see the left button on my stylus recognized as eraser:

 event11  TABLET_TOOL_AXIS +47.179s     218.58*/106.30* pressure: 0.00
 event11  TABLET_TOOL_PROXIMITY +47.199s        218.52/106.75   pressure: 0.00  pen      (0xb00f8566, id 0x11) proximity-out
 event11  TABLET_TOOL_PROXIMITY +47.210s        218.39*/107.26* pressure: 0.00* eraser   (0xb00f8566, id 0) proximity-in    axes:p  btn:SS2
 event11  TABLET_TOOL_PROXIMITY +47.450s        218.39/107.26   pressure: 0.00  eraser   (0xb00f8566, id 0) proximity-out
 event11  TABLET_TOOL_PROXIMITY +50.404s        219.93*/109.36* pressure: 0.00* pen      (0xb00f8566, id 0x11) proximity-in     axes:p  btn:S
 event11  TABLET_TOOL_AXIS +50.449s     219.91*/109.36  pressure: 0.00
 event11  TABLET_TOOL_AXIS +50.480s     219.87*/109.38* pressure: 0.00

And right button recognized as BTN_STYLUS (331):

 event11  TABLET_TOOL_AXIS +7.365s      204.25*/117.47* pressure: 0.00
 event11  TABLET_TOOL_BUTTON +7.365s    331 (BTN_STYLUS) pressed, seat count: 1
 event11  TABLET_TOOL_AXIS +7.380s      204.58*/117.60* pressure: 0.00
 event11  TABLET_TOOL_AXIS +7.385s      204.88*/117.75* pressure: 0.00
 event11  TABLET_TOOL_AXIS +7.400s      205.11*/117.87* pressure: 0.00
 event11  TABLET_TOOL_BUTTON +7.505s    331 (BTN_STYLUS) released, seat count: 0
 event11  TABLET_TOOL_AXIS +7.544s      205.36/117.95*  pressure: 0.00

So, libinput works correctly, I guess. But why it doesn't work for most applications? They just ignore this events? Or is it a problem related to button mapping?

[Xyene]

Wayland has a tablet protocol, and applications need to bind tablet input handlers through it in order to get tablet events. GIMP and Evince, being drawing applications, do bind tablet handlers and thus receive tablet events. So does Firefox.

If an application does not bind tablet handlers, Sway will treat the tablet as a mouse, and convert the tablet events it receives from libinput into mouse events it sends to the application. The conversion turns:

• tip down → left mouse button pressed
• tip up → left mouse button released
• any button → right mouse button pressed

[Elnee]

@Xyene Thank you very much for clarification.

[fcomoreira1]

@Xyene Let me know if I understood it correctly. It is up to each application to implement (or not) input handlers specific for tablet events libinput sends?

I recently switched to sway and noticed that xournal++ interprets my Wacom pen as a mouse, which is weird to me, as on X it handles it right. Is it because Xournal++ has to has an implementation specific for libinput?

I know this is an old issue, but this one of the only problems I have been having since I switched, and using these tablets is very important for the classes I teach virtually.

[Xyene]

Yes, your understanding is correct.

I believe Xournal++ used GTK 2 until ~recently, which did not support Wayland tablet events. My understanding is more recent versions of Xournal++ switched to GTK 3, so tablet events have the ability to work there.

I don't use Xournal++ myself so I can't speak to whether that's the case or not, but I'd double-check you're using a recent version.

[fcomoreira1]

I am using the most recent (non-beta/dev) one. Do you know anyone that supports pen correctly? I can switch in order to stay using sway, but I really need the note-taking app to support my drawing table well.

[fluix-dev]

I'm using 1.0.20 and that supports things like pressure which I assume is the correct tablet events. You should definitely try the latest version from source though if 1.0.20 doesn't work for you.

[fcomoreira1]

The pressure sensitivity does work for me actually. But on the configuration to remap buttons on xournal, the one that applies to the Pen is the mouse one. Also, in X when it detects the pen there is no cursor shown when hovering the paper, only the black dot that also appears when writing.

But that is not my biggest problem. On Xorg I used xsetwacom to adjust my pressure sensitivity, which by default its a little low for me and to remap the first button to become just an scrolling button.

My question is, on Sway those settings should be set on every app (if supported), or it would/should be dealt by Sway itself?

This may be a silly question, sorry if it is, as I am still very new to Sway and Wayland stuff overall.

[fluix-dev]

But on the configuration to remap buttons on xournal, the one that applies to the Pen is the mouse one.

Hmm, I'm not sure what you mean here. In Edit > Preferences > Stylus Buttons, I'm able to change my pen buttons and eraser which works correctly. Perhaps you're editing in the "Mouse" section?

Also, in X when it detects the pen there is no cursor shown when hovering the paper, only the black dot that also appears when writing.

Yeah this is the case for me as well.

My question is, on Sway those settings should be set on every app (if supported), or it would/should be dealt by Sway itself?

I don't believe Sway currently has controls for this, but @Xyene would be a better person to ask (also whether it would be possible for Sway to support this I guess).

[Farielle]

Hello,

I am unsure if I should continue the discussion on this issue or start a new one, so tell me if I'm at the wrong place. I also wanted to be able to scroll with one of the pen button on my wacom tablet.

I'm using this as a config for my wacom stylus :

input "1386:216:Wacom_Bamboo_Comic_2FG_Pen" {
    map_to_output DP-1
    scroll_button 331
    scroll_method on_button_down
}

I got the 331 from libinput debug-events :

 event21  TABLET_TOOL_BUTTON      +2.300s   331 (BTN_STYLUS) pressed, seat count: 1
 event21  TABLET_TOOL_BUTTON      +2.460s   331 (BTN_STYLUS) released, seat count: 0

However, this don't work for scrolling while pressing this button on the stylus. I don't know why.

I have confirmed that it worked for my mouse with scroll_button 272 for left click for example. I have also noticed that libinput would print the button code differently for the stylus and the mouse, for exemple

 -event7   POINTER_BUTTON          +0.000s  BTN_LEFT (272) pressed, seat count: 1
 event7   POINTER_BUTTON          +0.079s   BTN_LEFT (272) released, seat count: 0

(here NAME (number) as opposed to BTN_STYLUS) I don't know if this can be related to why the scroll on the stylus don't work. Are the mouse button and stylus button treated differently ?

[kanashimia]

Are the mouse button and stylus button treated differently ?

Yes, this is a missing feature in the libinput, see: https://gitlab.freedesktop.org/libinput/libinput/-/issues/729 After libinput implements this it should also be fixed on the wlroots/sway and gtk/qt side.

Another option would be to use same "hacks" as on X, one could modify sway to add such scrolling gesture support, sway already has some gesture support for a touchpad, not sure how nice it would work with an absolute device like this.