v2: Switch XRGB to XBGR
v3: Rewrite HDR mode checking and setting
v4: Restructure HDR support detection
v5: Fix code style
v6: Fix old style function declaration
v7: This function should be declared static
v8: This helper function can accept a const struct on input
v9: Rebase now that 0.20 is merged
v10: Rewrite with multiple color format attempts
v11: Add in the parts that accidentally got left in my
original color-management-v1 patch
v12: Add missing function prototype
v13: Apply suggested changes
v14: Changed HDR application setup in new output
v15: Rewrite configure_new_output to use lab_wlr_scene_output_commit
v16: Fixed application of HDR on external mode or output config change
v17: Fixed it for real this time instead of crashing
v18: Moved the effective resolution collection, plus one style change.
Menu accelerators are one-letter mnemonics to quickly select/exec
items from the current menu. For each menu item, the accelerator is
defined as the first character of the item label, converted to
lowercase. A different accelerator can be explicitly defined in
menu.xml with the special '_' character before the target letter.
- Add a field `accelerator` to the `menuitem` struct
- Implement `menu_item_select_by_accelerator()`
Example:
The accelerator for an item with the label "e_macs" is 'm'.
This function behaves identically to `scaled_font_buffer_update()`
but allows setting the text as pango markup, supporting further
customization like underscores.
This fixes a warning in gcc16 below:
../src/img/img-xpm.c: In function ‘xpm_load_to_surface’:
../src/img/img-xpm.c:354:33: warning: variable ‘xcnt’ set but not used [-Wunused-but-set-variable=]
354 | for (int n = 0, xcnt = 0; n < wbytes; n += cpp, xcnt++) {
| ^~~~
dbus-update-activation-environment and systemctl --user import-environment
were fired asynchronously via spawn_async_no_shell, racing with the autostart
script. Any systemd user service started from autostart (e.g. via
labwc-session.target) could start before the import completed, leaving
WAYLAND_DISPLAY and related variables absent from its environment and those
of any apps it launches.
Run both commands synchronously via a new spawn_sync_no_shell helper so
the import is guaranteed to complete before the autostart script executes.
The raise_on_focus_delay is meant to dampen z-order churn from
focus-follows-mouse cursor passes. Applying it to every focus
change meant explicit actions (alt-tab cycle finish, Focus action,
xdg/xwayland activation, view map, etc.) also waited for the delay
before raising, which felt laggy.
Route all non-sloppy-focus callers through an immediate raise and
keep the timer-based raise only for desktop_focus_view_or_surface(),
which is the sloppy-focus entry point.
If the user disables raiseOnFocus or lowers raiseOnFocusDelay while
a raise is queued, the queued raise should not fire against the new
config. Cancel it in reload_config_and_theme() before rereading the
rc.xml.
The pending_auto_raise_view pointer would become dangling if the
view it references is destroyed before the timer fires. Clear it
in view_destroy() alongside the existing active_view cleanup.
When raiseOnFocus is enabled and raiseOnFocusDelay is > 0, defer
view_move_to_front() until a wl_event_loop timer elapses instead of
raising immediately. The pending view/timer pair lives on struct
server so that at most one raise can be pending per compositor.
Semantics:
delay_ms == 0 : immediate raise (preserves prior behavior)
delay_ms > 0, hover A : schedule raise of A after delay_ms
another hover before : timer is reset and the new view becomes
expiry the pending one (brief flyby hovers do
not stack up raises)
focus change, raise=false: pending raise is cancelled
This is most useful with followMouse to avoid brief passes of the
cursor stacking up z-order changes.
Add a new <focus><raiseOnFocusDelay> element accepting an integer in
milliseconds. The default of 0 preserves the current behavior (raise
immediately when raiseOnFocus is enabled).
The new field is carried as uint32_t raise_on_focus_delay_ms on
struct rcxml. This commit only adds the parser and default; the
actual delay logic follows in a subsequent commit.
Modifier+right-drag resize was silently ignored on fully maximized views
because of an early-return guard in interactive_begin(). The axis-specific
un-maximization logic introduced in #3043 already handles partial
maximization correctly; extend that to the VIEW_AXIS_BOTH case so both
axes are cleared while keeping the current geometry as the starting point
of the resize.
Move already permits dragging maximized views, so this also removes an
asymmetry between the move and resize paths.
Fixes: #3524
Use wlr_client_buffer->texture directly instead of wlr_texture_from_buffer.
All buffers in content_tree are wlr_client_buffer.
wlr_texture_from_buffer calls client_buffer_begin_data_ptr_access which
fails when client_buffer->source == NULL (client released buffer early,
e.g. wl_shm foot-terminal).
Add action `DebugToggleKeyStateIndicator` to show in the top-left corner
the pressed, bound, pressed-sent keys as well as modifiers.
This should help fault find issues like #2771 and #3238
Based-on: #3262
Co-authored-by: @tokyo4j
Android's bionic libc implements secure_getenv() as a function that
always returns NULL because app processes don't have AT_SECURE set.
This prevents xkbcommon from reading XKB_DEFAULT_LAYOUT and other
environment variables when resolving keyboard layouts.
Use XKB_CONTEXT_NO_SECURE_GETENV on Android so xkbcommon falls back
to regular getenv(), which works correctly in the Android app
environment.
It was used to get window icon via _NET_WM_ICON, which is now
implemented by wlroots 0.20. Anyone who needs another atom can revert
this commit and add atoms in the `atoms` array.
Ref: 515275ee7214bf91f8a758b660093eb4b932195a
(wlr_scene: Introduce wlr_scene_set_gamma_control_manager_v1)
This wlroots change eliminates the need for separate event tracking for gamma
control application.
v2: Fix code style
v3: Rebase now that 0.20 is merged
Ref: 84d603acc06a45dd3c3a4b2cf1fd08b2933ca2b5
(xwayland: take wlr_buffer in wlr_xwayland_set_cursor())
Ref: 6ae54dca23064e897b393283887986e5719a747f
(xwayland: lock new buffer instead of the old one)
Co-Authored-By: Consolatis
This wlroots change fixes a potential UAF which we dealt with in labwc.
We can thus remove the workaround completely.
Ref: 06275103f249cd2954630e59383342e102a6c1a3
(input-method-v2: Destroy keyboard grab before input method)
Background:
My MR in wlroots (!5107) stopped emitting `wlr_input_method_v2`
on its `commit`/`destroy` events, but didn't stop emitting
`wlr_input_method_keyboard_grab_v2` on its `destroy` event. That was
because `handle_keyboard_grab_destroy()` was called *after*
`handle_input_method_destroy()` for some reason, which caused segfault
when dereferencing `relay->input_method.keyboard_grab` in
`handle_keyboard_grab_destroy()`.
MR 5170 reversed this weired order of destroy handler calls, and finally
stopped emitting `wlr_input_method_keyboard_grab_v2` on its `destroy`
event.
Empirically, the associate event is always seen just after map_request
but before surface map. Window properties are also read by wlroots just
before emitting associate. So after some trial and error, this seems to
be the best place to set initial view states and compute initial
placement.
Fixes initial positioning of "urxvt -g -0-0".
urxvt placement regressed in:
9903331995
("xwayland: rework setting initial geometry from surface")
map_request handler was added ~2 years ago in:
c9018da4c4
("xwayland: set initial geometry in map_request handler")
I'm not sure if the map_request handler was incorrect from day one,
or if something changed in wlroots and/or Xwayland since then.
The basic idea is to set the initial geometry from the surface exactly
once, just before we need it, i.e. either (1) when mapping the view or
(2) right before processing an initial maximize/fullscreen request.
I've consolidated various parts of the initial geometry setup to take
place at this point (in ensure_initial_geometry_and_output()).
The main motivation is to have a valid, adjusted floating geometry for
the view *before* saving the natural geometry when processing an initial
maximize/fullscreen request. This reduces code duplication and addresses
a FIXME in set_initial_position(), as well as fixing an issue where the
natural geometry could exceed the usable output area.
Some other minor changes:
- The initial output is now set directly from the surface geometry if
the "application/user-set position" hint is given. This is unlikely
to matter in practice, but theoretically an initially maximized view
could now appear on a different (application-chosen) output.
- Floating view size is now constrained to the usable area even if a
position hint is set. It seemed inconsistent that `xterm -g 200x200`
was constrained but `xterm -g 200x200+0+0` was not.
