fix(linux): suppress Ozone Wayland Vulkan incompatibility warning

[sambitcreate]

Description

On Linux Wayland sessions running Electron, Chromium logs initialization warnings for VA-API and Vulkan compatibility:

[ERROR:media/gpu/vaapi/vaapi_wrapper.cc:1796] vaInitialize failed: unknown libva error
[ERROR:ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc:249] '--ozone-platform=wayland' is not compatible with Vulkan. Consider switching to '--ozone-platform=x11' or disabling Vulkan

Environment

• OS: Linux (Wayland session, XDG_SESSION_TYPE=wayland)
• Electron 43.1.1 / Chromium 150.0.7871.114

Proposed Fix

When running on Linux under Wayland, explicitly disable Vulkan or tune Chromium flags (e.g. app.commandLine.appendSwitch('disable-features', 'Vulkan') or passing --disable-features=Vulkan in development and packaged runners) to prevent unnecessary GPU initialization warnings.

[pullfrog]

Analysis and plan for #88 — suppress the Ozone/Wayland Vulkan incompatibility warning on Linux

Root cause

The warning originates in Chromium, not in Aiden. WaylandSurfaceFactory::CreateVulkanImplementation() (ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc, the LOG_IF(ERROR, !use_swiftshader) line) is reached when the GPU process tries to bring up a native Vulkan implementation during startup while running on the Ozone Wayland platform. Wayland's ozone backend has no Vulkan WSI, so Chromium logs the "not compatible with Vulkan" error and falls back. It is cosmetic: rendering proceeds on EGL/ANGLE-GL, and only the Vulkan feature umbrella (native Vulkan raster, WebGPU-on-Vulkan probing) is affected. The vaInitialize failed: unknown libva error line in the issue body is a separate, unrelated libva/VA-API probing message and is out of scope.

Aiden currently appends no Chromium switches anywhere (grep for appendSwitch finds only reads via app.commandLine.hasSwitch("user-data-dir") in main/runtime-profile.ts), and the renderer has no WebGPU usage, so disabling the Vulkan feature under Wayland carries no functional loss. The issue's proposed fix matches the suggestion Chromium itself prints ("or disabling Vulkan") and is the standard Electron workaround.

Key facts that shape the fix:

• Electron ^43.1.1 / Chromium 150 confirmed in package.json; Wayland is auto-selected by Chromium when XDG_SESSION_TYPE=wayland (the author's environment).
• Chromium merges repeated --disable-features occurrences additively, so an append cannot clobber anything (nothing else sets it today anyway).
• main/bootstrap.ts is the bundled main entry (package.json main → build/main/index.js); code there runs before app ready in dev (prepare-macos-dev-runtime.mjs) and packaged runs alike, so a switch appended there covers every launch path.
• Wayland detection must mirror Chromium's own heuristic (XDG_SESSION_TYPE === "wayland" or WAYLAND_DISPLAY set), and must respect an explicit --ozone-platform=x11 override if a user forces X11 under a Wayland session.
• CI (Linux xvfb smoke) is X11-only, so the suppression can only be verified manually on a real Wayland session; unit tests must cover the pure gating logic instead.

Plan

1. Pure detection module — main/linux-wayland-vulkan-core.ts (no electron import)

• isWaylandSession(env): XDG_SESSION_TYPE === "wayland" or non-empty WAYLAND_DISPLAY — mirrors Chromium's ozone auto-detection.
• shouldSuppressOzoneWaylandVulkan(platform, env, ozonePlatformOverride): Linux only, Wayland session only, and returns false when an explicit --ozone-platform=x11 override is present.
• Pure functions so they are unit-testable under tsx --test (electron cannot be imported by plain-node tests; repo pattern is a pure *-core.ts + thin electron seam, cf. runtime-profile-core.ts/runtime-profile.ts).

2. Electron seam + call site

• main/linux-graphics-flags.ts: thin wrapper importing app and the core predicate; when it fires, app.commandLine.appendSwitch("disable-features", "Vulkan") (exactly what the issue proposes; do not use app.disableHardwareAcceleration() — that forces software rendering and is a real regression).
• Call it at the top of main/bootstrap.ts before runtime-profile config, so it applies to dev, packaged, and packaged-soak runs on Linux Wayland, and is a no-op elsewhere.
• Optional: one logger.info diagnostic line documenting the suppression for support triage.

3. Tests (repo rule: any new test file must be registered in package.json)

• New main/linux-wayland-vulkan-core.test.ts covering the matrix: wayland via XDG_SESSION_TYPE, wayland via WAYLAND_DISPLAY, x11/tty/missing env, non-Linux platforms no-op even under wayland env, explicit --ozone-platform=x11 override defeats suppression.
• Register the file in a tsx --test npm script that actually runs in CI on every platform (e.g. a small test:linux-graphics chained into pretest, or appended to the monolithic test list), since test:linux-contracts/test:linux-native are deliberately Linux-only and not chained.
• Optionally pin the bootstrap.ts call site with a source-reading contract test in the style of runtime-profile-bootstrap.test.ts.

4. Verification

• Manual (author's machine, the only place this can be proven): start the dev runtime from a Wayland session with XDG_SESSION_TYPE=wayland and confirm the terminal no longer shows ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc ... not compatible with Vulkan, while the window still renders (GL compositing is unaffected). Also sanity-check an X11 session for no change.
• CI: run npm run lint and the newly registered test suite; the existing xvfb Linux packaged smoke (X11) confirms no regression on the non-Wayland path.
• Risk note: if the log unexpectedly persists on a Wayland host after this change (i.e. the Vulkan attempt reaches the GPU process via a path not gated by the feature), report back with evidence rather than escalating to disabling hardware acceleration; the likely residual cause would be Electron-level enablement needing an upstream-appropriate fix.

5. Housekeeping

• Update .memory/ (Linux desktop support section) and .papercuts/troubleshooting.md as appropriate when implementing.
• Scope the vaInitialize/libva warning to a follow-up issue; it is a distinct subsystem (VA-API probing driven by host libva drivers) and suppressing it would mean disabling VA-API decode, a separate decision.

Outcome: one small, gated, testable change; cosmetic-only; no user-visible behavior change on macOS, Windows, X11 Linux, or WebGL/WebGPU paths.

Task list (3/3 completed)

• Gather context: issue fix(linux): suppress Ozone Wayland Vulkan incompatibility warning #88, similar issues, codebase Linux/Electron entry
• Research the Ozone Wayland Vulkan warning and suppression options
• Produce structured plan and report progress

  ^{｜ Implement plan ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using DeepSeek Flash ｜ 𝕏}