summary refs log tree commit diff stats
path: root/results/classifier/gemma3:12b/graphic/1107
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/gemma3:12b/graphic/1107')
-rw-r--r--results/classifier/gemma3:12b/graphic/110725
1 files changed, 25 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/graphic/1107 b/results/classifier/gemma3:12b/graphic/1107
new file mode 100644
index 000000000..357381aba
--- /dev/null
+++ b/results/classifier/gemma3:12b/graphic/1107
@@ -0,0 +1,25 @@
+
+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"