[Mesa-dev] 10-bit fbconfigs break most video players using VAAPI+GLX

[Tapani Pälli]

On 2/8/19 11:39 AM, Michel Dänzer wrote:
> On 2019-02-08 10:30 a.m., Tapani Pälli wrote:
>> On 2/6/19 7:40 PM, Michel Dänzer wrote:
>>> On 2019-02-06 12:55 p.m., Tapani Pälli wrote:
>>>> On 2/6/19 1:16 PM, Michel Dänzer wrote:
>>>>> On 2019-02-05 11:30 p.m., Marek Olšák wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Video players request fbconfigs with these attributes:
>>>>>> GLX_RED_SIZE = 8
>>>>>> GLX_GREEN_SIZE = 8
>>>>>> GLX_BLUE_SIZE = 8
>>>>>> GLX_ALPHA_SIZE = 0
>>>>>>
>>>>>> Note that the values specify MINIMUM required component sizes, not
>>>>>> exact
>>>>>> sizes. 10-10-10-2 satisfies the requirement and therefore
>>>>>> glXChooseFBConfig
>>>>>> returns it first. Then video players choose the first config.
>>>>>>
>>>>>> There are many video players that have this issue. I guess they
>>>>>> copied the
>>>>>> same code from each other.
>>>>>>
>>>>>> If we expose 10-bit or 16-bit formats, a lot of software will be
>>>>>> broken.
>>>>>> Any ideas how to get out of this rabbit hole?
>>>>>>
>>>>>> My suggestion is to change the behavior of glXChooseFBConfig to return
>>>>>> 8-8-8 or 8-8-8-8 first if they satisfy the attributes and ignore the
>>>>>> spec.
>>>>>
>>>>> Deliberately violating the spec and diverging from other GL(X)
>>>>> implementations sounds like a bad idea to me.
>>>>>
>>>>> We should help getting broken code fixed by identifying it and making
>>>>> suggestions.
>>>>>
>>>>>
>>>>> For code using glXChooseFBConfig, unless I'm missing something, a
>>>>> water-tight way to get a config which exactly matches a specific format
>>>>> is to specify all of GLX_RED/GREEN/BLUE/ALPHA_SIZE corresponding to
>>>>> each
>>>>> component's size, and GLX_BUFFER_SIZE corresponding to the sum of all
>>>>> sizes. The former and the latter have opposing sort orders, so only a
>>>>> single combination of R/G/B/A sizes should match all five of them.
>>>>>
>>>>
>>>> This is the main reason why 1010102 is still disabled in i965, there are
>>>> still issues, even with ubuntu 18.10. It looks like gnome-shell version
>>>> in 18.10 is too old (does not have the 'fix' which was essentially to
>>>> disable 1010102),
>>>
>>> gnome-shell is a different case though, and AFAIK it's only ever been
>>> broken if Xorg runs at depth 30.
>>>
>>>
>>>> Xorg 1.20 seems to work ok with DefaultDepth 30 though.
>>>
>>> With no 10/10/10/x FBConfigs? I don't get any depth 30 GLX visual in
>>> that case either, so no compositing manager using OpenGL can work.
>>> glxgears works, but only via automatic compositing I suspect.
>>
>> Hmm I'm not sure I follow you here but I got gnome-shell compositor
>> running when setting DefaultDepth to 30 and it still had the bug where
>> picking the objects (like selecting a window) did not work, rendering
>> was looking OK though
> 
> Yeah, as I wrote that's a different issue from what this thread is about.

Sure, that can be discussed separately. I just wanted to note this as a 
working desktop with wide color support would be one nice goal to have 
and there has been requests to get this working. Apparently using 
modesetting driver and compton compositor is the safest path. I've CC'd 
Mario who has knowledge on working combinations.

> 
>> and there were 1010102 visuals available in glxinfo.
> 
> So does i965 expose 1010102 configs when the X server runs at depth 30?
> Or did you test with another driver?

I tested this with i965 and setting allow_rgb10_configs to true. Having 
said that, currently I cannot seem to be able to launch X with '--depth 
30' anymore, I don't know what did I change but will try to get it back 
again :/

> I was thinking only exposing 1010102 configs (by default) when the X
> server runs at depth 30 might be a solution, but I wonder if that might
> affect some CTS/piglit tests or apps making use of those configs.

Yes, this seems like possible solution.

// Tapani