Instead of walking PATH like a previous proposal [1], this one
checks that the Xwayland path specified in the pkg-config file
exists.
I think this is a reasonable compromise:
- Users that don't have Xwayland installed system-wide won't get
a bogus DISPLAY env variable set up.
- Users that have WLR_XWAYLAND set won't be affected by this check.
- Users that have Xwayland installed system-wide and a different
Xwayland in their PATH still get their custom Xwayland.
- Users that don't have Xwayland installed system-wide but have it
somewhere else in PATH are left out. But this is pretty niche,
and they can just set WLR_XWAYLAND.
[1]: https://github.com/swaywm/wlroots/pull/2314
Check that the pkg-config file is available. This will be required
in the future to check whether xwayland supports features such as
-listenfd, -initfd or -verbose.
If there's no pkg-config file, check that the Xwayland executable
is available.
This effectively makes our relationship with xwayland closer to what
a dynamic library is: checked at build-time, but can be overridden
at run-time.
Fixes this warning:
WARNING: Project targeting '>=0.54.0' but tried to use feature introduced in '0.56.0': variables as dictionary.
Fixes: 6f873078d4 ("build: use dictionnary for features instead of configuration_data")
This allows users to to something like this when wlroots is used as a
subproject:
wlr_has_xwayland = wlroots.get_variable('have_xwayland')
Instead of having to parse conf_data from the subproject object.
Our internal state machine gets screwed up if selection events are not
monotonically increasing in time, and we can enter a self-copy loop from
the proxy window that exhausts all pipes.
Snippet of logs when this occurs:
00:00:46.238 [wlr] [xwayland/selection/incoming.c:487] XCB_XFIXES_SELECTION_NOTIFY (selection=277, owner=4194626)
00:00:46.238 [wlr] [xwayland/selection/incoming.c:487] XCB_XFIXES_SELECTION_NOTIFY (selection=277, owner=2097153)
00:00:46.238 [wlr] [xwayland/selection/outgoing.c:378] XCB_SELECTION_REQUEST (time=58979563 owner=2097153, requestor=2097153 selection=277, target=279, property=278)
00:00:46.238 [wlr] [xwayland/selection/outgoing.c:397] ignoring old request from timestamp 58979563; expecting > 58979563
00:00:46.238 [wlr] [xwayland/selection/outgoing.c:29] SendEvent destination=2097153 SelectionNotify(31) time=58979563 requestor=2097153 selection=277 target=279 property=0
00:00:46.238 [wlr] [xwayland/selection/incoming.c:453] XCB_SELECTION_NOTIFY (selection=277, property=0, target=279)
Note that 2097153 is `selection->window`, and 4194626 is Emacs.
The race occurs if the selection owner changes back to our proxy window
between when we get `XCB_XFIXES_SELECTION_NOTIFY` for Emacs and when we
call `xcb_convert_selection` in `incoming.c:source_send` -- the
ConvertSelection request can end up hitting our proxy window, but the
timestamp will be rejected.
Fixes#2192.
There is one exception: layer-shell still uses wlr_log. Would need to
convert to fprintf to drop the wlroots dep there.
Fixes: 34e7f69d69 ("examples: remove dependency on wlr_egl from clients")
Store the previously focused surface in `state->focused` as well as in
`state->original` when starting an implicit grab. That way at the end
of an implicit grab, the detection whether the grab started and ended
on the same surface works as intended, even if the original surface was
never left at all.
Mesa provides YUV shaders, and can import multi-planar YUV DMA-BUFs
as a single EGLImage. Remove the arbitrary limitation.
If the driver doesn't support importing YUV as a single EGLImage,
the import will fail and the result will be the same anyways.
