[bug] Tablet input detected but unable to draw

[kjkent]

Observations:

• Unable to draw when using tablet stylus, despite pen-{down,up} events being detected (logs below)
• The stylus cursor is never shown, whether using mouse or stylus, it's always on the mouse cursor (console logs do show a difference when using mouse vs stylus, however)
• The primary (front) and secondary (rear) stylus button actions are swapped
• Mouse input works as expected
• Inconsistent and brief canvas movement seen on primary stylus button press/move. As this is the behaviour of the middle mouse button, I wonder if there's some kind of clash between input modes.

To Reproduce

• Open rnote
• Attempt to draw using tablet

Expected behavior

• Pen-down events result in drawing
• Stylus buttons map to correct actions
• Cursor reflects input device

Console Output

Timestamps might be a bit jumbled as I've cherrypicked events from the avalanche of event logs. I've tried to preserve event order, at least.

Movement & pen touch:

GTK_DEBUG=interactive rnote:

motion 482.050781 466.738281, seat 0x55691671a270 state 0
tablet motion 482.050781 466.738281
tablet tool 1 distance 65535
tablet frame, time 3185890
pointer surface of seat 0x55691671a270 left output 0x55691673c3c0
pointer surface of seat 0x55691671a270 entered output 0x55691673c3c0
tablet tool 1 pressure 44799
motion 481.824219 466.964844, seat 0x55691671a270 state 0
tablet motion 481.824219 466.964844
tablet frame, time 3185903
motion 481.253906 467.988281, seat 0x55691671a270 state 0

RUST_LOG=debug RUST_BACKTRACE=1 rnote:

62.207863692s TRACE rnote::canvas::input: element=Element { pos: [[171.234375, 420.3359375]], pressure: 0.8937056534676128 } pen_state=Proximity modifier_keys={} pen_mode=Some(Pen) event_time_delta=0ns msg="handle pen event element"
  62.224829769s TRACE rnote::canvas::input: canvas event MotionNotify - gdk_modifiers: ModifierType(0x0), is_stylus: true

wev:

[4278190081:zwp_tablet_tool_v2] down: serial: 2471
[4278190081:zwp_tablet_tool_v2] frame: time: 1373067
[4278190081:zwp_tablet_tool_v2] motion: x, y: 105.324219, 383.757812
[4278190081:zwp_tablet_tool_v2] pressure: 51846 (0.791)
[4278190081:zwp_tablet_tool_v2] up

libinput debug-events:

event28  TABLET_TOOL_TIP              +49.961s         15.93*/48.76*   pressure: 0.51* down
event28  TABLET_TOOL_AXIS          4  +49.991s         16.19*/48.74*   pressure: 0.70*
event28  TABLET_TOOL_TIP              +50.321s         29.10*/43.14*   pressure: 0.00* up

Pen button 1:

GTK_DEBUG=interactive rnote:

# button down
motion 391.222656 357.500000, seat 0x55691671a270 state 0
tablet frame, time 3552006

# button up
tablet frame, time 3552082
frame 0x55691a02f0f0

RUST_LOG=debug RUST_BACKTRACE=1 rnote:

265.756767817s TRACE rnote::canvas::input: canvas event ButtonPress - gdk_button: 2, is_stylus: true
265.966858505s TRACE rnote::canvas::input: canvas event ButtonRelease - gdk_button: 2, is_stylus: true
265.877480038s TRACE rnote::canvas::input: canvas event MotionNotify - gdk_modifiers: ModifierType(BUTTON2_MASK), is_stylus: true

wev:

[4278190081:zwp_tablet_tool_v2] button: serial: 2638;  button: 331 (stylus), state: 1 (pressed)
[4278190081:zwp_tablet_tool_v2] button: serial: 2639;  button: 331 (stylus), state: 0 (released)

libinput debug-events:

event28  TABLET_TOOL_BUTTON           +3.196s  s331 (BTN_STYLUS) pressed, seat count: 1
event28  TABLET_TOOL_BUTTON           +3.286s  s331 (BTN_STYLUS) released, seat count: 0

Pen button 2:

GTK_DEBUG=interactive rnote:

# button down
motion 458.406250 665.437500, seat 0x55691671a270 state 0
tablet frame, time 3751764
frame 0x55691a02f0f0

# button up
tablet frame, time 3752268
frame 0x55691a02f0f0

