Create a virtual display on Apollo start #1138
-
|
I'm using Apollo on a headless virtual machine (running Windows 10 that has Apollo and other stuff autostarting as a service). I would like to have 1920x1080 on Windows boot without a need to connect to Apollo first. I tried to mess with the options above with no success whatsoever :\ Is there a way to set it up correctly? I only need a single constant virtual display that will work regardless of if there are Apollo clients online or even ever connected or not. Basically, I guess, my use case is to use Apollo more like a virtual display with a glorified VNC-like control. (Not sure if it's relevant: Also, I don't think I could make the dummy HDMI plug work, but I might didn't investigate that enough because the setup is pretty complicated - Windows is running as a guest in libvirt/qemu on a Linux machine that only has a single integrated Intel GPU with a kernel driver that allows it to connect the graphics card via virtual function in passthrough mode; and that virtual function is oblivious of the dummy display plug) |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
A dummy plug should work. I've done similar things on a machine with only an iGPU, passed it through and connected a real monitor to the guest Windows VM. Apollo isn't needed here in your use case. Or you should check Virtual Display Driver which is always connecting a virtual display, but that's not suitable and causing all sorts of problems for normal streaming users. |
Beta Was this translation helpful? Give feedback.
-
|
Phew, I got some progress. Gotta document it below. My setup details (click to expand; kinda offtopic)So, the physical machine is a miniPC with an Intel N150 Alder Lake processor that has integrated Intel Graphics. It's got Ubuntu installed on it. (There's also a HDMI dummy plug connected to it, although I couldn't manage to make it work; I'm not competent enough with Linux machines having displays, even dummy ones).There's also libvirt+qemu with a virtual machine that runs Windows 10 (NTDEV tiny10, actually, so it might have been the reason I've had problems with it, but I'm too lazy to mess around with it further). On the host, I got the i915-sriov-dkms driver working, and passed the VF1 to the VM as PCI passthrough. It seems to be working fine (Windows correctly detects it after installing Intel Graphics drivers and btop on the host machine shows that GPU's getting some load when the VM is busy doing... stuff). There's a separate service that starts on boot. That service basically runs some automation/testing stuff, that also has an WebUI/API. Since Apollo doesn't initialize any virtual displays until a client connects to it, that service has been struggling to deal with the Basic Display Adapter being the only "display" with a 640x480 resolution. Once in a while, I need to use remote desktop in there to mess around with that service, but I need that service to run 24/7 without any need of me checking in. I learned about app identity and realized that I can create an app that doesn't do anything (just like Sunshine's virtual display) that would still start a virtual display and keep it regardless of which client has connected to it, so I created a separate app (before, i was starting the built-in "virtual desktop" app) with the settings:
Running After starting an app with Apollo itself, it creates a virtual display just fine, although now I got another issue - having a black screen when trying to connect to that app (that was already started by Apollo) from any other Artemis instance. Since I don't have to actually connect remotely in there too often and it's more important that it runs by itself 24/7 and autorestores on, say, power loss, I can deal with that for now, phew. The black screen issue is really weird - the machine still has the display working fine (at least screenshots made by my service look fine - there's desktop, taskbar and everyhting) and mouse/keyboard work fine as well, but the whole display output in Artemis (Moonlight, too) just keeps being pitch black, while the Apollo's log getting flooded with the same lines (I formatted it a bit for readability): parts of a verbose logWhich looks weird - looks like it tries to create a new virtual display despite having app identity (without client app identity) on. The state of monitors/displays that got initialized after starting the app with an api POST request{
"EnumDisplayMonitors/GetMonitorInfo": [
{
"Monitor": [0, 0, 1920, 1080],
"Work": [0, 0, 1920, 1040],
"Flags": 1,
"Device": {
"ID": "MONITOR\\SMKD1CE\\{4d36e96e-e325-11ce-bfc1-08002be10318}\\0001",
"Key": "\\Registry\\Machine\\System\\CurrentControlSet\\Control\\Class\\{4d36e96e-e325-11ce-bfc1-08002be10318}\\0001",
"Name": "\\\\.\\DISPLAY2\\Monitor0",
"String": "Generic PnP Monitor"
},
"DevicePath": "\\\\.\\DISPLAY2"
}
],
"EnumDisplayDevices": [
[
"ROOT\\BasicDisplay",
"\\REGISTRY\\MACHINE\\SYSTEM\\ControlSet001\\Services\\BasicDisplay",
"\\\\.\\DISPLAY1",
"Microsoft Basic Display Driver"
],
[
"root\\sudomaker\\sudovda",
"\\Registry\\Machine\\System\\CurrentControlSet\\Control\\Video\\{685307E7-A2E4-11F0-B921-00E04C680CE9}\\0000",
"\\\\.\\DISPLAY2",
"SudoMaker Virtual Display Adapter"
]
]
}I realize that Apollo (at least in its current state) might be an overkill, but I had even more issues with Sunshine+VDD. |
Beta Was this translation helpful? Give feedback.
A dummy plug should work. I've done similar things on a machine with only an iGPU, passed it through and connected a real monitor to the guest Windows VM.
Apollo isn't needed here in your use case.
Or you should check Virtual Display Driver which is always connecting a virtual display, but that's not suitable and causing all sorts of problems for normal streaming users.