| Age | Commit message (Collapse) | Author |
|---|
|
Reduces code duplication.
|
|
Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
|
|
During direct scan-out, pass the damaged region to the wlroots
backend.
|
|
When there is no damage, no need to perform an output commit, even
when direct scan-out is used.
|
|
|
|
We already do this in handle_commit().
|
|
#7524 was a partial fix. Seems like this is still an issue when
unplugging and plugging the monitor back in.
Closes: https://github.com/swaywm/sway/issues/7528
|
|
Otherwise the initial bounds would be `INT_MAX` until `handle_mode` or `handle_commit` is called :)
|
|
|
|
Check whether output->damage_ring.current is empty before calling
wlr_output_attach_render(). Saves us from having to un-do that
via wlr_output_rollback().
|
|
That way output_render() only does what it says on the tin.
|
|
|
|
This sends fractional-scale-v1 events before the first configure
event. That way clients have all of the metadata they need to render
the first frame.
|
|
Closes: https://github.com/swaywm/sway/issues/7464
|
|
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3511
|
|
We can centralize all output-related surface events from there.
|
|
|
|
This way we can move focus on the same seat an activation token
originates from.
|
|
For compatibility with i3 [1].
[1]: https://i3wm.org/docs/ipc.html#_output_event
|
|
fixes #7394
Test cases:
* zwlr_output_configuration_head_v1_set_adaptive_sync 0->0, no change
* 0->1, enabled
* 1->0, disabled
* 1->1, no change
Similar tests with an incapable display resulted in `"Adaptive sync
failed, ignoring"` messages as expected.
|
|
Since [1], wlr_renderer_begin() can fail. Check its return value
and bail.
This fixes an assertion error (when begin() fails and then we try
to render something) after a GPU reset.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/commit/a541c9510a4cf544313bc9b0503d75820b42444e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We want to create a context before knowing the pid it will match with.
|
|
|
|
Views now maintain a reference to a launch context which, as a last
resort, is populated at map time with a context associated with its pid.
This opens the possibility of populating it before map via another
source, e.g. xdga-tokens or configuration.
|
|
Soon we will match views with more than just a pid.
|
|
This reuses wlroots token tracking for workspace matching. It doesn't
export any xdga tokens for clients yet.
|
|
This removes the need to rename the pid_workspaces when a workspace
is renamed.
It also opens the possibility of tracking other node types. Tracking
containers would allow application to be placed correctly in the
container tree even if the user has moved their focus elsewhere since
it was launched.
|
|
This removes the pid_workspace bits from tree/root before it gets
too interesting.
No functional change.
|
|
References: https://github.com/swaywm/wlroots/pull/2693
|
|
Fixes: https://github.com/swaywm/sway/issues/7254
|
|
wlr_output_damage is to be replaced with wlr_damage_ring, so use that.
|
|
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3753
|
|
Currently, when encountering a non-desktop display, sway offers the
output for leasing and returns without storing it in a sway specific
output type like `struct sway_output`. Additionally, running
`swaymsg -t get_outputs` doesn't show non-desktop outputs.
This commit stores the non-desktop outputs into a struct called
`sway_output_non_desktop`, and adds them to a list on `sway_root`
|
|
While at it, use an int for the config field, just like we do for
all other fields.
|
|
This commit reverts 03879290dbee26127f6867ef60bc2a7f9a6c8c5f and
fc84bcb7fb0ffa29b1f9bed287762241a3473803.
|
|
|
|
|
|
|
|
|
|
Our layer shell implementation assigns every layer surface to an output
on creation. It tracks this output using the output field on the
underlying wlr_layer_surface_v1 structure. As such, much of the existing
code assumes that output is always non-NULL and omits NULL checks
accordingly.
However, there are currently two cases where we destroy a
sway_layer_surface and output is NULL. The first is when we can't find
an output to assign the surface to and destroy it immediately after
creation. The second is when we destroy a surface in response to its
output getting destroyed, as we set output to NULL in
handle_output_destroy() before we call wlr_layer_surface_v1_destroy(),
which is what calls the appropriate unmap and destroy callbacks.
The former case doesn't cause any problems, since we haven't even
allocated a sway_layer_surface at that point or registered any
callbacks. The latter case, however, currently triggers a crash (#6120)
if a popup is visible, since our popup_handle_unmap() implementation
can't handle a NULL output.
To fix this issue, keep output set until right before we free the
sway_layer_surface. All we need to do is remove some of the cleanup
logic from handle_output_destroy(), since as of commit c9060bcc12d0
("layer-shell: replace close() with destroy()") that same logic is
guaranteed to be happen later when wlroots calls handle_destroy() as
part of wlr_layer_surface_v1_destroy().
This lets us remove some NULL checks from other unmap/destroy callbacks,
which is nice. We also don't need to check that the wlr_output points to
a valid sway_output anymore, since we unset that pointer after disabling
the output as of commit a0bbe67076b8 ("Address emersions comments on
output re-enabling") Just to be safe, I've added assertions that the
wlr_output is non-NULL wherever we use it.
Fixes #6120.
|
|
Currently, a floating window that's been fullscreened can send us
xdg_toplevel::move, and we'll enter seatop_move_floating, which lets us
drag the surface around while it's fullscreen. We don't want
this--fullscreen surfaces should always be aligned to the screen--so add
the same check that seatop_default already does when entering this mode.
Tested with Weston's weston-fullscreen demo, which sends a move request
if you click anywhere on its surface.
|
|
Improved type safety.
|
|
Improved type safety.
Closes: https://github.com/swaywm/sway/issues/6813
|
|
|
