Linux Wayland support

[tonsky]

Assembled from https://twitter.com/nikitonsky/status/1417154031470927876

• Multi-touch touchpad gestures
• Multi monitor with different DPI
• Much less screen tearing with anything that access the hardware directly in some way (e.g. hardware accelerated video).
• Security (e.g. unwanted key logging, screen logging)
• Isolated key input

[jakeisnt]

I'd love to spearhead this if this is still desired! 😁

[tonsky]

It is! It would be awesome. Let me know what you need to get started

[jakeisnt]

Sure! Just wondering how we should set this up in the repository - I'm thinking:

• Rename linux to xorg
• Create new wayland folder with same structure
• In CMake build, if on Linux, identify Wayland by determining whether the current session is Wayland (https://stackoverflow.com/questions/45135228/effective-way-of-detecting-x11-vs-wayland-preferrably-with-cmake), then finding dependency paths (https://github.com/LunarG/VulkanSamples/blob/master/cmake/FindWayland.cmake); fall back to Linux if we don't find them.

Does this sound reasonable?

[tonsky]

should it be xorg or x11? I think we use x11 sometimes in the code base, do you think it should be changed? or better stick with x11, as we already have it?

re: CMake, the question I’m more interested in is, should we build two different runtime libraries or a single one? If two, would we be able to determine at runtime which one to load?

Also, not sure if we need separate build for cmake, since it’s only for build machine. We could require both X11 and Wayland dev dependencies to exist at the same time. Up to you on this one

[jakeisnt]

• Let's use ~X11~ x11 as the name
• Looks like GTK3 builds statically with both Wayland and X11 by default, based on https://github.com/GNOME/gtk/blob/7213bf5b09dfd9d9daf5c30a257a8792e4c66421/meson.build. This seems like something we'd want given that some DEs allow the user to switch between X and Wayland (I think Gnome still does this?). This is a fairly small package, so I don't think size will be a huge issue if we build with both.

We can just check at runtime whether (1) wayland dependencies are available to dynamically link with and (2) whether a wayland server is present and fall back to X if either of those fail

[tonsky]

Sounds like a plan!

[TheDrawingCoder-Gamer]

I want to flag some issues for anyone considering implementing wayland

• wayland is secure, so a lot of "obvious" apis don't exist
  • such as getting window position
• it's likely impossible to directly configure a surface and keep it invisible. Setting it to invisible will require destorying the surface. This is also true for DMA-BUF, so if you want to do GPU sharing you'll have to deal with destroying the surface on layer change
• cursor changes are very special. You can ask for pointer enter, but you have to attach a surface each time, and you can switch images by swapping surfaces on that buffer. I'm kind of confused by "hotspots", as i'm unsure if it changes between cursors - if it does, i'm unsure how to handle it, as you require the serial of the last pointer enter request.
• In general it's more restrictive than other backends. I've been working on a big rewrite, but I've had multiple blockers. I just plain don't quite understand C++ so fighting with the compiler is a part of my process, but I'm hoping to get somewhat working code soon

[tonsky]

Would be very cool to support it natively! Thanks for all the work