Can't click with tablet pen after SDL3 was enabled

[cosstab]

First, thanks for the good work!

After updating to Osu Tachyon 2026.512.0, pen pressure sensitivity seems to not be working on my Arch Linux PC. I can move the cursor around, but I can't click on anything using my pen. Mouse works fine.

I'm not sure if it's related, but just after opening the game I can see "Screen resolution" appear with a wrong resolution (I'm using 1920x1080).

osu.bug.sdl3.mp4

Logs:

1778562364.runtime.log
1778562364.input.log

Also, the game sometimes won't run (#6750).

Setting OSU_SDL3=0 apparently fixes all these problems.

[cosstab]

I normally use GNOME, but I tried to switch to KDE and I can't reproduce any of those problems, everything works fine.

While running GNOME I also noticed that, in game, the arrow is shown instead of the circle pointer. You can see how the pointer changes when I use tablet vs mouse:

osu.bug.2.mp4

"Loading paused" appears before the game starts, even if I move the pen around.

Maybe it thinks the game is out of focus?

[cosstab]

I noticed that I can click using the pen at the same time that the mouse is moving. It's like the game thinks it's out of focus when it switches to the tablet pointer.

[cosstab]

I stopped the system's OpenTabletDriver service, and now pen click seems to work normally on GNOME. On KDE, or with OSU_SDL3=0, it works whether or not the service is running.

GNOME can show multiple cursors on screen, but KDE alternates between mouse or tablet depending on what's being used. I wonder if the problem is related to that.

I also made a bit of debugging using the framework's flappy game template and saw some related weird behavior, I will post more about that when I have free time.

[Susko3]

I noticed that I can click using the pen at the same time that the mouse is moving. It's like the game thinks it's out of focus when it switches to the tablet pointer.

Could you test this in osu!framework visual tests: test name "ActiveState"? If your hypothesis is correct, host.Window.CursorInWindow should be green when pen click is working, and red when it isn't.

[cosstab]

Oh this is better than debugging with the flappy game, lol.

With the system's OpenTabletDriver running, the pen doesn't trigger CursorInWindow:

Osu.otd.running.mp4

I can't click on anything using the pen.

With the OTD service stopped, I have to manually enable Tablet Input and everything works as expected:

Osu.otd.stopped.mp4

With SDL2 and OTD running, mouse and pen work, but sometimes CursorInWindow is green when both cursors are outside.

[cosstab]

Actually, in KDE the pen doesn't trigger CursorInWindow either. It's only triggered by the mouse in both cases.
The main difference is that if I move the mouse inside the window, CursorInWindow always stays on:

osu.kde.mp4

In GNOME, if I move the mouse inside, CursorInWindow turns off when the pen moves but the mouse isn't moving:

osu.gnome.mp4

Also I noticed that in GNOME the mouse cursor sometimes "wants" to stay inside the window. But this doesn't happen in KDE:

osu.gnome.2.mp4

[Susko3]

Thanks for testing, I have a fix in mind. Could please you confirm this for me:

1. Set envvar SDL_EVENT_LOGGING=2
2. Make sure that you get SDL_EVENT_PEN_PROXIMITY_IN when the pen enters the window (both when entering over the window edge and when entering tablet detection range)
3. Make sure that you get SDL_EVENT_PEN_PROXIMITY_OUT when the pen leaves the window (both when leaving over the window edge and when leaving tablet detection range)

You can also try this with my fix: https://github.com/Susko3/osu-framework/tree/fix-pen-clicking. Use the ActiveState test to check.

4. Additionally with my fix, check that the mouse position doesn't do anything weird when the the pen enters/leaves window edge/detection range

[cosstab]

SDL_EVENT_PEN_PROXIMITY_IN/OUT seems to behave as you expected.
With your fix, I noticed that CursorInWindow isn't disabled by SDL_EVENT_PEN_PROXIMITY_OUT if host.isActive is true. But now I can click on things with the pen :)
Left cursor is mouse, right is pen:

pen.fix.testt.mp4

I saw that there's a margin around the window where proximity gets triggered (I'm not sure if that's a problem). And if I don't move the pen while it's inside the window, it triggers PROXIMITY_OUT, and PROXIMITY_IN when movement is detected again:

pen.fix.test2.mp4

All of this behavior is now identical in GNOME and KDE. But the "mouse doesn't want to escape out of the window" thing, keeps happening in GNOME like before. I have to move it fast in order to get it out. Not a problem with the pen, though.