Terminating a sunshine session makes Hyprland temporarily unresponsive

Bugs / FRs / Support
, ,
1
Hyprland version 
Hyprland 0.50.1 built from branch  at commit 4e242d086e20b32951fdc0ebcbfb4d41b5be8dcc dirty ([gha] Nix: update inputs).
Date: Sat Jul 19 23:37:06 2025
Tag: v0.50.1, commits: 6291
built against:
 aquamarine 0.9.2
 hyprlang 0.6.3
 hyprutils 0.8.1
 hyprcursor 0.1.12
 hyprgraphics 0.1.5


no flags were set
50 lines before the log spam

[LOG] [CXDGOutputProtocol] New xdg_output for virt-1: client 564c59cb5cd0 (not xwayland)
[LOG] [CScreencopyProtocol] Bound client successfully!
[LOG] [CXDGOutputProtocol] New xdg_output for virt-1: client 564c59cb5cd0 (not xwayland)
[LOG] [CScreencopyProtocol] Bound client successfully!
[LOG] [CXDGOutputProtocol] New xdg_output for virt-1: client 564c59cb5cd0 (not xwayland)
[LOG] [AQ] [libinput] event256 - Pen passthrough: is tagged by udev as: Tablet

[LOG] [AQ] [libinput] event256 - Pen passthrough: device “Pen passthrough” (beef:dead) is not known to libwacom

[LOG] [AQ] [libinput] event256 - Pen passthrough: device is a tablet

[LOG] [AQ] libinput: New device Pen passthrough: 48879-57005
[LOG] New aquamarine tablet with name Pen passthrough
[LOG] Attached tablet pen-passthrough to global
[LOG] Setting calibration matrix for device pen-passthrough
[LOG] Binding tablet pen-passthrough to output
[LOG] [CWLCompositorResource] New wl_surface with id 30 at 564c5a018160
[LOG] [CWLCompositorResource] New wl_surface with id 30 at 564c5a017350
[LOG] [CWLCompositorResource] New wl_surface with id 30 at 564c5a01b470
[LOG] [CWLCompositorResource] New wl_surface with id 50 at 564c5a0110f0
[LOG] [CWLCompositorResource] New wl_surface with id 30 at 564c5a011570
[LOG] [CWLCompositorResource] New wl_surface with id 30 at 564c5a019480
[LOG] [CWLCompositorResource] New wl_surface with id 40 at 564c5a019900
[LOG] [CWLCompositorResource] New wl_surface with id 68 at 564c5a016560
[LOG] [AQ] [libinput] event31 - Touch passthrough: is tagged by udev as: Mouse Touchscreen

[LOG] [AQ] [libinput] event31 - Touch passthrough: device is a pointer

[LOG] [AQ] [libinput] event31 - Touch passthrough: device is a touch device

[LOG] [AQ] [libinput] event256 - touch-arbitration: activated for Pen passthrough<->Touch passthrough

