Repository navigation
SDL3 migration, Phase 3: pen/pressure input and native window handle - #271
Conversation
|
macOS: tested and working, but found a bug: |
Drops EasyTab (SDL_GetWindowWMInfo/SDL_SYSWMEVENT have no SDL3 equivalent reachable without per-platform native message hooks) in favor of SDL3's native SDL_EVENT_PEN_* events, per #263's R4 recommendation: broader native coverage (Windows Ink, XInput2, Wayland tablet-v2, Cocoa) than EasyTab has today, with no Wintab/XInput1 vs. SDL3-XInput2 conflict to work around (R1). - SDL_EVENT_PEN_AXIS (SDL_PEN_AXIS_PRESSURE) feeds the existing penPressure global that mouse events already read from, mirroring the current finger-pressure-as-pen-proxy pattern. - SDL_EVENT_PEN_PROXIMITY_OUT resets pressure/pointer type, fixing the "stale pressure after the pen last touched the tablet" bug the issue flagged in the existing pointerType handling. - SDL_HINT_PEN_TOUCH_EVENTS is disabled so pen input doesn't also synthesize touch events that would fight the pressure tracking above with a second, less precise value (R5); SDL_HINT_PEN_MOUSE_EVENTS is left at its default so position/clicks keep arriving as ordinary mouse events, unchanged. - SDL3Display::nativeHandle() is ported via SDL_GetWindowProperties() (SDL_PROP_WINDOW_WIN32_HWND_POINTER / _COCOA_WINDOW_POINTER / _ANDROID_WINDOW_POINTER / _X11_WINDOW_NUMBER), replacing the removed SDL_GetWindowWMInfo(); verified against a real X11 window in this session. This direction and the SDL_EVENT_PEN_* handling above have not been validated against real tablet hardware (R1-R3 in the issue all require it); the SDL2 backend's EasyTab path is untouched and unaffected. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Set the SDL video driver hint to "wayland,x11" on Linux when WAYLAND_DISPLAY is set, so Wayland sessions get a native window (with X11 as fallback) instead of XWayland. An explicit SDL_VIDEO_DRIVER/SDL_VIDEODRIVER env var still takes precedence. Refs #145. Pixel-perfect DPI handling is tracked in #315. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Treat mouse events tagged SDL_PEN_MOUSEID as pen input instead of relying on the last pressure value, which is 0 after the pen leaves proximity. The first stroke was reported as a mouse (pressure 1.0) and drew at the fixed brush size. Assisted-by: Claude <noreply@anthropic.com> Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
05f62ee to
b0eec56
Compare
A hovering pen sends no pressure axis events, so the stored pressure stayed 0 after proximity-out and the full-size brush preview was shown until the first touch. Mark the pen as present on proximity-in and pen motion. Assisted-by: Claude <noreply@anthropic.com> Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The synthesized double click was emitted after the second release, and ui::Widget turns it into a mouse down with no matching release, so a freehand stroke kept running at 1px. Emit it in place of the second press instead, mark the button pressed in the manager, and keep the pen pressure through the conversion. Assisted-by: Claude <noreply@anthropic.com> Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Tested on macOS -- latest patchset OK |
Hard to even test, because the still active pressure makes the app regain focus immediately, but looks to be working properly (no weird pressure spikes noticed) |
256d177 to
c0eeb63
Compare
|
Windows: |
93faa9e to
b2cabc6
Compare
|
SDL3 backend tablet support works ✅, it's EasyTab that doesn't |
I am not sure about EasyTab, but clippy for sure does not support Wayland natively, so running in a XWayland session to at least have some partial KWayland/xwayland-sattelite wrapping over X11 clipboard looks like a safer choice.
b2cabc6 to
b62da0e
Compare
|
Xfce X11 session: OK |
Summary
Part of #73. Closes #263.
This phase's issue flagged an architectural decision (R4) that needed to be made before implementing anything: whether to keep the vendored EasyTab library (patching its WM plumbing for SDL3), drop it entirely for SDL3's native pen API, or run a hybrid. Per discussion, we went with dropping EasyTab and using SDL3's native
SDL_EVENT_PEN_*events, matching the issue's own recommendation — broader native pen coverage (Windows Ink, XInput2, Waylandtablet-v2, Cocoa) than EasyTab has today, and it sidesteps the X11 XInput1-vs-XInput2 conflict the issue raised as a high-risk open question (R1).Changes
SDL_EVENT_PEN_AXIS(whenaxis == SDL_PEN_AXIS_PRESSURE) feeds the existingpenPressureglobal that mouse events already read from — same pattern as the existing finger-pressure-as-pen-proxy hack, just fed by a real pen axis instead of a touch digitizer's pressure field.SDL_EVENT_PEN_PROXIMITY_OUTnow resetspenPressureto 0 andpointerTypeback toMouse— EasyTab never reset this, so a plain mouse click after the pen last touched the tablet would get misreported as pen input with stale pressure.SDL_HINT_PEN_TOUCH_EVENTSis disabled so pen input doesn't also synthesize touch events that would fight the pressure tracking above with a second, less precise value.SDL_HINT_PEN_MOUSE_EVENTSis left at its SDL3 default (enabled), so position/clicks keep arriving as ordinarySDL_EVENT_MOUSE_*events exactly as before — no change needed to the mouse-event handling added in Phase 2.SDL_EVENT_PEN_PROXIMITY_IN/DOWN/UP/MOTION/BUTTON_DOWN/BUTTON_UPare consumed silently — position/clicks are already covered by the synthesized mouse events, so there's nothing left to do with them beyond the pressure tracking above.SDL3Display::nativeHandle(): ported viaSDL_GetWindowProperties()+SDL_PROP_WINDOW_WIN32_HWND_POINTER/_COCOA_WINDOW_POINTER/_ANDROID_WINDOW_POINTER/_X11_WINDOW_NUMBER, replacing the removedSDL_GetWindowWMInfo(). This is independent of the pen-input decision above and is used by native file dialogs, thecliplibrary (clipboard), and Explorer/Finder shell integration.SDL3Displayconstructor's"Tablet support: FAILED"placeholder from Phase 0/1 scaffolding, since there's no more per-window tablet loading step to report on.What's explicitly not changed
The SDL2 backend's EasyTab path is untouched — this only affects
she/sdl3/.Test plan
-DUSE_SDL2_BACKEND=off -DUSE_SDL3_BACKEND=on.bin/bespritedlaunches and exits cleanly under a boundedtimeout, no new "Unknown event" spam from the added pen cases.nativeHandle()'sSDL_GetWindowProperties/SDL_PROP_WINDOW_X11_WINDOW_NUMBERpath directly with a standalone SDL3 program in this (X11) session — it returns a real, plausible, nonzero X11 window ID rather than a stubnullptr.she/osx/tablet.mmtap (the issue notes the macOS path doesn't use EasyTab/WM-info at all, so it should be unaffected either way — worth confirming).🤖 Generated with Claude Code