>
> > 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
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel