Age | Commit message (Collapse) | Author |
|
|
|
We have the policy of requiring up-to-date dependencies instead of
adding conditionals for older versions. libinput 1.14 was published more
than 1 year ago.
|
|
|
|
Every host seat with pointer capability propagates events to one of
sub-pointer depending which output window we entered.
active_pointer tracks reference to sub-pointer on enter/leave events to
avoid lookup for it on every move events.
Fixes swaywm/wlroots#1499
|
|
|
|
This effectively gets swaywm/wlroots#1499 to the point where
functionality somewhat preserved and no crash happens.
We still can have only one cursor, but we can control it from multiple
seats in time-sharing manner by entering/leaving output.
|
|
|
|
|
|
|
|
|
|
This uncovered many places where we were using things without directly
including them.
|
|
This matches the signature of wlr_renderer_impl.begin
|
|
There's no reason to have duplicate enums
|
|
|
|
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
|
|
|
|
|
|
|
|
wlr_keyboard_modifier enums
|
|
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.
|
|
|
|
|
|
|
|
This accidentally slipped through 1b0e4c7.
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|