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