[LOG] [AQ] libinput: New device Touch passthrough: 48879-57005
[LOG] New aquamarine pointer with name Touch passthrough
[LOG] New mouse has libinput sens 0.00 (0.00) with accel profile 0 (0)
[LOG] Attached pointer touch-passthrough to global
[LOG] Applied config to mouse mouse-passthrough, sens 0.00
[LOG] Applied config to mouse mouse-passthrough-(absolute), sens 0.00
[LOG] Applied config to mouse touch-passthrough, sens 0.00
[LOG] New mouse created, pointer AQ: 564c5a018810
[LOG] New aquamarine touch with name Touch passthrough
[LOG] Setting calibration matrix for device touch-passthrough-1
[ERR] Failed to bind touch device touch-passthrough-1 to output ‘[[Auto]]’: monitor not found
[LOG] Attached touch touch-passthrough-1 to global
[LOG] New touch device added at 564c59bc5df0
[LOG] cursorImage request: surface 564c5953cb10
[LOG] [CScreencopyProtocol] Bound client successfully!
[LOG] [CXDGOutputProtocol] New xdg_output for virt-1: client 564c5a018dc0 (not xwayland)
[LOG] [CScreencopyProtocol] Bound client successfully!
[LOG] [CXDGOutputProtocol] New xdg_output for virt-1: client 564c5a018dc0 (not xwayland)
[LOG] [CLinuxDMABUFParamsResource] Creating a dmabuf, with id 0: size [Vector2D: x: 2550, y: 1440], fmt XR24, planes 1
[LOG] [CLinuxDMABUFParamsResource] | plane 0: mod 0 fd 164 stride 10200 offset 0
[LOG] [CLinuxDMABUFParamsResource] Creating a dmabuf, with id 0: size [Vector2D: x: 2550, y: 1440], fmt XR24, planes 1
[LOG] [CLinuxDMABUFParamsResource] | plane 0: mod 0 fd 164 stride 10200 offset 0
[LOG] [CLinuxDMABUFParamsResource] Creating a dmabuf, with id 0: size [Vector2D: x: 2550, y: 1440], fmt XR24, planes 1
[LOG] [CLinuxDMABUFParamsResource] | plane 0: mod 0 fd 164 stride 10200 offset 0
[LOG] [CLinuxDMABUFParamsResource] Creating a dmabuf, with id 0: size [Vector2D: x: 2550, y: 1440], fmt XR24, planes 1

In case someone does not know sunshine

GitHub - LizardByte/Sunshine: Self-hosted game stream host for Moonlight.

Upon disconnecting a sunshine connection, Hyprland becomes temporarily, but entirely unresponsive (not even responding to IPC requests) and keeps an entire CPU core busy. The duration of this unresponsiveness grows with the duration of the preceding sunshine session. I assume that this is related to the following lines being repeatedly written to the Hyprland log:

[LOG] [CLinuxDMABUFParamsResource] Creating a dmabuf, with id 0: size [Vector2D: x: 2550, y: 1440], fmt XR24, planes 1
[LOG] [CLinuxDMABUFParamsResource]  | plane 0: mod 0 fd 153 stride 10200 offset

The final size of the Hyprland log is consistent with the lines being written about 60 times a second, so I assume a dmabuf is created whenever sunshine captures the screen.

While the connection is open, the memory consumed by Hyprland steadily increases (going from about 250 MB to 2.5 GB within approximately 12 hours). Though this could also be caused by other factors, since I did not yet monitor the memory consumption without a sunshine connection.

The output captured is a headless one (in case that is relevant).

I have the following theory on what happens:

Obviously, the dmabufs are not persistent. Otherwise, my PC would run out of memory in a matter of minutes or even seconds (under the assumption that a dmabuf contains an entire screen, one would consume 2550*1440*24\approx 88 MB[where MathJax :slightly_frowning_face:?]). However, because of the increasing memory consumption, I assume that some record of the buffers is kept. Upon the session terminating, some logic (maybe cleanup?) iterates over all these buffers, which results in the full CPU usage and Hyprland no longer responding. Since I currently do not have time to read Hyprland’s source code, I sadly cannot verify this theory, but it is the best I was able to come up with.

If my theory is correct, can you fix this on your end? Or is the issue caused by something that sunshine does wrong, which should be reported to them instead?

One additional phenomenon, which I could not quite make sense of: The duration of Hyprland not responding seems to not scale entirely linearly with the time the sunshine session is up for. After about 15 minutes, btop does not show any spike of CPU usage and there seems to be no period of Hyprland not responding, after about 1.5 hours, CPU usage goes to 100% and Hyprland does not respond for >3 minutes.

2

Can you attach WAYLAND_DEBUG logs from the sunshine client running on the hanging up Hyprland? (from after it hung)

3

Good to know such a thing exists in wayland.
I was able to also replicate the issue using only a real monitor.

