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

Reply via email to