[nvidia] Chromium stable snap doesn't display anything on Wayland with Nvidia as primary GPU

[Leo]

Hi
I'm testing the Ubuntu 22.04 beta with wayland and when I try to open the Chromium browser (stable snap package), only see a black/transparent window. If I switch from Wayland to Xorg, everything is normal again.

I tried to delete the profile folder , but I have the same result.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

See also bug 1968610

[Daniel van Vugt (vanvugt)]

It's still broken on mantic with chromium snap 119.0.6045.159. The console seems to repeat:

  KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied
  ...

But Google Chrome (deb version 119.0.6045.159-1) works perfectly. So this sounds like a confinement problem.

[Daniel van Vugt (vanvugt)]

^^^
Suspiciously like bug 2023322 now

[Marius Gedminas (mgedmin)]

I have the same problem but with Intel video. Chromium 124.0.6367.60 shows up camouflaged as my desktop wallpaper after the last snap update.

[Daniel van Vugt (vanvugt)]

That's a Chromium/Chrome regression and is not related to this Nvidia bug at all. Still, you can work around it with:

  google-chrome --ozone-platform=x11

[Daniel van Vugt (vanvugt)]

I've seen a suggestion this bug might have been fixed for a few months... until bug 2063049 happened. So let's wait for that fix first.

[Daniel van Vugt (vanvugt)]

Confirmed still happening on Noble, same as comment #3.

[Nathan Teodosio (nteodosio)]

Resorting to software rendering with 'chromium --disable-gpu' should work around the problem.

Some information that might help debugging:

1. With

   sudo bash -c "echo -n noquiet > /sys/module/apparmor/parameters/audit"
   journalctl -f

   Then starting Chromium, what denials are reported?

2. dpkg -l|grep nvidia

3. journalctl -b --grep='renderer for'

https://download.nvidia.com/XFree86/Linux-x86_64/525.53/README/kms.html

> NVIDIA's DRM KMS support is still considered experimental. It is disabled by default, but can be enabled on suitable kernels with the 'modeset' kernel module parameter. E.g.,
>
> modprobe -r nvidia_drm ; modprobe nvidia_drm modeset=1

Do we have this on?

[Daniel van Vugt (vanvugt)]

Yes nvidia-drm.modeset=1 is enabled by default in Ubuntu. I also think those docs are outdated because:

> Buffer allocation and submission to DRM KMS using gbm is not currently supported.

hasn't been true since before the 495 driver. After that Nvidia has supported gbm.

Even in the docs for the latest driver version it hasn't been updated:

https://download.nvidia.com/XFree86/Linux-x86_64/555.52.04/README/kms.html

[Alessandro Astone (aleasto)]

Interestingly enough, the Chromium snap behaves differently with nvidia 535 and 550.
- With 535 you see the description of this bug report, i.e. chromium renders transparently.
- When 550 the chromium rendering process segfaults, and after crashing 3 times a fall back mechanism kicks in to use software rendering, so you only get a transparent window for a couple of seconds and then it starts "working".

Debugging shows that neither snap-confine nor the gnome extension are ready for nvidia on wayland.
They're missing some libraries (ex: libnvidia-allocator.so, libnvidia-egl-gbm.so, gbm/nvidia-drm_gbm.so) and config files pointing to the relevant libraries (ex: /usr/share/egl/egl_external_platform.d/*), as well as environment variables that point to the relevant directories in the confined environment (ex: $GBM_BACKENDS_PATH, $__EGL_EXTERNAL_PLATFORM_CONFIG_DIRS).

Even with those pieces in place, I couldn't get chromium to work hardware accelerated (with mixed results in `eglinfo` too).

It is very important to note that by default chromium is using X11 through XWayland.
If we switch the default (--ozone-platform=wayland), chromium immediately falls back to software rendering, thus mitigating the transparent window bug.

However if I now force GLVND to only consider nvidia and ignore mesa with $__EGL_VENDOR_LIBRARY_FILENAMES (together with some of the other fixes from the above paragraph), then `chromium --ozone-platform=wayland` is hardware accelerated! This suggests a bug in GLVND from core22 in my opinion: needs further investigation.

[Daniel van Vugt (vanvugt)]

AIUI we can't expect proprietary Nvidia to work properly in confined snaps without those snaps also using graphics-core22 or gpu-2404 (https://discourse.ubuntu.com/t/the-gpu-2404-snap-interface/44251).

[Sebastien Bacher (seb128)]

The edge channel of chromium uses core24 and the gnome46 sdk (which uses gpu-2404) so that might be a better base to test on

[Nathan Teodosio (nteodosio)]

> The edge channel of chromium uses core24 and the gnome46 sdk

As does beta as of recently.

There is also the a build with Wayland EGL instead at stable/w-no-gbm.

[Alessandro Astone (aleasto)]

Because the `gnome` extension is automagically connected to gpu-2404 [1] both latest/edge and latest/beta, which default to `ozone-platform=wayland`, render correctly and with some [2] hardware acceleration out-of-the-box.

Forcing it to use XWayland still exhibits the same issue as this bug report.

No changes instead with `stable/w-no-gbm`

[1]: https://github.com/canonical/snapcraft/pull/4744
[2]: see attachment - compositing is not accelerated, and webgl has "reduced performance"

[Daniel van Vugt (vanvugt)]

I think I've been hitting the same transparent window bug on Intel graphics for the last few weeks. I say it's the same bug because I discovered my Chrome had been using software rendering (https://issues.chromium.org/issues/343352540). To work around the transparency I just had to open a new tab. But also forcing my desktop to use hardware rendering again has solved the transparency issue.