Bugzilla

(In reply to grulja from comment #44)
> (In reply to Martin Stránský [:stransky] (ni? me) from comment #43)
> > Note that the fix here is still correct. It's needed for Wayland/XWayland and multi GPU scenarios. The best solution may be to read DRM device from  OpenGL and create headless (drm) GL context over it. We do the same approach for dmabuf/vaapi and dmabuf snapshots in Firefox.
> > 
> > To use correct display is minimum. Right now the pipewire code uses Wayland even if browser run on X11 (Xwayland) which is "interesting" :)
> 
> I was told by Jonas that getting the display through EGL_PLATFORM_X11_KHR should give you the same one, as it goes through XWayland and Glamor, which gets it from Wayland. In the multi GPU scenario you should alway get the same EGL display for both Firefox and Wayland/gbm used in the screen sharing code.

Please test that by yourself.

1) load Firefox in debugger as:
```
 MOZ_ENABLE_WAYLAND=0 gdb ./firefox
``
that configures Firefox to run on XWayland even when Wayland is available (that's default right now for release).

2) put breakpoint to wl_display_get_registry
3) run firefox and open screen sharing code
4) See the backtrace:

``
#0  wl_display_get_registry (wl_display=0x7fffb640ae70) at /usr/include/wayland-client-protocol.h:1064
#1  dri2_initialize_wayland_drm (disp=0x7fffb7321600) at ../src/egl/drivers/dri2/platform_wayland.c:2118
#2  dri2_initialize_wayland (disp=disp@entry=0x7fffb7321600) at ../src/egl/drivers/dri2/platform_wayland.c:2777
#3  0x00007fffc9e28c40 in dri2_initialize (disp=disp@entry=0x7fffb7321600) at ../src/egl/drivers/dri2/egl_dri2.c:1205
#4  0x00007fffc9e1a4a1 in eglInitialize (dpy=<optimized out>, major=0x7fffffffb53c, minor=0x7fffffffb538) at ../src/egl/main/eglapi.c:703
#5  0x00007ffff00ac937 in webrtc::EglDmaBuf::EglDmaBuf() (this=0x7fffb5f09b80) at /raid/src4/third_party/libwebrtc/modules/desktop_capture/linux/wayland/egl_dmabuf.cc:375
#6  0x00007ffff00b3b29 in std::make_unique<webrtc::EglDmaBuf>() ()
    at /home/komat/.mozbuild/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/unique_ptr.h:821
#7  webrtc::SharedScreenCastStreamPrivate::StartScreenCastStream(unsigned int, int, unsigned int, unsigned int) (this=0x7fffc2c72200, stream_node_id=101, fd=186, width=0, height=0)
    at /raid/src4/third_party/libwebrtc/modules/desktop_capture/linux/wayland/shared_screencast_stream.cc:395
#8  0x00007ffff00aa22b in webrtc::BaseCapturerPipeWire::OnScreenCastRequestResult(webrtc::xdg_portal::RequestResponse, unsigned int, int)
    (this=0x7fffba6bbc80, result=webrtc::xdg_portal::RequestResponse::kSuccess, stream_node_id=0, fd=0)
    at /raid/src4/third_party/libwebrtc/modules/desktop_capture/linux/wayland/base_capturer_pipewire.cc:60
#9  0x00007ffff00af82c in webrtc::ScreenCastPortal::OnPortalDone(webrtc::xdg_portal::RequestResponse) (this=0x7fffb720d010, result=webrtc::xdg_portal::RequestResponse::kUnknown)
    at /raid/src4/third_party/libwebrtc/modules/desktop_capture/linux/wayland/screencast_portal.cc:135
#10 0x00007ffff00b0c5c in webrtc::ScreenCastPortal::OnOpenPipeWireRemoteRequested(_GDBusProxy*, _GAsyncResult*, void*)
    (proxy=<optimized out>, result=<optimized out>, user_data=0x7fffb720d010) at /raid/src4/third_party/libwebrtc/rtc_base/logging.h:406
```

So perhaps somewhere deeply is used the same device but we're getting config through dri2_initialize_wayland() and we're configure dmabuf via zwp_linux_dmabuf_v1_get_version() (if that extension is available). See egl/drivers/dri2/platform_wayland.c in Mesa for details.

