Originally, I thought that we could safely subtract opaque regions
from the background even if the black rect optimization was kicking in.
This is wrong because a scene node that isn't fully occluded will still
appear in the render list even if its partially under a black rect. We
need to make sure that while culling the background, we only consider
opaque regions that are also visible. This will fix the black rect
optimization with the background.
We don't need to worry about the black rect optimization here (that
always assumes that there will be a black background) because the
background is culled based on the render list. That means if a black rect
is removed, the visibility will reach all the way to the bottom forcing
the renderer to clear the area not breaking the assumption.
If culling is not enabled, there is no longer any guarantee that the
elements behind the rect won't be rendered. We must render the black rect
in all circumstances to cover up anything rendered.
This fixes the WLR_SCENE_DISABLE_VISIBILTY option.
If the client binds to version 3 of zxdg_output_v1 and version 1 of
wl_output no wl_output.done or zxdg_output_v1.done event is
emitted [1].
Also no wl_output.done event is emitted when version 2 or lower of
zxdg_output_v1 is bound to.
Add a version check to output_manager_handle_get_xdg_output so that no
wl_output.done event is emitted when using version 1 of wl_output and
version 2 or lower of zxdg_output_v1.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/81
This has a few benefits one of them crucial for proper operation:
- The primary output will be based on the largest area that is actually
visible to the user. Presentation and frame done events are based on
this state. This is important to do since we cull frame done events.
If we happen to be in a situation where a surface sits mostly on output
A and some on output B but is completely obstructed by for instance a
fullscreen surface on output A we will erroneously send frame_done
events based on output A. If we base things as they are in reality
(visibility) the primary output will instead be output B and things will
work properly.
- The primary output will be NULL if the surface is completely hidden.
Due to quirks with wayland, on a surface commit, frame done events are
required to be sent. Therefore, a new frame will be submitted for rendering
on the primary output. We can improve adaptive sync on completely hidden
but enabled surfaces if we null out the primary output in this state.
- The client will be more likely to choose better metadata to use
for rendering to an output's optimal rendering characteristics.
We can also get rid of the intersection checks in the rendering functions
because we are guaranteed to already be in the node do to the prior
intersection checking of the node visibility.
Simplify damage handling by using our cached visibility state.
Damaging can happen in one step because since we can use the old visibility
state which represent what portions of the screen the scene node was. This
way we can damage everything in one step after the fact.
Will query the scene for all nodes that appear in the given wlr_box.
The nodes will be sent to the iterator from closest to farthest from the
eye.
Refactor wlr_scene_node_at to use this new function.
This lets the renderer handle the wlr_buffer directly, just like it
does in texture_from_buffer. This also allows the renderer to batch
the rectangle updates, and update more than the damage region if
desirable (e.g. too many rects), so can be more efficient.
Only the exclusion zone for mapped layer shell surfaces should be respected. In
particular, a layer shell surface that was mapped with an exclusion zone but is
now unmapped should not adjust the usable area.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3471
This allows whatever the user calls from the signal handlers to react to observe
the new state rather than the old, e.g. that a surface is no longer mapped in
the unmap handler.
This results in the following warning, which in release mode causes an
error due to -Werror:
../types/seat/wlr_seat_pointer.c: In function ‘wlr_seat_pointer_send_axis’:
../types/seat/wlr_seat_pointer.c:344:25: error: ‘low_res_value_discrete’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
343 | if (version < WL_POINTER_AXIS_VALUE120_SINCE_VERSION &&
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
344 | value_discrete != 0 && low_res_value_discrete == 0) {
| ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
This commit fixes:
- sending discrete scrolling events to multiple pointer resources
- sending events to clients which don't support wl_pointer.axis_discrete
When the client doesn't support high-resolution scroll, accumulate
deltas until we can notify a discrete event.
Some mice have a free spinning wheel, making possible to lock the wheel
when the accumulator value is not 0. To avoid synchronization issues
between the mouse wheel and the accumulators, store the last delta and
when the scroll direction changes, reset the accumulator.
Upgrade the seat protocol to version 8 and handle clients that support
high-resolution scroll wheel events.
Since the backend already sends discrete values in the 120 range,
forwarding them is enough.
Currently, the "wlr_event_pointer_axis" event stores low-resolution
values in its "delta_discrete" field. Low-resolution values are always
multiples of one, i.e., 1 for one wheel detent, 2 for two wheel
detents, etc.
In order to simplify internal handling of events, always transform in
the backend from the low-resolution value into the high-resolution
value.
The transformation is performed by multiplying by 120. The 120 magic
number is used by the kernel and it is exposed to clients in the
"WLR_POINTER_AXIS_DISCRETE_STEP" constant.
When using direct scanout back_buffer is NULL. We'd emit a commit
event with WLR_OUTPUT_STATE_BUFFER set but with a NULL buffer field,
which is non-sensical.
