- Nov 08, 2020
-
-
xdg_popups can be destroyed by the compositor when closed. When this happens, wlroots makes the xdg_popup surface inert and resets the xdg_surface role to NONE. Currently, wlroots sends a protocol error and asserts that an xdg_surface has a role when committed. This is racy if at the same time the client commits an xdg_popup and the compositor closes it. This patch removes the assertion and ignores commits on xdg_surfaces without a role set.
- Nov 06, 2020
-
-
Simon Ser authored
Otherwise the client might have an outdated modifiers state. The same is done in wlr_seat_keyboard [1]. [1]: https://github.com/swaywm/wlroots/blob/8348fc3ef8b992fce097bef81111eda3677957f4/types/seat/wlr_seat_keyboard.c#L163
-
- Nov 05, 2020
-
-
-
Simon Ser authored
We don't support that yet.
-
Simon Ser authored
-
Simon Ser authored
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.
-
Simon Ser authored
Similar to the one already present in wlr_output_event_precommit.
-
Simon Ser authored
The docs were outdated and weren't matching what the DRM backend does (the only implementor of wlr_output_export_dmabuf).
-
Simon Ser authored
This allows callers to grab the current frame right after committing it, without having to incur a full vblank worth of latency.
-
- Nov 04, 2020
-
-
Simon Ser authored
This is already done by wlr_output_schedule_frame (it calls wlr_output_update_needs_frame).
-
- Nov 03, 2020
-
-
Simon Ser authored
Closes: https://github.com/swaywm/wlroots/issues/2372
-
-
Simon Ser authored
-
Simon Ser authored
When performing a modeset, the DRM backend will request a page-flip event. However frame_pending wasn't set to true, so any subsequent wlr_output_schedule_frame calls would imemdiately trigger a synthetic frame event, asking the compositor to submit a new frame. Committing the new frame fails with "a page-flip is already pending" error in the DRM backend.
-
- Nov 02, 2020
-
-
Simon Ser authored
This avoids Xlib.h inclusion via EGL headers. See [1] for discussion. This change is based on a Weston commit [2]. [1]: https://github.com/KhronosGroup/EGL-Registry/pull/111 [2]: wayland/weston@526765dd
-
- Oct 31, 2020
-
-
- Oct 30, 2020
-
-
When an output is disabled one last pageflip will happen to disable it. Currently this pageflip causes a frame event. Since the output is disabled we don't want to send this frame event.
-
- Oct 27, 2020
-
-
- Oct 20, 2020
-
-
-
-
This accidentally slipped through 1b0e4c7e.
-
- Oct 18, 2020
-
-
-
-
-
Daniel Kondor authored
Based on the wlr-protocols PR: https://github.com/swaywm/wlr-protocols/pull/52
-
-
-
Ilia Bozhinov authored
Goal currently is to get support working for a single output, thus there is only one touch device created. Multi-output support is left for later.
-
-
- Oct 16, 2020
-
-
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.
-
- Oct 14, 2020
-
-
This is necessary to react to changes in position of override-redirect views.
-
- Oct 13, 2020
-
-
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.
-
- Oct 12, 2020
-
-
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.
-
- Oct 11, 2020
-
-
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.
-