nouveau 30bpp / deep color status

[Ilia Mirkin]

On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner
<mario.kleiner.de at gmail.com> wrote:
> Cc'ing mesa-dev, which was left out.
>
>
> On 03/05/2018 01:40 PM, Ilia Mirkin wrote:
>>
>> On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
>> <mario.kleiner.de at gmail.com> wrote:
>>> Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs
>>> to
>>> DRIconfigs, so we could probably implement dri_loader_get_cap(screen,
>>> DRI_LOADER_CAP_RGBA_ORDERING) == TRUE for the EGL loaders.
>>>
>>> But for GLX it is not so easy or quick. I looked if i could make the
>>> servers
>>> GLX send proper channelmask attributes and Mesa parsing them, but there
>>> aren't any GLX tags defined for channel masks, and all other tags come
>>> from
>>> official GLX extension headers. I'm not sure what the proper procedure
>>> for
>>> defining new tags is? Do we have to define a new GLX extension for that
>>> and
>>> get it in the Khronos registry and then back into the server/mesa
>>> code-base?
>>
>>
>> Can all of this be solved by a healthy dose of "don't do that"? i.e.
>> make sure that the DDX only ever exposes one of these at a time? And
>> also make the mesa driver only expose one as a DISPLAY_TARGET?
>>
>
> Yes, if "don't do that" is consistently possible on all future drivers.

I don't think it'd be undue burden for a driver to have to decide on
one ordering which is The Way To Do It (tm) for that hw, even if the
hw supports both. Could also drop some logic into the glx thing to
always pick a specific one in case both are supported, and hopefully
the DDX would have identical logic.

> Under EGL there is matching of channel masks, so only X11+GLX is
> problematic. Not sure if anything special would need to be done for
> XWayland, haven't looked at that at all so far. Or the modesetting ddx,
> which currently assumes xrgb ordering for 10 bit.

For the modesetting ddx, it has to switch to drmAddFB2 so that it
knows the exact format. No other way around that, unfortunately. But
that'll require work, and I'm happy enough that xf86-video-nouveau
works (as that is what I recommend to anyone who'll listen).

>
>>>
>>> The current patches in mesa for XBGR also lack enablement pieces for EGL,
>>> Wayland and X11 compositing, but that's a different problem.
>>
>>
>> EGL/drm and EGL/wayland should be enabled (look at Daniel Stone's
>> patches from a short while back, also upstream now). kmscube (with
>> some patches that are upstream now) and weston both run OK for me. I
>> think EGL/x11 is iffy though - haven't played with it.
>>
>>    -ilia
>>
>
> There are some from Daniel which unify the handling of formats inside egl,
> not with any abgr2101010 definitions though. Indeed on master compositing
> doesn't work for depth 30 windows. I have some patches that fix this, and
> some hack for EGL/x11 compositing that seems to work. Will send them out
> soon.

D'oh! Those patches were definitely there. I guess they got dropped at
some point. Daniel, can you resend those?

  -ilia