Additional pixel formats for wl_shm

[Kristian Høgsberg]

On Fri, Apr 26, 2013 at 04:08:01PM +0300, Pekka Paalanen wrote:
> Hi Kristian,
> 
> I'm working on Raspberry Pi, where the VideoCore can deal directly with
> a large number of pixel formats. However, wl_shm only exposes ARGB and
> XRGB 32-bit per pixel formats, which on such tiny devices are very
> wasteful.
> 
> Would it be acceptable to add more formats to the wl_shm formats enum?
> I have happily forgot all the previous discussions about the topic, and
> a quick search into the mailing list archives didn't turn up much.
> 
> We are especially interested in 16-bit per pixel formats to save memory
> and bandwidth, and if I am reading the GLESv2 specification right,
> RGB565, RGBA4444 and RGBA5551 should be directly supported, so at least
> those could be uploaded into textures without manual conversion. Of
> course, the new rpi-renderer I am working on does not use GL for
> compositing anymore, but it should be able to use those formats
> directly, too.
> 
> I have also another proposition: an extension to let wl_shm support
> custom pixel formats outside of the core protocol listed formats.
> 
> It would have a new global interface, which when bound, would advertise
> additional pixel formats as a (string, uint) tuple, where the string
> describes the pixel format, and the uint is the corresponding format
> name to pass into wl_shm_pool.create_buffer as the format argument.
> wl_shm would not advertise these format names itself. We would need to
> define a WL_SHM_FORMAT_CUSTOM_BASE to reserve some name space for the
> custom formats.
> 
> Or something along those lines.
> 
> Of course, this is just working around the pixel format enum wl_shm has
> anyway, so if you would be willing to take more exotic pixel formats
> into the wl_shm format enum, this extension would not be needed.
> 
> Does any of this sound acceptable for upstream Wayland, or do you think
> we'd better just write a new wl_buffer factory with everything we need?

There's no reason not to just copy over the drm formats (which wl_drm
already uses) to the wl_shm enum.  I don't think we need an elaborate
scheme for work-in-progress formats, lets just add the full list and
then just advertise the ones the compositor supports.

The main reason for not doing that originally was that I didn't want
to overwhelm clients with a huge list of formats that they would have
to pick and choose from.  But as long as ARGB32 is always available, I
don't see a problem in advertising extra formats.

> Btw. Google found this:
> http://people.freedesktop.org/~krh/fourcc.patch
> Why was that or similar never used? :-)

I ended up deciding to keep details about pixel formats private.  It's
still true that having a wayland list of pixel formats to choose from
would be convenient, but in the end I didn't want to imply that
wl_buffer is always about pixels.

Kristian