[generated by Claude Fable 5, approved by Saul]

For about a week my video calls had snow: scattered bright white pixels, like a weak analog TV signal, in the video tiles and nowhere else. Both my own preview and the other person’s feed. Only on one of my two monitors (an Acer on DisplayPort; the Samsung on HDMI was clean). And it came and went.

Linux, X11, i3, NVIDIA RTX 5070 with the 595 proprietary driver, Chromium.

What it wasn’t

• Not the camera. Both feeds had it, and swapping which tile was on top, the snow stayed with the position on screen, not the stream.
• Not video decoding. chromium --disable-accelerated-video-decode and --disable-gpu-compositing changed nothing.
• Not the rendered frame. A screenshot taken while the snow was visible was clean. So whatever it was happened after the framebuffer, between the GPU and the panel.
• Not the software stack. Nothing in the driver, kernel, mesa, or Chromium had been upgraded since spring. No Xid errors in 40 days of kernel log.

“After the framebuffer, on one monitor” reads as a bad cable. It got more convincing: toggling the driver’s dithering on that output (nvidia-settings -a "[dpy:DP-0]/Dithering=2") made the snow mostly vanish – and so did toggling it back on. A refresh-rate bounce with no other change (xrandr --output DP-0 --rate 75; xrandr --output DP-0 --rate 60) also cleared it for a while. Holding a window drag made it worse. Every one of those is what a marginal DisplayPort link does: any reset of the display head retrains the link, it comes up clean, then drifts. I reseated the cable.

What it was

Reseating the cable made things worse: the top-left of the Acer got stuck showing a chunk of a different workspace. Switching workspaces changed the window titles above it but not the stuck region. The mouse cursor drew over it fine. Restarting i3 did nothing.

xwininfo -root -tree listed a window sitting exactly there:

0x2a00001 "MPlayer": ("vdpau" "MPlayer")  1532x531+2+30

An mplayer I’d opened on a preview clip on August 17th, paused, and forgotten on another workspace. mplayer on NVIDIA defaults to -vo vdpau, and VDPAU doesn’t draw into an X window: it hands frames to a presentation queue that the display engine composites onto the output through a hardware overlay plane, on the way to the monitor. X never sees those pixels, which is why the screenshot was clean, and X’s window stacking doesn’t govern the plane, which is why unmapping the window didn’t hide it. The cursor is also a hardware plane, which is why it kept working.

So for a week a stale overlay plane had been parked on that display head. I can’t say exactly how the driver turned that into white pixels inside Chromium’s video tiles – my guess is that the plane’s clip region is recomputed against screen damage each frame, and the video tiles were the only thing on that screen damaging every frame – but the correlation is exact. Every “link retrain” that seemed to help was really the head reset knocking the plane off until mplayer’s next present put it back. A mouse drag repaints more, so it got worse.

kill <mplayer pid>. Snow gone, stuck region gone, both instantly.

Fix

Stop using mplayer. mpv (the maintained fork; mplayer’s last release was 2022) renders through vo=gpu into an ordinary window, so unmapping the window means the pixels are gone. Hardware decode still works (hwdec=auto); it’s only the overlay presentation path that’s the problem.

alias mplayer=mpv

If you must use mplayer, -vo gl in ~/.mplayer/config avoids the overlay. -vo xv is another overlay and has the same failure mode.