[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.