Since 1d581656c7 ("backend/drm: set "max bpc" to the max") we
set the "max bpc" property to the maximum value. The kernel driver
is supposed to clamp this value depending on hardware capabilities.
All kernel drivers lower the value depending on the GPU capabilities.
However, none of the drivers lower the value depending on the DP-MST
link capabilities. Thus, enabling a 4k@60Hz mode can fail on some
DP-MST setups due to the "max bpc" property.
Additionally, it's not a good idea to unconditionally set "max bpc"
to the max. A high bpc consumes more lanes and more clock speed,
which means higher power consumption and the busy lanes cannot be
used for something else (e.g. other data transfers on a USB-C cable).
For now, let's tie the "max bpc" to the pixel format of the buffer.
Introduce a heuristic to make "high bit-depth buffer" a synonym of
"I want the best quality".
This is not perfect: a "max bpc" higher than 8 might be desirable
for pixel formats with a color depth of 8 bits, for instance when
the color management KMS properties are used. But we don't really
support that yet, so let's leave this for later.
Closes: https://github.com/swaywm/sway/issues/7367
The invalid_destroy and invalid_unlock protocol errors aren't currently
sent by wlroots and instead left up to the compositor. However, we can
handle these as well without much additional complexity.
This also adds a missing wl_resource_destroy() call if the lock is inert
in lock_handle_unlock_and_destroy().
We only need it for one thing: gamma size. Moreover, some bits in
the drmModeCrtc will become out-of-date, for instance the current
mode, so let's avoid caching the whole struct and only keep what
we know won't change.
Instead of having a pending_fb field on the struct wlr_drm_plane,
move it to struct wlr_drm_connector_state. That way, there's no
risk having a stale pending FB around: the state doesn't survive
across tests and commits.
The cursor is a special case because it's disconnected from the
atomic state: the wlr_backend_impl.set_cursor hook sets the cursor
for the next commit. Move the field to
wlr_drm_connector.cursor_pending_fb.
We'll move the pending primary FB into the connector state in the
next commit, dropping wlr_drm_plane.pending_fb in the process.
Introduce a dedicated field for the cursor, which has to be managed
in a special way due to our set_cursor API.
This avoids re-building the whole project when switching one
Meson option. This shrinks down the compiler invocation command
line, making it more readable and making it easier to inspect
which flags are passed in (the generated file can be opened).
Additionally this is more consistent with our external feature
handling, which uses <wlr/config.h> already.
The Vulkan spec doesn't guarantee that the driver will wait for
implicitly synchronized client buffers before texturing from them.
radv happens to perform the wait, but anv doesn't.
Fix this by extracting implicit fences from DMA-BUFs, importing
them into Vulkan as a VkSemaphore objects, and make the render pass
wait on these VkSemaphores.
wlroots uses "// private state" comments to denote structure fields
which shouldn't be accessed by compositors, so let's drop
wlr_output_layout_output_state and inline its fields into
wlr_output_layout_output; this also simplifies layout output creation.
struct wlr_vk_format_props contains a mix of properties for shm
and dmabuf, and it's not immediately clear which fields are for
which kind of buffer. Use a nested struct to group the fields.
Query the formats at init time, then forget about the renderer.
This will allow wl_drm to be created with a list of formats instead
of a renderer, and will behave better after a GPU reset.
The backend no longer changes the output state behind the
compositor's back. Instead, compositors can listen to the "commit"
event and check for WLR_OUTPUT_STATE_ENABLED/WLR_OUTPUT_STATE_MODE.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2300
Some compositors may want to use the linux-dmabuf-v1 implementation
with a completely custom renderer. Add a function to create the
global with a default feedback.
Right now the Vulkan renderer blocks until the frame is complete
after rendering. This is necessary because Vulkan doesn't
interoperate well with implicit sync we use everywhere else.
Use the new kernel API to import a sync_file into a DMA-BUF to
avoid blocking.
We need to wait for the pending command buffer to complete before
re-using stage buffers. Otherwise we'll overwrite the stage buffer
with new contents before the texture is fully uploaded.
We need to wait for any pending command buffer to complete before
we're able to fully destroy a struct wlr_vk_texture: the Vulkan
spec requires the VkDescriptorSet to be kept alive.
So far we've done this in vulkan_end(), after blocking until the
command buffer completes. We'll soon stop blocking, so move this
logic in get_command_buffer(), where we check which commands buffers
have completed in a non-blocking fashion.
vkCmdCopyBufferToImage requires that the buffer offset be a multiple
of the texel block size, which for single plane uncompressed formats
is the same as the number of bytes per pixel. This commit adds an
alignment parameter to vulkan_get_stage_span which ensures that the
provided span (and the sequence of image copy operations derived which
use it) have this alignment.
0xFFFFFFFF milliseconds is 4,294,967,295 ms so about 50 days.
A little bit too close for comfort.
Use int64_t instead of uint64_t to avoid C's implicit conversion
footguns in computations.
This is a first step towards moving texture uploading out of
wlr_compositor.
This commit allows compositors to opt-out of the texture uploading
by passing a NULL wlr_renderer. An immediate user of this is
gamescope, which currently implements a stub wlr_renderer just to
make wlr_compositor happy.
Let's just forward-declare struct wlr_backend instead.
We need to fixup the Vulkan renderer: it needs makedev(), which
got included by chance via <wlr/backend.h> → <wlr/backend/session.h>
→ <libudev.h>.
This can be used to know when wlr_xwayland_server decides to start
a new Xwayland process. At that point the wl_client has already
been created but the Xwayland process hasn't been started yet.
Up until now, wlr_backend_autocreate() created the wlr_session and
then stuffed it into struct wlr_multi_backend so that compositors
can grab it later.
This is an abuse of wlr_multi_backend and the wlr_backend API:
wlr_backend_get_session() and wlr_multi_backend.session only exist
to accomodate the needs of wlr_backend_autocreate(). What's more,
the DRM and libinput backends don't implement
wlr_backend_impl.get_session.
Instead, return the struct wlr_session to the compositor in the
wlr_backend_autocreate() call. wlr_backend_get_session() will be
removed in the next commit.
This is a re-implementation of wl_shm. The motivations for using
this over the one shipped in libwayland are:
- Properly handle SIGBUS when accessing a wl_buffer's underlying
data after the wl_buffer protocol object has been destroyed.
With the current code, we just crash if the client does that
and then shrinks the backing file.
- No need to fight the wl_shm_buffer API anymore. This was awkward
because we weren't notified when clients created a wl_shm buffer,
and this doesn't play well with our wlr_buffer abstraction.
- Access to the underlying FD. This makes it possible to forward
the wl_shm buffer to a parent compositor with the Wayland/X11
backends.
- Better stride checks. We can use our format table to ensure that
the stride is consistent with the bpp and width.
We'll use this function from wlr_shm too.
Add some assertions, use int32_t (since the wire protocol uses that,
and we don't want to use 16-bit integers on exotic systems) and
switch the stride check to be overflow-safe.
Call glGetGraphicsResetStatusKHR in wlr_renderer_begin to figure
out when a GPU reset occurs. Destroy the renderer when this
happens (the OpenGL context is defunct).
The concept of a persistent accumulated surface offset is wrong
from a protocol point-of-view. wl_surface.offset is tied to a
commit, its interpretation depends on the surface role.
For example, with the following sequence:
wl_surface@1.offset(1, 1)
wl_surface@1.commit()
wl_pointer@2.set_cursor(wl_surface@1, 42, 42)
The final cursor hotspot is (42, 42): the commit which happened
before the set_cursor request has no impact on the hotspot
computation.
The wlr_output_cursor logic already uses wlr_surface.current.{dx,dy}.
wlr_scene's drag icon doesn't, update it accordingly.
Allow to get whether has alpha channel of the VkImage, it can help an
optimization to disable blending when the texture doesn't have alpha.
Because the VkFormat isn't enough because it's always set to
VK_FORMAT_B8G8R8A8_SRGB or VK_FORMAT_R8G8B8A8_SRGB.
This allows compositors to indicate which features they support,
and is required to eventually make this API stable.
References: https://github.com/swaywm/sway/issues/7260
32daa43a45 has removed the asymmetry in
the relationship of a wlr_surface and an unmapped wlr_xwayland_surface,
when wlr_surface.role_data wasn't NULL but wlr_xwayland_surface.surface
was. However, this also means that
wlr_xwayland_surface_from_wlr_surface() now returns NULL if the
wlr_surface is unmapped. Fix the documentation to reflect this.
