From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPJ0-0001Te-0J for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:11:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TBPIq-0006MO-D3 for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:11:01 -0400 Received: from mx3-phx2.redhat.com ([209.132.183.24]:53980) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TBPIq-0006MF-4e for qemu-devel@nongnu.org; Tue, 11 Sep 2012 08:10:52 -0400 Date: Tue, 11 Sep 2012 08:10:51 -0400 (EDT) From: Alon Levy Message-ID: <1236865820.33057578.1347365451501.JavaMail.root@redhat.com> In-Reply-To: <1325808533.33053564.1347365025414.JavaMail.root@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] hw/qxl: support client monitor configuration via device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: qemu-devel@nongnu.org, Gerd Hoffmann > > 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 > > > > > >