On 9 February 2018 at 16:02, Daniel Stone <dan...@fooishbar.org> wrote:
> Hi Emil,
> On 8 February 2018 at 21:56, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>> On 8 February 2018 at 14:05, Daniel Stone <dani...@collabora.com> wrote:
>>> Extend the visual map from only containing names and bitmasks, to also
>>> carrying the three format enums we need. These are the DRIImage format
>>> tokens for internal allocation, FourCC codes for wl_drm and dmabuf
>>> protocol, and wl_shm codes for swrast drivers.
>>> We will later use these formats to eliminate a bunch of open-coded
>> At some point i was drawing some plans about making the (2?) odd
>> wl_shm format like their WL_DRM/DRI_IMAGE/drm_fourcc brethren.
>> Until (if even since it's fiddly) that happens having all the bits in
>> one place is a great step.
> That would be a protocol break for all software-rendered clients, so
> even though it would be really great, I just don't see it happening.
> Oh well.
I think it shouldn't break if we do something like the following:
- wl_shm v2, introduces .format2 (deprecates .format)
- update mesa to wl_registry_bind wl_shm v2 or later (as we do for dmabuf)
To avoid the crazy/partial DRM/SHM/DMABUF format enums, one could even:
- throw a single formats enum, keeping some compat. defines
- which the extensions to the new format - a no-op
mesa-dev mailing list