GNOME Videos (Totem) refused to play anything on my Fedora 43 box. Every attempt — app menu, double-click in Files, or clicking an MP4 inside Cursor — ended with:

Cannot initialize OpenGL output

Audio was fine elsewhere; this was specifically the GTK/GStreamer OpenGL video sink failing. Here is what was going wrong and what actually fixed it.

My setup

  • Fedora 43, GNOME on Wayland
  • NVIDIA GeForce RTX 5080, proprietary driver 580.x
  • Totem 43.2 from RPM (org.gnome.Totem), not Flatpak

glxinfo on X11 looked healthy — OpenGL 4.6, direct rendering yes. The failure only showed up in Totem’s GStreamer pipeline on Wayland.

What the logs said

Running Totem with GST_DEBUG=2 produced the real error: 

Failed to create OpenGL context: Failed to create a OpenGL context: EGL_BAD_CONTEXT
Failed to initialize OpenGL with Gtk

So this is not a missing codec problem (that was a separate Kdenlive Flatpak rabbit hole). Totem could not create an EGL desktop GL context for gtkglsink.

Root cause: NVIDIA + Wayland + desktop OpenGL

Modern GTK apps and GStreamer’s GL sink often try to use desktop OpenGL over EGL. On NVIDIA’s proprietary driver in a Wayland session, that path is flaky or broken; OpenGL ES works.

The fix is one environment variable: 

export GDK_GL=gles

That tells GTK to use GLES, which NVIDIA handles correctly on Wayland.

Fix 1: App launcher (menu only)

Copy the desktop file and wrap Exec: 

mkdir -p ~/.local/share/applications
cp /usr/share/applications/org.gnome.Totem.desktop ~/.local/share/applications/
sed -i 's|^Exec=totem %U|Exec=env GDK_GL=gles totem %U|' \
  ~/.local/share/applications/org.gnome.Totem.desktop
update-desktop-database ~/.local/share/applications

This helps when you start Videos from the app grid. It does not fix opening a file from Cursor, Nautilus, or xdg-open — read on.

Fix 2: D-Bus service (file clicks — the important one)

Totem runs a persistent background service: 

/usr/bin/totem --gapplication-service

It is activated via D-Bus from /usr/share/dbus-1/services/org.gnome.Totem.service. That service file calls /usr/bin/totem directly — no GDK_GL=gles. Once that process starts without the variable, every file you open reuses the broken instance, even if your desktop file is patched.

Override the session D-Bus service in your home directory (takes precedence over the system file): 

mkdir -p ~/.local/share/dbus-1/services

cat > ~/.local/share/dbus-1/services/org.gnome.Totem.service << 'EOF'
[D-BUS Service]
Name=org.gnome.Totem
Exec=/usr/bin/env GDK_GL=gles /usr/bin/totem --gapplication-service
EOF

Then kill any running Totem and try again: 

pkill totem
gio open ~/Downloads/some-video.mp4

Verify the running process has the variable: 

pid=$(pgrep -n totem)
tr '\0' '\n' < /proc/$pid/environ | grep GDK_GL
# GDK_GL=gles

After this, clicking an MP4 in Cursor’s file tree finally worked — that was the symptom that sent me down the wrong path for a while.

Fix 3: Session-wide (optional, recommended)

So every new login and D-Bus activation gets GLES without one-off wrappers: 

mkdir -p ~/.config/environment.d

cat > ~/.config/environment.d/99-nvidia-gdk-gl.conf << 'EOF'
GDK_GL=gles
EOF

For the current session without logging out: 

export GDK_GL=gles
dbus-update-activation-environment --systemd GDK_GL

System-wide (all users on Wayland), I also added: 

# /etc/profile.d/nvidia-wayland-gl-fix.sh
if [ "${XDG_SESSION_TYPE:-}" = wayland ] && [ -z "${GDK_GL:-}" ]; then
  export GDK_GL=gles
fi

Log out and back in once so environment.d applies to apps started before you fixed Totem (including Cursor).

Quick checklist

  1. GST_DEBUG=2 totem file.mp4 — confirm EGL_BAD_CONTEXT / OpenGL errors
  2. GDK_GL=gles totem file.mp4 — should play
  3. Add D-Bus override under ~/.local/share/dbus-1/services/
  4. pkill totem, restart Cursor if needed, open file again
  5. Add environment.d and re-login for a permanent session fix

Related notes

  • Same class of bug affects other GTK + GL apps on NVIDIA/Wayland — not just Videos.
  • Kdenlive Flatpak on Fedora is a different problem: missing HEVC/H.264 decoders in the sandbox. Native RPM Kdenlive + system FFmpeg worked for phone footage; Videos needed GDK_GL, not codecs.
  • Switching to an X11 session is a workaround; GLES is the less disruptive fix.

Summary

Symptom: GNOME Videos — “cannot initialize OpenGL output”.
Cause: Totem’s GL sink + NVIDIA + Wayland + desktop GL.
Fix: GDK_GL=gles, especially in the D-Bus service so file associations and IDE clicks do not reuse a broken gapplication-service.

Hope this saves someone an evening of blaming their MP4 files.