Firefox-Wayland doesn't start on the proprietary nvidia driver
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
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.
Comment 1•5 years ago
|
||
Which Linux distribution and version do you use?
Reporter | ||
Comment 2•5 years ago
|
||
Opensuse Tumbleweed, nvidia 440.82, firefox 77.0.1
Updated•5 years ago
|
Comment 3•5 years ago
|
||
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.
Comment 4•5 years ago
|
||
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).
Reporter | ||
Comment 5•5 years ago
|
||
You have to check if ubuntu enables EGLStreams on Mutter builds.
Reporter | ||
Comment 6•5 years ago
|
||
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.
Assignee | ||
Comment 8•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 10•4 years ago
|
||
bugherder |
Comment 11•4 years ago
|
||
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
- Create context.
- Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces)
- 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.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 12•4 years ago
|
||
This is an alternative to D118304.
The following is currently not well-defined by the EGL specification:
- Create context.
- Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces)
- 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.
Updated•4 years ago
|
Comment 13•4 years ago
|
||
Comment 14•4 years ago
|
||
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
Comment 16•4 years ago
|
||
Assignee | ||
Comment 17•4 years ago
|
||
Please back out the current push again, there is a regression that won't be caught by CI. Thanks and sorry.
Comment 18•4 years ago
|
||
(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
Updated•4 years ago
|
Comment 19•4 years ago
|
||
Comment 20•4 years ago
|
||
(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.
Comment 21•4 years ago
|
||
bugherder |
Assignee | ||
Comment 22•4 years ago
|
||
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.
Updated•4 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 26•3 years ago
|
||
As HW-WR now appears to work fine on native wayland, we should revert D117434 which forced SW-WR.
Description
•