[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1868617] Re: multiseat: route different spice tablet events to dist
From: |
dkg |
Subject: |
[Bug 1868617] Re: multiseat: route different spice tablet events to distinct vdagents |
Date: |
Mon, 23 Mar 2020 20:18:16 -0000 |
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