Can't stream a headless monitor created with Hyprland

[Kofa1]

Is there an existing issue for this?

• [X] I've found a comment, but not an issue https://github.com/LizardByte/Sunshine/issues/2250#issuecomment-2002496041

Is your issue described in the documentation?

• [X] It only documents x11

Is your issue present in the latest beta/pre-release?

I'm too lazy to test

Describe the Bug

Virtual outputs created with hyprctl output create headless don't seem to be recognized by Sunshine. Error: Unknown Monitor connector type [HEADLESS]: Please report this to the GitHub issue tracker\

Expected Behavior

No response

Additional Context

https://github.com/hyprwm/Hyprland/issues/6623#issue-2367348069

Host Operating System

Linux

Operating System Version

6.10.2-arch1-1, Hyprland window manager

Architecture

64 bit

Sunshine commit or version

Sunshine version: 0.23.1

Package

Linux - AUR (Third Party)

GPU Type

Nvidia

GPU Model

TU117

GPU Driver/Mesa Version

nvidia-open 555.58.02-10

Capture Method

None

Config

output_name = Headless output 2
resolutions = [
    352x240,
    480x360,
    858x480,
    1280x720,
    1920x1080,
    2560x1080,
    2560x1440,
    3440x1440,
    1920x1200,
    3840x2160,
    3840x1600,
    1920x1200
]

Apps

No response

Relevant log output

