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. > 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 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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
