From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIKCA-0008Hb-FC for qemu-devel@nongnu.org; Wed, 20 Mar 2013 10:40:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIKC5-0003qq-6r for qemu-devel@nongnu.org; Wed, 20 Mar 2013 10:40:50 -0400 Received: from mail-pb0-f43.google.com ([209.85.160.43]:49825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIKC4-0003qg-Me for qemu-devel@nongnu.org; Wed, 20 Mar 2013 10:40:45 -0400 Received: by mail-pb0-f43.google.com with SMTP id md12so1412218pbc.2 for ; Wed, 20 Mar 2013 07:40:43 -0700 (PDT) From: Anthony Liguori In-Reply-To: <5149BBFD.5050300@suse.de> References: <51498793.2000209@redhat.com> <5149BBFD.5050300@suse.de> Date: Wed, 20 Mar 2013 09:40:38 -0500 Message-ID: <87ppyuf82h.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] QOM-ify QemuConsoles ... List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= , Gerd Hoffmann Cc: "qemu-devel@nongnu.org" , Stefan Berger Andreas F=C3=A4rber writes: > Hi Gerd, > > Am 20.03.2013 10:55, schrieb Gerd Hoffmann: >> I think the next logical step ahead is to QOM-ify the QemuConsoles, so >> we can link the QemuConsole to the thing actually backing it. For a >> graphical console that would be the emlated graphic device. For a text >> console it would be the serial line or monitor hooked up to it. >>=20 >> With this in place we should be able to answer questions like "which >> device backs this QemuConsole" by inspecting the object tree and handle >> requests like "do a screendump of this device please". It will also be >> useful to setup input routing: "pointer events from $this QemuConsole >> should to $that virtual input device". >>=20 >> Hints how to do that best? Pointers to sample code to look at? From a >> brief look it seems we only QOM-ified emulated devices and not host-side >> objects yet ... > > You could look at virtio-rng. TPM doesn't use QOM yet AFAIR. I think the first step is to figure out what the relationships are. I was looking through the changes and vaguely, it appears that its: - Each UI has one or more DisplayChangeListeners - Each DisplayChangeListener can be mapped to 1 or more QemuConsoles - Each QemuConsole can then be mapped to some thing that's drawing. So DisplayChangeListener is basically a QemuConsole multiplexer. If we are keeping this basic design, then I think it's just a matter of converting DisplayChangeListener to a QOM object, QemuConsole to QOM object, then finally each UI. Then you can select via links what QemuConsoles map to each DCL. Regards, Anthony Liguori > > Cheers, > Andreas > > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3= =BCrnberg