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? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1868617 Title: multiseat: route different spice tablet events to distinct vdagents Status in QEMU: New Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1868617/+subscriptions