The docs were outdated and weren't matching what the DRM backend does
(the only implementor of wlr_output_export_dmabuf).

This allows callers to grab the current frame right after committing it,
without having to incur a full vblank worth of latency.

This is already done by wlr_output_schedule_frame (it calls
wlr_output_update_needs_frame).

Closes: https://github.com/swaywm/wlroots/issues/2372

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.

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]: https://gitlab.freedesktop.org/wayland/weston/commit/526765ddfdfd

Marten Ringwelski authored Oct 29, 2020 and emersion committed 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.

Tudor Brindus authored Oct 19, 2020 and emersion committed Oct 20, 2020

This accidentally slipped through 1b0e4c7e.

Based on the wlr-protocols PR:
https://github.com/swaywm/wlr-protocols/pull/52

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.

Isaac Freund authored Oct 16, 2020 and emersion committed 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.

Ilia Bozhinov authored Oct 14, 2020 and emersion committed Oct 14, 2020

This is necessary to react to changes in position of override-redirect
views.

Tudor Brindus authored Oct 12, 2020 and emersion committed 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.

Tudor Brindus authored Oct 11, 2020 and emersion committed 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.

Tudor Brindus authored Oct 03, 2020 and emersion committed 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).

Tudor Brindus authored Oct 10, 2020 and emersion committed Oct 11, 2020

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.

Tudor Brindus authored Oct 10, 2020 and emersion committed Oct 11, 2020

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.

- Add a prefix to make it clear log messages come from libinput
- Properly convert libinput log priority to wlroots'

Roman Gilg authored Oct 01, 2020 and emersion committed Oct 09, 2020

The data of a head is only sent when it is enabled. While the head was disabled
data might have been changed. In this case clients were not informed about this
change. A later enable change that does not also update the other data must
still lead to the propagation of this data.

Since we do not know what other data was changed while the head was disabled
just send together with an enable change all current data.

Isaac Freund authored Oct 09, 2020 and emersion committed Oct 09, 2020

The protocol requires clients to set opposing anchors when requesting
a width or height of 0.

The goal of this patch is not to break clients that rely on this
behavior but to improve the consistency of the layer shell ecosystem
through adherence to the protocol.

Rouven Czerwinski authored Sep 19, 2020 and emersion committed Oct 08, 2020

Implement a simple loop detection while trying to retrieve the parent
for a TRANSIENT_FOR window.

Fixes swaywm/sway#4624

I'm not sure what this was used for, but it's not used by libwayland.
Setting _WAYLAND_DISPLAY would result in the Wayland backend being
picked but would ignore the actual value of the env variable.

Isaac Freund authored Sep 08, 2020 and emersion committed Sep 10, 2020

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.

Roman Gilg authored Sep 03, 2020 and emersion committed Sep 04, 2020

With version 2 we send make, model and serial number to allow clients the
identification of heads.