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 >>> conversions. >> >> 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) - ??? - profit
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 -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
