GitLab

A launchee notifies with a "remove"¹ message when done starting up.
Catch these and forward to the compositor. This allows the compositor to
end the startup sequence that might have been started by another
protocol like xdg-activation.

We don't handle other messages since we expect the launcher to use a
wayland protocol like xdg-activation.

While `_NET_STARTUP_ID` helps to associate toplevels with startup-ids
this signals the end of the startup sequence.

1) https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt

(cherry picked from commit e479dc1e)

This is use for startup notifications per startup-notifiation spec

https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
(cherry picked from commit de1522ae)

This reverts commit 8dec751a.

Revert this until phosh has a fixed release.

Ilia Bozhinov authored Oct 27, 2020 and emersion committed 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.

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

We don't support that yet.

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.

Similar to the one already present in wlr_output_event_precommit.

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.