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