> > Hi, > > > > Sorry for top posting, but trying to summarize this thread here. > > > > I must say I like Gerd's approach, as it unifies code paths mostly, > > instead of having yet another interface where we do 2 way > > capabilities > > negotiation, with all the extra test matrix entries that would > > entice > > for full testing, we keep things simple. > > So you are suggesting to send the message to both parties, and ignore > it in the guest agent if it sees a qxl device. s/device/drm device file/ - this is linux specific right now, for windows guests we would check for something else presumably (not interesting right now).
> That's the only way > this works, since otherwise you need a handshake between spice and > qxl: > > server > (1) receive VDAgentMonitorsConfig config > (2) call qxl->client_monitors_config > (3) wait for qxl->client_monitors_config_not_acked <-- after timeout? > when do we decide interrupt wasn't cleared due to guest not > supporting it, or due to not enough time having passed? > (4a) if timeout, send VDAgentMonitorsConfig to agent > (4b) else done > > > > > So we would have: > > 1) monitor config in rom space > > 2) QXL_INTERRUPT_CLIENT_MONITORS_CONFIG to tell the guest it is > > updated > > 3) Some way to avoid a new monitor config arriving and the guest > > being > > busy reading the previous race. > > 4) The server will always update the monitor config in rom space > > 5) If the guest has not requested > > QXL_INTERRUPT_CLIENT_MONITORS_CONFIG > > and there is an agent the server will send the monitor info to > > the > > agent > > > > Note an alternative to the handshake suggested is simply adding a > > crc > > to the monitor config block. If that fails we hit the the (rare) > > race > > and > > the guest re-reads it. > > > > Regards, > > > > Hans > > > > > >
