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
Attachment:
pgpN5QUCOm0Ok.pgp
Description: OpenPGP digital signature
