Paletted pixel formats could be supported in Wayland

[Pekka Paalanen]

Hi all,

once again I read some comments about how important paletted pixel
formats still are to some users. Here are some musings about how they
could be supported in Wayland, because I want to underline that Wayland
in no way denies paletted pixel formats; not for apps and not for
compositors.

Nothing stops Wayland compositors from using paletted pixel formats
towards hardware already, but it's not practical because the compositor
must convert from formats like ARGB8888 to paletted, which can be
costly. First, there needs to be a way for clients to deliver paletted
buffers, and second, there needs to be a way for the compositor to say
it prefers paletted pixel formats and the preferred palette.

We would need a Wayland extension, say, wp_color_palette, that can be
used to attach a palette to a wl_buffer. This can have the precondition
that the wl_buffer has a paletted pixel format and that the palette
matches the format. Compositors need to advertise paletted pixel
format support through the usual pixel format advertisements, but
produce a protocol error if such wl_buffer is attached anywhere without
a palette.

The palette itself could be a wl_buffer from the wl_shm factory. It can
be required to have width equal to the number of palette entries and
height=1 pixels. The pixel format of the palette buffer must not be
paletted itself, but otherwise it could be any ARGB or XRGB format if
such flexibility is useful. Or, the palette could be some completely
new structure. It's just that wl_shm already exists for CPU-accessible
mmapped pixel buffers, so it would be nice to re-use.

Nothing stops doing all that with dmabuf as well, if it had use.

The above would provide clients the ability to deliver arbitrary
paletted content, but the compositor might struggle to drive a paletted
framebuffer as the palette might not match the hardware.

wp_color_palette needs some way to give the preferred palette to
clients. Clients should use the preferred palette when possible.

A compositor would also want to produce a list of preferred pixel
formats. We have a precedent of this in zwp_linux_dmabuf_v1 in form of
the modifier feedback and similar design could be copied to apply to
wl_shm without modifiers. That would help clients to pick the best
pixel formats they can produce, e.g. a DRM_FORMAT_C4.

Who knows, maybe paletted pixel format support could be plumbed through
Xwayland too?

One important aspect is that any palette support must fit in with color
management as well. I believe that is achieved by using a palette to
map from DRM_FORMAT_Cx to ARGB, and then leaving the rest to the color
management extensions as they are defined, essentially making a
paletted buffer behave like an ARGB buffer.

Yes, this would allow paletted HDR content, as paradoxical as it might
be.

I see no fundamental or theoretical obstacles here, other than
difficulty of compositing with alpha. Maybe there would need to be an
option for fully transparent and fully opaque pixels with nothing in
between (no semi-transparent palette entries).

However, I have to leave any development in this direction to anyone
who actually needs this. I could take some part in reviewing the
protocol extension and Weston implementation, but that's all.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20221018/1b236de1/attachment-0001.sig>