Skip to content

Add pure Wayland headful mode - #336

Closed
chruffins wants to merge 3 commits into
mainfrom
hypeship/pure-wayland-experiment
Closed

Add pure Wayland headful mode#336
chruffins wants to merge 3 commits into
mainfrom
hypeship/pure-wayland-experiment

Conversation

@chruffins

@chruffins chruffins commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

summary

  • add an optional pure Wayland headful mode using Weston's headless backend
  • launch Chromium with the native Wayland Ozone backend without starting Xorg
  • retain the existing X11 path as the default
  • package wf-recorder 0.6.0 and wlr-randr 0.5.0 for the Wayland capture path
  • add an opt-in neko-wayland supervisor service and wrapper gate
  • document repeatable browser-only benchmark results

browser-only benchmark

Ten fresh-container trials per mode on the rebuilt image, using the same Chromium flags and a 1920x1080 configuration:

metric X11 pure Wayland
wrapper readiness (mean) 3.139s 2.409s
Chromium startup (mean) 656ms 575ms
CDP evaluation p50 (mean) 0.921ms 0.960ms
CDP screenshot p50 (mean) 266ms 116ms
container memory (mean) 709MiB 412MiB

The screenshot metric is CDP Page.captureScreenshot; it does not measure product capture or live view. The memory reduction primarily comes from not starting Xorg and Mutter.

image build and validation

  • the normal build currently fails because the upstream checksum list no longer contains ffmpeg-n7.1-latest-linux64-gpl-7.1.tar.xz
  • a smoke rebuild succeeded using a temporary local substitution to the currently published FFmpeg n9.0 archive; the working tree was restored afterward
  • validated the rebuilt image contains wf-recorder, wlr-randr, FFmpeg, and the neko-wayland supervisor configuration
  • go test ./cmd/chromium-launcher ./cmd/wrapper
  • go vet ./cmd/chromium-launcher ./cmd/wrapper
  • separately built a temporary wlroots/Cage/grim prototype and captured a PNG through zwlr_screencopy_v1

limitations

This PR benchmarks the browser/CDP path. The shipped image still uses the released Neko base image, so the Wayland Neko capture/input implementation requires a separately published Neko image before end-to-end product live-view testing.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit b45262e. Configure here.

if prof == profileHeadful && webrtc {
startAll("neko")
if waylandPure {
startAll("neko-wayland")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrong compositor for Wayland WebRTC

High Severity

Enabling ENABLE_WAYLAND_WEBRTC in pure mode starts neko-wayland with wf-recorder, wlr-randr, and output HEADLESS-1, while the wrapper still launches weston-pure. Weston does not expose the wlroots screencopy or output-management protocols those tools need, so capture and resize fail even though the README requires a wlroots compositor.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit b45262e. Configure here.

@chruffins chruffins closed this Aug 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant