qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH spice v2 1/2] QXL interface: add functions t


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [RFC PATCH spice v2 1/2] QXL interface: add functions to identify monitors in the guest
Date: Thu, 18 Oct 2018 10:44:41 +0200
User-agent: NeoMutt/20180716

> > + * supported address at the moment, other identifiers can be introduced
> > later.
> > + * <DOMAIN> is the PCI domain, followed by <SLOT>.<FUNCTION> of any PCI
> > bridges
> > + * in the chain leading to the device. The last <SLOT>.<FUNCTION> is the
> > + * graphics device.
> 
> Maybe better to specify also the encoding, like decimal/hexadecimal and number
> of digits.

lspci style (i.e. slot is two digits hex, function is one digit).

> > +/**
> > + * spice_qxl_monitor_set_device_display_id:
> > + * @instance the QXL instance to set the device display ID to
> > + * @monitor_id the SPICE monitor ID to set the device display ID to
> > + * @device_display_id the actual ID of the display (output) on the graphics
> > device

Hmm, why do we need the monitor_id here?

The reason to have this function is to allow the guest agent figure
which channel is which head in case we have multiple display channels
registered for one device.

For linux-qxl multihead we don't need this as all heads use the same
display channel, right?

> > +SPICE_GNUC_VISIBLE
> > +void spice_qxl_monitor_set_device_display_id(QXLInstance *instance,
> > +                                             uint32_t monitor_id,
> > +                                             uint32_t device_display_id)
> 
> I still don't understand why, as suggested by Gerd, we need another function
> instead of 2 additional parameters to the above API specifying start and
> number, this API looks much more prone to errors.

We can also just add a device_display_id parameter to the other
function, that should work too.

> Also there's no much documentation for this "device display ID" in the code,
> potentially can be generated with something like:

It's the head index, starting at zero.

cheers,
  Gerd




reply via email to

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