Andreas Färber <[email protected]> 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. >> >> 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". >> >> 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 > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
