Moonlight broken by sway 1.9

[qdii]

• Description:

  • Moonlight is a remote desktop application. In sway 1.9, the application can no longer stream images (but can still detect remote servers and establish a connection to them). Rolling back to sway 1.8.1 fixes the issue.

• Sway Version: 1.9

• Debug Log:

  • Moonlight console logs for sway 1.8.1 and sway 1.9

• Environment variables:

  • SDL_VIDEODRIVER=wayland,x11
  • WLR_DRM_DEVICES=/dev/dri/card0
  • VDPAU_DRIVER=radeonsi
  • LIBVA_DRIVER_NAME=radeonsi

[emersion]

Maybe caused by this?

00:00:01 - SDL Info (0): Direct rendering via DRM is disabled
...
00:00:01 - SDL Error (0): No suitable Vulkan devices found!

https://github.com/moonlight-stream/moonlight-qt/blob/fc6c51c75ac34d1795f11650cb4f25b30bea6cbe/app/streaming/video/ffmpeg-renderers/drm.cpp#L304

[qdii]

Here is a diff of the good and bad log (without timestamp or memory addresses):

1659d1658
< Qt Info: Found "ModeSeven.ttf" at ":/data/ModeSeven.ttf"
1661c1660,1662
< Qt Info: Executing request: "http://192.168.1.8:47989/serverinfo?uniqueid=0123456789ABCDEF&uuid=d89e3ed4d4cc48ec99eac53656b68e52"
---
> Qt Info: Executing request: "http://192.168.1.8:47989/serverinfo?uniqueid=0123456789ABCDEF&uuid=e9ffef49767847e8b3831e1c06df80b4"
> Qt Info: Executing request: "https://192.168.1.8:47984/serverinfo?uniqueid=0123456789ABCDEF&uuid=5f7acf9877b64ef1bde9f0eb94765ed7"
> Qt Info: Found "ModeSeven.ttf" at ":/data/ModeSeven.ttf"
1665d1665
< Qt Info: Executing request: "https://192.168.1.8:47984/serverinfo?uniqueid=0123456789ABCDEF&uuid=7b0d0038d1934ddfbd7834a15252c60b"
1696c1696
< Qt Info: Executing request: "https://192.168.1.8:47984/resume?uniqueid=0123456789ABCDEF&uuid=36885516d72d46f696a793cbd78a6e77&appid=881448767&mode=1280x720x30&additionalStates=1&sops=1&rikey=50f9673e9de49cc88cc50d74a2ad3bad&rikeyid=1487765550&localAudioPlayMode=0&surroundAudioInfo=196610&remoteControllersBitmap=0&gcmap=0&gcpersist=0&corever=1"
---
> Qt Info: Executing request: "https://192.168.1.8:47984/resume?uniqueid=0123456789ABCDEF&uuid=89326e3b9b8a43ee922528984ab1ea2d&appid=881448767&mode=1280x720x30&additionalStates=1&sops=1&rikey=9e587b6acca5bf9224f5f620d2621993&rikeyid=295447488&localAudioPlayMode=0&surroundAudioInfo=196610&remoteControllersBitmap=0&gcmap=0&gcpersist=0&corever=1"
1733,1735c1733,1735
< SDL Info (0): Qt UI screen is at (0,0)
< SDL Info (0): SDL found matching display 3
< SDL Info (0): Found display mode with desktop resolution: 1440x2560x60
---
> SDL Info (0): Qt UI screen is at (2880,0)
> SDL Info (0): SDL found matching display 0
> SDL Info (0): Found display mode with desktop resolution: 1542x2742x60
1743,1744d1742
< SDL Info (0): Dropping window event during flush: 1 (0 0)
< SDL Info (0): Dropping window event during flush: 6 (1440 2560)
1746c1744,1761
< wp_viewport@39: error 2: source rectangle out of buffer bounds
---
> SDL Info (0): Dropping window event during flush: 1 (0 0)
> SDL Info (0): Received first video packet after 600 ms
> FFmpeg: [hevc @ ] nal_unit_type: 32(VPS), nuh_layer_id: 0, temporal_id: 0
> FFmpeg: [hevc @ ] nal_unit_type: 33(SPS), nuh_layer_id: 0, temporal_id: 0
> FFmpeg: [hevc @ ] nal_unit_type: 34(PPS), nuh_layer_id: 0, temporal_id: 0
> FFmpeg: [hevc @ ] nal_unit_type: 19(IDR_W_RADL), nuh_layer_id: 0, temporal_id: 0
> FFmpeg: [hevc @ ] nal_unit_type: 19(IDR_W_RADL), nuh_layer_id: 0, temporal_id: 0
> FFmpeg: [hevc @ ] nal_unit_type: 19(IDR_W_RADL), nuh_layer_id: 0, temporal_id: 0
> FFmpeg: [hevc @ ] nal_unit_type: 19(IDR_W_RADL), nuh_layer_id: 0, temporal_id: 0
> FFmpeg: [hevc @ ] Decoding VPS
> FFmpeg: [hevc @ ] Main profile bitstream
> FFmpeg: [hevc @ ] Decoding SPS
> FFmpeg: [hevc @ ] Main profile bitstream
> FFmpeg: [hevc @ ] Decoding VUI
> FFmpeg: [hevc @ ] Decoding PPS
> FFmpeg: [hevc @ ] Format yuv420p chosen by get_format().
> FFmpeg: [hevc @ ] Output frame with POC 0.
> FFmpeg: [hevc @ ] Decoded frame with POC 0.
1747a1763,1775
> SDL Info (0): Raising 1 keys
> SDL Info (0): Global video stats
> SDL Info (0): ----------------------------------------------------------
> Incoming frame rate from network: 21.60 FPS
> Decoding frame rate: 21.60 FPS
> Rendering frame rate: 21.60 FPS
> Host processing latency min/max/average: 6.2/30.8/10.2 ms
> Frames dropped by your network connection: 0.00%
> Frames dropped due to network jitter: 0.00%
> Average network latency: 1 ms (variance: 0 ms)
> Average decoding time: 5.89 ms
> Average frame queue delay: 0.48 ms
> Average rendering time (including monitor V-sync latency): 0.71 ms
1756d1783
< SDL Info (0): No video traffic was ever received from the host!