last 50 lines of sunshine log

[ 961023.408] {Default Queue} → zwp_linux_buffer_params_v1#275053.create(2560, 1440, 875713112, 0)
[ 961023.584] {Default Queue} zwp_linux_buffer_params_v1#275053.created(new id wl_buffer#4278190080)
[ 961023.592] {Default Queue} → zwlr_screencopy_frame_v1#275054.copy(wl_buffer#4278190080)
[ 961025.984] {Default Queue} zwlr_screencopy_frame_v1#275054.flags(0)
[ 961026.011] {Default Queue} zwlr_screencopy_frame_v1#275054.ready(0, 13075, 922090688)
[ 961026.020] {Default Queue} → wl_buffer#4278190080.destroy()
[ 961026.036] {Default Queue} → zwlr_screencopy_frame_v1#275054.destroy()
[2025-07-28 11:50:37.525]: Info: CLIENT DISCONNECTED
[2025-07-28 11:50:37.530]: Info: Setting default sink to: [alsa_output.pci-0000_04_00.0.hdmi-stereo]
[ 961039.693] {Default Queue} → zwlr_screencopy_manager_v1#5.capture_output(new id zwlr_screencopy_frame_v1#275055, 1, wl_output#7)
[ 961039.921] discarded [unknown]#-16777216.[event 0](0 fd, 8 byte)
[ 961039.934] discarded [unknown]#-16777216.[event 0](0 fd, 8 byte)
[ 961039.938] discarded [unknown]#-16777216.[event 0](0 fd, 8 byte)
[ 961039.953] {Display Queue} wl_display#1.delete_id(275054)
[ 961039.966] {Default Queue} zwlr_screencopy_frame_v1#275055.buffer(1, 2560, 1440, 10240)
[ 961039.997] {Default Queue} zwlr_screencopy_frame_v1#275055.linux_dmabuf(875713112, 2560, 1440)
[ 961040.013] {Default Queue} zwlr_screencopy_frame_v1#275055.buffer_done()
[ 961040.124] {Default Queue} → zwp_linux_dmabuf_v1#6.create_params(new id zwp_linux_buffer_params_v1#275054)
[ 961040.141] {Default Queue} → zwp_linux_buffer_params_v1#275054.add(fd 59, 0, 0, 10240, 0, 0)
[ 961040.156] {Default Queue} → zwp_linux_buffer_params_v1#275054.create(2560, 1440, 875713112, 0)
[ 961040.360] {Default Queue} zwp_linux_buffer_params_v1#275054.created(new id wl_buffer#4278190080)
[ 961040.375] {Default Queue} → zwlr_screencopy_frame_v1#275055.copy(wl_buffer#4278190080)
[ 961042.827] {Default Queue} zwlr_screencopy_frame_v1#275055.flags(0)
[ 961042.861] {Default Queue} zwlr_screencopy_frame_v1#275055.ready(0, 13075, 938972377)
[ 961042.873] {Default Queue} → wl_buffer#4278190080.destroy()
[ 961042.893] {Default Queue} → zwlr_screencopy_frame_v1#275055.destroy()
[ 961056.340] {Default Queue} → zwlr_screencopy_manager_v1#5.capture_output(new id zwlr_screencopy_frame_v1#275056, 1, wl_output#7)
[ 961056.434] discarded [unknown]#-16777216.[event 0](0 fd, 8 byte)
[ 961056.437] discarded [unknown]#-16777216.[event 0](0 fd, 8 byte)
[ 961056.438] discarded [unknown]#-16777216.[event 0](0 fd, 8 byte)
[ 961056.442] {Display Queue} wl_display#1.delete_id(275055)
[ 961056.446] {Default Queue} zwlr_screencopy_frame_v1#275056.buffer(1, 2560, 1440, 10240)
[ 961056.452] {Default Queue} zwlr_screencopy_frame_v1#275056.linux_dmabuf(875713112, 2560, 1440)
[ 961056.455] {Default Queue} zwlr_screencopy_frame_v1#275056.buffer_done()
[ 961056.496] {Default Queue} → zwp_linux_dmabuf_v1#6.create_params(new id zwp_linux_buffer_params_v1#275055)
[ 961056.501] {Default Queue} → zwp_linux_buffer_params_v1#275055.add(fd 49, 0, 0, 10240, 0, 0)
[ 961056.504] {Default Queue} → zwp_linux_buffer_params_v1#275055.create(2560, 1440, 875713112, 0)
[ 961056.598] {Default Queue} zwp_linux_buffer_params_v1#275055.created(new id wl_buffer#4278190080)
[ 961056.602] {Default Queue} → zwlr_screencopy_frame_v1#275056.copy(wl_buffer#4278190080)
[ 961060.924] {Default Queue} zwlr_screencopy_frame_v1#275056.flags(0)
[ 961060.933] {Default Queue} zwlr_screencopy_frame_v1#275056.ready(0, 13075, 957249784)
[ 961060.936] {Default Queue} → wl_buffer#4278190080.destroy()
[ 961060.940] {Default Queue} → zwlr_screencopy_frame_v1#275056.destroy()
[1167056.536] {Default Queue} wl_seat#20.capabilities(7)
[1167056.567] {Default Queue} zwp_tablet_v2#4278190080.removed()
[1167056.574] {Default Queue} → zwp_tablet_v2#4278190080.destroy()
[1167056.592] {Default Queue} → wl_surface#30.destroy()
[1167056.600] {Default Queue} wl_seat#20.capabilities(3)
[1167056.603] {Default Queue} → wl_touch#31.release()
[2025-07-28 12:36:56.292]: Info: Terminate handler called

