shameful pr#868
Open
SamHSmith wants to merge 1 commit into
Open
Conversation
SamHSmith
force-pushed
the
master
branch
2 times, most recently
from
July 17, 2026 22:50
09e8377 to
6d0e265
Compare
We always draw our own window decorations (title bar, borders, resize edges), so we never want the window manager to add server-side ones on top. Set the legacy _MOTIF_WM_HINTS property with MWM_HINTS_DECORATIONS and decorations=0 at window creation; this is honored by effectively every modern WM (Mutter/GNOME, KWin/KDE, XFWM, Openbox, i3, ...) including XWayland. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> linux/x11: move & resize borderless window via _NET_WM_MOVERESIZE Disabling server-side decorations also removed the window manager's move/resize affordances, leaving the window stuck in place. Since we draw our own title bar & borders, implement the hit-testing ourselves: the frontend already describes the custom title bar, resize edges, and the interactive "client area" sub-rects each frame (via the previously stubbed wm_window_push_custom_* calls), so store that data per-window and, on a left button press, translate it into an EWMH _NET_WM_MOVERESIZE request that hands the interactive drag off to the window manager. This mirrors the Win32 WM_NCHITTEST path. Presses over a title-bar client area (menu items, window buttons) or the window body are delivered normally, so those widgets keep working. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> linux/x11: render during interactive resize + resize-edge cursors Two fixes for the borderless move/resize: - Render during resize. The window did not select StructureNotifyMask, so no ConfigureNotify arrived while the WM drove an interactive resize (the pointer is grabbed by the WM, so no other events flow either) and nothing repainted until the drag ended. Select structure notifications and turn ConfigureNotify/Expose into Wakeup events so the main loop renders a frame at each new size. - Resize cursors. On mouse motion, hit-test the pointer against the custom resize edges and override the cursor with the matching left-right / up-down / diagonal resize cursor while hovering an edge (a title-bar widget under the pointer still wins, as with clicks). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> linux/x11: frame-synced resize via _NET_WM_SYNC_REQUEST Implement the basic _NET_WM_SYNC_REQUEST protocol correctly so the compositor holds off compositing until our frame for the new size is ready, eliminating resize stutter/tearing. Previously the sync counter was updated immediately in the event handler, before the frame was drawn, which defeats the protocol (the compositor is told "ready" while the old-size frame is still on screen). Instead, remember the requested sync value on the request, and set the counter only after the frame is presented (from the GL swap, for both the glx and egl backends). Also fixes a truncation bug: the counter was set with XSyncIntToValue (32-bit), dropping the high 32 bits of the 64-bit sync value; use XSyncIntsToValue with the full hi/lo pair. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> linux: native Wayland window-manager backend (opt-in: build.sh raddbg wayland) Add a native Wayland backend alongside the X11 one, selected at compile time via the WM_WAYLAND define (`./build.sh raddbg wayland`). It renders through EGL/wl_egl_window and implements the full wm_ API: - xdg-shell (xdg_wm_base/xdg_surface/xdg_toplevel) with client-side decorations requested via xdg-decoration, so we draw our own. - Frame-perfect resize the Wayland-native way: on xdg_surface.configure we resize the wl_egl_window, ack_configure, and the next EGL commit is atomically the acked size - no XSync counter needed. - Input via wl_pointer + wl_keyboard (xkbcommon), including key repeat (timerfd) and modifier tracking. - Interactive move/resize handed to the compositor via xdg_toplevel move/resize, with the same custom title-bar/edge hit-testing and resize-edge cursors (wl_cursor) as the X11 backend. Color correctness: request an sRGB-capable EGL config (probed, since the first matching config often fails sRGB surface creation and silently falls back to linear), so the final blit's linear->sRGB encode matches the GLX path exactly; and mark the surface opaque to avoid alpha-blend color shifts. Generated xdg-shell / xdg-decoration protocol code is committed under src/linux/window_manager/generated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> linux: one binary with runtime X11/Wayland selection (no compile-time switch) Previously the Linux window backend was chosen at compile time (WM_WAYLAND). Now a single build compiles BOTH backends and picks one at runtime, so `./build.sh raddbg` just works on either display server. - The per-OS wm_ functions in each backend are renamed wm_x11_* / wm_wl_*, and a small dispatch layer (linux_window_manager_dispatch.c) implements the public wm_* API, forwarding to the active backend via lnx_wm_backend. - Selection (wm_init): prefer Wayland, fall back to X11 if the Wayland connect fails or no session is present. RADDBG_BACKEND=x11|wayland overrides; an absent WAYLAND_DISPLAY implies X11. wm_wl_init now returns a bool instead of aborting, so the fallback is graceful. - Rendering uses EGL for both backends (GLX can't drive Wayland); the EGL init/equip/swap branch on lnx_wm_backend at runtime, picking the native display/window and doing the X11-only _NET_WM_SYNC_REQUEST ack. The sRGB-capable-config probe now runs for both, and X11 additionally extracts the matching X visual. - build.sh always links X11 + Wayland (x11 xext wayland-client wayland-egl wayland-cursor xkbcommon) and defaults the GL backend to EGL. Verified all three selection paths (Wayland default, RADDBG_BACKEND=x11, absent WAYLAND_DISPLAY) from a single binary; X11 path renders correctly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> raddbg: thicken window resize border to 4px for an easier grab target window_edge_px feeds both the visual border inset and the resize hit region (via wm_window_push_custom_edges), shared by the X11 and Wayland backends. Bump it from ~3.4px to a DPI-scaled 4px at 96 DPI. Co-Authored-By: Claude Opus 4.8 <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.
This has some linux fixes.