Additional pixel formats for wl_shm

[Pekka Paalanen]

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?

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


Thanks,
pq