[Feature Request] CI instead real machines

[Drsheppard01]

It's possible to make CI build with installing any WM/DE and wlprobe and start test?

For example Fedora Rawhide has hyprland, labwc, Weston, wayfire, river, miracle-wm

[bbb651]

While not all compositors have an headless mode, I (think?) all of them support running nested in another compositor, so I think it should be possible to run weston in headless mode, spawn a different nested compositor, which itself is set to spawn wlprobe, and pass the information back out through a named pipe.

[GalaxySnail]

Do compositors provide different protocols depending on the hardware environment? For example, wlroots doesn't provide the linux-dmabuf protocol when using the pixman renderer. [1] I'm not sure if other compositors have similar issues.

[1] https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3844

[bbb651]

That's annoying, I think we can compare the new support data to the existing one every time and error on regressions because it's highly unlikely compositor support regresses, so worst case we'll miss newly added interfaces/versions that regress, and it can be easily verified manually.

I got a proof of concept working with niri, which is sort of a worst case because it doesn't forward client output at all and has no option to set a custom wayland socket (it's hardcoded with the default smithay logic, I've happened to read that code before it basically finds the lowest unused wayland-N so it's possible to predict but it seems too fragile), but using a named pipe works:

weston -Bheadless -Sweston &
mkfifo /run/user/1000/output
WAYLAND_DISPLAY=weston niri -- bash -c "wlprobe > /run/user/1000/output" &
cat /run/user/1000/output

I think this should also work running all the compositors in parallel, as weston supports this for testing.

[bbb651]

I just compared the output and you're right, it's already a problem, the following interfaces don't show up in this setup:

• wl_drm
• wl_eglstream_display
• wp_drm_lease_device_v1
• zwlr_gamma_control_manager_v1
• zwp_linux_dmabuf_v1

These all seem DRM related, once again weston comes to the rescue, although I still need to figure out how to use VKMS.

@PolyMeilex I also noticed wl_output appears twice in niri.json and cosmic.json because I created them with two monitors, maybe wlprobe should deduplicate them?

[PolyMeilex]

@PolyMeilex I also noticed wl_output appears twice in niri.json and cosmic.json because I created them with two monitors, maybe wlprobe should deduplicate them?

Oh, yeah, I never noticed as I'm always using a VM to generate those. But judging by the fact that wlprobe is supposed to be wayland-info alternative it should output all advertised globals. Perhaps we can add a dedup cli flag, or just postprocess the output in JS if needed.

[bbb651]

I managed to get DRM somewhat working with VKMS (with the weston drm backend instead of headless, should still run heedlessly on CI), and it solves wl_drm and wl_eglstream_display. I do get a permission denied error every time it tries to paint, which makes sense as /sys/devices/platform/vkms/drm/card* is owned by root and LIBSEAT_BACKEND=noop (it's the only one that worked for me, although I haven't tried builtin yet because it looks like the build I have from arch has it compiled out)

[13:35:10.348] atomic: couldn't commit new state: Permission denied
[13:35:10.348] repaint-flush failed: Permission denied

Script:

sudo modprobe vkms
WESTON_TEST_SUITE_DRM_DEVICE=$(basename /sys/devices/platform/vkms/drm/card*) LIBSEAT_BACKEND=noop weston -Bdrm -Sweston
mkfifo /run/user/1000/output
WAYLAND_DISPLAY=weston niri -- bash -c "wlprobe > /run/user/1000/output" &
cat /run/user/1000/output

Edit: I forgot WESTON_TEST_SUITE_DRM_DEVICE (and WESTON_TEST_SUITE_ALLOC_DEVICE which I wanted to try for dmabuf with vgem) do nothing outside the weston test compositor, LIBSEAT_BACKEND=noop weston -Bdrm --drm-device=card1 -Sweston does stop most of the errors but wl_drm and wl_eglstream_display don't show up anymore... I'm starting to lose hope in the nested compositor approach, even without the weston problem I'm not even sure all compositors support all features in this environment, particularly with things like zwlr_gamma_control_manager_v1. Writing a custom seatd backend sounds like it would work, but it might be a lot of effort and it won't work on at least Gnome and KDE (I found this commit but doesn't look like it ever got merged). Alternatively we can go the other direction and just slap a VM inside github actions (it doesn't support kvm, maybe qemu could work?), actually on a headless system maybe just vkms + vgem and a normal starting sequence could work, as it would look pretty similar to regular machine?