1 files changed, 54 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1107 b/results/classifier/118/graphic/1107
new file mode 100644
index 000000000..ea08d77f8
--- /dev/null
+++ b/results/classifier/118/graphic/1107
@@ -0,0 +1,54 @@
+graphic: 0.942
+files: 0.818
+peripherals: 0.775
+virtual: 0.657
+device: 0.657
+boot: 0.591
+semantic: 0.584
+performance: 0.549
+hypervisor: 0.548
+x86: 0.496
+PID: 0.472
+architecture: 0.446
+i386: 0.429
+user-level: 0.426
+debug: 0.386
+permissions: 0.330
+mistranslation: 0.306
+VMM: 0.299
+ppc: 0.291
+vnc: 0.290
+register: 0.281
+socket: 0.278
+risc-v: 0.276
+network: 0.264
+KVM: 0.234
+kernel: 0.211
+TCG: 0.206
+arm: 0.183
+assembly: 0.160
+
+Virtual monitor heads are not "connected" until viewed in a front end
+Description of problem:
+When you attach a virtual GPU to a guest, qemu appears to only "attach" a virtual monitor to an output port when that virtual display is
+viewed using the GUI.  For example, when you boot using the above command line, there will be four displays in ```/sys/class/drm/``` on the guest,
+```card0-Virtual-1``` through to ```card0-Virtual-4```.  In each of these directories, there is an "enabled" file, which contains either
+"enabled" or "disabled".  These contain "disabled" until you switch tab/view to look at it using the GUI, at which point they change to "enabled".
+
+This causes a problem for us because Weston will not initialise displays that do not have a monitor attached, meaning the system we are trying
+to boot fails because not all the Weston display surfaces are available.
+
+There does not appear to be a command line option to force virtual monitors to be attached to virtual displays immediately.  Looking through the
+Gtk user interface code (and the other front ends) there does not appear to be a call into the qemu core that requests the connection of a virtual
+monitor to the virtual displays - my guess is that qemu only connects a monitor when a render request first happens (or similar), but I have not followed the code paths deeper than the source files in ```QEMU/ui/```.
+
+I also tried using the ```screengrab``` command to screenshot each head, but this does not need sufficient to cause the display to be marked
+enabled in the guest.
+
+While we could possibly automate the GUI using some external tool, we ultimately need to run this in a CI environment using
+```egl-headless``` or similar.
+Steps to reproduce:
+1. Launch qemu with virtio-gpu-gl setting max_outputs > 1
+2. On guest, ```cat /sys/drm/class/card0-Virtual-2``` - it reads "disabled"
+3. On host, switch the view to look at the second display ("virtio-gpu-gl-pci.1")
+4. On guest, ```cat /sys/drm/class/card0-Virtual-2``` - it now reads "enabled"