[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] virtualGraphicCards
> You mean > "Graphic console support - post 3.0" > ? > I don't quiet get: > 1 kernel fb mapping? or X server? The idea is that the graphical console will have "back/front" structure similar to the other devices, with a viewer in dom0 reading screen data from the guest and either displaying it, or exporting it over the network. The question here is: do we write a kernel framebuffer driver for this (and get the X server to use that) or implement it in the X server directly? I think the former solution is probably going to have the best cost/benefit. One thing that's important (IMHO) is not to require networking in order to get the virtual display - makes it easier to install, configure stuff, etc via a graphical interface. Cheers, Mark > Do you mean how the virtual graphics card is "seen" by the dom0? Or/And > accessed? > > Imho, a glue-layer could abstract several approaches, for example 9P > (the Plan9-folks love it, I did not have the time to test it and thus I > don't have an opinion yet. However, I believe it is good ;-)) and VNC, > and the dom0 decides itsself howto access the "data" - this would be > pretty good because some OSes (which may be dom0-cabable some day) may > find method-N better (are optimized for it) than method-M... and so on > ;-) > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |