[libvirt] [PATCH 1/1] Support for RDP

Pritesh Kothari Pritesh.Kothari at Sun.COM
Thu Apr 23 12:41:25 UTC 2009

Hi Daniel,

> We don't currently have any explicit representation of a video card
> device. The <graphics> tag is really representing the host I/O
> layer, covering video, mouse, keyboard (and potentially audio
> too).

I didn't get you here? i mean there is a seperate virDomainSoundDefPtr, virDomainInputDefPtr, etc?

> I think we need to add an explicit tag to represent video devices
> real soon. At very least we need to be able to indicate the type
> of video card - QEMU supports 4 already vga, cirrus, vmwarevga
> and xenfb. We probably also need to be able to indicate whether
> a video card supports multiple monitors / outputs, and the amont
> of Video RAM, etc.
> One random idea would be to add
>    <video>
>       <model type='cirrus' ram='500'/>
>    </video>

does it means the graphics tag is no more and is replaced with video tag? or video tag is added in addition to graphics tag?

in any case how about adding "multihead" and "3Daccel" to it and renaming ram to vram, something like this:

       <model type='cirrus' vram='500' multihead='2' 3Daccel='yes'/>

> I've not looked at this in huge detail yet. I'm wondering whether we need
> to expose it or not ? Is it something that's commonly used, or neccessary
> to configure per VM ?   For QEMU and Xen, the VNC auth type is jsut
> configured per-host in the global Xen or libvirt QEMU config file for the
> host. So we don't bother to expose it in the XML
> One idea might we to make the auth stuff a child element of '<graphics>'
> so we don't start adding huge numbers of attributes to the main elemnt

Yes it per VM feature and generally exposed by any RDP server, so not specific to VirtualBox, but a general case. i think the earlier mail give details of it.

regarding the child element it is ok to have it as child element.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090423/d04c6dc7/attachment-0001.htm>

More information about the libvir-list mailing list