...on the basis that it reduces user-space breakage with respect to
layer-shell clients disappearing on suspend/resume and on VT change.
Revert the following two commits:
- 1edd5e2 "backend/drm: Remove reset from interface"
- 0f255b4 "backend/drm: Remove automatic reset on VT switch"
This it not intended to be reverted on the `master` branch. Instead, the
next wlroots release is anticipated to handle the situation differently,
possibly by splitting some objects and leaving output-related wl_globals
which have been announced to clients. See discussions on [issue-3944].
[issue-3944]: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3944#note_3030632
Background:
With [MR-4878] on wlroots-0.19.0, the DRM backend destroys/recreates
outputs on VT switch and in some cases on suspend/resume too. The reason
for this change was that (i) the KMS state is undefined when a VT is
switched away; and (ii) the previous outputs had issues with restoration,
particularly when the output configuration had changed whilst switched
away. This change causes two issues for users:
- Some layer-shell clients do not re-appear on output re-connection, or
may appear on a different output. Whilst this has always been the case,
it will now also happen in said situations. It is technically possible
for layer-shell clients to deal with this more thoughtfully by handling
the new-output and surface-destroy signals to achieve desired
behaviours, but such changes take time and meanwhile Desktop Environment
teams and other users consider this a serious regression.
- Some Gtk clients issue critical warnings on some compositors as they
assume that at least one output is always available. This will be fixed
in `Gtk-3.24.50` and is believed to be a harmless warning,
[MR-4878]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4878
Testing:
1. This reversion has been tested with [conky] and [GlassyClock]. With the
reversion applied, the clients remain visible after VT switching.
2. It was also tested with labwc on tty1; and sway on tty2. No adverse
affects were observed when changing output scales on either compositor.
[conky]: https://github.com/brndnmtthws/conky
[GlassyClock]: https://github.com/tsujan/GlassyClock
The spec says [1]:
> If set, the Window Manager should use this in preference to WM_NAME.
However we overwrite WM_NAME with NULL when _NET_WM_NAME is unset.
Fix this by storing both WM_NAME and _NET_WM_NAME, so that we
handle properly all combinations of events (e.g. a client setting
both and later clearing one).
[1]: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html#id-1.6.2
This reverts commit 86eaa44a3a.
That commit caused a regression for IME users in many compositors:
when a input_method is activated while a key is pressed, and a virtual
keyboard is created by IME, the following key-release event via the
virtual keyboard is missed since the key in the virtual keyboard haven't
been pressed. For example, pressing and releasing Ctrl+F in Firefox with
fcitx5 running triggered repeated keys (ffffff...) in the opened input
box.
Move single-pixel buffer status cache from wlr_scene_surface to
wlr_scene_buffer, it makes more sense there and means the optimisations
will still work if wlr_scene_buffer is used without wlr_scene_surface.
Direct scanout can be enabled and disabled on a frame-by-frame basis,
and so we could end up sending different feedback to a surface on every
other frame. Reacting to new feedback is expensive, as the client may
need to reallocate their swapchain.
Debounce the state change a number of frames, for now set to 30, to
avoid immediate reaction to scanout (or composition) that only lasts a
few frames.
A timer could be used instead, but it did not seem worth the complexity.
What just want to know that the state has been stable across a
reasonable number of samples, and a counter seems sufficient for that.
The single-pixel buffer protocol is used to allow wayland clients to
easily draw solid-color rectangles by presenting a 1x1-pixel buffer and
scaling it to the desired size. This patch improves how these buffers
are then handled in the scene-tree renderer.
We already ignore opaque black rectangles at the very bottom (and
anything under them) because we assume we'll be rendering on a black
background. This patch detects black opaque single-pixel buffers and
handles them in the same way as black opaque rectangles. It also
renders single-pixel buffers as rectangles rather than buffers because
this is probably more efficient in the underlying renderer.
In wlr_scene_surface we cache whether the attached buffer is a
single-pixel buffer. This is done because the
wlr_single_pixel_buffer_v1 will be destroyed after texture upload, after
which it becomes much more annoying to check if the buffer is a
single-pixel buffer.
Add wlr_single_pixel_buffer_v1_try_from_buffer() and move `struct
wlr_single_pixel_buffer_v1` to wlr_buffer.h. This allows other code to
find out if a wlr_buffer is a single-pixel buffer and, if so, find out
what color it is.
This avoids processing events which we're not interested in.
Specifically, this fixes a case where output_commit() could be
indirectly called from itself either from import_dmabuf() or while
waiting for a configure event when enabling the output.
Remove unneeded includes of wlr_output.h from wlr_compositor.h and
wlr_cursor.h (unneeded now that we forward-declare struct wlr_surface)
and put the actually-required includes in the right places.
wlr_compositor.h contains references to `struct wlr_surface` in function
arguments before it actually defines it. This generally works because
wlr_compositor.h includes wlr_output.h which contains a
forward-declaration for `struct wlr_surface` (despite not actually
referencing it).
This is all pretty weird, and gives very confusing errors if you manage
to end up with wlr_output.h including wlr_compositor.h (eg. via an
indirect route) so make it less weird.
The old approach of using a signal is fundamentally broken for a common
usecase: When the waiter is ready, it's common to immediately finish and
free any resources associated with it.
Because of the semantics of wl_signal_emit_mutable() this is UB.
wl_signal_emit_mutable() always excepts that the waiter hasn't been freed
until the signal has finished being emitted.
Instead of over engineering the solution, let's just add a callback required
by wlr_drm_syncobj_timeline_waiter_init(). In this callback, the implementation
is free to finish() or free() any resource it likes.
This fixes a problem where an outdated surface input region was used to
compute the effective confinement region.
Additionally, this commit fixes a bug in pointer_constraint_create()
which caused the initial region to not be applied immediately.
This is a breaking change: set_region is now emitted before the role
commit hook is called, and it's not emitted if the region hasn't
actually changed.
