Moonlight-Qt on Pi 5: labwc OpenGL fallback throttles 4K framerate

[fbrinker]

Disclaimer: I've tried to solve my issue multiple hours and AI (Claude Opus) assisted me with debugging, finding the workaround and creating this issue. Please let me know if you need any further information or have other ideas I could try. :)

Edit: Updated title and root cause after further tests

---

Batocera build version

43 2026/04/30 09:10

Your architecture

Raspberry Pi 5 Model B Rev 1.1 (bcm2712)

Your Graphic Processor Unit(s) (GPU)

VideoCore V (vc4-kms-v3d)

Issue description

Moonlight-Qt exhibits severe diagonal screen tearing/shearing when launched through EmulationStation on Batocera V43. The tearing appears as diagonal white/bright lines running from bottom-left to top-right, with occasional image distortion.

Root cause (corrected after further testing):
Under labwc, Moonlight-Qt can't use its DRM renderer (labwc owns DRM master) and falls back to the SDL OpenGL renderer on the v3d node. At 4K this path costs ~22–24 ms/frame and caps rendering at ~37 FPS, below the incoming rate, so frames are dropped. With direct KMS (no compositor) Moonlight uses the DRM renderer, puts the decoded NV12 straight on a vc4 plane (~10 ms/frame) and renders the full incoming rate.

The framerate cap above is a render-throughput limit, not V-sync/tearing (compositor has allowTearing=no).

The diagonal lines from the original report are a separate, intermittent artifact on the OpenGL path — also not classic tearing (they show even on static frames). Trigger not isolated; did not reproduce under direct KMS. With direct KMS it's fine.

Evidence

Under labwc (tearing present)
When launched through EmulationStation, Moonlight logs show:

SDL Info (0): Direct rendering via DRM is disabled
SDL Info (0): Direct rendering via DRM is disabled
SDL Info (0): SDL renderer backend: opengl
SDL Info (0): SDL renderer backend requires main thread rendering

The GPU driver reported is v3d (the 3D render node), not the display controller.

Without labwc (no tearing)
When labwc and EmulationStation are stopped and Moonlight is launched directly with SDL_VIDEO_DRIVER=kmsdrm:

SDL Info (0): Sharing DRM FD with SDL
SDL Info (0): GPU driver: vc4
SDL Info (0): Plane 81 is active on CRTC 92
SDL Info (0): Plane 655 is active on CRTC 92
SDL Info (0): Using DRM renderer
SDL Info (0): Selected DRM plane supports chosen decoding format: 3231564e
SDL Info (0): FFmpeg-based video decoder chosen

The GPU driver is vc4 (display controller), DRM planes are used directly, and tearing is completely eliminated.

Additional observations

• The highest quality setting is 50.000, but I would prefer 80.000 for 4k streams
• At 4K@60 (display matched to the 60 FPS stream): the diagonal artifact is reduced but still occurs, and rendering stays capped (~37 FPS), the renderer still falls back to SDL OpenGL. Only direct KMS resolves both.
• Hardware HEVC decoding via V4L2 stateless API works correctly in both scenarios.
• Controller input latency is also noticeably worse under labwc's OpenGL path compared to direct DRM rendering.

System details

Kernel: 6.12.62
Compositor: labwc 0.9.3 (Wayland)
Moonlight-Qt: 6.1.0
Sunshine: 2026.417.201619
Host GPU: NVIDIA GeForce RTX 3080
Stream: 3840x2160 @ 60 FPS, HEVC, 80 Mbps
Display: LG C5 OLED via Denon AVR (HDMI)

Detailed reproduction steps

Steps to reproduce

• Install Batocera V43 on a Raspberry Pi 5
• Configure Moonlight-Qt and pair with a Sunshine host
• Launch any Moonlight stream through EmulationStation → observe diagonal tearing

Details of any attempts to fix this yourself

SSH into Batocera and run:

   killall emulationstation
   killall labwc
   sleep 2
   SDL_VIDEO_DRIVER=kmsdrm SDL_JOYSTICK_HIDAPI=0 moonlight-qt --4K --fps 60 --bitrate 80000 stream <HOST_IP> Steam Big Picture

Observe that tearing is completely gone

Expected behavior

Moonlight-Qt should be able to use DRM direct rendering (vc4 display planes) for tear-free video output, even when launched through EmulationStation under labwc.

Suggested fix

Modify the Moonlight launcher in Batocera's configgen to stop labwc before launching Moonlight-Qt with SDL_VIDEO_DRIVER=kmsdrm, and restart labwc + EmulationStation after Moonlight exits. This approach requires no upstream changes to labwc or Moonlight-Qt.
Alternatively, enabling direct scanout support in labwc for fullscreen applications on the Pi 5 would be a more elegant long-term solution, allowing Moonlight's framebuffers to be placed directly on DRM overlay planes without compositor involvement.

Details of any modifications you have made to Batocera.

Added an fixed eid to the boot config to detect my TV through the Denon AVR properly.
Tried some changes at the Moonlight Config without any success. I've tried to use the working one from my previous PiOS Image with Moonlight-QT

Logs and data

batocera-support-20260606000420.tar.gz

[fbrinker]

Another note: To be able to stream in 4k, I had to do the following change to the /boot/config.txt

dtoverlay=vc4-kms-v3d,cma-512

The added cma-512 solved the stream crashing right after the start all the time.

[fbrinker]

Update: Tested with 4K@60Hz (matching the 60 FPS stream). Tearing is reduced from constant to occasional, but still present. Logs confirm V-sync is active but the renderer still falls back to SDL renderer backend: opengl with Direct rendering via DRM is disabled. The OpenGL path on the Pi 5's v3d GPU simply cannot guarantee tear-free page flips under labwc — only DRM direct rendering via vc4 (without labwc) achieves zero tearing.

Edit: So matching the refresh rate (V-sync now active) reduces the diagonal artifact but doesn't eliminate it, and the framerate stays capped. Only direct DRM rendering via vc4 (without labwc) is fully clean. (See the follow-up update below: the core problem turned out to be a render-throughput cap on the OpenGL path, not page-flips/V-sync.)

[fbrinker]

Update: My original root cause (V-sync/page-flip tearing) was wrong. Re-tested with Moonlight's stats — it's a render-throughput cap on the OpenGL path. Same stream (4K60, HEVC, 80 Mbps), only difference = compositor:

path	rendering FPS	render time	frames dropped
via ES (labwc, GL)	30–38 (5 runs, never >38)	22–24 ms	15–45%
direct KMS (SDL_VIDEO_DRIVER=kmsdrm)	= incoming	10–16 ms	~0%

Control: a KMS run at incoming=40 FPS rendered 40.47 @ 9.79 ms, while labwc runs at higher incoming (44–59) still capped ~37. So it's the render path, not game FPS or network (1 ms latency, 0% connection loss throughout). Decode is fine in both (decode rate = incoming, V4L2 HEVC stateless).

Not claimed: pure-GPU timing (render-time figure includes V-sync), codec dependence (I couldn't force H.264 via the ES option, possibly a separate issue), or the shear trigger.

Workaround unchanged: stop labwc → launch with SDL_VIDEO_DRIVER=kmsdrm → restart after stopping the stream.