Additional pixel formats for wl_shm

[Jason Ekstrand]

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.

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.

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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

Thanks,
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130426/bcc8449a/attachment.html>