Bug 492285

Summary:	Forward backend configuration from startplasma to kwin
Product:	[Plasma] kwin	Reporter:	Robin Bankhead <kde.bugs>
Component:	wayland-generic	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	CONFIRMED ---
Severity:	wishlist	CC:	bugs.kde.org, kde, michal, nate
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Robin Bankhead 2024-08-27 21:20:23 UTC

Simply put, I would like to be able to run a headless, persistent, detachable/reconnectable plasma-wayland session with a VNC server, as wlroots-based compositors are able to do with the aid of WayVNC[1].

I am aware that kwin_wayland has a virtual backend, which was mooted when introduced as a means to provide such functionality[2] - that was a long time ago so I do not know whether that would still be considered the best starting point.

I am also unsure how easily reproducible is what wlroots provides that WayVNC needs, or whether it would be necessary to implement everything including the server in a "KDE Way"; so I don't know if this will be a big ask or a VERY big ask. I would just like to know if there's an avenue and any interest towards it. I think it could be very beneficial in cloud systems, VMs and even plain old LAN usage once X11 finally shuffles off.

[1] https://github.com/any1/wayvnc
[2] http://blog.martin-graesslin.com/blog/2015/10/september-update-for-plasmas-wayland-porting/

Comment 1 Vlad Zahorodnii 2024-09-17 11:59:05 UTC

It sounds like you rather need a way to tell the plasma start script to start kwin_wayland with the virtual backend and also provide a way to pass additional arguments to configure the mode size or the refresh rate.

Comment 2 Robin Bankhead 2024-09-17 12:16:08 UTC

(In reply to Vlad Zahorodnii from comment #1)
> It sounds like you rather need a way to tell the plasma start script to
> start kwin_wayland with the virtual backend and also provide a way to pass
> additional arguments to configure the mode size or the refresh rate.

*If* the virtual backend is viable for such a purpose (this is one aspect on which I wasn't able to get up-to-date info), then what you detail would be a necessary part of the puzzle, yes. But there is also how inputs are handled. I don't understand very well how responsibilities divide up between what the compositor needs to do to enable it and what a VNC server, as a distinct entity, needs to implement for itself.

Comment 3 David Edmundson 2024-09-27 08:22:24 UTC

VNC support in kwin is not something we intend to do directly, we support 3rd party apps streaming content (see krdb or others)

Having a mechanism to specify the virtual backend from startplasma makes sense.

Comment 4 Robin Bankhead 2024-09-28 14:14:53 UTC

Thank you for clarifying things for me. So it sounds like the virtual backend *can* provide what a 3rd-party VNC server would need on the output side. I will look elsewhere for what would need doing on the input side.

Can I just enquire regarding virtual backend outputs, can they be resized dynamically? And could a virtual output be added (dynamically or at launch) to a "bare metal" session as a second screen?

Comment 5 Robin Bankhead 2025-08-12 13:03:45 UTC

(In reply to Robin Bankhead from comment #4)
>And could a virtual output be added (dynamically or at launch)
> to a "bare metal" session as a second screen?

Just to self-answer my 2nd question above: Yes, I found that KRFB's krfb-virtualmonitor tool does exactly this, with the virtual output exported to VNC. (Unfortunately that is output-only and does not take input from the VNC client, for whatever reason.)