WayfireWM: update to 0.11

[dogknowsnx]

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, x86_64-glibc
• I built this PR locally for these architectures (if supported. mark crossbuilds):
  • x86_64-musl

Changelog

EDIT: possible blocker

cc @ericonr

[viper968]

Tested this on Void x86_64 (glibc), and it builds and runs cleanly.

Build: ./xbps-src pkg wayfire with no patches, against wlroots0.20-0.20.2_1 from the repo. wf-config 0.11.0 builds cleanly too. No build warnings of note.

Runtime: running 0.11.0 as a daily driver in an LXQt + Wayfire session (Intel i5-12500H iGPU + NVIDIA RTX 3050 Ti, single eDP output). Session starts normally, existing wayfire.ini from 0.10.1 was picked up without migration, and screen sharing through xdg-desktop-portal-wlr works.

Per-window capture also works, which was my reason for wanting 0.11 — though to be precise, that needs more than this PR: the new ext-toplevel plugin (new in 0.11, provides ext_foreign_toplevel_list_v1) and the out-of-tree wf-copy-capture plugin for ext_foreign_toplevel_image_capture_source_manager_v1, which Wayfire core intentionally doesn't provide. wf-copy-capture requires wayfire >= 0.11.0, so this PR is a hard prerequisite for it.

Re: WayfireWM/wayfire#3097 — worth noting that report is filed against 0.12.0-a352aa3b (master) on an AMD Radeon 760M, not against the 0.11.0 release. So it may not be a blocker for this PR at all. I can't reproduce it either way since I'm on Intel/NVIDIA, and I haven't specifically exercised the vk-color-management plugin — but I've seen no rendering artifacts in normal desktop use.

One note for anyone else testing this branch: building it as-is currently pulls in a from-source rebuild of mesa (and therefore LLVM, Vulkan, SPIRV-Tools, rust-bindgen). That's not a problem with the change itself — the branch base pins xorg-server-xwayland against mesa 26.1.5 while the binary repo has 26.1.6, so the exact-version match fails and xbps-src builds it. Applying just the two templates on top of current master avoids it entirely and takes a couple of minutes instead.

Happy to test anything else on this if it helps move it out of draft.

_{Testing done with assistance from Claude (an AI agent); the build and runtime results above are from my own machine.}

[dogknowsnx]

Thanks for testing

Re: WayfireWM/wayfire#3097 — worth noting that report is filed against 0.12.0-a352aa3b (master) on an AMD Radeon 760M, not against the 0.11.0 release.

The changes were merged before the v0.11.0 release: WayfireWM/wayfire#3080 - it's still only a single report, but I think it's "severe" enough in order to wait for a fix/revert.

EDIT: I'll mark this ready for review and leave it up to a member to decide

One note for anyone else testing this branch: building it as-is currently pulls in a from-source rebuild of mesa

Simply rebase before building (EDIT: rebased the branch)

Testing done with assistance from Claude (an AI agent); the build and runtime results above are from my own machine.

This often results in TMI imho

[dogknowsnx]

Fwiw, a new wf-shell version (0.11.0) has been released, as well. It currently doesn't build on Void due to an unresolved dependency (see linked issue below). Do note that wf-shell-0.10.0_1 is working perfectly fine w/ wayfire-0.11.0_1 (I've never used it myself, but I didn't experience any issues during some brief testing), so I might not include that update in this PR.

EDIT: I worked around the issue, but half of the builds are failing - @Duncaen Sorry for pinging you, but could it be that not finding /usr/share/wayfire/protocols/unstable/wayfire-shell-unstable-v2.xml is cross compilation related? UPDATE: upstream uploaded new tarballs just now.. workaround no longer needed, but build failures persist..

[Duncaen]

Sounds like you either have to add wayfire to hostmakedepends or somehow change the lookup path to use ${XBPS_CROSS_BASE}, it uses pkg-config to get the variable and its kind of a "known" issue of the pkg-config implementation that we use that it won't include the cross chroot when getting variables directly.

https://github.com/WayfireWM/wf-shell/blob/v0.11.0/proto/meson.build#L1

[dogknowsnx]

Sounds like you either have to add wayfire to hostmakedepends

Yeah, I figured - great, thanks!