| Age | Commit message (Collapse) | Author |
|---|
|
This is a common interface that can be used for all primary selection
protocols, as discussed in [1]. A new function wlr_seat_set_primary_selection
is added to set the primary selection for all protocols.
The seat now owns again the source, and resets the selection to NULL when
destroyed.
[1]: https://github.com/swaywm/wlroots/issues/1367#issuecomment-442403454
|
|
This commits completely refactors wlr_gtk_primary_selection. The goal is to
remove gtk-primary-selection state from the seat and better handle inert
resources where it makes sense.
wlr_seat_client.primary_selection_devices has been removed and replaced by
wlr_gtk_primary_selection_device. This allows us to make offers inert when the
current selection is replaced.
wlr_seat_set_primary_selection has been removed because it relied on wlr_seat
instead of wlr_gtk_primary_selection_device_manager. A new function,
wlr_gtk_primary_selection_device_manager_set_selection (candidate for the
longest function name in wlroots) has been added. It doesn't take a serial
anymore as serial checking only makes sense for set_selection requests coming
from Wayland clients (serial checking is now done in the Wayland interface
implementation).
Since wlr_gtk_primary_selection_device_manager is now required to set the
selection, a new function wlr_xwayland_set_gtk_primary_selection_device_manager
(candidate number two for longest function name) has been added.
Devices are now made inert when the seat goes away.
Future work includes removing the last primary selection bits from the seat,
mainly wlr_seat.primary_selection_source and wlr_seat.events.primary_selection,
replacing those with new fields in wlr_gtk_primary_selection_device. Or maybe
we could keep those in the seat and replace them with a re-usable interface
(for future zwp_primary_selection_v1 support). We need to think how we'll sync
these three protocols (GTK, X11 and wayland-protocols).
See https://github.com/swaywm/wlroots/issues/1388
|
|
|
|
We don't require it, Xwayland doesn't require it, and all X11 apps I tried
don't need it.
|
|
|
|
Depending on the log verbosity, close the stdout/stderr streams.
|
|
|
|
|
|
Fixes #964
|
|
|
|
|
|
|
|
Makes the xwayland startup process two phased.
The first phase just initialises the X11 sockets.
The second phase starts the Xwayland server itself.
When starting xwayland lazily the second phase will be postponed until
a client has connected to the X11 socket.
Changes in behaviour:
The DISPLAY environment is now set immediately after the X11 sockets
are created.
When the Xwayland server is killed or crashes, the sockets will not be
recreated, but reused.
Fixes #849: Start up Xwayland lazily
|
|
|
|
Some systems don't have xwayland in /usr/bin, but in other paths.
wlroots was unable to find Xwayland binaries outside of standard locations
|
|
|
|
|
|
xwm.h was meant to be private, so move it to include/xwayland/xwm.h
We had an ifdef WLR_HAS_XCB_ICCCM in xwayland.h which was easy to move
to xwm, it is not safe to use the WLR_HAS_* in the public headers.
I checked a few of our current users and none rely on xwm.h being
public as expected (rootston, sway, hsroots)
|
|
This adds `wlr_xwayland_surface_is_unamanged`, to allow compositors more
fine grained control over XWayland focus.
A surface that is unmanaged should not receive focus, while other
windows that are just override redirect may want it (dmenu).
The way unamanged is determined is taken from wlc.
|
|
|
|
|
|
|
|
|
|
|
|
This is more robust than trying to recopy a few fields.
Note: wlr_xwayland->events.ready now resets after each trigger, so one can
hook on it again and be called when restart is ready
|
|
|
|
This is very ugly, there must be a better way to do that (not memset it?)
Meanwhile, this fixes rootston xwayland on restart
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The intermediate fork needs to wait for SIGUSR1 for when Xserver is
ready, or SIGCHLD if the exec didn't work out.
Also change the exit() to _exit() as that is apparently more appropriate
for forks (and waitpid's status was wrong without it for some reason)
Fixes #122.
|
|
wayland WILL close this fd during wl_client_destroy, after our handler
if we close it as well this will close some of the fd we reopened
|
|
|
|
|
|
|
|
|
|
|
