Add wayland support with SDL_VIDEODRIVER=wayland

[horriblename]

Adds support for using the wayland SDL backend. Needs to be "enabled" by the user by running with the environment variable SDL_VIDEODRIVER=wayland

So far nothing "meaningful" is done - I just made it not crash under wayland, tablet and
clipboard (and probably more) support is presumably broken for now.

TODO:

• implement wayland support for tablet
• why are text not rendering?
• handle touch screen events instead of relying on SDL - SDL is kinda buggy when gestures are involved
• fix text input protocol being "active" by default

If there are other code that depends on X11 that you know of, I would appreciate a mention :)

Note that I'm not going to make wayland the default because upstream SDL doesn't and I'm not smart
enough to understand why.

[pbsurf]

Could you provide some more info on the crash you encountered: Linux distro, version, window manager, etc. Was XWayland not installed? I haven't looked into Wayland support because I assumed that there are enough other X applications that X support would remain for the foreseeable future ... but maybe I am mistaken?

Is all text missing from the UI? This can happen if Roboto-Regular.ttf is not in the same folder as the executable (although there should be dialog that appears in this case).

[horriblename]

Regarding the crash, it only happens when wayland backend is explicitly used via SDL_VIDEODRIVER=wayland (I should've put it in the title, my bad). I'm looking to add native wayland support because running through xwayland comes with its own problems, e.g. in Hyprland, when fractional scaling is enabled, xwayland apps are not scaled properly and appear pixelated. This may very well be a Hyprland problem, I didn't really test on other WMs. I just thought that adding support for wayland would be good long-term

back to the crash, it was due to SDL_GetWindowWMInfo returning different union variants based on the backend used (SDL_VIDEODRIVER)

Red-hat marked xorg as deprecated some time ago, but I don't think xwayland is going away anytime soon, so you're not wrong in thinking X apps would continue to work.

Is all text missing from the UI? This can happen if Roboto-Regular.ttf is not in the same folder as the executable (although there should be dialog that appears in this case).

I didn't see any dialog, but I'll double-check tomorrow, thanks

[pbsurf]

Sure, native Wayland support would be welcome. I don't think there is X-specific code in any other files. Happy to answer any other questions that come up.

[horriblename]

This can happen if Roboto-Regular.ttf is not in the same folder as the executable

this was indeed the fix

---

right now SDL seems to handle touch events fine (with some caveat below). Should I rely on SDL's builtin touch support or read raw touch events from wayland and re-emit SDL ones (like in the xorg tablet handler)? I'm not really sure if the touch support exists in the current SDL submodule, but since on linux it's recommended to USE_SYSTEM_SDL perhaps that's not a problem...?

There is currently a "bug" where: SDL_Event.tfinger.x and y are supposed to be a float between 0 and 1 (doc), but the xorg handler emits the pixel position instead (presumably the same problem happens on all platforms). Should I fix this first for all platforms, in a separate PR? The other option would be to continue with this wrong interpretation in the wayland backend, I don't really know what consequences either option will bring

---

SDL3 has builtin support for tablets it seems. Not saying you should migrate, but just want to know if there are plans to do so - if there are, it might make more sense for me to wait for a SDL3 migration to take advantage of the builtin tablet support

[pbsurf]

I would recommend bypassing SDL for all mouse, touch, and pen input as is done for X in the current linuxtablet.c

Using pixel positions instead of normalized values for tfinger.x,y is intentional, although I don't recall exactly why I did this - maybe just because none of the underlying platforms use normalized values. If SDL_FINGER_NORMALIZED is defined, svggui.cpp will assume normalized values so unmodified SDL would work.

I don't plan to migrate to SDL3. I haven't looked carefully at how it implements tablet support for other platforms, but on Windows it doesn't appear to support high resolution position data (POINTER_INFO.ptHimetricLocation) or batched points (GetPointerPenInfoHistory()), both of which are necessary for the best possible fidelity.

I intend to replace SDL with the platform support from styluslabs/maps. For Linux that's linuxmain.cpp, most of which is just cut-and-paste from Write's linuxtablet.c, so creating a wayland version of linuxtablet.c now wouldn't be any wasted work.