feat(linux,#757): X11 ARGB transparent surface + xlib transparent opt-in [WIP]#758
Draft
dfattal wants to merge 3 commits into
Draft
feat(linux,#757): X11 ARGB transparent surface + xlib transparent opt-in [WIP]#758dfattal wants to merge 3 commits into
dfattal wants to merge 3 commits into
Conversation
…groundEnabled opt-in Wire the transparent-background path on desktop Linux (X11/XCB), the runtime half of the avatar-overlay compose-under-bg feature (#757). - XR_DXR_xlib_window_binding: add transparentBackgroundEnabled (SPEC_VERSION 1->2), matching the Win32/Cocoa siblings; parse it in oxr_session.c into the existing xsi.transparent_background_enabled path. - comp_vk_native_window_xcb.c: select a 32-bit ARGB TrueColor visual + colormap when transparency is requested (was a hard no-op), with an opaque fallback + one-time WARN when no ARGB visual/compositor is available; free the colormap on destroy. The target's PRE_MULTIPLIED/INHERIT compositeAlpha selection is not macOS-gated, so it engages for X11 once the surface advertises it. Requires a compositing WM (GNOME/Mutter, KWin, picom). Wayland surface backend and the DP-side compose-under pass are follow-ups on #757. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ce_binding Add an app-provided Wayland surface present path to the vk_native compositor, the Wayland sibling of the X11/XCB path. Transparency is native on Wayland (a surface composites its premultiplied alpha over what's behind it — no ARGB visual needed), so transparentBackgroundEnabled just selects a non-opaque compositeAlpha. - Extension XR_DXR_wayland_surface_binding (wl_display* + wl_surface* + transparentBackgroundEnabled), registered + parsed alongside the xlib binding. - comp_vk_native: new comp_vk_native_wayland_handle; the target builds a VkWaylandSurfaceKHR (VK_KHR_wayland_surface, loaded via GetInstanceProcAddr) when the app provides a surface. Discriminated by a window_is_wayland flag threaded oxr → compositor_create → target_create (the target reads it, not the opaque compositor struct). - App-provided only — no self-created window / xdg-shell (the app owns the surface lifecycle), mirroring the xlib app-window path. - Gated on XRT_HAVE_WAYLAND (new top-level pkg_check_modules(WAYLAND wayland-client) + option_with_deps); OFF → the whole path compiles out (X11/XCB unaffected). CI: add libwayland-dev so the Wayland path is compile-tested. X11/Xorg stays the primary desktop path; this future-proofs for Wayland sessions. Runtime behavior needs a Wayland compositor to confirm; CI compiles it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…etrics) Suki (DS1): windowed scene aspect ratio wrong. Root cause: the vk_native compositor's get_window_metrics Linux branch keyed on c->xcb_window (the SELF-CREATED window), which is NULL on the app-provided-window path (the app hands its window via XR_DXR_xlib_window_binding; the compositor wraps it into c->xcb_handle, leaving c->xcb_window NULL). So window metrics returned false and the runtime fell back to DISPLAY-scoped Kooima → the window aspect never reached the off-axis FOV. - comp_vk_native_window_xcb: add query_screen_position(handle) — the handle-based sibling of get_screen_position (xcb_get_geometry for the root + translate). - get_window_metrics Linux branch: use c->xcb_handle (populated for BOTH the self-created and app-provided paths) via query_geometry + query_screen_position, instead of c->xcb_window. Window-scoped Kooima now works for app-owned windows. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Runtime half of the Linux avatar-overlay transparency feature (#757). Draft — WIP; opened for Linux tri-LTS CI compile-validation while the rest of the feature lands.
In this PR (WS3 + WS5):
XR_DXR_xlib_window_binding:transparentBackgroundEnabled(SPEC_VERSION 1→2), parsed inoxr_session.c.comp_vk_native_window_xcb.c: 32-bit ARGB visual + colormap when transparency is requested (opaque fallback + WARN otherwise); frees colormap on destroy. The target's PRE_MULTIPLIED/INHERIT compositeAlpha selection (already non-macOS-gated) engages once the surface advertises it.Requires a compositing WM (GNOME/Mutter, KWin, picom).
Not yet in this PR (tracked on #757): WS3b Wayland surface backend; extension header sync to displayxr-extensions (on merge).
🤖 Generated with Claude Code