User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4173.0 Safari/537.36

Steps to reproduce:

I got kde on wayland running with EGLStreams & the proprietary nvidia driver and tried to open firefox

Actual results:

All i get is a black screen. On gnome it doesnt even start.

On gnome terminal I get:
[GFX1-]: Failed to create EGLSurface
[GFX1-]: We don't have EGLSurface to draw into. Called too early?
Gdk-Message: 14:38:16.467: Error 71 (Erro de protocolo) dispatching to Wayland display.

Which Linux distribution and version do you use?

Opensuse Tumbleweed, nvidia 440.82, firefox 77.0.1

I have tried to run Gnome Wayland and Plasma Wayland with proprietary Nvidia on Ubuntu 20.04, but haven't succeeded in 2 hours of trying.

I edited /etc/default/grub and added nvidia-drm.modeset=1 at the end of GRUB_CMDLINE_LINUX DEFAULT.
Then I ran

# grub-mkconfig -o /boot/grub/grub.cfg
# update-grub
# update-initramfs -u

I created a /etc/profile.d/kwin.sh file that contains

export KWIN_DRM_USE_EGL_STREAMS=1

I made sure that /etc/gdm3/custom.conf contains WaylandEnable=true.
I commented out the "gdm-disable-wayland" line for the nvidia driver in /lib/udev/rules.d/*gdm*.
I installed libnvidia-egl-wayland1.
I rebooted after each change.

# cat /sys/module/nvidia_drm/parameters/modeset
even says Y

But gdm3 doesn't show Wayland.
After switching from gdm3 to sddm I saw Wayland options:
Ubuntu Wayland exited back to the login screen.
Plasma Wayland froze right after login with a black screen.

Now, after 2 hours, I rebooted to an older Debian Testing with Nouveau and Gnome Wayland worked out of the box.
Plasma Wayland froze after some taskbar animations, but I haven't updated this system for a longer time. Will try it again after updating. I will also keep trying to enable EGLStreams for a basic test.

After updating, the stability problem of Plasma Wayland is gone. Nightly works with native Wayland backend on Debian Testing with Nouveau. It's good to know that at least the default configuration works without problem. Now I just need to succeed with enabling EGLStreams on the proprietary driver.
If you wouldn't have said "OpenSUSE Tumbleweed" (rolling release distro), then I would have assumed your Plasma version was just outdated (bug 1644312).

You have to check if ubuntu enables EGLStreams on Mutter builds.

I've tested it on Fedora. If I disable webrender and it works but in an ambiguous way. In WebGL 1 Driver Renderer it says "NVIDIA Corporation -- GeForce GT 1030/PCIe/SSE2" and on GPU #1 "llvmpipe (LLVM 10.0.0, 256 bits)". Window Protocol: wayland/drm.

There's no HW acceleration. If I enable webrender or layers.acceleration.force-enabled i get a black screen.

Currently we fail to display anything when using the Nvidia EGL
implementation. Similar issues seem to happen in GTK4.

If we're lucky this will be fixed by future Nvidia drivers as they
started to adopt DMABUF/GBM.

https://hg.mozilla.org/mozilla-central/rev/a2eaaaf41bc8

The following scenario is not well-defined by the EGL specification, as
described on the Khronos bug tracker here https://www.khronos.org/members/login/bugzilla/show_bug.cgi?id=13534

1. Create context.
2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces)
3. Make it current with a default framebuffer (ie with some draw/read surfaces)

After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK?

With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL
backend currently assumes this behavior. However with the proprietary NVIDIA
driver the answer is actually GL_NONE, meaning any rendering done after step #3
will be lost.

As a fix, Firefox can simple call glDrawBuffer after making a surface current
to set the draw buffer appropriately, either to GL_BACK for a double-buffered
surface or to GL_FRONT for single-buffered. As mentioned above, this is
redundant on Mesa, but should also be harmless.

This is an alternative to D118304.

The following is currently not well-defined by the EGL specification:

1. Create context.
2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces)
3. Make it current with a default framebuffer (ie with some draw/read surfaces)

After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK?

With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL
backend currently assumes this behavior. However with the proprietary NVIDIA
driver the answer is actually GL_NONE, meaning any rendering done after step #3
will be lost.

As a fix, Firefox can simple call glDrawBuffer after making a surface current
to set the draw buffer appropriately, either to GL_BACK for a double-buffered
surface or to GL_FRONT for single-buffered. As mentioned above, this is
redundant on Mesa, but should also be harmless.

Backed out changeset e5d0803d80dd (Bug 1646135) for causing mochitest-plain crashes.
https://hg.mozilla.org/integration/autoland/rev/b150a33fe57d9af340e7a65bded817ed11321135

Push with failures:
https://treeherder.mozilla.org/jobs?repo=autoland&revision=e5d0803d80ddde38f08570a12ede749256e4dca1&selectedTaskRun=Mg2p5rq7RTKnqNmqFMxg3A.0

Failure log:
https://treeherder.mozilla.org/logviewer?job_id=343862441&repo=autoland&lineNumber=1697

Updated, thanks.

Please back out the current push again, there is a regression that won't be caught by CI. Thanks and sorry.

(In reply to Robert Mader [:rmader] from comment #17)

Please back out the current push again, there is a regression that won't be caught by CI. Thanks and sorry.

Done.
https://hg.mozilla.org/integration/autoland/rev/b434222eaaf2c6c880fe92adbbba7bf2a50e57ab

(In reply to Pulsebot from comment #19)

Pushed by robert.mader@posteo.de:
https://hg.mozilla.org/integration/autoland/rev/c2191ee9cb65
Set draw buffer after eglMakeCurrent when using desktop
GL,r=gfx-reviewers,lsalzman

I think we need to revert and fix this one.

https://hg.mozilla.org/mozilla-central/rev/c2191ee9cb65

As concluded on #gfx-firefox, the patch could have been nicer to (fDrawBuffers instead `fDrawBuffer' and some details), but IIUC it is ok for now.

As HW-WR now appears to work fine on native wayland, we should revert D117434 which forced SW-WR.