Login

u/Mrlou_st

r/OperaGX r/debian r/linux
▲ 1 r/OperaGX

[Linux] Video playback broken on x.com and reddit.com in Opera GX 132 (Chromium 148) — anyone else? Detailed diagnosis inside

Hey r/operagx,

I've been chasing a video playback bug on Opera GX 132 for a while and I think I've narrowed it down. Posting here because I want to know if other Linux users are seeing this, and I figured the diagnosis might help the community and the devs lurking here.

TL;DR: Videos on x.com (and reddit.com via embedded Twitter posts) show the poster frame for half a second, then throw a "Media could not be played" error. Multiple Chromium flag combinations were tested, and none of them fixed it. The root cause is an upstream Chromium 148 security regression regarding stricter CSP enforcement around srcdoc iframes colliding with x.com's player architecture. Firefox and older Chrome stable are completely unaffected.

Environment: Debian Trixie (Testing/Sid), Niri Wayland compositor, Mesa 26.0.8. Opera GX is launched via XWayland with --ozone-platform=x11 (required for window management stability on Niri). Mods/themes are active.

Symptoms: The video element renders the initial thumbnail/poster for ~500ms, then drops into "Media could not be played". DevTools Console reveals two specific CSP violations originating from about:srcdoc and blocked data: URI fetches.

The Real Root Cause (Chromium 148 CSP Collision) This is a silent, deterministic failure cascade triggered by strict W3C CSP Level 3 enforcement rules matching inside the 148 core:

  1. srcdoc iframe restriction: x.com builds its web player framework inside an iframe srcdoc="". Cryptographic nonces from the parent document do not propagate into opaque srcdoc boundaries. Because a nonce is active on the parent, the engine discards 'unsafe-inline'. Thus, X's inline initialization scripts inside the iframe are flatly blocked by the browser.
  2. connect-src data: URI block: The player attempts to fetch the AMD FidelityFX-CAS shader encoded directly as a data:text/plain;base64,... URI string. This fetch violates the parent's connect-src because the data: scheme is not whitelisted by the site headers.

What I tried (Flags Attempted) Here is the quick list of everything we tested that fails to fix the issue:

  • Default configuration / X11 wrapper: Broken.
  • Adding --disable-features=ExtensionContentVerification: Broken (Opera GX uses its own internal verifier).
  • Adding --use-gl=swiftshader (Software CPU decoding): Browser becomes laggy but video remains broken. This proves the GPU/Mesa presentation stack is not the primary cause.
  • Adding --disable-features=WebGPU: Causes a SEGFAULT during the browser init loop.
  • Adding --disable-features=WebGPU,WebGL --no-sandbox: Browser remains stable, but video stays broken and CSP errors persist.

Note on YouTube: Regular YouTube videos work flawlessly because they avoid the nested srcdoc layout. YouTube Live Streams do fail, but with a completely different symptom ("Se ha producido un error" + Playback ID) which points to a separate failure path.

Current Status & Workaround I have formally filed this bug report with the Opera Desktop engineering team via Jira Service Management under tracking reference GB-80414 to log the Chromium 148 lifecycle behavior, as well as reaching out to the X Developer community.

For now, the only solid workaround for viewing videos on x.com or Reddit is to temporarily swap to Firefox 128+ or an older stable Chrome build (Chromium <= 138) which handles the srcdoc security inheritance context leniently.

Full Technical Analysis & Logs The complete diagnostic record, full flag outcomes, and the Mermaid execution cascade diagram are published in this live Gist:https://gist.github.com/louzt/77f0804ca11bad6636f0ac67928bd384

If you're on Linux and seeing this 500ms video drop, please chime in! It would be awesome to confirm your compositor (Niri, Sway, Hyprland?) and whether you see the same behavior on single-display setups.

reddit.com
u/Mrlou_st — 3 days ago
▲ 5 r/debian+1 crossposts

[Guide/RFC] Fixing NVIDIA 550/580 DKMS Compilation on Kernel 7.0+ (VMA API Breakage) &amp; Wayland USB-C D3cold Panics

Hey everyone,

I recently hit a massive brick wall on Debian Sid/Testing when my kernel updated to 7.0+. My NVIDIA driver (550.163) completely failed to compile via DKMS, and to make matters worse, trying to hotplug my external USB-C monitor on Wayland caused my GPU to panic and the laptop fans to instantly ramp up to 100%.

Since official support for 7.0+ RC/testing kernels isn't fully here yet, I did a deep dive into the kernel source and the ACPI power states to figure out exactly what broke and how to bypass it.

I've documented the full architectural breakdown and provided a C-patch in a Gist, but here is the TL;DR:

1. The Kernel 7.0+ DKMS Breakage

Linux 7.0 completely refactored the VMA locking API. They purged the VMA_LOCK_OFFSET macro from include/linux/mm_types.h and changed the signature of __is_vma_write_locked() from 2 arguments to 1. The NVIDIA proprietary driver source (specifically nv-mmap.c) still tries to use the old API, causing GCC to abort.

The Fix: I wrote a forward-compatibility patch using #if LINUX_VERSION_CODE &gt;= KERNEL_VERSION(7, 0, 0) to provide a synthetic VMA_LOCK_OFFSET and route the lock checks through __vma_raw_mm_seqnum().

2. The Wayland USB-C / D3cold Panic

In hybrid Optimus laptops, the USB-C DP alt-mode is physically wired to the NVIDIA dGPU. When your Wayland compositor (Niri, Sway, etc.) routes rendering through the AMD iGPU for power saving, the NVIDIA GPU enters D3cold (deep sleep). When you hotplug a monitor, the GPU wakes up, but Wayland never establishes an EGL context for it. The GPU panics, and the firmware maxes out the fans to prevent thermal damage.

The Fix: You have to force the GPU to maintain state and provide a legacy framebuffer.

  • GRUB: nvidia-drm.modeset=1 nvidia_drm.fbdev=1
  • Modprobe (/etc/modprobe.d/nvidia-pm.conf): options nvidia NVreg_DynamicPowerManagement=0x02

The Patch & Full Guide

If you are currently stuck on Kernel 7.0+ and need to get your DKMS building again, you can grab the .patch file and the auto-patching instructions for dkms.conf here:

https://gist.github.com/louzt/1c85044d5090d19223c3f5edf426a19e

Disclaimer: I am currently pinned to kernel 6.19.14 for work stability, so I am publishing this patch as an RFC (Request for Comments) based on forensic analysis. If you are on 7.0+ and apply the patch, please share your build logs in the Gist comments!

u/Mrlou_st — 19 days ago