[Spice-devel] [RFC PATCH v2 00/20] Monitor ID rework

[Gerd Hoffmann]

> struct {
>   ...
>   uint8_t channel_id:4;
>   uint8_t monitor_id:4;
>   ...
> };
> 
> at this point however both the client and server have to be changed,

Server side yes, because it assigns the numbers.
Why the client side too?

> this new schema is just introducing a limitation (16 channels and 16
> monitors) which you won't have using 2 different fields.

IIRC the 16 monitors limit is there anyway somewhere in spice.
The 16 display channels limit is new indeed.

> > Maybe it is better to make the size of the gaps depend on the number of
> > monitors a channel has, i.e. if channel 0 is a qxl device with up to
> > four outputs configured we skip channels 1+2+3 and the next display
> > device gets channel 4.  We don't have holes in the display numbering
> > then.
> 
> However you don't know the number of monitors (client) till you
> receive a specific message so at the beginning you don't know
> the information you need (on the client) and to fix this you would
> have to change the protocol to send it earlier.

On the server side you know how many outputs a given device can have.
To be exact qemu knows and would need to tell spice-server about it.
(it's the qxl.max_outputs property).  spice-server can then enumerate
the channels accordingly then.

So when the client asks the server for the list of channels the server
would (assuming two qxl devices with two outputs each) return this ...

  display channel 0
  display channel 2
  input channel 0
  sound channel 0
  [ ... ]

... instead of ...

  display channel 0
  display channel 1
  [ ... ]

... and I hope clients can cope without modification even though there
is no "display channel 1".

> > Well, I hope it *does* save us the compatibility trouble, that is the
> > whole point.  If if doesn't work out because there assumtions in the
> > code base about the way channels are numbered, then scratch the idea.
> 
> No, there are not assumption on channel numbering. But there are on
> the channel/monitor combination.

Yes.  Today you can have either multiple channels with one monitor each
or one channel with multiple monitors.

We also want multiple channels with multiple monitors.

I think the setups which are working today will continue working without
client side modifications.  To make multiple channels with multiple
monitors work we probably need client side changes too.

cheers,
  Gerd