Closed Bug 1646135 Opened 1 year ago Closed 3 months ago

Firefox-Wayland doesn't start on the proprietary nvidia driver

Categories

(Core :: Widget: Gtk, defect, P3)

77 Branch
defect

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: haaaain, Assigned: rmader)

References

(Blocks 2 open bugs)

Details

Attachments

(4 files, 1 obsolete file)

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

Component: Graphics → Widget: Gtk
Priority: -- → P3

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.

Depends on: 1650583
No longer depends on: 1650583
Duplicate of this bug: 1670492

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.

Assignee: nobody → robert.mader
Pushed by robert.mader@posteo.de:
https://hg.mozilla.org/integration/autoland/rev/a2eaaaf41bc8
Disable HW-WR on Nvidia prop. drivers on Wayland, r=aosmond
Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch

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.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: FIXED → ---

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.

Pushed by robert.mader@posteo.de:
https://hg.mozilla.org/integration/autoland/rev/e5d0803d80dd
Set draw buffer after eglMakeCurrent on Wayland and X11,r=gfx-reviewers,lsalzman

Updated, thanks.

Flags: needinfo?(robert.mader)
Pushed by robert.mader@posteo.de:
https://hg.mozilla.org/integration/autoland/rev/717b4a7cc264
Set draw buffer after eglMakeCurrent on Wayland and X11,r=gfx-reviewers,lsalzman

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

Flags: needinfo?(sheriffs)

(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

Flags: needinfo?(sheriffs)
Attachment #9228821 - Attachment description: Bug 1646135 - Set draw buffer after eglMakeCurrent on Wayland and X11,r=#gfx-reviewers → Bug 1646135 - Set draw buffer after eglMakeCurrent when using desktop GL,r=#gfx-reviewers
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

(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.

Flags: needinfo?(robert.mader)
Status: REOPENED → RESOLVED
Closed: 3 months ago3 months ago
Resolution: --- → FIXED

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.

Flags: needinfo?(robert.mader)
Duplicate of this bug: 1719372
Duplicate of this bug: 1710729
Attachment #9228821 - Attachment is obsolete: true
Blocks: wr-nv-linux
Duplicate of this bug: 1717673

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

You need to log in before you can comment on or make changes to this bug.