(In reply to grulja from comment #44)
> (In reply to Martin Stránský [:stransky] (ni? me) from comment #43)
> > Note that the fix here is still correct. It's needed for Wayland/XWayland and multi GPU scenarios. The best solution may be to read DRM device from  OpenGL and create headless (drm) GL context over it. We do the same approach for dmabuf/vaapi and dmabuf snapshots in Firefox.
> > 
> > To use correct display is minimum. Right now the pipewire code uses Wayland even if browser run on X11 (Xwayland) which is "interesting" :)
> 
> I was told by Jonas that getting the display through EGL_PLATFORM_X11_KHR should give you the same one, as it goes through XWayland and Glamor, which gets it from Wayland. In the multi GPU scenario you should alway get the same EGL display for both Firefox and Wayland/gbm used in the screen sharing code.

Please test that by yourself.

1) load Firefox in debugger as:
```
 MOZ_ENABLE_WAYLAND=0 gdb ./firefox
```
that configures Firefox to run on XWayland even when Wayland is available (that's default right now for release).

2) put breakpoint to wl_display_get_registry
3) run firefox and open screen sharing code
4) See the backtrace:

```
#0  wl_display_get_registry (wl_display=0x7fffb640ae70) at /usr/include/wayland-client-protocol.h:1064
#1  dri2_initialize_wayland_drm (disp=0x7fffb7321600) at ../src/egl/drivers/dri2/platform_wayland.c:2118
#2  dri2_initialize_wayland (disp=disp@entry=0x7fffb7321600) at ../src/egl/drivers/dri2/platform_wayland.c:2777
#3  0x00007fffc9e28c40 in dri2_initialize (disp=disp@entry=0x7fffb7321600) at ../src/egl/drivers/dri2/egl_dri2.c:1205
#4  0x00007fffc9e1a4a1 in eglInitialize (dpy=<optimized out>, major=0x7fffffffb53c, minor=0x7fffffffb538) at ../src/egl/main/eglapi.c:703
#5  0x00007ffff00ac937 in webrtc::EglDmaBuf::EglDmaBuf() (this=0x7fffb5f09b80) at /raid/src4/third_party/libwebrtc/modules/desktop_capture/linux/wayland/egl_dmabuf.cc:375
#6  0x00007ffff00b3b29 in std::make_unique<webrtc::EglDmaBuf>() ()
    at /home/komat/.mozbuild/sysroot-x86_64-linux-gnu/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/unique_ptr.h:821
#7  webrtc::SharedScreenCastStreamPrivate::StartScreenCastStream(unsigned int, int, unsigned int, unsigned int) (this=0x7fffc2c72200, stream_node_id=101, fd=186, width=0, height=0)
    at /raid/src4/third_party/libwebrtc/modules/desktop_capture/linux/wayland/shared_screencast_stream.cc:395
#8  0x00007ffff00aa22b in webrtc::BaseCapturerPipeWire::OnScreenCastRequestResult(webrtc::xdg_portal::RequestResponse, unsigned int, int)
    (this=0x7fffba6bbc80, result=webrtc::xdg_portal::RequestResponse::kSuccess, stream_node_id=0, fd=0)
    at /raid/src4/third_party/libwebrtc/modules/desktop_capture/linux/wayland/base_capturer_pipewire.cc:60
#9  0x00007ffff00af82c in webrtc::ScreenCastPortal::OnPortalDone(webrtc::xdg_portal::RequestResponse) (this=0x7fffb720d010, result=webrtc::xdg_portal::RequestResponse::kUnknown)
    at /raid/src4/third_party/libwebrtc/modules/desktop_capture/linux/wayland/screencast_portal.cc:135
#10 0x00007ffff00b0c5c in webrtc::ScreenCastPortal::OnOpenPipeWireRemoteRequested(_GDBusProxy*, _GAsyncResult*, void*)
    (proxy=<optimized out>, result=<optimized out>, user_data=0x7fffb720d010) at /raid/src4/third_party/libwebrtc/rtc_base/logging.h:406
```

So perhaps somewhere deeply is used the same device but we're getting config through dri2_initialize_wayland() and we're configure dmabuf via zwp_linux_dmabuf_v1_get_version() (if that extension is available). See egl/drivers/dri2/platform_wayland.c in Mesa for details.