1 files changed, 53 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1868617 b/results/classifier/zero-shot/108/other/1868617
new file mode 100644
index 000000000..a667bd41a
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/1868617
@@ -0,0 +1,53 @@
+other: 0.852
+files: 0.835
+device: 0.817
+semantic: 0.793
+performance: 0.763
+graphic: 0.753
+socket: 0.717
+PID: 0.676
+network: 0.671
+debug: 0.647
+permissions: 0.623
+boot: 0.582
+vnc: 0.577
+KVM: 0.505
+
+multiseat: route different spice tablet events to distinct vdagents
+
+docs/multiseat.txt says:
+
+> Note on spice: Spice handles multihead just fine.  But it can't do
+> multiseat.  For tablet events the event source is sent to the spice
+> agent.  But qemu can't figure it, so it can't do input routing.
+> Fixing this needs a new or extended input interface between
+> libspice-server and qemu.  For keyboard events it is even worse:  The
+> event source isn't included in the spice protocol, so the wire
+> protocol must be extended to support this.
+
+I'm not sure exactly what "can't figure it" means, but it looks to me like qemu can't route incoming tablet events from a spice client to distinct vdagent channels.
+
+I think this part of the process can be fixed within qemu.  I've reported https://gitlab.freedesktop.org/spice/spice-gtk/issues/121 to address the issues with the keyboard interface at the protocol level.
+
+Here are two different ways i can think of to potentially solve this (i'm not qemu hacker, feel free to correct me or propose a better solution):
+
+ - the spicevmc chardev's "name" parameter could be used to identify the agent numerically (e.g. "vdagent:1" instead of "vdagent")
+
+ - the -device virtserialport could identify whether it is connected via a multiseat PCI bridge (pci-bridge-seat) and group it with the other monitor from there.
+
+Is one of these approaches preferable?
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting older bugs to "Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+