RUST_LOG=debug RUST_BACKTRACE=1 rnote:

408.281247637s TRACE rnote::canvas::input: canvas event ButtonPress - gdk_button: 3, is_stylus: true
413.963237199s TRACE rnote::canvas::input: canvas event ButtonRelease - gdk_button: 3, is_stylus: true
408.310687312s TRACE rnote::canvas::input: canvas event MotionNotify - gdk_modifiers: ModifierType(BUTTON3_MASK), is_stylus: true

wev:

[4278190081:zwp_tablet_tool_v2] button: serial: 2905;  button: 332 (stylus2), state: 1 (pressed)
[4278190081:zwp_tablet_tool_v2] button: serial: 2906;  button: 332 (stylus2), state: 0 (released)

libinput debug-events:

event28  TABLET_TOOL_BUTTON           +6.382s  s332 (BTN_STYLUS2) pressed, seat count: 1
event28  TABLET_TOOL_BUTTON           +6.526s  s332 (BTN_STYLUS2) released, seat count: 0

Desktop (please complete the following information):

• OS: Arch Linux
• App Version: 0.13.1
• Installation Source: Arch Linux repos (extra/rnote)
• Desktop Environment: Hyprland 0.51.1
• Display Server: Wayland
• Input Source: External tablet (Wacom Intuos (CTL-4100))

Additional context Thanks in advance, rnote looks awesome + I look forward to using it.

[Doublonmousse]

Can you run

GTK_DEBUG=interactive rnote

Go to the global tab and copy/paste the content (in particular I want to know the gtk4 version)

The primary (front) and secondary (rear) stylus button actions are swapped

Are the libinput mappings inverted as well? Probably not a big deal as you can remap them

Inconsistent and brief canvas movement seen on primary stylus button press/move. As this is the behaviour of the middle mouse button, I wonder if there's some kind of clash between input modes.

That's probable here. Although the thing is that in previous versions this was the way to detect the pen down event. And on gnome 48 this meant that you had to set the pen buttons a certain way (middle click !) on gnome so that it would work in rnote (this changed from the versions from before)

Can you run gtk4-demo and see if you can draw in the Paint demo with stylus only activated? In practice this is the most official demo app to showcase the pen input feature, so if this doesn't work or doesn't use the correct API gtk came up with this is a gtk4 issue.

I believe this is the same issue as https://gitlab.gnome.org/GNOME/gtk/-/issues/7781 where something broke between gtk 4.18 and 4.20 ?

Does changing the mappings (application defined vs the other options) for the pen buttons affect this

[dr-moreira]

Describe the bug Wacom tablet pressure stopped working in Rnote after GTK4 upgrade to 4.20.1 on Wayland (Hyprland).

Environment

• OS: Arch Linux
• Rnote version: 0.13.1
• GTK4 version: 4.20.1
• Compositor: Hyprland 0.51.1
• Tablet: Wacom Intuos S 2

To Reproduce

1. Update GTK4 from 4.18.6 to 4.20.1
2. Open Rnote on Wayland
3. Try to draw with tablet pressure
4. Pressure doesn't work

Expected behavior Tablet pressure should work as it did with GTK4 4.18.6

Workaround

• Downgrade GTK4 to 4.18.6: works ✓
• Run with GDK_BACKEND=x11: works ✓
• libinput debug-events shows pressure correctly

This appears to be a GTK4 4.20.1 regression on Wayland.

[Doublonmousse]

So,

• When clicking on a pen button then getting it on a screen, I expect to see in order

button press x -- as soon as the pen button is both pressed and in range 
MotionNotify - gdk_modifiers: ModifierType(BUTTON1_MASK) -- when the pen touches the screen

The mapping from gdk button to pen button is done in retrieve_button_shortcut_key (BUTTON_SECONDARY for primary pen button and BUTTON_MIDDLE for the secondary one.)

I'm seeing BUTTON3_MASK and BUTTON2_MASK in the gdk_modifiers, are you testing with the pen already on the screen ?

For the movement then pen touch

62.207863692s TRACE rnote::canvas::input: element=Element { pos: [[171.234375, 420.3359375]], pressure: 0.8937056534676128 } pen_state=Proximity modifier_keys={} pen_mode=Some(Pen) event_time_delta=0ns msg="handle pen event element"
  62.224829769s TRACE rnote::canvas::input: canvas event MotionNotify - gdk_modifiers: ModifierType(0x0), is_stylus: true

