- Use wrapper struct to track keyboard pointer per-listener
- Get keyboard from listener that fired event, not from seat
- Properly clean up listeners on keyboard disconnect
- Create XKB keymap before wlr_backend_start() so it's available when
libinput detects keyboards synchronously during startup
- Support multiple keyboards by allocating per-device listeners instead
of replacing listeners on each new keyboard
- Remove duplicate keymap creation code that ran too late
Defines a Wayland protocol for native dock applications (dockapps).
Clients create a wl_surface, wrap it with wmaker_dockapp_v1, and
render ARGB content at the compositor-specified tile size. The
compositor places the surface in a dock slot with full transparency
support, eliminating the opaque-black-background issue of XWayland.
Protocol:
- wmaker_dockapp_manager_v1: global, get_dockapp(surface)
- wmaker_dockapp_v1: set_app_id, configure event, closed event
Compositor implementation registers the global and handles surface
commit by placing the dockapp in its assigned dock tile frame_buf
tree.
When reparenting the XWayland toplevel surface into the dock tile,
use (0,0) position and icon_size dimensions. The getSize call on
the non-existent icon_window returned garbage causing integer overflow
in the centering calculation.
Shows the XWayland toplevel surface in the dock tile. Black background
is an inherent limitation of X11 opaque windows under XWayland.
Next step: native Wayland dockapp protocol for proper transparency.
- appIconMouseDown: allow drag (Button1) even when icon->owner is NULL,
which happens for dockapps whose WWindow is unmanaged after docking
- canBeDocked: fall back to aicon->wm_class/wm_instance when owner is
NULL so dockapps can be snapped into dock slots
- wl_pointer_focus: don't give seat pointer focus to views embedded in
frame_bufs (dockapps) — let WM handle input via frame_buf path
- wl_handlers button hittest: route clicks on embedded views to their
parent frame_buf instead of the client surface
- wl_window_unmap: don't disable scene_node if view is reparented into
a frame (docked)
- Reparent owner's client_win surface into dock tile frame_buf tree
- Raise client scene_node above tile background
- Don't disable scene_node on unmap if reparented into a frame
- Handle OR views and XWayland child windows in client_reparent
- Diagnostics still in place
Dock apps (e.g. wmclock) use override_redirect icon_windows that get
reparented into dock tile frame_bufs. The reparent code only searched
toplevel_list, missing OR views in or_list. The icon_window's scene
node was never moved to the dock tile's scene tree, so it rendered
invisibly at (0,0) in the wrong layer.
- wl_client_reparent: search or_list for OR views and reparent their
scene_node into the parent frame_buf's tree
- wl_window_map: handle OR view enable so window_map(icon_win) works
- Listen for xdg_shell new_popup signal
- Create scene tree for popups as children of parent toplevel
- Unconstrain popup geometry on initial commit
- Store xdg_surface->data for parent lookup by nested popups
- Remove redundant wl_update_pointer_focus from button handler,
let wlr_seat manage implicit grabs internally
- Listen for set_hints signal on XWayland surfaces so hints
(including dockapp initial_state) are available at map time.
- Remove the hardcoded 640x480 initial configure — let clients
request their own geometry via request_configure.
- Link xcb for future dockapp icon_window operations.
Two fixes:
1. Handle request_configure for XWayland surfaces. Without this,
X clients block waiting for ConfigureNotify on startup (5s timeout).
Now we immediately ACK with wlr_xwayland_surface_configure.
2. Replace direct wlr_scene_output_commit in wl_event_flush with
wlr_output_schedule_frame. Rendering happens in handle_output_frame
when the output is ready. Eliminates 'No free output buffer slot'
spam and prevents reentrant dispatch crashes.
wlroots manages XWayland internally via its own xcb connection.
Our second Xlib connection (XOpenDisplay) interfered with XWayland's
event routing, preventing WM_DELETE_WINDOW from reaching X clients
and causing slow XWayland startup.
Removed:
- Persistent wl_state.x_display / x11_event_source
- X11 event pump (wl_handle_x11_events)
- Xlib-based icon capture, GC creation, key/message forwarding
- XSetErrorHandler on our connection
- Reentrant wl_event_loop_dispatch in wl_event_flush (caused UAF)
Root cursor now set via wlr_xwayland_set_cursor (wlroots API).
XWayland close button now works correctly.
Same fix as commit 2581233 for XDG toplevels — wApplicationDestroy
needs main_window_desc (the wwin) to clean up the appicon. Call it
before wUnmanageWindow which frees wwin.
The XWayland backend was not listening for request_fullscreen events
from wlr_xwayland_surface. Wine/Proton games that request fullscreen
via _NET_WM_STATE_FULLSCREEN had the signal silently ignored, leaving
them in a tiny window.
Add handle_xwayland_request_fullscreen listener that calls
wFullscreenWindow/wUnfullscreenWindow, matching the XDG toplevel path.
fill_rect used PIXMAN_OP_OVER which blends over existing pixels.
Uninitialized view backing images retained stale pixel data (e.g.
from icon tiles previously in that heap region), causing visual
artifacts like appicons showing through editmenu entries in WPrefs.
SRC fully replaces destination pixels, eliminating bleed-through.
ASAN found the heap corruption bug. When a toplevel is destroyed, the
view is freed but the wmaker-popup-v1 wl_resource still exists. When
the client later disconnects, wayland-server calls the resource
destroy callback which accessed the freed view (writing to
view->popup). This corrupted whatever was subsequently allocated in
that memory region, causing the SIGSEGV-in-malloc crashes.
Fix: NULL out the resource user_data before freeing the view.
The wl_event_loop_dispatch in event_flush could process a session
deactivation event (VT switch) while mid-animation, triggering a
wlroots assertion in wlr_backend_finish. Skip the commit and dispatch
when the DRM session is inactive.
Each frame_buf gets a canary field (0xDEADBEEF) set at creation.
Before every frame_paint, all canaries are checked. If one is
trashed, dumps all frame_buf IDs/sizes/addresses to /tmp/wm-canary.log
before aborting.
Set canary in ALL frame_buf creation paths:
- wl_frame_create_toplevel, wl_frame_create_child
- wl_fake_leader_create
- wl_client_reparent (WINGs view frame_buf creation)
- wl_view_commit_backing_impl (WINGs toplevel)
- wl_screen dock_shadow and icon frame_bufs
- wl_window pixmap-to-frame_buf path
Animation loops (iconify/shade zoom) call event_flush repeatedly
with wusleep delays. The scene commit returned immediately without
waiting for the DRM page flip, so only the final frame was visible.
After committing, flush clients and dispatch the event loop once to
process the page-flip completion. This allows the next commit in the
animation loop to succeed, producing smooth multi-frame animations.
wlr_scene_xdg_surface_create handles geometry offset internally.
Our manual subtraction of geometry.x/y in handle_toplevel_commit,
handle_toplevel_map, and wl_window_move was double-subtracting,
causing client surfaces to render behind their frames.
Remove all manual geometry offset from scene node positioning.
Two fixes for button/titlebar bevel consistency:
1. Implement the draw_bevel noop with real light/dim border drawing
from the WTexSolid colors.
2. Render button backgrounds using wTextureRenderImage with WREL_RAISED
(same function the titlebar uses). This produces the identical
2-pixel wrlib bevel (RBevelImage/RBEV_RAISED2) that the titlebar
gets, ensuring buttons and titlebar match exactly.
When MenuTextColor is not explicitly set (defaults to black), dark
widget themes render invisible black-on-dark menu text. Compute
luminance contrast between text color and background; if insufficient
(< 64 difference), substitute white text on dark backgrounds or black
text on light backgrounds.
When the titlebar is rendered into the parent frame buffer (fallback
for undersized titlebar child), buttons sampled their background
color from the stale titlebar child buffer. This caused color
mismatch in inactive state or after theme changes.
Fix: detect when the titlebar child is too small and sample the
button background from the parent frame buffer instead.
When the pointer moves over WM frame_bufs (titlebar, resizebar,
buttons), reset the cursor image to left_ptr. Without this, the
cursor stayed as whatever the last client set it to (e.g. text beam
from a text editor).
Switch from wlr_scene_subsurface_tree_create (which only handles
wl_subsurfaces) to wlr_scene_xdg_surface_create (which also creates
scene nodes for XDG popups). This makes right-click menus, tooltips,
and dropdown menus from native Wayland clients (LibreWolf, etc.)
visible in the scene graph.
The geometry view was sized using "%+05i, %+05i" but painted with
"%+5i , %+5i " (wider due to trailing spaces). This caused the
rendered text to exceed the view width. Use the same format for both
so the backing pixman image is correctly sized.
When switching VTs and returning, the DRM output may be destroyed and
recreated. Two issues caused the background to revert:
1. pending_background was freed after first application, so subsequent
output creation had nothing to reapply.
2. A new bg_rect (default purple) was created for each new output and
rendered on top of the existing bg_image scene buffer.
Fix: keep pending_background permanently, and disable the new bg_rect
when a background image is already active in the scene graph.
Native Wayland clients (e.g. plan9port acme/devdraw) warp the pointer
by locking it via zwp_pointer_constraints_v1, setting a
cursor_position_hint, then immediately destroying the lock. The
compositor is expected to warp the cursor to the hint on unlock.
Our handler just activated the constraint and ignored the hint. Now we
listen for the constraint destroy event and warp the cursor to the
hint position (converted from surface-local to global coordinates).
wlr_cursor_warp with NULL device silently fails (returns false) if the
target coordinates fall outside the output layout bounds. This made
pointer warping appear completely broken.
Switch to wlr_cursor_warp_closest which clamps to the nearest valid
point on the output layout, ensuring the cursor always moves.
The close button on internal windows (dock app settings, etc.) did
nothing because:
1. wwin->protocols.DELETE_WINDOW was never set for internal windows,
so windowCloseClick skipped the wClientSendProtocol call.
2. Even if it were called, wl_client_send_protocol just called
client_close which looks for an XDG/XWayland surface. Internal
windows have synthetic WINGs view IDs, not real surfaces.
Fix: set DELETE_WINDOW protocol flag in wManageInternalWindow, and
handle internal windows in wl_client_send_protocol by calling
wUnmanageWindow directly.
Add runtime bounds check before the titlebar texture blit. If the
destination pixman image is smaller than the blit dimensions, log a
diagnostic warning with the exact sizes and skip the blit instead of
corrupting the heap. This will help identify the conditions that
trigger the remaining heap overflow.
The titlebar child frame_buf can have a height smaller than tb_h
(fwin->top_width clamped to total_h). The existing bounds check only
verified width, not height. The blit loop wrote tb_h rows into a
shorter pixman image, overflowing into adjacent heap allocations.
This caused 100%% reproducible SIGSEGV in malloc (heap corruption
detected by glibc) on any operation following a frame paint where the
titlebar child was shorter than expected — e.g. opening the Run dialog
after a menu frame was painted.
Fix: check both width AND height before using the titlebar child buffer.
Fall back to drawing into the parent frame buffer (which is correctly
sized) when either dimension is insufficient.
wl_frame_configure and wl_window_resize reallocate fb->image (unref
old pixman image, create new one) but never updated the WINGs backing
table. W_GetViewBacking() continued returning the freed pointer.
Any subsequent draw into that backing (e.g. WMDrawString for titlebar
text) wrote into freed memory, corrupting the heap. The corruption
manifested as SIGSEGV/SIGABRT at the next malloc or free — in
fontconfig, Mesa, RReleaseImage, etc. depending on timing.
Fix: call W_RegisterBacking(fb->id, fb->image) after reallocation in
both resize paths.
Two issues with window shading:
1. wShadeWindow resizes the frame to top_width-1 tall. wl_frame_paint
used the unclamped fwin->top_width as titlebar blit height, writing
one row past the pixman buffer. Heap corruption detected by glibc on
next free (RReleaseImage) caused SIGABRT. Fix: clamp tb_h to total_h.
2. The parent frame scene_buf was only enabled when show_resizebar was
true. When the titlebar child buffer is too narrow (falls back to
drawing into the parent), the shaded frame had its scene_buf disabled
and the titlebar was invisible. Fix: also enable the parent scene_buf
when the titlebar was drawn into it (no titlebar child found).
wipe_desktop: iterate windows sending DELETE_WINDOW or killing (needed for
proper compositor shutdown).
get_shortcut_string, icon_select, icon_change_title: delegate to pure
WM functions that have no X11 dependency.
These were noops hiding calls to pure functions with no X11 deps:
- get_shortcut_string: calls GetShortcutKey (fixes missing menu shortcuts)
- icon_select: calls wIconSelect
- icon_change_title: calls wIconChangeTitle
Core code must not call backend directly. misc.c:slide_windows and
move_window now delegate to wm_backend->slide_windows/move_window.
Wayland backend implements both using scene node moves + event_flush.
wl_frame_paint is expensive (pixman blit per motion event).
Decorations content does not change during resize, only geometry.
Skip repaint while grab_type==2; repaint once on grab release.
Without schedule_frame, drag/resize updates sit in the scene graph
until the next natural vsync. At 144Hz this is 7ms max. Scheduling
after each motion ensures the next frame picks up the move/resize.
The 16ms dispatch timeout added up to 16ms of input latency.
4ms reduces this to ~4ms maximum.
Removing unconditional wlr_output_schedule_frame from the main loop
stops flooding the swapchain. The output frame callback in
handle_output_frame drives rendering at vsync naturally.
Two issues with window shading:
1. wShadeWindow resizes the frame to top_width-1 tall. wl_frame_paint
used the unclamped fwin->top_width as titlebar blit height, writing
one row past the pixman buffer. Heap corruption detected by glibc on
next free (RReleaseImage) caused SIGABRT. Fix: clamp tb_h to total_h.
2. The parent frame scene_buf was only enabled when show_resizebar was
true. When the titlebar child buffer is too narrow (falls back to
drawing into the parent), the shaded frame had its scene_buf disabled
and the titlebar was invisible. Fix: always commit and enable the
parent scene_buf (cleared to transparent, so unused areas are safe).
W_ViewDestroyedFn hook clears last_hovered_view when the pointed-to
view is destroyed. Prevents use-after-free in motion handler when
the hovering over a view inside a dialog that is then closed.
wl_update_pointer_focus reset cursor to left_ptr on every motion
event when no Wayland surface was under the pointer. WINGs compositor
views are pixman scene nodes, not Wayland surfaces, so surface was
always NULL over dialogs. Now preserve cursor when over frame_bufs.
Levi Neely
lkn