[Mesa-dev] [PATCH 3/3] i965/dri: Support R8G8B8A8 and R8G8B8X8 configs

[Daniel Stone]

Hi Chad,

On 28 June 2017 at 00:49, Chad Versace <chadversary at chromium.org> wrote:
> On Tue 27 Jun 2017, Kenneth Graunke wrote:
>> On Tuesday, June 27, 2017 11:00:48 AM PDT Chad Versace wrote:
>> > On Wayland, this also creates no new configs, and therfore breaks no
>> > existing apps. (I tested with mesa-demos' eglinfo and es2gears_wayland
>> > on Skylake). The reason differs from GLX, though. In
>> > dri2_wl_add_configs_for_visual(), the format table contains only
>> > B8G8R8X8, B8G8R8A8, and B5G6B5; and dri2_add_config() correctly matches
>> > EGLConfig to format by inspecting channel masks.
>>
>> [...]
>> I suppose fixing it would cause GLX to begin exposing new RGBA visuals
>> (in addition to BGRA).  I don't think we want to do that - I don't see much
>> point outside of Android.  It's mostly harmless, except that changing the
>> visuals ends up being absurdly painful for driver developers, since the X
>> server and clients need to agree on lists.  That means you can't move across
>> the change point without updating the Mesa your X server uses and restarting
>> the X server.
>>
>> If we do fix GLX, and want to avoid exposing visuals, I think we could
>> easily add an #ifdef ANDROID.  Is there some reason to not go ahead and
>> do that now?
>
> For now, there's no reason to not #ifdef ANDROID the new config formats.
> And I'll squash that into this patch if you ask.
>
> But, I intentionally did not #ifdef ANDROID the new formats just in case
> Wayland wanted to use them. Currently,
> src/egl/drivers/dri/platform_wayland.c will not use them. But, I suspect
> that Wayland would use them (but not require them) after Daniel Stone's
> patches land, in series "EGL/Wayland modifiers, format cleanup".
>
> ^^^ Daniel, is that correct?

Wayland certainly could use them, yeah. Given we don't have native
visuals - or even the concept of a 'surface format' distinct from the
format of whatever buffer was currently attached - the component
ordering is irrelevant as long as it's correctly translated between
the wl_drm/DRM/DRI FourCC tokens and the DRI_IMAGE_FORMAT_* tokens.

Currently we whitelist XRGB8888/ARGB8888/RGB565 (DRM FourCC-style
naming) when adding configs though, so it's a no-op for now.

Cheers,
Daniel