I'd expect a gdk_modifiers: ModifierType(BUTTON1_MASK) as this (in principle) should be used to differentiate proximity to pen down.

But you see the modifier is not here even though the pressure is >0.

I can workaround this part to an extent like I did here on Windows though, see https://github.com/flxzt/rnote/pull/1113/files#diff-488bca4d88a2d32fbe68851282e211cf93e04b446a54e79a25f4e73081d86de2R180-R191

Though pretty sure I don't need to do the second part I had to do on windows. I'm going to wait on a response on the gtk side and maybe spin a branch with that manual workaround later today depending on the response

[lennartbrandin]

Environment Really same setup except perhaps the devices Tablet: Wacom Pen and multitouch sensor Pen/Finger (By Libinput)

Workaround

* Downgrade GTK4 to 4.18.6: works ✓
* Run with GDK_BACKEND=x11: works ✓
* libinput debug-events shows pressure correctly

This appears to be a GTK4 4.20.1 regression on Wayland.

Changing Backend works but has other drawbacks if using wayland setup. Downgrading has other issues for me (as one might expect), parts of UI being invisible, but the pen pressure works.

Particularly the breaking change seems to appear between 4.19.3 and 4.19.4.

[Doublonmousse]

Particularly the breaking change seems to appear between 4.19.3 and 4.19.4.

Thanks. Pretty sure it's from https://gitlab.gnome.org/GNOME/gtk/-/commit/237738028639e0238ec2a30a34987d5ab7311a83#e2e44794dfe2b8d2d6b138fd252e925b06b20813_3055_3083

In the meantime, running a nightly with a workaround. See https://github.com/Doublonmousse/rnote/actions/runs/18138828610 and https://github.com/flxzt/rnote/blob/main/BUILDING.md#nightlies to install the nightly once it finishes (ETA 30 minutes).

Although maybe the flatpak is not affected if it's not yet on the Gnome 49 sdk? And installing the flatpak would be a temporary solution? Anyway the branch is here https://github.com/Doublonmousse/rnote/tree/workaround_gtk_pen_down

Reporting on https://gitlab.gnome.org/GNOME/gtk/-/issues/7793 upstream

[lennartbrandin]

The provided nightly works for me, thanks you.

[Svampebob1]

I can report that the Flatpak version also solves the issue.

[anesthetice]

Doublonmousse's patch fixes the issue of the stylus not being detected at all

// workaround for issue https://gitlab.gnome.org/GNOME/gtk/-/issues/7793
#[cfg(target_os = "linux")]
{
    if element.pressure > 0.0 && is_stylus {
        pen_state = PenState::Down;
    }
}

But now I have another issue where a line is drawn between the end of a previous segment and the start of a new segment...

The patch itself doesn't cause this issue, as downgrading gtk fixed it (patch still applied)

[Doublonmousse]

But now I have another issue where a line is drawn between the end of a previous segment and the start of a new segment...

Well that's a bother. Maybe the pen up can be forced. Something like

    if element.pressure == 0.0 && is_stylus {
        pen_state = PenState::Up;
    }

Or use the flatpak in the meantime (the patch doesn't actually matter for the flatpak actually as the gtk version is 4.18.x on it)

[anesthetice]

But now I have another issue where a line is drawn between the end of a previous segment and the start of a new segment...

Well that's a bother. Maybe the pen up can be forced. Something like

if element.pressure == 0.0 && is_stylus {
    pen_state = PenState::Up;
}

Or use the flatpak in the meantime (the patch doesn't actually matter for the flatpak actually as the gtk version is 4.18.x on it)

That worked, thank you!

[keithfernandez0]

I had the same issue with my stylus pen (also on Arch Linux host machine) and reverting back to GTK 4.18.6 restores the functionality of the pen, but with degraded GUI if using wayland as other users have pointed out.

[mbussler1]

Will there be a new release with the patch included?

[JadenJSJ]

For Arch users I made a rnote build with Doublonmousse's patch

Hopefully it will serve helpful to someone :D https://github.com/JadenJSJ/rnote/releases

Download the release non debug build and install with pacman -U rnote-tablet-fix-0.13.1-1-x86_64.pkg.tar.zst

I took the PKGBUILD from the Arch Gitlab.