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.
Add a 'labnag' meson option (default: auto) to allow disabling the
labnag notification daemon at build time. This is useful for
embedded/headless deployments (e.g. Android) where labnag is not
needed, and avoids building its wayland-client dependencies.
Disable with: meson setup build -Dlabnag=disabled
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.
wlr_scene_*_create() functions all allocate memory via calloc() and
return NULL if the allocation fails. Previously, the failures were
handled in any of 3 different ways:
- sending a wayland protocol error
- exiting labwc with an error
- segfault (no NULL check at all)
Since labwc does not attempt to survive heap exhaustion in other
allocation paths (such as `znew`), it seems more consistent to use the
same die_if_null() check used in those paths to exit with an error.
For the three most common create() functions (tree, rect, buffer),
add small lab_wlr_ wrappers to common/scene-helpers.
When an X11 client clears override-redirect on a window (i.e. it
becomes "managed") without an unmap/map cycle, wlroots doesn't
re-emit the set_title/class/icon events. We need to synthesize
them to re-read the values from the surface.
From what I can tell, only older/misbehaving X11 clients would
actually do this (toggle override-redirect without unmap/map), so
this is perhaps a bit pedantic, but an easy fix anyway.
Before this commit, ssd_update_title() returned early and the title was
not updated when the title gets empty. Furthermore, this caused the
title buffer to be misplaced outside of the titlebar when the window is
resized.
Reproducer:
1. Build and launch https://github.com/tokyo4j/wayland-demo/tree/repro-labwc-ssd-title-not-updated
2. One second later, the window title gets empty. But the title in
SSD is not updated.
3. Un-minimize the window. Now the title buffer is misplaced outside of
the titlebar.
- To reset the mode request we were using wlr_output_state_set_mode(NULL) which is not
allowed in wlroots. Replace it with removing the mode from the commit manually.
- Before this patch, we would assume that we can't configure an output if it doesn't have
any fixed mode. This is not true for wayland backed nested outputs. Replace the fixed
return false with wlr_output_test_state().
- Prevent configuring the output if the test fails as the current behavior was a
workaround for the hardcoded return false in case there were no fixed modes available.
Fixes: #3428
Reported-By: kode54
When running on the X11 or Wayland backend, each output corresponds
to a window in the parent compositor. Unlike DRM outputs, these
cannot be reconnected after being destroyed.
Terminate the compositor when the last output is destroyed on these
nested backends, matching the expected behavior when the user closes
the window.
