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"](https://wayland.app/protocols/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`](https://webkitgtk.org/reference/webkitgtk/unstable/index.html) might have better Wayland support through GTK4. [Migrating to that would take some effort](https://github.com/WebKit/WebKit/blob/11d5d62ba36c7db1aab5cdf2b465dc8a8890eaf9/Source/WebKit/gtk/migrating-to-webkitgtk-6.0.md) and it also means [migrating from GTK3 to GTK4](https://docs.gtk.org/gtk4/migrating-3to4.html). 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 (https://github.com/anko/hudkit/commit/024bfb6fd25a6ac91c6d9ba67a551d6ffca633ff), 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 https://github.com/anko/hudkit/commit/024bfb6fd25a6ac91c6d9ba67a551d6ffca633ff 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.

[xxcrabx]

I'm also using Wayland and trying to make this work for IINACT but I seem to run in a very different issue. The run.sh seems to open and I don't get any errors but the blue overlay doesn't appear and after quite some time of waiting it just opens a web inspector that crashes after a few seconds. I know there's no "official" Wayland support but I wanted to add my experience since I've got a different result.

[Helios747]

I have a different issue as well. I can get the overlay to act as an overlay using the rules @redeven posted, but I can't click on any button in the overlay, like allowing audio access. On FFXIV raiding overlays I also can't click the settings buttons on them.

Additionally, I can't figure out how to resize or position any of the overlays. For example, DPS meters for FFXIV are stuck taking up the whole screen and I can't figure out how to make it smaller.

More people are going to come looking for wayland support as multiple major distros are now defaulting to it on all GPUs.

[mgunyho]

Hi, I just tried the example on Sway with a multi-monitor setup, and there are a few issues:

• Mouse clicks and keyboard events are not passed through to any windows underneath
• All of the monitor outlines are on the same monitor. Hudkit just opens a window that is the size of the largest monitor, and everything is inside that. All of the x and y coordinates are zero:

  file:///tmp/hudkit-test/page.html:91:28: CONSOLE LOG [
  {
    "name": "0x0BCA",
    "x": 0,
    "y": 0,
    "width": 1128,
    "height": 752
  },
  {
    "name": "BenQ 241W",
    "x": 0,
    "y": 0,
    "width": 1920,
    "height": 1200
  },
  {
    "name": "ASUS PA238",
    "x": 0,
    "y": 0,
    "width": 1920,
    "height": 1080
  }
  ]

• One of my monitors (asus PA238) is in portrait orientation, but hudkit doesn't recognize this

Here's a screenshot showing my screen layout and how hudkit opens (when launching from the central monitor):

[alextwomey]

Running on wayland gives me this error: Gdk-Message: 19:05:59.007: Error 71 (Protocol error) dispatching to Wayland display.

[justinkv]

Running on wayland gives me this error: Gdk-Message: 19:05:59.007: Error 71 (Protocol error) dispatching to Wayland display.

I also get the same error, I set WAYLAND_DEBUG to 1 and it provides some more details:

[4131544.556] wl_callback#49.done(24260)
[4131544.565]  -> wp_linux_drm_syncobj_manager_v1#35.get_surface(new id wp_linux_drm_syncobj_surface_v1#49, wl_surface#42)
[4131544.569]  -> wp_linux_drm_syncobj_manager_v1#35.import_timeline(new id wp_linux_drm_syncobj_timeline_v1#39, fd 44)
[4131577.655] {Default Queue}  -> wl_surface#42.attach(wl_buffer#47, 0, 0)
[4131577.668] {Default Queue}  -> wl_surface#42.set_buffer_scale(2)
[4131577.672] {Default Queue}  -> wl_surface#42.damage(0, 0, 2752, 1152)
[4131577.677] {Default Queue}  -> xdg_toplevel#44.set_min_size(2752, 1152)
[4131577.681] {Default Queue}  -> xdg_toplevel#44.set_max_size(2752, 1152)
[4131577.686] {Default Queue}  -> xdg_surface#43.set_window_geometry(0, 0, 2752, 1152)
[4131577.706] {Default Queue}  -> wl_surface#42.frame(new id wl_callback#40)
[4131577.710] {Default Queue}  -> wl_surface#42.commit()
[4131578.641] {Display Queue} wl_display#1.error(wp_linux_drm_syncobj_surface_v1#49, 4, "explicit sync is used, but no acquire point is set")
Gdk-Message: 18:54:03.817: Error 71 (Protocol error) dispatching to Wayland display.

Googling that debug error makes me think it's an issue with NVIDIA drivers, there was a workaround mentioned here that does seem to allow the overlay to come up without crashing and I'm able to open some webpages that then show up in a window.

The example page though is crashing with segmentation fault, haven't found out what is causing that yet.

347976 segmentation fault (core dumped) WEBKIT_DISABLE_DMABUF_RENDERER=1 hudkit "file:///home/*****/page.html"