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
Previously, the clipboard and primary selections shared the same window.
This was racey, and could have led to pasting failures.
On xfixes selection owner change notification, the logic for requesting
the supported mimetypes of the new owner's selection looks like:
xcb_convert_selection(
xwm->xcb_conn,
selection->window,
selection->atom,
xwm->atoms[TARGETS],
xwm->atoms[WL_SELECTION],
selection->timestamp
);
This means ask the selection owner to write its TARGETS for the
`selection->atom` selection (one of PRIMARY, CLIPBOARD, DND_SELECTION)
to `selection->window`'s WL_SELECTION atom.
However, `selection->window` is shared for both PRIMARY and CLIPBOARD
selections, and WL_SELECTION is used as the target atom in both cases.
So, there's a race when both selections change at the same time.
The CLIPBOARD selection might support mimetypes {A, B, C}, and the
PRIMARY only {A, B}. If the ConvertSelection requests/responses "cross
on the wire", so to speak, wlroots can end up believing that the PRIMARY
selection also supports C.
A Wayland client may then ask for the PRIMARY selection in C format,
which will fail with "convert selection failed".
This commit fixes this by using a separate window for PRIMARY and
CLIPBOARD target requests, so that WL_SELECTION can be used as the
target atom in both cases.
This commit introduces logic for using a new X11 window for each
incoming transfer, rather than having a global window for each selection
source.
This eliminates a whole class of bugs involving multiple concurrent
incoming transfers.
For now, we retain the outgoing transfer queue, and the selection
source-specific windows to support it. Source-specific windows are no
longer used in the incoming path, and will be removed in a future PR.
Refs #1497.
Previously, Xwayland could restart, and we'd get events for transfers
pointing to the previous (now freed) xwm instance. This led to
use-after-free segfaults.
Closes#2565.
Apart from reducing duplication, this has the positive side-effect of
allowing all deallocs to use
`xwm_selection_transfer_destroy_property_reply`, as opposed to the
latter and a mix of ad-hoc `free`s.
Previously, wlr_xwm_selection_transfer.source_fd meant:
- the source of data in a Wayland -> X11 copy (good)
- the destination of data in a X11 -> Wayland copy (confusing)
This made reading through xwayland/selection/incoming.c difficult: in
many places, "source" actually means "destination".
When we receive an Expose event, that means that we must redraw that
region of the X11 window. Keep track of these regions with pixman
regions, and merge them with the additional output damaged regions.
Fixes#2670
In certain situations windows can have their input field set to false
but still expect to receive input focus by passively listening to key
presses via a parent window. The ICCCM specification outlines how focus
should be given to clients.
Further reading: https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7
Relates to #2604
This actually simplifies the logic since we no longer have to wait for
enter/leave events, and also improves the UX when e.g. handling a crash
with gdb attached.
See #2659
This allows a compositor to get a KMS connector object ID from a
wlr_output. The compositor can then query more information about
the connector via libdrm.
This gives more freedom to compositors and allows them to read
KMS properties that wlroots doesn't know about. For instance,
they could read the EDID or the suggested_{X,Y} properties and
change their output configuration based on that.
The subconnector property indicates the connector sub-type. This is
useful because that usually indicates what kind of connector the user
has plugged in to their monitor, e.g. a DisplayPort-to-DVI cable will
indicate a DVI subconnector. Also some laptops have non-DP connectors
that are internally linked to a DP port on the GPU.
Set the output description accordingly.
See https://drmdb.emersion.fr/properties/3233857728/subconnector
Value is now an enum with a new value ("on-demand") that compositors can use to allow "normal" keyboard focus semantics regardless of the layer the client surface is on. An error is sent for invalid keyboard interactivity values. The old behavior is retained for clients using the previous version of the protocol.
Also adjusted the layer-shell example program to use the new keyboard interactivity options.
This function is inferior to wlr_xdg_surface_for_each_popup_surface()
for rendering as it does not iterate over subsurfaces. Furthermore,
no compositor is known to use this to iterate popups for any purpose
other than rendering. Therefore remove the function, which may of course
be reintroduced at a later date if a use-case is found.
Stop keeping track of buffers on the parent GPU when multi-GPU is used.
This removes support for export_dmabuf on secondary GPUs, but renderer
v6 will bring this back by managing the swapchains in wlr_output instead
of the backends.
This function will allow compositors to implement input handling in a
way consistent with rendering more easily.
Calling wlr_layer_surface_v1_surface_at() and checking if the result is
a wlr_xdg_popup is flawed as there may be subsurfaces in the popup tree.
This function will allow compositors to implement input handling in a
way consistent with rendering more easily.
Calling wlr_xdg_surface_surface_at() and checking if the result is a
wlr_xdg_popup is flawed as there may be subsurfaces in the popup tree.
Sometimes wlr_session_find_gpus will encounter an error. This is
different from finding zero GPUs.
On error, wlr_session_find_gpus already returns -1. However, this is
casted to size_t, so callers uncorrectly assume this is a success.
Instead, make wlr_session_find_gpus return a ssize_t and allow callers
to handle the error accordingly.
wlr_drm_connector.crtc may be updated by the DRM backend while a
page-flip is pending. In this case, the page-flip handler won't be able
to find the right wlr_drm_connector from the CRTC ID.
Save the CRTC when performing a page-flip to ensure we always find the
right connector when we get the event.
This callback allowed compositors to customize the EGL config used by
the renderer. However with renderer v6 EGL configs aren't used anymore.
Instead, buffers are allocated via GBM and GL FBOs are rendered to. So
customizing the EGL config is a no-op.
We now properly mark the cursor plane's formats as linear-only, and we
now have a version of wlr_drm_format_intersect that handles the case of
linear-only formats and implicit modifiers.
We can remove the special drm_plane_init_surface flag we had for cursor
planes. This also allows us to use a non-linear layout for cursor planes
on drivers that support it.
Tested on amdgpu GFX9.
The Present protocol states:
> An event context is associated with a specific window; using an existing
> event context with a different window generates a Match error.
Instead of a global event context, use a per-window event context to fix
this error:
[backend/x11/backend.c:608] X11 error: op Present (SelectInput), code Match (no extension), sequence 63, value 4194307
Closes: https://github.com/swaywm/wlroots/issues/2577
Instead of using a timer, rely on X11 Present events and send a new
frame event when the parent compositor displays a new frame on screen.
The previous attempt at doing this [1] hit issues with EGLSurface, but
we don't use that anymore.
[1]: https://github.com/swaywm/wlroots/pull/1894
The DRM backend is a little special when it comes to wlr_outputs: the
wlr_drm_connectors are long-lived and are created even when no screen is
connected.
A wlr_drm_connector only advertises a wlr_output to the compositor when
a screen is connected. As such, most of wlr_output's state is invalid
when the connector is disconnected.
We want to stop using wlr_output state on disconnected connectors.
Introduce wlr_drm_connector.name which is always valid regardless of the
connector status to avoid reading wlr_output.name when disconnected.
Simplify and unify connector-specific logging with a new
wlr_drm_conn_log macro. This makes it easier to understand which
connector a failure is about, without having to explicitly integrate the
connector name in each log message.
gbm_bo_create_with_modifiers doesn't take GBM flags, so our
wlr_gbm_allocator interface doesn't either. We were still internally
using GBM flags in the DRM backend, leading to awkward back-and-forth
conversions.
The only flag passed to drm_plane_init_surface was GBM_BO_USE_LINEAR, so
turn that into a bool to make sure other flags can't be passed in.
Move the "force linear" logic out of init_drm_surface, because the
supplied wlr_drm_format should already contain that information.
Rename wlr_renderer_get_dmabuf_formats to
wlr_renderer_get_dmabuf_texture_formats. This makes it clear the formats
are only suitable for creating wlr_textures.
wlr_surface_send_enter now stores outputs that have been entered.
Combined with a new 'bind' event on wlr_output, this allows us to delay
enter events as necessary until the respective wl_output global has been
bound.
Closes: https://github.com/swaywm/wlroots/issues/2466
Wait for a DRM device if none is found in wlr_session_find_gpus. This
can happen if the compositor is loaded before the display kernel driver.
This supersedes the logind CanGraphical property.
To test, e.g. with i915 and sway:
rmmod -f i915
sway &
modprobe i915
Closes: https://github.com/swaywm/wlroots/issues/2093
Instead of operating on FDs in {open,close}_device, operate on
wlr_devices. This avoids the device lookup in wlr_session and allows
callers to have access to wlr_device fields.
For now, we use it to remove wlr_session_signal_add and replace it with
a more idiomatic wlr_session.events.change field. In the future, other
events will be added.
The swapchain maximum capacity is set to 4, so that we have enough room
for:
- A buffer currently displayed on screen
- A buffer queued for display (e.g. to KMS)
- A pending buffer that'll be queued next commit
- An additional pending buffer in case we want to invalidate the
currently pending one
Every host seat with pointer capability propagates events to one of
sub-pointer depending which output window we entered.
active_pointer tracks reference to sub-pointer on enter/leave events to
avoid lookup for it on every move events.
Fixesswaywm/wlroots#1499
We were previously exporting DMA-BUFs when receiving the capture_output
request, and sending a done event on wlr_output.events.precommit. Instead,
export and send done on wlr_output.events.commit.
The resource field of wlr_xdg_positioner is never initialized or
accessed within wlroots. The wl_resource for this interface is stored
in the wlr_xdg_positioner_resource struct.
This brings the layer-shell api in line with that of xdg-shell and
avoids reimplementing this function in every compositor in order to
render layer shell popups correctly.
This type is meant to be 4 bytes large as seen in _XcursorReadUInt which
always reads 4 bytes. An unsigned int is often 4 bytes large but this
isnt' guaranteed so it is cleaner to use the exact type we want.
This event contains a `committed` bitfield, which allows callers to know
which output fields changed during the commit.
This allows users to setup a single atomic commit listener, instead of
setting up one listener for each event (mode, scale, transform, and so
on).
References: https://github.com/swaywm/wlroots/issues/2098
These states are distinct in the time period between the ack_configure
and the next commit on the surface. Splitting these states avoids the
following race for example:
- client starts at 1000x1000
- wlr_xdg_toplevel_set_size 500x500
- size is different -> configure sent
- client acks the configure
- wlr_xdg_toplevel_set_size 1000x1000
- compare_xdg_toplevel_state returns true since there is no pending
configure and the currently committed size is still 1000x1000
- no new configure is sent
- client commits at the size it last acked, 500x500
Certain clients require this property to be set for expected behavior.
Most notably, steam client CSD maximize button no longer worked
after unmaximizing once, unless the state was changed by another
method. The state is unset whenever another surface gains focus.
