Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
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.
|
|
|
|
- Add a prefix to make it clear log messages come from libinput
- Properly convert libinput log priority to wlroots'
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
With version 2 we send make, model and serial number to allow clients the
identification of heads.
|
|
The following information through separate events are added:
- make
- model
- serial_number
This should allow clients to identify a display over different sessions and
load configuration data back.
A note is added that the description should be preferred when representing a
display in UI to users but as a short form for example the model could be used
in this case of course too.
|
|
|
|
seat0s have TTYs
|
|
When starting a compositor that's using the "direct" session backend,
wlroots needs to handle calls to `drmSetMaster()` and `drmDropMaster()`.
As both calls used to require `CAP_SYS_ADMIN`, wlroots thus simply
refused starting in case the process doesn't enjoy evelated privileges.
Permission rules have changed since linux.git commit 45bc3d26c95a (drm:
rework SET_MASTER and DROP_MASTER perm handling, 2020-03-19). As a
result, starting with Linux v5.8, both ioctls will now also succeed if
the process is currently or has been the DRM master. And as the first
process to open render nodes will become the DRM master automatically,
this effectively means that process elevation is not strictly required
in all setups anymore.
So let's drop the `geteuid() != 0` permission check to allow those new
rules to do their magic.
|
|
|
|
Ding dong the witch is dead
Fixes #2381
|
|
(almost certainly due to systemd version <246)
|