blob: 9612de1ed5354d7c3a459c9f02c7858a7687b2f5 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
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.]
|