xkb_keymap_new_from_string() assumes that the string is
NULL-terminated, but we don't check this so the function might
access outside the mmap'ed region. Use the safer
xkb_keymap_new_from_buffer() function.
Reported-by: Julian Orth <ju.orth@gmail.com>
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/work_items/4072
The predictive frame scheduler builds upon the presentation scheduler,
adding a delay based on the measured CPU and GPU time required to
prepare a frame to place the frame event as close as safely possible to
the commit deadline.
Previously, needs_frame was only set specifically when a non-damaging
update was required, and would only be cleared when the backend
committed the frame.
Under the new frame scheduler, needs_frame is always set when a frame is
scheduled, with effectively a single scheduling path for all change
sources, and needs_frame must have been true for a frame to be emitted.
Drop wlr_scene_output_needs_frame to make it clear that such a check is
no longer meaningful.
Headless present events aren't suitable for the present scheduler. This
new scheduler is a good place for headless' existing frame logic to go,
so move it into there.
With this decoupling, there's nothing tying the scheduler to the
headless backend, hence the generic name.
Actually send the modifiers event when there is no keymap set.
Compositors may need lower-level "raw" access to the key/modifiers
events from the backend. Currently it is impossible for a compositor
to get modifier events from the backend without them being filtered
through an xkb_state controlled by wlroots.
I need this feature for river in order to fix some keyboard state
synchronization bugs.
Note that setting a keymap resets the modifiers so I don't think setting
wlr_keyboard->modifiers directly here is a concern.
Currently the width/height of the extents is too small if the first node
visited has position/dimensions 0,0,100,100 and the second node has
position/dimensions -20,-20,10,10.
In this case the current code calculates total extents as
-20,-20,100,100 but the correct extents are -20,-20,120,120.
References: https://codeberg.org/river/river-classic/issues/17
This changes the behavior of wlr_linux_drm_syncobj_surface_v1 to
automatically signal release of previous commits as they are replaced.
Users must call wlr_linux_drm_syncobj_v1_state_add_release_point or
wlr_linux_drm_syncobj_v1_state_signal_release_with_buffer to delay the
signal as appropriate.
When doing direct-scanout, if the surface has color-representation
metadata present then pass on that metadata to the output state.
Also, if a buffer has color representation IDENTITY+FULL then normalise
this to NONE+NONE which is equivalent.
Add color_representation to wlr_output_state, holding color
representation metadata about the primary buffer. This can be set
using wlr_output_state_set_primary_color_representation() and a
new enum value WLR_OUTPUT_STATE_COLOR_REPRESENTATION in
wlr_output_state.committed indicates when this data is present.
Also add color-representation to wlr_output, and discard
color-representation in wlr_output_state if it matches what's already
been committed to the output.
This guards against a crash where the server implements
wlr_ext_image_capture_source_v1_interface without setting .get_pointer_cursor().
In general, we should install a NULL check here because this is a crash
waiting to happen. Now, instead of crashing, the resource will be created and
the copy capture session will be stopped.
The outputs loop in handle_scene_buffer_outputs_update may remove entries
from the list while iterating, so use wl_list_for_each_safe instead of
wl_list_for_each.
Fixes: 39e918edc8 ("scene: avoid redundant wl_surface.enter/leave events")
Currently we send wl_surface.enter/leave when a surface is hidden
and shown again on the same output. In practice, this happens very
often since compositors like river and sway enable and disable
the scene nodes of surfaces as part of their atomic transaction
strategy involving rendering saved buffers while waiting for
clients to submit new buffers of the desired size.
The new strategy documented in the new comments avoids sending
redundant events in this case.
The v5 layer shell interface allows the client to specify which edge the
exclusive zone will apply to, instead of deducing it from the anchor
points. Add support for this to the layer shell scene helper.
If the wlr_keyboard_group_remove_keyboard function is expanded, the code
is equivalent to:
```
wl_list_for_each_safe(device, tmp_device, &group->devices, link) {
struct wlr_keyboard_group *_group = group;
struct wlr_keyboard *_keyboard = device->keyboard;
struct keyboard_group_device *_device, *_tmp;
wl_list_for_each_safe(_device, _tmp, &_group->devices, link) {
if (_device->keyboard == _keyboard) {
remove_keyboard_group_device(_device);
continue;
}
}
}
```
It's just running one more loop meaninglessly.
wlr_scene_output_needs_frame checks wlr_output.needs_frame and
wlr_scene_output.gamma_lut_changed, neither of which incur damage. The
needs_frame flag is often set by e.g., cursor movement.
For the purpose of a capture frame we are only interested in frames with
damage. Continue without damage causes session_handle_source_frame to
silently skip copying the frame, which causes the session to get stuck:
no ready or failed event is emitted, and frame_pending is still set so
no further output frame events will occur.
Only render in case there is damage, but send frame callbacks
regardless.
