qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]