Experiment: Virtual KMS (VKMS) + KRFB

Help
1

Hi,

A while ago I heard about the kernel’s vkms module, and I have been interested in seeing if it could be used as a way of achieving a headless remote desktop setup with plasma-wayland.

First I tried enabling the kernel module while inside a normal Plasma-wayland session on my laptop. I flipped on all available params because why not:

modprobe vkms enable_cursor=true enable_writeback=true enable_overlay=true create_default_dev=true

This got me a 1024x768 screen appearing in Plasma’s Display Configuration applet. In the config I was able to choose the monitor’s arrangement and resolution (although obviously I couldn’t see it). Good start(?)

I then installed and setup KRFB to start on login and allow unattended access, and checked this works.

For headless I need to tell Plasma to only use the vkms output, so I used this script to launch it from a TTY:

#!/bin/sh

#specify the vkms drm device

export KWIN_DRM_DEVICES="/dev/dri/card1" 
/usr/libexec/plasma-dbus-run-session-if-needed startplasma-wayland

On the TTY I got the normal plasma startup console output, then a blank screen. In my VNC viewer, I saw my Plasma desktop … but with a few issues:

  • The panel does not redraw, so e.g. the clock remains frozen at login time
  • Mouse works but pointer image does not change when it should (e.g. to scaling icon when at window edges/corners)
  • Applications can be opened but just show their initial draw (so e.g. Firefox just shows an unpopulated toolbar and blank page)
  • Resizing a window just results in the existing contents being scaled/warped to fit the new dimensions

So it seems like everything is functional but most operations are failing to trigger screen redraws. It’s more than I expected TBH, but obviously not exactly usable.

So my question is: Can I improve on this? There are lots of other envvars for Kwin but I don’t know whether any have utility to change the situation here. With vkms being software-only, maybe there’s simply no way it can handle plasma-wayland properly, but I’d like to be sure I’ve tried whatever I can.

Thanks for any tips/suggestions you may have.

2

In trying to better understand the meaning and effect of $KWIN_DRM_DEVICES I read these two items:

  1. 1. KDE Kwin docs

The first device in the list will be used by KWin and most apps for rendering.

  1. 2. ArchWiki
# Example: Render on Intel (card1), Output to VKMS (card2)
export KWIN_DRM_DEVICES=/dev/dri/card1:/dev/dri/card2

If I interpret this right, then it means you can specify card0 (the Intel iGPU) to do the rendering, which I assume KDE needs to be done on a proper accelerated device, but the output will go out over card1 (VKMS screen).

I tried it, but what I in fact got was both screens active. In my VNC viewer, I found them both displayed side-by-side. On the plus side, everything on the VKMS screen was rendered perfectly and redrawn correctly, and it became primary screen so the panel was on it. On the negative: The physical “seat” of the laptop remains active and interactive - mouse and keys work on it, and a desktop (although empty) is shown. Also I have this surplus screen area next to the desktop I want to use in the VNC session.

I thought perhaps I could just turn off the laptop screen in Display Configuration, but as soon as I did this, the VNC session became unresponsive, and when I reopened the viewer, its screen redraws were broken again, the same as in my original trial. (I didn’t try it but I imagine the same thing would happen if the laptop screen switched off when idle.)

I also tried using TigerVNC’s new w0vncserver instead of KRFB but the results and behaviour were much the same.

So this did not really improve the situation. I think there is only going to be a workable approach if it can be made to totally ignore the existence of the physical laptop screen, and I don’t see another way to do that. I see two possible avenues:

  1. If other switches can be thrown via envvars or whatever, to make Plasma/Kwin run happily with only the VKMS device;
  2. If using the manual method of creating a VKMS device (creating a series of dirs and symlinks in configfs, as detailed in the documentation) can enhance its capabilities beyond that of just loading the module with create_default_dev to create a device.