| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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, if the Wayland client died before an incremental transfer
was complete, the logs would be spammed by "write error to target fd" as
wlroots entered some control flow wherein it'd continually try
scheduling further writes to the already-dead pipe.
This commit contains no behavioral changes, but introduces explicit
handling for draining the X11 selection in case of Wayland client death.
|
|
If `xwm_data_source_write` failed, it's failed permanently. In fact, a
failing `xwm_data_source_write` sets `transfer->property_reply` to
null as part of its error handling.
Instead of relying on an indirect check (whether
`transfer->property_reply` is still non-null), explicitly use the return
value from `xwm_data_source_write`.
|
|
The `fd` is marked `O_NONBLOCK`, so `write` will never spuriously return
`EINTR`. Therefore, `write` failing is permanent, and we can return 0 to
make the return value meaningful.
|
|
wlroots would log "Unhandled NET_WM_STATE property change" log
messages for atoms we know about. Simplify the code structure
and remove these extra messages.
|
|
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".
|
|
Since we never end up calling xcb_convert_selection, the file descriptor
ends up getting leaked (i.e., not cleaned up within
xwm_data_source_write).
|
|
Previously, any error would be masked by an internal isatty call:
24:31:48.174 [DEBUG] [wlr] [xwayland/selection/incoming.c:386] XCB_SELECTION_NOTIFY (selection=277, property=278, target=256)
24:31:48.174 [ERROR] [wlr] [xwayland/selection/incoming.c:30] write error to target fd: Inappropriate ioctl for device
|
|
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
|
|
One of many memory leaks detected by an asan build
|
|
Developers can use x11trace or similar to analyze the protocol messages.
|
|
This function may end up being called more than once if the Xwayland
binary does not exist on the system.
|
|
The compiler is smarter at figuring out whether a function should be
inlined or not.
|
|
Closes: https://github.com/swaywm/wlroots/issues/2154
|
|
Xwayland has its own special handling for signals like SIGSEGV/SIGABRT.
Instead of leaving the job to the OS, it tries to walk up the call stack
(badly, because a lot of information is missing), print the stack trace
to stdout, then exit(1). This is very annoying because it prevents
Xwayland crashes from being easily debugged.
Xwayland has a flag "-core" that aborts instead of exiting. This allows
the OS to generate a coredump. It's far from perfect but better than
nothing, I guess.
|
|
|
|
|
|
|
|
This accidentally slipped through 1b0e4c7.
|
|
This is necessary to react to changes in position of override-redirect
views.
|
|
We already mostly did this, but there were a couple of branches
(`calloc` failures) where we'd bail without letting the other side know.
Refs swaywm/sway#4007. Likely not going to be a real improvement there
(if `calloc` fails you're already pretty screwed), but it does address a
theoretical possibility.
|
|
It seems that if we ever try to reply to a selection request after
another has been sent by the same requestor (we reply in FIFO order),
the requestor never reads from it, and we end up stalling forever on a
transfer that will never complete.
It appears that `XCB_SELECTION_REQUEST` has some sort of singleton
semantics, and new requests for the same selection are meant to replace
outstanding older ones. I couldn't find a reference for this, but
empirically this does seem to be the case.
Real (contrived) case where we don't currently do this, and things break:
* run fcitx
* run Slack
* wl-copy < <(base64 /opt/firefox/libxul.so) # or some other large file
* focus Slack (no need to paste)
fcitx will send in an `XCB_SELECTION_REQUEST`, and we'll start
processing it. Immediately after, Slack sends its own. fcitx hangs for a
long, long time. In the meantime, Slack retries and sends another
selection request. We now have two pending requests from Slack.
Eventually fcitx gives up (or it can be `pkill`'d), and we start
processing the first request Slack gave us (FIFO). Slack (Electron?)
isn't listening on the other end anymore, and this transfer never
completes. The X11 clipboard becomes unusable until Slack is killed.
After this patch, the clipboard is immediately usable again after fcitx
bails. Also added a bunch of debug-level logging that makes diagnosing
this sort of issue easier.
Refs swaywm/sway#4007.
|
|
When debugging Xwayland-related issues, a common first step in debugging
has been to ask the reporter to move their real Xwayland to
/usr/bin/Xwayland.bin, and create a shell script starting Xwayland with
extra arguments under the original /usr/bin/Xwayland location.
Introducing a `WLR_XWAYLAND` environment variable makes this less
invasive, by allowing the user to swap out Xwayland without resorting to
global system changes (or source patches).
|
|
Fixes #2425.
wlroots can only handle one outgoing transfer at a time, so it keeps a
list of pending selections. The head of the list is the currently-active
selection, and when that transfer completes and is destroyed, the next
one is started.
The trouble is when you have a transfer to some app that is misbehaving.
fcitx is one such application. With really large transfers, fcitx will
hang and never wake up again. So, you can end up with a transfer list
that looks like this:
| T1: started | T2: pending | T3: pending | T4: pending |
The file descriptor for transfer T1 is registered in libwayland's epoll
loop. The rest are waiting in wlroots' list.
As a user, you want your clipboard back, so you `pkill fcitx`. Now
Xwayland sends `XCB_DESTROY_NOTIFY` to let us know to give up. We clean
up T4 first.
Due to a bug in wlroots code, we register the (fd, transfer data
pointer) pair for T1 with libwayland *again*, despite it already being
registered. We do this 2 more times as we remove T3 and T2.
Finally, we remove T1 and `free` all the memory associated with it,
before `close`-ing its transfer file descriptor.
However, we still have 3 copies of T1's file descriptor left in the
epoll loop, since we erroneously added them as part of removing T2/3/4.
When we `close` the file descriptor as part of T1's teardown, we
actually cause the epoll loop to wake up the next time around, saying
"this file descriptor has activity!" (it was closed, so `read`-ing would
normally return 0 to let us know of EOF).
But instead of returning 0, it returns -1 with `EBADF`, because the file
descriptor has already been closed. And finally, as part of error-handling
this, we access the transfer pointer, which was `free`'d. And we crash.
|
|
This one was awful to track down, but calls to `wlr_log` with %m have
the errno masked by the `isatty` call in `log_stderr`. Switch them to
`wlr_log_errno` instead.
Cue quality "how can read(2) POSSIBLY be returning ENOTTY?" moments.
|
|
Implement a simple loop detection while trying to retrieve the parent
for a TRANSIENT_FOR window.
Fixes swaywm/sway#4624
|
|
|
|
|
|
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.
|
|
|
|
|
|
This avoids uninitialized items and makes it clear where the magic
number 2 is coming from.
|
|
This helps mitigate buffer overflows.
|
|
In case wl_event_loop_add_timer errors out, don't insert the free'd
wlr_xwayland_surface in the list.
Closes: https://github.com/swaywm/wlroots/issues/1721
|
|
|
|
This improves the failure cases when incremental transfers fail to
complete successfully for one reason or another.
|
|
If Xwayland is restarted, the ready handler assumes there is no xwm instance.
This means all of xwm was leaked on Xwayland restart. This caused compositors
to consume all cpu resources, where time is spent dispatching. Now we destroy
xwm if we get an event mask containing WL_EVENT_HANGUP or WL_EVENT_ERROR.
|
|
The xwayland ready signals are used to do initial setup like starting xwm.
Discarding the signals means that the handler functions will not be called
in the case that Xwayland is restarted and thus, xwm managed clients fail.
Fixes #2174."
|
|
This prevents a very unlikely crash in `xwayland_socket_connected`.
Refs #2163.
|
|
This fixes issues with (at least) dialogs in Jetbrains IDEs becoming
unclickable if they ever lost focus (ref. swaywm/sway#5373). Prior to
this change, since `xwm->focus_surface` would be set prior to
`xwm_surface_activate` being called, the latter would short-circuit
immediately and not notify the application of the focus change.
|
|
|
|
Split the server part of wlr_xwayland into wlr_xwayland_server. This
allows compositors to implement their own XWM when wlroots' isn't a good
fit.
|
|
Previously, some atoms had a leading underscore, others didn't. Be more
consistent and never use a leading underscore (symbols with a leading
underscore followed by an upper-case letter are reserved).
|
|
|
|
It's very easy to break the mapping between the atom_name enum and the
atom_map array. Use explicit indexes to prevent issues.
|
|
This reflects what i3 does [1].
[1]: https://github.com/i3/i3/blob/b3faf9fca9254679a4715486a4de80ebaee70410/src/handlers.c#L1076
Fixes: c067fbc010da ("xwm: allow applications to change focus between their own surfaces")
Closes: https://github.com/swaywm/sway/issues/4926
|
|
Although currently this problem is present in only Steam, and it is
actually a client bug.
|
|
When running wlroots compositors with Xwayland executable bits
unset, if DISPLAY is set to the display number wlroots has set
up, then X and gtk clients (at least) hang when they are ran.
X clients should fail with an error and exit while gtk clients
should fall back to wayland backend and run correctly. This is
because wlroots opened sockets for Xwayland but wasn't closing
them if Xwayland failed to start.
|
|
Bumps minimum version to 0.51.0
- Remove all intermediate static libraries.
They serve no purpose and are just add a bunch of boilerplate for
managing dependencies and options. It's now managed as a list of
files which are compiled into libwlroots directly.
- Use install_subdir instead of installing headers individually.
I've changed my mind since I did that. Listing them out is annoying as
hell, and it's easy to forget to do it.
- Add not_found_message for all of our optional dependencies that have a
meson option. It gives some hints about what option to pass and what
the optional dependency is for.
- Move all backend subdirectories into their own meson.build. This
keeps some of the backend-specific build logic (especially rdp and
session) more neatly separated off.
- Don't overlink example clients with code they're not using.
This was done by merging the protocol dictionaries and setting some
variables containing the code and client header file.
Example clients now explicitly mention what extension protocols they
want to link to.
- Split compositor example logic from client example logic.
- Minor formatting changes
|
