Wayland support

[WilliamImm]

I'm looking to use a Wayland-based DE/compositor in the future over X11, and I'm what barriers there would be to using HUDKit on Wayland. Has this been tested?

For context, IINACT recommends HUDKit for overlays on Linux, and I want to make sure this works as well without having to go and use an X11-based environment.

[anko]

It "should" work in theory, but I haven't gotten it to work in my rudimentary tests. (I don't use Wayland day-to-day.)

All of the windowing operations in hudkit use GTK3 currently, which has a Wayland backend in addition to X11, and doesn't document having any relevant platform limitations. But it seems there are many undocumented limitations, because running hudkit in weston-x11 (Wayland within X11), doesn't work: no visual, but mysteriously no errors either. I haven't debugged it further than that, because there is no obvious starting point and I don't know enough about Wayland to guess.

Perhaps the limitation is in weston, and a proper full Wayland desktop would work? I haven't tested one. If you want to test it, you should be able to run the example as per the readme, without changes. If it doesn't work, try export GDK_BACKEND=wayland first, to make extra sure the Wayland backend is used.

Technical notes on feasibility of future upgrade to GTK4

It seems the idiomatic way to make an overlay window on Wayland, as used by https://github.com/francma/wob, is an unstable Wayland protocol feature "wlr-layer-shell-unstable-v1". I don't know if there are alternatives, or what GTK3/GTK4 use to implement e.g. gdk_window_set_override_redirect or gtk_window_set_keep_above.

I would really rather rely on GTK than add platform-specific code paths. If GTK says it has a Wayland backend, but can't actually do the same thing on Wayland as on X11, that's a GTK limitation that should be fixed in GTK.

Currently-unstable webkitgtk-6.0 might have better Wayland support through GTK4. Migrating to that would take some effort and it also means migrating from GTK3 to GTK4. We can't migrate to GTK4 separately; each WebKit version depends on a specific GTK version.

I would like to stick to the stable WebKit API for ease of maintenance; the previous unstable webkitgtk-5.x never became stable for example, and many distros don't package it anymore. I would be open to starting a migration effort on a separate branch though, since the GTK4 API is stable even if the corresponding WebKit isn't yet, and I'd expect most of the migration to be GTK changes rather than WebKit.

[WilliamImm]

I can test w/ a few representative examples of Wayland envs: KDE Plasma & Sway (wlroots-based compositor). Enough to see what might be needed, or might not be needed (hopefully).

Gimme a little and I'll set it up.

[cptn-cosmo]

For me it generally seems to work on wayland (KDE Plasma 6 in this case) but the position is off, which might be due to my displays using different resolutions and I don't understand how i can make the overlay window smaller and move it to sa specific location, which would be my usecase to use it as a DPS meter overlay for the game...

[anko]

@cptn-cosmo Thanks for testing this. I am pleasantly surprised that it works even that well. I want to fix that bug and support your use-case.

The detected monitor coordinates shown in the top-left debug information look correct to me, so the fault must be with how the overlay is being positioned. It is positioned based on the same monitor coordinates though, which are correct…

My first suspicion is that something else moves the window after it positions itself. I remembered reading in GTK docs that some window managers ignore window move requests until after the window becomes visible, instead doing their own "smart" window positioning. So I added (024bfb6), which tries to reposition the window correctly again after the window becomes visible.

Could you test again with that change included? It's on the master branch.

[Crosant]

For me it generally seems to work on wayland (KDE Plasma 6 in this case) but the position is off, which might be due to my displays using different resolutions and I don't understand how i can make the overlay window smaller and move it to sa specific location, which would be my usecase to use it as a DPS meter overlay for the game...

Same problem for me on two monitors with the same resolution, so that is not the problem, also happens with 024bfb6 applied

[redeven]

wayland (KDE Plasma 6 in this case)

Not sure if it's just a KDE Wayland specific issue, but there's a KDE specific workaround, you can just add a Window Rule for hudkit. These settings spawn it at the top-left corner as expected, and make sure it stays as an overlay on top of everything else, doesn't have a border or titlebar, and it doesn't show up on the taskbar or when alt+tabbing.