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

[Tapani Pälli]

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 and there were 1010102 visuals available in 
glxinfo. I did not run any tests to actually utilize those visuals 
myself though.


> 
>> I guess one way forward would be to expose 1010102 but start
>> listing all problematic apps with 'allow_rgb10_configs=false' to drirc.
> 
> Then they would probably never get fixed anyway.
> 
> 

// Tapani