Bugzilla

(In reply to Robert Mader [:rmader] from comment #29)
> > * comment 23 (gdk_screen_get_rgba_visual) works with GLX, but breaks EGL in general (EGL_BAD_MATCH). I need to find the bug with printf debugging.
> >   * I know from my test app that the visual from gdk_screen_get_rgba_visual is correct/desired.
> 
> The difference might be that in your test app AFAICS you use `gdk_screen_get_rgba_visual()` before creating the EGL context. Normally we already have our global one (the one with no window). `gdk_screen_get_rgba_visual()` will then create a GLX context when we already have an EGL context and that appears to be what breaks on the Nvidia driver. That's the reason why we need to use EGL to select the visual. And why it needs to finally get fixed (likely by somehow specing how to select a visual with alpha support - random orderings are not really a good solution).

I am confused or you are confused or we both are confused in different aspects:

EGL_BAD_MATCH is caused by trying to call eglCreateWindowSurface with an EGLconfig that is incompatible to the Xwindow.
https://searchfox.org/mozilla-central/rev/b822a27de3947d3f4898defac6164e52caf1451b/gfx/gl/GLContextProviderEGL.cpp#194

Therefore CreateConfig **must** choose the fb config that wants the xvisual that our Xwindow has or will have,
**but** aVisual is always 0 because [nullptr](https://searchfox.org/mozilla-central/rev/d37daf2f82ed22b6a2a5cbbb975423825dfd69fa/gfx/webrender_bindings/RenderThread.cpp#1164) is passed as widget. [Because aVisual is 0, the code to exclude incompatible egl configs is never used](https://searchfox.org/mozilla-central/rev/b822a27de3947d3f4898defac6164e52caf1451b/gfx/gl/GLContextProviderEGL.cpp#936-945).

It's EGL CreateConfig which is broken: aVisual must not be 0. There must be aVisual so that the code can skip the first fb config on Nvidia to select the second which is compatible.
Can the visual be remembered somewhere or can gdk_screen_get_rgba_visual also be callled when creating the shared context? Because the shared context needs an EGLconfig that is compatible to all windows it is used with. (IIUC: Either all windows are transparent, or none can be.)

I think I have read somewhere that GdkVisual is per-screen:
Does that mean that if the shared context is used for all windows and if a user has two Xscreens because he has two graphics cards with each one monitor, then a Firefox window on the second Xscreen/graphics card would need a different Xvisual, EGLconfig and EGLSurface than the second Firefox window on the other graphics card/Xscreen? But wouldn't that mean that at some point the window would be half visible on one graphics card/screen/monitor and on the other, which could never be compatible? Would it need to fall back to SW WR?
Or is it impossible to move a window between two Xscreens? 

What I also did not understand when comparing Firefox to my demo app:
It might be required to listen for Gtk screen-changed events (IIUC: switching between virtual terminals (Ctrl+Alt+F<x>), suspend&resume?) and then to set new visuals on all widgets, to create a new compatible EGLconfig and to create a new EGLSurface from EGLconfig and Xwindow who are compatible to each other. Couldn't that be the underlying problem of bug 1279309?

(In reply to Robert Mader [:rmader] from comment #29)
> > * comment 23 (gdk_screen_get_rgba_visual) works with GLX, but breaks EGL in general (EGL_BAD_MATCH). I need to find the bug with printf debugging.
> >   * I know from my test app that the visual from gdk_screen_get_rgba_visual is correct/desired.
> 
> The difference might be that in your test app AFAICS you use `gdk_screen_get_rgba_visual()` before creating the EGL context. Normally we already have our global one (the one with no window). `gdk_screen_get_rgba_visual()` will then create a GLX context when we already have an EGL context and that appears to be what breaks on the Nvidia driver. That's the reason why we need to use EGL to select the visual. And why it needs to finally get fixed (likely by somehow specing how to select a visual with alpha support - random orderings are not really a good solution).

I am confused or you are confused or we both are confused in different aspects:

EGL_BAD_MATCH is caused by trying to call eglCreateWindowSurface with an EGLconfig that is incompatible to the Xwindow.
https://searchfox.org/mozilla-central/rev/b822a27de3947d3f4898defac6164e52caf1451b/gfx/gl/GLContextProviderEGL.cpp#194

Therefore CreateConfig **must** choose the fb config that wants the xvisual that our Xwindow has or will have,
**but** aVisual is always 0 because [nullptr](https://searchfox.org/mozilla-central/rev/d37daf2f82ed22b6a2a5cbbb975423825dfd69fa/gfx/webrender_bindings/RenderThread.cpp#1164) is passed as widget. [Because aVisual is 0, the code to exclude incompatible egl configs is never used](https://searchfox.org/mozilla-central/rev/b822a27de3947d3f4898defac6164e52caf1451b/gfx/gl/GLContextProviderEGL.cpp#936-945).

It's EGL CreateConfig which is broken: aVisual must not be 0. There must be aVisual so that the code can skip the first fb config on Nvidia to select the second which is compatible.
Can the visual be remembered somewhere or can gdk_screen_get_rgba_visual also be callled when creating the shared context? Because the shared context needs an EGLconfig that is compatible to all windows it is used with. (IIUC: Either all windows are transparent, or none can be.)

I think I have read somewhere that GdkVisual is per-screen:
Does that mean that if the shared context is used for all windows and if a user has two Xscreens because he has two graphics cards with each one monitor, then a Firefox window on the second Xscreen/graphics card would need a different Xvisual, EGLconfig and EGLSurface than the other Firefox window on the other graphics card/Xscreen? But wouldn't that mean that at some point the window would be half visible on one graphics card/screen/monitor and on the other, which could never be compatible? Would it need to fall back to SW WR?
Or is it impossible to move a window between two Xscreens? 

What I also did not understand when comparing Firefox to my demo app:
It might be required to listen for Gtk screen-changed events (IIUC: switching between virtual terminals (Ctrl+Alt+F<x>), suspend&resume?) and then to set new visuals on all widgets, to create a new compatible EGLconfig and to create a new EGLSurface from EGLconfig and Xwindow who are compatible to each other. Couldn't that be the underlying problem of bug 1279309?