XWayland clients use the _NET_WORKAREA root window property to determine
how much of the screen is not covered by panels/docks. The property is
used for example by Qt to determine areas of the screen that popup menus
should not overlap (see QScreen::availableVirtualGeometry).
Depends on wlroots MR:
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4406
v2: prevent calling wlr_xwayland_set_workareas() too early
v3: fix segfault at exit (server->xwayland == NULL)
Chases: 756ecf8ee9f1e75bc7b8297dc84f97c7d699174b
backend/wayland: use request_state when toplevel is resized
Chases: 3ef68a484243555b020200c6f95246d994932c3f
backend/x11: use request_state when window is resized
Ref: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/2693
We now delay requested resolution changes by the backend until
the next frame event which causes us to render the new content
on the already enlarged buffer. Before this change, an empty
(black) buffer would have been shown instead before the next
frame event caused a new render of the actual contents.
Keep commiting the new state and then scheduling a frame event
would not help as due to the commit call it would still show an
empty buffer in the meantime.
Just modifying wlr_output->pending wouldn't work either because
wlr_scene_output_commit() *completely* ignores it (and it will
be removed in future wlroots commits). For this reason we move
to wlr_scene_output_build_state() directly because it allows us
to supply the current wlr_output->pending state and thus apply
any resolution change in lockstep with new rendering. Result:
No more flickering in the wayland backend and resizing is again
smooth as butter.
This prevents constant flicker while resizing
when running nested via the wayland backend.
For the X11 backend (can be tested via `WLR_BACKENDS=x11 labwc`),
it is still rather janky but at least doesn't cause endless self-
resizing anymore.
Use the same fix/workaround as in output_update_for_layout_change() to
make sure that the cursor is also visible after (re-)enabling an output
in handle_output_power_manager_set_mode().
Currently, if the output layout changes while the session is locked,
the lock surfaces may end up wrongly positioned, which looks bad and
may reveal some of the user's workspace underneath.
To prevent this, re-align the scene trees and reconfigure the lock
surfaces when the output layout changes.
The wlroots wlr_output_layout provides two different modes of operation:
- automatically
- manually
In automatic mode wlroots reacts to new / removed outputs and resolution
changes and then adjusts the output positions within the layout itself.
The manual mode disables this behavior and thus it is the whole
responsibility of the caller (e.g. us relaying whatever wdisplays /
kanshi provides) to ensure that the layout is somewhat sane. E.g. that
it doesn't have any holes between outputs and there are no overlapping
outputs.
The mode is set for each output individually. To use (and keep using)
the automatic mode, outputs have to be added via the _add_auto() variant
(which we do) and they are not allowed to be moved via _move() (which
we currently do and thus break the automatic layout).
To fix that, this patch compares the user (tool) supplied position to the
automatically calculated position and only if they differ we call _move().
This restores the original approach of naming the argument `layout_changed`
which fits much better than `enforce_view_arrange`. Especially when extending
the function to also handle region updates once merged.
Move the desktop_arrange_all_views() call outside layers_arrange() into
a new function, output_update_usable_area(). The new function currently
does exactly what layers_arrange() used to, but will be expanded in a
later commit.
Add output_update_all_usable_areas(), which is the same as calling
output_update_usable_area() for each output, but only calls
desktop_arrange_all_views() once.
Rebased and slightly modified by @Consolatis
`output` here is the `pos` argument of `wl_list_for_each`, which means
it is always assigned a return value of `wl_container_of`; this in
turn means that it is never NULL.
checking against NULL here just confuses static analysis and readers
IMHO it encourages better design (by making dependencies more obvious)
to have source file/header file pairs like view.c/view.h, rather than a
monolithic header like labwc.h with everything in it.
I don't think we need to break up all of labwc.h at once, but maybe we
can start pulling it apart bit by bit as it's convenient.
Also:
- Move "struct border" to ssd.h so that view.h can use it without pulling
in all of labwc.h.
- Add a missing required #include within scaled_font_buffer.h (forward
declaration of "struct font" is not enough).
This fixes an issue with the wlr_output_cursor not being properly
initialized on new outputs, because wlr_output_layout.events.change
is triggered too soon, before the wlr_output_cursor exists.
Without this fix we will never react to output configuration changes
via wlr-randr and friends.
If output_config_apply() commits the new config, handle_output_layout_change()
is called but doesn't do anything because the config is still pending.
This patch moves the code into its own function do_output_layout_change()
which additionally gets called after all output configs are committed.
The original handler is turned into a wrapper around do_output_layout_change().
Reported-by @heroin-moose
Apps such as Gamescope eventually want to offer a DRM lease option to use planes and handle all of getting to the screen themselves.
This implements logic to allow leasing of desktop displays
