Additional pixel formats for wl_shm

[Pekka Paalanen]

On Thu, 2 May 2013 10:23:04 +0300
Pekka Paalanen <pekka.paalanen at collabora.co.uk> wrote:

> On Wed, 1 May 2013 21:38:48 -0400
> Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> 
> > 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.
> 
> Ok, cool. And we can just document for wl_shm, that pre-multiplied ARGB
> 32-bit-per-pixel, and XRGB, should always be present, and others are
> optional, right?
> 
> How do we define pre-multiplied alpha or not? Does it work to say that
> everything having an alpha channel is pre-multiplied, including ayuv?
> I'm sure there are cases where one would prefer non-pre-multiplied due
> to practical considerations, but do we care?
> Or should we go with the fourcc definition, which I guess would not
> have pre-multiplied?
> 
> And how about the conflicts? The current wl_shm formats named
> "argb8888" and "xrgb8888" are also used in the wl_drm set but
> with different numerical value. And maybe also conflicting on
> pre-multiplication?

Ping? (Now with the right sender address, so also the list gets this.)
- pq