| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
We're about to get one more Xwayland-related thing, and this header
already contains two things.
|
|
Version 4 of the protocol adds support for reporting/setting adaptive
sync state of outputs. Implement these new requests/events in wlroots.
|
|
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3514
|
|
References: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/29
|
|
|
|
We were crashing in the error codepath [1] when
wlr_drm_create_lease() fails.
To fix this, delay the creation of the wlr_drm_lease_v1 until the
request is granted. Previously we were allocating that struct early
without populating the drm_lease field. However that means we ended
up with a half-constructed struct in the error codepath which is
annoying to handle.
[1]: https://github.com/swaywm/sway/issues/7204#issuecomment-1269797356
|
|
|
|
|
|
These are unused.
|
|
.. by including wlr_buffer.h
|
|
When starting up, the compositor might call wlr_output_set_mode()
with a mode which is already the current one. wlroots will detect
this and make the wlr_output_set_mode() call a no-op. During the
next wlr_output_commit() call, wlroots will perform an atomic
commit without the ALLOW_MODESET flag.
This is an issue, because some drivers need ALLOW_MODESET even if
the mode is the same. For instance, if the FB stride or modifier
changed, some drivers require a modeset.
Add a new flag "allow_artifacts" which is set when the compositor
calls mode-setting functions. Use this flag to figure out whether
we want to perform atomic commits with ALLOW_MODESET.
(The name "allow_artifacts" is picked because ALLOW_MODESET is a
misnomer, see [1].)
[1]: https://patchwork.freedesktop.org/patch/505107/
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3499
|
|
Instead of using low-level wl_shm_buffer and wlr_dmabuf_v1_buffer
APIs, use the unified wlr_buffer APIs. That way it doesn't matter
what the exact wlr_buffer implementation is used, any which provides
the necessary capabilities (data_ptr or dmabuf) would work.
Simplifies the logic a bit, and will make the transition to wlr_shm
easier.
|
|
Make it clear it's only about shm, not about DMA-BUFs.
|
|
Will allow us to simplify common shm/DMA-BUF logic later on.
|
|
Make it clear that one is for shm buffers only, and the other is
for DMA-BUF buffers only.
|
|
CTA-861-H defines a picture aspect ratio which may be attached to
each mode. This affects the way the sink will display the image.
See annexes H.1 and H.2 for examples.
|
|
Be consistent with other headers.
|
|
Same as the previous commit.
|
|
dac040f87fee1cfdd7660aa1786b0734d95e03a4 mistakenly renamed
xdg_surface_destroy listener, which was listening to *unmap* events, to
xdg_surface_unmap. The actual fix, however, is to listen to destroy
events. This fixes various crashes.
|
|
It returns a bool, not an int.
|
|
This was previously used by the X11 backend but is no longer required
since the previous commit.
|
|
Previously, adaptive sync was just a hint and wouldn't make any
atomic commit fail if the backend didn't support it. The main reason
is wlr_output_test wasn't supported at the time.
Now that we have a way for compositors to test whether a change can
work, let's remove the exception for adaptive sync and convert it to
a regular output state field.
|
|
This simplifies some of the growth logic, but uses array_realloc to shrink the
array if needed.
|
|
|
|
|
|
|
|
visibility
|
|
|
|
Also make the regular rendering logic use the introduced
render list.
|
|
|
|
This indicates whether the surface offset has changed.
|
|
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.
|
|
Closes: #3405
Supersedes: !3562
Co-authored-by: Xiao YaoBing <xiaoyaobing@qq.com>
|
|
This implements the single-pixel-buffer-v1 protocol [1], to allow clients
to create 1x1 buffers with a single color.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/104
|
|
This version adds a wm_capabilities event.
|
|
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.
|
|
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.
|
|
The logic doesn't support handling multiple outputs so let's not break
the assumption and handle damages per output much like how damage_ring
is done.
|
|
wlr_xdg_surface_from_wlr_surface() for example may return NULL even if
the surface has the xdg surface role if the corresponding xdg surface
has been destroyed.
|
|
This is necessary to handle damage coming from the backend and software
cursors.
|
|
|
|
wlr_damage_ring is effectively wlr_output_damage untied from wlr_output.
|
|
Events used by our input devices were recently renamed from wlr_event_* to
wlr_*_event, but the documentation and a single point of use was not updated
accordingly.
Regressed by: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3484
|
|
This union is unnecessary since the recent input device refactor and can
now be replaced by wlr_*_from_input_device() functions.
|
|
|
|
This function applies a configuration sent by a client on a
struct wlr_output_state.
|
|
Whether a texture is opaque or not doesn't depend on the renderer
at all, it just depends on the source buffer. Instead of forcing
all renderers to implement wlr_texture_impl.is_opaque, let's move
this in common code and use the wlr_buffer format to know whether
a texture will be opaque.
|
|
69477051ccff ("matrix: deprecate wlr_matrix_projection") marked it
as deprecated. 1 year later, we can now remove it from our public
API.
|
