Color transforms are better suited than raw gamma tables, because:
- They don't need to get copied around: they are ref'counted.
- They can represent more color operations (will be useful for the
upcoming KMS color pipeline API, and for the Wayland color
management protocol).
Converting the LCMS2 transform to a 3D LUT early causes issues:
- It's a lossy process, the consumer will not be able to pick a
3D LUT size on their own.
- It requires unnecessary conversions and allocations: an intermediate
3D LUT is allocated, but the renderer already allocates one.
- It makes it harder to support arbitrary color transforms in the
renderer, because each type needs to be handled differently.
Instead, expose a function to evaluate a color transform, and use
that to build the 3D LUT in the renderer.
If a surface is mirrored on two outputs, we don't want to pick the
first output if the second has a higher refresh rate.
Also fixes duplicate frame/feedback events when a surface is added
to multiple scenes.
This lets the surface handler decide which output to send frame
callbacks from. The output_sample event already works this way.
Introduce wlr_scene_surface_send_frame_done() as a replacement for
wlr_scene_buffer_send_frame_done() when a compositor doesn't have
an output at hand.
Adds linux-dmabuf support to the pixman renderer. The main reason is so
clients can use GPU-accelerated rendering even if the compositor is
using the pixman renderer for whatever reason. This also allows the
pixman renderer to import dmabufs (only RGB/ARGB formats, not YUV for
now).
Since after this change all renderers store a DRM FD, I move the drm_fd
from the individual implementations to the shared wlr_renderer base.
This means that renderer_autocreate() can set pixman's drm_fd for it and
the pixman renderer doesn't have to know about DRM at all.
Originally based on
961edfe44e
Allow direct access to the pixel data of linux_dmabuf_v1 buffers by
mmapping the FD. This causes a wait on any outstanding fences and also
triggers the DMA_BUF_SYNC mechanism to do any cache fiddling needed.
This doesn't support multi-planar formats (e.g. YUV420 from hardware
codecs)
I also fix the comment on wlr_renderer.render_buffer_caps (it's used for
textures, not the render target) and update
wlr_renderer_init_wl_display() and
wlr_linux_dmabuf_feedback_v1_init_with_options() to use the renderer's
own claimed buffer_caps instead of hardcoding DMABUF as required.
Loosely based on 46ef2cfa3c
Follow-up from !4803. Make things consistent by making all `struct
timespec`s in events owned. Reduces the need for thinking about
ownership/lifetimes.
The spec says [1]:
> If set, the Window Manager should use this in preference to WM_NAME.
However we overwrite WM_NAME with NULL when _NET_WM_NAME is unset.
Fix this by storing both WM_NAME and _NET_WM_NAME, so that we
handle properly all combinations of events (e.g. a client setting
both and later clearing one).
[1]: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html#id-1.6.2
This reverts commit 86eaa44a3a.
That commit caused a regression for IME users in many compositors:
when a input_method is activated while a key is pressed, and a virtual
keyboard is created by IME, the following key-release event via the
virtual keyboard is missed since the key in the virtual keyboard haven't
been pressed. For example, pressing and releasing Ctrl+F in Firefox with
fcitx5 running triggered repeated keys (ffffff...) in the opened input
box.
