Virtual Output Use Cases and API Design

[404NotFoundJS]

I’m adding virtual output support to niri, mainly for remote desktop use (testing with Sunshine/Moonlight). I have a minimal implementation working and would like feedback on the API and structure before going further.

Current state

• Virtual outputs via IPC (niri msg action create-virtual-output, optional name / resolution / scale)
• Config support with a virtual keyword in the output section
• Outputs stored in niri.virtual_outputs and rendered through wlr-screencopy
• TTY backend skips DRM rendering when TtyOutputState is missing

Issues

• Virtual outputs only update while a screencopy client is active; otherwise nothing drives frame callbacks or rendering
• Niri::create_headless_output() is shared between the headless test backend and virtual outputs, which feels like a layering violation

Use cases

• Remote desktop (Sunshine/Moonlight)
• Remote Desktop Portal (non-screencopy path)
• Dedicated virtual displays for screencasting
• Headless / accessibility setups
• Testing and development

Anything important missing?

Questions

• Should virtual outputs have a synthetic refresh rate to drive rendering when idle?
• How should the Remote Desktop Portal case integrate with this?
• Is there a cleaner separation between headless backends and virtual outputs?

Feedback welcome before I go further.

[YaLTeR]

For refresh rate while there are cases where the consumer can reasonably drive it, I think in most cases you want synthetic fixed refresh rate. Even for screencopy where I believe the consumer will repeatedly request it, and the expectation is that the compositor only returns a new frame when it's ready.

[404NotFoundJS]

That makes sense. So the virtual output should tick at its configured refresh rate regardless of whether anything is capturing it, and screencopy just grabs whatever frame is current when it requests one.

I'll add a timer-based render loop for virtual outputs. Should be straightforward.

For screencopy specifically, I'm currently queuing a redraw on damage-based requests since virtual outputs don't have VBlank triggers. With a synthetic refresh rate that probably becomes unnecessary - the output will already be rendering on schedule.

[lewisflude]

This sounds useful! Currently due to using an ultrawide display, I've been experimenting with using a HDMI dummy plug.

[paper42]

My usecase would be being able to send apps to an eink display using https://codeberg.org/platosha/einkway (because hdmi eink controllers are expensive), I would love to test it

[SturgeonInc]

I have an idea to use virtual displays as a meta-workspace, even though I have only one physical screen. E.g. I could have all my classes' dedicated workspaces on one display, and all my leisure ones in another.

I also have a concept a sort of "minimizing" windows script with via a virtual display

[fabio-stoppa]

HI! any updates on this?

[Sempyos]

No

[Atan-D-RP4]

I believe there's an open issue for this in upstream Smithay. pop-os/cosmic-epoch#99

The person who posted made that had been in talks with the cosmic team for supporting this and doing some reading into the code for it.

Might be worth it to reach out.

[rektide]

#714 was for headless output, which is a very overlapping ask.

[juliadin]

Of not even a subset. From the discussion I gathered that most headless use cases I can think of are covered. I'd love to see this happen.