[resolutions] -- [[
    352x240,
    480x360,
    858x480,
    1280x720,
    1920x1080,
    2560x1080,
    2560x1440,
    3440x1440,
    1920x1200,
    3840x2160,
    3840x1600,
    1920x1200
]]
[output_name] -- [Headless output 2]
[2024:08:03:23:29:21]: Info: Sunshine version: 0.23.1
[2024:08:03:23:29:21]: Info: Found display [wayland-1]
[2024:08:03:23:29:21]: Info: Found interface: zxdg_output_manager_v1(9) version 3
[2024:08:03:23:29:21]: Info: Found interface: wl_output(47) version 4
[2024:08:03:23:29:21]: Info: Found interface: wl_output(48) version 4
[2024:08:03:23:29:21]: Info: Found interface: wl_output(49) version 4
[2024:08:03:23:29:21]: Info: Found interface: wl_output(50) version 4
[2024:08:03:23:29:21]: Warning: Missing Wayland wire for wlr-export-dmabuf
[2024:08:03:23:29:21]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:21]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:21]: Info: Found display [wayland-1]
[2024:08:03:23:29:21]: Info: Found display [wayland-1]
[2024:08:03:23:29:21]: Info: Found interface: zxdg_output_manager_v1(9) version 3
[2024:08:03:23:29:21]: Info: Found interface: wl_output(47) version 4
[2024:08:03:23:29:21]: Info: Found interface: wl_output(48) version 4
[2024:08:03:23:29:21]: Info: Found interface: wl_output(49) version 4
[2024:08:03:23:29:21]: Info: Found interface: wl_output(50) version 4
[2024:08:03:23:29:21]: Info: Resolution: 1920x1080
[2024:08:03:23:29:21]: Info: Resolution: 1280x1024
[2024:08:03:23:29:21]: Info: Resolution: 1920x1200
[2024:08:03:23:29:21]: Info: Resolution: 1280x1024
[2024:08:03:23:29:21]: Info: Name: eDP-1
[2024:08:03:23:29:21]: Info: Found monitor: LG Display 0x05E5 (eDP-1)
[2024:08:03:23:29:21]: Info: Offset: 2560x1024
[2024:08:03:23:29:21]: Info: Logical size: 1536x864
[2024:08:03:23:29:21]: Info: Name: HDMI-A-1
[2024:08:03:23:29:21]: Info: Found monitor: BNQ BenQ FP93GS 0x00003760 (HDMI-A-1)
[2024:08:03:23:29:21]: Info: Offset: 1280x0
[2024:08:03:23:29:21]: Info: Logical size: 1280x1024
[2024:08:03:23:29:21]: Info: Name: HEADLESS-2
[2024:08:03:23:29:21]: Info: Found monitor: Headless output 2
[2024:08:03:23:29:21]: Info: Offset: 2560x256
[2024:08:03:23:29:21]: Info: Logical size: 1536x960
[2024:08:03:23:29:21]: Info: Name: HEADLESS-3
[2024:08:03:23:29:21]: Info: Found monitor: Headless output 3
[2024:08:03:23:29:21]: Info: Offset: 3789x0
[2024:08:03:23:29:21]: Info: Logical size: 1280x1024
[2024:08:03:23:29:21]: Info: -------- Start of KMS monitor list --------
[2024:08:03:23:29:21]: Info: Monitor 1 is eDP-1: LG Display 0x05E5 (eDP-1)
[2024:08:03:23:29:21]: Info: Monitor 0 is HDMI-A-1: BNQ BenQ FP93GS 0x00003760 (HDMI-A-1)
[2024:08:03:23:29:21]: Error: Unknown Monitor connector type [HEADLESS]: Please report this to the GitHub issue tracker
[2024:08:03:23:29:21]: Error: Unknown Monitor connector type [HEADLESS]: Please report this to the GitHub issue tracker
[2024:08:03:23:29:21]: Info: --------- End of KMS monitor list ---------
[2024:08:03:23:29:21]: Info: // Testing for available encoders, this may generate errors. You can safely ignore those errors. //
[2024:08:03:23:29:21]: Info: Trying encoder [nvenc]
[2024:08:03:23:29:21]: Info: Screencasting with KMS
[2024:08:03:23:29:21]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:21]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:21]: Error: Couldn't find monitor [-393538374]
[2024:08:03:23:29:21]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:21]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:21]: Error: Couldn't find monitor [-393538374]
[2024:08:03:23:29:21]: Info: System tray created
[2024:08:03:23:29:21]: Info: Screencasting with KMS
[2024:08:03:23:29:21]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:21]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:21]: Error: Couldn't find monitor [-393538374]
[2024:08:03:23:29:21]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:21]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:21]: Error: Couldn't find monitor [-393538374]
[2024:08:03:23:29:21]: Info: Encoder [nvenc] failed
[2024:08:03:23:29:21]: Info: Trying encoder [vaapi]
[2024:08:03:23:29:21]: Info: Screencasting with KMS
[2024:08:03:23:29:21]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:21]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:21]: Error: Couldn't find monitor [-393538374]
[2024:08:03:23:29:21]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:21]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:21]: Error: Couldn't find monitor [-393538374]
[2024:08:03:23:29:21]: Info: Screencasting with KMS
[2024:08:03:23:29:21]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:21]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:21]: Error: Couldn't find monitor [-393538374]
[2024:08:03:23:29:21]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:21]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:21]: Error: Couldn't find monitor [-393538374]
[2024:08:03:23:29:21]: Info: Encoder [vaapi] failed
[2024:08:03:23:29:21]: Info: Trying encoder [software]
[2024:08:03:23:29:21]: Info: Screencasting with KMS
[2024:08:03:23:29:21]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:21]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:21]: Error: Couldn't find monitor [-393538374]
[2024:08:03:23:29:22]: Info: Screencasting with KMS
[2024:08:03:23:29:22]: Info: /dev/dri/card0 -> nvidia-drm
[2024:08:03:23:29:22]: Info: /dev/dri/card1 -> amdgpu
[2024:08:03:23:29:22]: Error: Couldn't find monitor [-393538374]
[2024:08:03:23:29:22]: Info: Encoder [software] failed
[2024:08:03:23:29:22]: Fatal: Unable to find display or encoder during startup.
[2024:08:03:23:29:22]: Fatal: Please ensure your manually chosen GPU and monitor are connected and powered on.
[2024:08:03:23:29:22]: Error: Video failed to find working encoder
[2024:08:03:23:29:22]: Error: Failed to create client: Daemon not running
[2024:08:03:23:29:22]: Info: Configuration UI available at [https://localhost:47990]

[egrechko]

I am getting the exact same issue as well.

[d-air1]

I'm not a hyprland user, but I just found out about this protocol finally being merged in wayland. It is based on wlroots wlr-screencopy-unstable-v1, but with improvements.

Link to phoronix article here: https://www.phoronix.com/news/Wayland-Merges-Screen-Capture Link to merge request: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124

In the link that OP provided, the hyprland project seems to recommend that wlr_screencopy_v1 be used instead of wlr_export_dmabuf. Whereas If I'm understanding this correctly, this new protocol having being merged in upstream wayland protocols might be a bit more generic and useful for all desktop environments instead of just wlroots based ones. Assuming the rest of the desktops implement this. According to the merge request, wlroots already has. Perhaps this thread should be moved to a discussion for the time being?

[Kofa1]

I'm not a hyprland user, but I just found out about this protocol finally being merged in wayland. It is based on wlroots wlr-screencopy-unstable-v1, but with improvements.

Link to phoronix article here: https://www.phoronix.com/news/Wayland-Merges-Screen-Capture Link to merge request: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124

In the link that OP provided, the hyprland project seems to recommend that wlr_screencopy_v1 be used instead of wlr_export_dmabuf. Whereas If I'm understanding this correctly, this new protocol having being merged in upstream wayland protocols might be a bit more generic and useful for all desktop environments instead of just wlroots based ones. Assuming the rest of the desktops implement this. According to the merge request, wlroots already has. Perhaps this thread should be moved to a discussion for the time being?

Aren't they saying it's a Sunshine issue, which uses outdated protocols? Sorry, I'm not a Wayland dev I have no idea what they're responsible for, just trying to use Linux.

https://github.com/hyprwm/Hyprland/issues/6623#issuecomment-2185228948

https://github.com/hyprwm/Hyprland/issues/6623#issuecomment-2192660921

[d-air1]

@Kofa1 that is what they are saying, but his suggestion has also become outdated.

[aruhier]

@Kofa1 that is what they are saying, but his suggestion has also become outdated.

Kind of, as I don't think sway or hyprland support ext-image-capture-source-v1 already. I guess that wlr_screencopy_v1 will become deprecated in favor ext-image-capture-source-v1 at one point.

[Kofa1]

@Kofa1 that is what they are saying, but his suggestion has also become outdated.

Kind of, as I don't think sway or hyprland support ext-image-capture-source-v1 already. I guess that wlr_screencopy_v1 will become deprecated in favor ext-image-capture-source-v1 at one point.

I don't really understand, is it going to magically recognise the monitors once that protocol is updated in Hyprland?

[aruhier]

Nothing is magical, Sunshine needs to explicitly implement the client side of these protocols (wlr_screencopy_v1 to support the current releases of Hyprland and Sway, ext-image-capture-source-v1 for the standard protocol that is not yet implemented in Hyprland or Sway).

Hyprland and Sway for the moment only supports wlr_screen_copy_v1, I think ext-image-capture-source-v1 is being merged in wlroots. So if Sunshine switches to wlr_screen_copy_v1 instead of wlr_export_dmabuf, yes the monitors will be recognized directly on Hyprland and Sway. In the future, wlr_screen_copy_v1 might be deprecated for ext-image-capture-source-v1, which supports window/zone capture (and not only screen capture).

[korm-spec]

Is this gonna be fixed anytime soon? It's been a month and the problem exists for 5 months already.

[gschintgen]

Is this gonna be fixed anytime soon? It's been a month and the problem exists for 5 months already.

Could you link to your PR that fixes it? More seriously: This is a volunteer project. Things happen if somebody comes along and implements it. (This could be you!)

Pressuring is only counterproductive. It leads to developers getting grumpy, ignoring the issue or burning out.

Your choices are to be patient, to fix it yourself, or to hire somebody to do it.

Please be considerate. (Giving a thumbs up to the original report is fine and shows interest. Comments are for useful additional information.)

[ElYaiko]

Having same issue Any update?

[Nelo390]

Having same issue, wasn't a problem until i got a tablet with a resolution that i can't force my laptop screen to, though. Any workarounds for the time being?

[plantroon]

I found a decent workaround here:

https://www.reddit.com/r/linux_gaming/comments/199ylqz/streaming_with_sunshine_from_virtual_screens/

It involves dumping EDID from your monitor or downloading an existing dump. The link from the reddit post does not work for me anymore, but for example here is a collection of dumped EDID files https://github.com/linuxhw/EDID - though some further edits might be necessary.

(following is copied from the reddit post)

After that, create a new edid folder under /usr/lib/firmware/ and place your edid file there. e.g. /usr/lib/firmware/edid/samsung-q800t-hdmi2.1

Then set your kernel parameters as such: drm.edid_firmware=HDMI-A-1:edid/samsung-q800t-hdmi2.1 video=HDMI-A-1:e

Replacing HDMI-A-1 to whichever free HDMI output you have in your GPU. You can figure out your outputs with this:

for p in /sys/class/drm//status; do con=${p%/status}; echo -n "${con#/card?-}: "; cat $p; done

Add the EDID file to your initramfs config and regenerate the initramfs image. For Arch Linux you just add the full edid file path to your mkinitcpio.conf FILES section and regenerate it, as explained here. Might be different for other distros and/or dracut.

Reboot and you should have a new virtual screen that you can stream from in Sunshine using KMS capture. Likely works with wlroots capture too but I didn't test it.

I can confirm that it works for me for Intel UHD P630. I've been happily using it to stream my second monitor to a phone and a Windows PC over Moonlight for a few weeks now.

[Zerodya]

Any NixOS magician that was able to declare the workaround above in nix?

[mirql]

thanks @plantroon

also for everybody else i guess this details also can be helpfull:

https://github.com/hyprwm/Hyprland/issues/6623#issuecomment-2709045321

[itouchdennis]

The workaround doesn`t seem to work on my setup with my nvidia. the best I can get is the mesa fallback 1024x768. Wanted a higher resolution or even a custom res but nothing worked so far.. the edid files itself looking good... Too sad hyprland headless not working anymore with sunshine, it was its time ahead with the wlroots implementation working.

[Reboot-Codes]

Any NixOS magician that was able to declare the workaround above in nix?

@Zerodya we we're able to define that work-around via some funky injections into the kernel image + a sunshine app that runs commands to only use that. No idea if it works currently, but we tried to define it as best as possible. (Sunshine App needs KDE since we're using kscreen-doctor to fudge display configurations btw.)

https://github.com/Reboot-Codes/dotfiles/blob/807d2b881b71e53bfc1e048b286f98306432c3bd/nixos/custom-odin-nixos/configuration.nix (See L7 for the variable to set for the GPU's interface that you'd wanna use (run for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done to find an available one), L38 for kernel parameter, L88 for EDID injection, and L286 for sunshine app if you find that helpful at all.)

[gorgbus]

I managed to fix it in the sunshine itself by changing from the wrl-export-dmabuf-unstable-v1 protocol to wlr-screencopy-unstable-v1. https://github.com/gorgbus/Sunshine/tree/wayland-headless (you need to build it yourself) But I did only try it on arch and the whole thing was cobbled together in couple of hours, so I don't know if its done the ideal way or how stable it is.

So far I got zero issues from the couple of times I tried streaming it to my phone.

[ReenigneArcher]

@gorgbus could you make a PR into our repo?

[ReenigneArcher]

Would anyone with this issue be able to test the PR by @gorgbus ?

https://github.com/LizardByte/Sunshine/pull/3783

Artifacts from last build:

• AppImage/Flatpak: https://github.com/LizardByte/Sunshine/actions/runs/14287995965/attempts/2?pr=3783#artifacts
• Debian/Ubuntu/Arch: https://github.com/LizardByte/Sunshine/actions/runs/14287995970?pr=3783#artifacts
• Fedora: https://copr.fedorainfracloud.org/coprs/lizardbyte/pulls/build/8864342/

[Kabouik]

Would anyone with this issue be able to test the PR by @gorgbus ?

I spent 2 hours trying to package Sunshine for Guix but unfortunately I failed, I hit a wall when I realized it requires an Internet connection to use npm at some point (Guix build environments are sandboxed).

However, I have tried the Flatpak and I can confirm it works with a virtual monitor created in Sway using:

# Create a virtual monitor for Lunar
output HEADLESS-1 {
  pos 0,0
  mode 2712x1220
  scale 2
}
exec --no-startup-id sh -c 'swaymsg create_output'

# Launch Sunshine
bindsym $mod+Ctrl+s exec footclient -H -a sunshine sh -c 'notify-send "Launching Sunshine…"; exec flatpak run dev.lizardbyte.app.Sunshine'

# Create or re-enable HEADLESS-1 (no Sunshine)
bindsym $mod+Ctrl+v exec sh -c 'swaymsg output HEADLESS-1 enable; sleep 3; notify-send "HEADLESS-1 enabled."'

# Disable HEADLESS-1
bindsym $mod+mod1+v exec sh -c 'notify-send "Disabling HEADLESS-1…"; sleep 3; swaymsg output HEADLESS-1 disable'

# Kill Sunshine
bindsym $mod+mod1+s exec sh -c 'notify-send "Killing Sunshine…"; sleep 3; pkill -x sunshine'

And then setting the correct monitor number in the Sunshine web UI. Note that this was using Artemis as client, not Moonlight. Thanks a lot!

Quite convenient with my keyboard PC:

[Edit] Now I see I had other monitors still enabled in the PC despite none being plugged, so I guess I'll have to confirm that again another time when I'm sure I only have the virtual monitor. But I am positive I could stream the virtual one, just not sure if that works when there's only that one. [Edit 2] Yes, it works too.

[cronyakatsuki]

Would anyone with this issue be able to test the PR by @gorgbus ?

#3783

Artifacts from last build:

* AppImage/Flatpak: https://github.com/LizardByte/Sunshine/actions/runs/14287995965/attempts/2?pr=3783#artifacts

* Debian/Ubuntu/Arch: https://github.com/LizardByte/Sunshine/actions/runs/14287995970?pr=3783#artifacts

* Fedora: https://copr.fedorainfracloud.org/coprs/lizardbyte/pulls/build/8864342/

Can confirm it works on stable hyprland on nixos ( used the appimage ).

After setting the monitor settings (resoulution and refresh rate ) for headless output can connect kb and controller to start and play games with no issues using it.

[FearlessSpiff]

Can also confirm that the AppImage works for me on Hyprland on Arch. Thanks a lot!

Edit: ~~Somehow games won't start in Steem. But streaming Steam works perfectly fine.~~ Sorry, my bad. Everything works!

[SuperKenVery]

Should the docs be updated as well?

It still says:

wlr: Capture for wlroots based Wayland compositors via DMA-BUF.

[ReenigneArcher]

Probably

[SuperKenVery]

Here's my PR if it would be convenient for you: #3828

[hawatri]

Can also confirm that the AppImage works for me on Hyprland on Arch. Thanks a lot!

Edit: ~Somehow games won't start in Steem. But streaming Steam works perfectly fine.~ Sorry, my bad. Everything works!

I am totally new in Linux and Hyprland. Sunshine showing me errors that encoder or display not found. Would you help me to fix that please