Let me know if you need a longer tail or the full output (though it is 663 MB large, mostly due to the fact that I let it run for about an hour to be able to verify that the issue occurred)

4

hm, nothing looks amiss. I don’t know why this happens.

1 Like
5

I’m pretty sure this is a regression. I swear 2 weeks ago I was doing remote desktop things, and following the rolling log. and today after updating git I saw the waterfall of logs.

I will check tomorrow if it really was a regression

1 Like
6

if it’s a regression it would help greatly in debugging to know which commit exactly introduced this

7

Hey,

Maybe same issue, maybe not. I ran Sunshine and it would hang indefinitely for me when I ended a Sunshine session. I had to perform a hard restart to resolve it. Sunshine will use wlroots for wayland capture by default I believe.

As a workaround, change your “Capture method” to KMS instead. This stops the hang found when using Hyprland. See the below referenced github issue for the same.
ref: Freezes Compositor when closing sunshine after prolonged use · Issue #3854 · LizardByte/Sunshine · GitHub

1 Like
8

That very much sounds like my issue. I thought I had looked through the issues on the sunshine github. Maybe I didn’t. Or I overlooked it. I will try switching to KMS temporarily to confirm it is the same issue (or at least related).

…

I already can’t wait to switch back. My screen flashes pink when I move my mouse :frowning: .

9

The issue does not seem to be present on KMS. Since all the people reporting the bug in the lizardbyte github are using Hyprland, it is probably related to Hyprland’s reimplementation of the wlroots … API (I did not read that much into it, but it seems like an API)? But is it a bug in the implementation or API abuse by sunshine that works fine in the actual wlroots? Maybe I will have time to investigate further.

Additionally, some recent update of something seems to have somewhat reduced the freeze duration. It is now around 10 seconds after 1 hour, around 30 seconds after two hours and 35 minutes after seven hours.

PS: btw, the screen flashing pink on KMS stopped after switching Hyprland rendering back from my integrated to my dedicated Intel GPU. Maybe my 50mV CPU undervolt isn’t as stable as I had thought … Or it’s just some weird stuff with Intel GPUs again.

10

We don’t use wlroots, that’s probably one…