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), Xorg 1.20 seems to work ok with DefaultDepth 30
though. I guess one way forward would be to expose 1010102 but start
listing all problematic apps with 'allow_rgb10_configs=false' to drirc.
// Tapani
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
