Additional pixel formats for wl_shm

[Pekka Paalanen]

On Fri, 26 Apr 2013 09:09:28 -0500
Jason Ekstrand <jason at jlekstrand.net> wrote:

> pq,
> On Fri, Apr 26, 2013 at 8:13 AM, Pekka Paalanen <ppaalanen at gmail.com> 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.
> >
> 
> Yeah, I think that supporting 16-bit formats would be good for any embedded
> application.  I think Android defaults to 565 for GLES surfaces for that
> very reason.  Particularly when working with overlays and limited space,
> the ability to use smaller formats is a good idea.  Also, I think
> supporting YUV and similar would be good so that compositors could do
> colorspace conversions via overlays rather than software or GLSL
> client-side.
> 
> 
> > 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.
> >
> 
> Personally, I think we should prefer putting things in wl_shm over having
> additional formats being an extension.  That said, having it extendible
> might not be a bad idea.  It would allow for playing with new color formats
> without extending the core protocol and then they could be added later.
> That said, unless your color format is pretty exotic, I'd rather see it in
> wl_shm as an optional format than requiring an extension.

I agree, having formats enumerated in wl_shm would be straightforward.

> If we were to add a color format extension system, would it need to be a
> new interface?  Why couldn't we just have an extended_formats event in
> wl_shm that advertises both an enum and a string?  Having an extra
> interface to add enums to wl_shm seems a bit odd.

It's just an option, that allows to leave the Wayland core protocol
untouched. The new global interface would not necessarily need to
be in the core. But that certainly limits its usefulness, too.

I'm just not sure what the current policy with wl_shm pixel formats
is, hence the whole question. :-)


Thanks,
pq

> 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? :-)