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

[Frediano Ziglio]

> 
> > 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?
> 

The display_id is crafted by the client using channel ID and monitor ID
which are sent by the server. So the formula is on the client (and used
also in spice-gtk interface) however is also sent to server using
mouse messages and monitor configs (which both are used by server and
agent).

> > 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.
> 

I don't think solving assumptions and limit with other assumptions and
limits is a great plan. Don't confuse protocol limits with implementation
limits. I surely remember there's currently a 256 total monitors limit
in the implementation.

> > > 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.
> 

But the display_id is crafted by the client, not the server.

> 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".
> 

Hope so, we would need to test.

> > > 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
> 

Frediano