On Tue, Aug 28, 2018 at 05:26:15PM +0200, Lukáš Hrázký wrote:
> On Fri, 2018-08-24 at 17:21 +0200, Gerd Hoffmann wrote:
> > On Fri, Aug 24, 2018 at 03:38:07PM +0200, Lukáš Hrázký wrote:
> > > At this moment, the agent has no idea about channel_ids,
> >
> > I think this one should be solved.
> >
> > So, qemu knows which channel id belongs to which device (and head, in
> > case devices have one channel per head like virtio). qemu could pass
> > that information to spice-server, so vdagent can query it
> > from spice-server.
> >
> > Then vdagent can scan /dev/dri/card*, query the outputs of each device
> > (using libdrm), lookup the device in sysfs, build a channel-id -> output
> > mapping from that.
>
> Ok, supposing this is the first issue we should look into, could you
> describe the process in more detail? What values are used, passed over
> interfaces and translating into what, etc...
>
> In particular how do you map the devices in sysfs exactly to (e.g.
> xrandr) outputs?
I think we should attach some additional metadata to each display
channel. One item would be the device path of the device. Format
could be something like this:
pci/$domain/$slot.$fn/$slot.$fn
^^^^^^^^^ gpu device
^^^^^^^^^ pci bridge
There can me multiple or no pci bridges of course, depending where the
device is in the hierarchy. A typical libvirt configuration with qxl
in slot 2 at the root bus would be:
pci/0000/02.0
For a classic display channel qemu can set that information, using a new
spice_server_* function call.
For a streaming display channel that would be the job of the streaming
agent I think.
For each drm device you can figure the device path in sysfs (this is
virtio-gpu):
root@fedora ~# readlink /sys/class/drm/card0
../../devices/pci0000:00/0000:00:01.0/virtio0/drm/card0
Each output has a sysfs directory:
root@fedora ~# ll /sys/class/drm/card0/
total 0
drwxr-xr-x. 3 root root 0 Aug 29 07:33 card0-Virtual-1
^^^^^^^^^^^^^^^
It is also possible to use libdrm to get the information about the
outputs, see https://git.kraxel.org/cgit/drminfo/
The xorg modesetting driver will use the drm names for xrandr, and the
output above will show up as "VIRTUAL-1" in xrandr. The drm names are
unique, in case two devices are present in the system one will get
"Virtual-1" and the other "Virtual-2", so you can actually link the
xrandr name to the physical device.
The xorg qxl driver seems to use its own numbering, starting at zero
(instead of using drmModeConnector->connector_id). So we need a special
case here (easy to detect, no other device has a "Virtual-0" output), or
fix the xorg qxl driver, or both.
The nvidia driver isn't a drm driver I think, so this probably needs a
special case too. Should be present in sysfs still, so you can figure
the pci bus location, even if it might not be in /sys/class/drm but
somewhere else.
What else we need? I think we should have two fields for the output
(monitor): "first" and "count", so we can model all the configurations
we might have:
dual-head qxl (linux, one device, one channel)
device path first count
pci/0000/02.0 0 2
dual-head qxl (window, two devices, two channels)
device path first count
pci/0000/02.0 0 1
pci/0000/03.0 0 1
dual-head virtio-gpu (one device, two channels)
device path first count
pci/0000/02.0 0 1
pci/0000/02.0 1 1
Maybe it would be nice to also have a name which virt-viewer can show in
the view/display menu.
spice-server is probably the best place to manage that information
because everybody (qemu, agents, client) talks to the server. Also
client and agent are not persistent, they can come and go. So we need
new messages and libspice-server functions to set and get that
information.
To reference the display in the Mouse* and other messages I see two ways
then:
(1) We use channel-id + output-id (or monitor-id).
Needs a V2 of each message.
(2) Spice-server assigns a unique display-id to each output,
then we use this in the existing display-id field of the
messages (and as index into the display array).
Not sure which one is easier when it comes to backward compatibility.
cheers,
Gerd
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel