On Thu, Apr 23, 2009 at 02:41:25PM +0200, Pritesh Kothari wrote: > 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 mean in terms of how this is exposed to an end user. VNC provides interaction for video, keyboard & mouse. SDL provides interaction for video, keyboard, mouse & audio RDP is similar. There are still the explict config sections for how video, mouse, sounds, etc are exposed to the guest OS. > > 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? We'd have both - the <video> tag explicitly for things related to the video adapter device. The <graphics> tag for the host side I/O layer config, be it VNC, RDP or SDL. > in any case how about adding "multihead" and "3Daccel" to it and renaming ram to vram, something like this: > > <video> > <model type='cirrus' vram='500' multihead='2' 3Daccel='yes'/> > </video> Sure, vram seems fine. I think i'd call multihead 'monitors' or 'heads'. Isn't 3D support implied by the type of graphics card emulated ? eg cirrus is a 2d only card, so it seems like 3Daccel is redundant. Similarly if the graphics model were a 3d card. > > > 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. > > Regards > Pritesh -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list