summaryrefslogtreecommitdiffstats
path: root/results/classifier/105/mistranslation/1868617
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/105/mistranslation/1868617')
-rw-r--r--results/classifier/105/mistranslation/186861751
1 files changed, 51 insertions, 0 deletions
diff --git a/results/classifier/105/mistranslation/1868617 b/results/classifier/105/mistranslation/1868617
new file mode 100644
index 00000000..9612de1e
--- /dev/null
+++ b/results/classifier/105/mistranslation/1868617
@@ -0,0 +1,51 @@
+mistranslation: 0.884
+other: 0.852
+device: 0.817
+instruction: 0.801
+semantic: 0.793
+graphic: 0.753
+socket: 0.717
+network: 0.671
+boot: 0.582
+vnc: 0.577
+assembly: 0.561
+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.]
+