Tablet issues with clicks and focus.

[Vladimir-csp]

$ hyprland --version
Hyprland 0.48.1 built from branch  at commit 29e2e59fdbab8ed2cc23a20e3c6043d5decb5cdc dirty (version: bump to v0.48.1).
Date: Fri Mar 28 19:16:07 2025
Tag: v0.48.1, commits: 5937
built against:
 aquamarine 0.8.0
 hyprlang 0.6.0
 hyprutils 0.5.2
 hyprcursor 0.1.12
 hyprgraphics 0.1.2

Wacom one (but from what was posted in issues, this affects other tablet devices).

Not all events properly affect surfaces. Some cases:

1

• Try changing focus by clicking (with pen or other buttons) (with follow_mouse = 2).

2 (may take several attempts to reproduce):

• Open Firefox
• With tablet's right click analog open a context menu
• Try pressing page content away from menu with the pen to close the menu.
• Menu does not close, click is ignored

3

• Open PCmanFM-qt.
• Place cursor somewhere inside the window (with mouse or touchpad)
• Take the pen, open context menu somewhere else in the window
• Menu opens where cursor was put with the touchpad, not at the current (pen) position.

4 (may take several attempts to reproduce)

• Open GIMP
• Try opening menus and selecting items (like File/New) with the pen (from the menu bar or from context menu in the main window).

[dinesh-58]

Screen recordings of issues 1 and 4 are in #9758.

This works when using "mouse mode" in XP-Pen's drivers and OpenTabletDriver, though at that point the tablet is just emulating a USB mouse. Not really suitable for drawing. Might work with some plugins for OpenTabletDriver? Currently don't have the time to test these out.

Also, dragging the pen when holding the mod key (to move /resize the window) doesn't work. Strange cause dragging the pen when holding other keys in drawing apps works fine.

[afrolino02]

This work for me, thanks!

[vaxerski]

the big problem here is I don't have a tablet and thus can't really test, nor understand many parts.

With tablet's right click analog open a context menu

this for example is meaningless to me idk what a tablet right click analog is lol

[Vladimir-csp]

I'll try capturing exactly what an app dumps with wayland debug on various tablet events.

[Vladimir-csp]

tablet_gimp_wldebug_hyprland.log
tablet_gimp_wldebug_sway.log
There are PEN, RIGHT, MIDDLE headers in those files. What I did: opened GIMP and did stuff with tablet

• After PEN events just poked the window with a pen a bunch of times,
• after RIGHT (and pen) events opened menus with right button, closed with pen a bunch of times.
• after MIDDLE events pressed middle button a bunch of times

[darkwater]

I believe this is because window focusing happens in CInputManager::mouseMoveUnified, which is never called for tablet pen movements (which start in CInputManager::onTabletAxis)

Adding a simulateMouseMovement(); at the end of onTabletAxis makes focusing work, but I bet that's not the proper solution

Edit: Interestingly, the following does work:

• Move the cursor over another window
• Take the pen off the tablet (proximity out)
• Hover the pen back on (proximity in)

The window under the cursor is now focused.

Focusing isn't the only issue.

Discord (Vesktop) doesn't seem to take any mouse move events unless it's from proximity-in. Telegram Desktop only takes them after the procedure above, which isn't needed for Firefox (Zen Browser); I can move focus to Firefox with the keyboard, and then the pen works just fine.

Also, the cursor often isn't made visible from pen movements when it's invisible. Basically, it looks like pen movements have their own completely separate code that doesn't do all of the things you'd expect from mouse movement.

[PtaxLaine]

PROTO::tablet->down(PTOOL);
refocus();

PTOOL->buttonsDown.push_back(e.button);
refocus();

@darkwater
It looks like the refocused app may lose the first tablet event. Shouldn't you call refocus() before PROTO::tablet->buttonTool() and PROTO::tablet->down() calls?

[darkwater]

You're probably right, I just don't have a lot of headspace today to thing about the logic much and this still works assuming follow_mouse, since you're gonna move the pen at least a little bit before you can get it close enough for a tip event.

[darkwater]

re. windowrule=tablet2mouse, I think this could be a whole class of helpful rules actually.

Thinking back to when I was tinkering with Waydroid with a touchscreen, the Hyprland cursor kept getting in the way of my interactions with Waydroid, and I think it would also send mouse events to Waydroid in addition to touch events (it's been a while, my memory may very well be inaccurate).

I would like a bunch of rules to have more control over this. For example, to completely disable mouse events from touch inputs on a certain window/workspace. Some applications handle touch well, while others don't have any support at all.

[Espacio-root]

Also, I'm unable to select region with my wacom tablet when using slurp. Upon running the following command:
grim -g "$(slurp)"
I'm unable to drag my stylus to select a region in order to take a partial screenshot.

[PtaxLaine]

@Espacio-root
ATM, slurp doesn't support graphics tablets.

As I wrote above:

In general, if an app doesn’t support the wayland-tablet-v2-protocol, it won’t recognize any tablet events.
We might think of something like windowrule=tablet2mouse,, but (perhaps) that’s a topic for another discussion.

[PtaxLaine]

Since #10110 has been merged, the title topic of this discussion should be resolved.
Currently, I'm aware of a few other tablet-related issues (TODO):

• In some cases, drag-and-drop isn't completed after the pen tip/button release.
• Resizing and moving windows using the pen doesn't work.
• Changing the active window in a group with the pen does not work.
• Need to add mouse events simulation for wayland apps without wayland-tablet-protocol support
  (e.g. windowrule=tablet2mouse,,).
• Sometimes the added simulateMouseMovement() causes Krita to change focus on pen movements — as if input:follow_mouse were activated (when it’s not).
  *I can only reproduce this bug inside a VM.

I bet I forgot to add something to this list…

[darkwater]

One more issue I found but apparently forgot to post is that pointer frame events aren’t sent properly, which clients may expect before they start processing received events. In particular, Rust applications using Smithay will not work correctly

[Vladimir-csp]

Thanks! With v0.49 tablet is now usable with GIMP, at least at a glance.

[ljvdhooft]

Reproducable, with a little caveat:

• Lift up pen outside of hover range
• Put pen back in hover range in the region of another window
• Focus changes