[qdii]

@emersion Unlikely: the same log line is present in the working version. Besides, the same moonlight-qt binary is used both in sway 1.9 and 1.8.1.

[qdii]

The screen mismatch is likely a red-herring: it is probably just me using a different screen when I launched the application.

[qdii]

I'll try to find where it started with git bisect.

[qdii]

Trying to bisect, I'm bumping into compatibility issues with wlroots. Is sway 1.9 only compatible with wlroots > 0.17.0? (please let me know if I'm saying something stupid, I really don't know anything about all that).

[emersion]

Do you know which mechanism Moonlight uses for screen capture? xdg-desktop-portal, or something else?

It may be helpful to compare WAYLAND_DEBUG=1 logs of Moonlight on Sway 1.8 and 1.9.

[cgutman]

Moonlight is just the client that displays the video stream from the host. The host side software that is performing the display capture is Sunshine.

@qdii Just to confirm, this breakage when Sway 1.9 is running is on the client system running Moonlight, not the server system where Sunshine is running?

A couple things jump out in the logs. First, it looks like you're forcing software decoding, which means we will be using SDL to render. The SDL renderer in Moonlight is really nothing special. If it's broken, I'd imagine many other SDL2-based apps are broken too. Any chance you can reproduce the issue with one of the testgl* apps from SDL (SDL2 branch)?

Second, it looks like your connection is being stopped immediately after it's established in the bad log. I'm not really sure why that's happening (assuming you didn't do it on purpose), but I wonder if it's related to that wp_viewport@39: error 2: source rectangle out of buffer bounds message. If the window is getting destroyed after a Wayland protocol error, that would explain why the event loop stops and the connection terminates.

[emersion]

Ah, I missed this error. Indeed, all Wayland protocol errors are fatal and disconnect the client. The client is not using viewporter correctly here.

Closing as a client bug.

[qdii]

This breakage when Sway 1.9 is running is on the client system running Moonlight

Yes correct

First, it looks like you're forcing software decoding

Also correct, but the problem is also reproducible when using hardware decoding. I forced software decoding to remove a few moving pieces and make debugging simpler.

[qdii]

all Wayland protocol errors are fatal and disconnect the client. Closing as a client bug.

Ah looks like it's unrelated to Sway then.

Any idea why this bug isn't triggered on Sway 1.8.1 ?

[emersion]

wlroots added the check for bad viewporter usage recently-ish.

[qdii]

Ok I see. Thanks you two for helping with this :)

[cgutman]

The viewporter usage comes from SDL, so this bug probably belongs there.

[cgutman]

Closing the loop here - this was a SDL bug that is now fixed upstream in libsdl-org/SDL#9283