RE: [Xen-devel] virtualGraphicCards

["Retzki, Sascha [Xplain]" <sascha.retzki@xxxxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Daniel Hulme
> Sent: Wednesday, September 07, 2005 12:07 PM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] virtualGraphicCards
> 
> > I'd love to see this on Xen, I'd love to work on this, but I am
> > "unskilled" ;-), so it is a bit hard for me at the moment. Anyway,
any
> > help, brainstorming, code, is highly appreciated.
> So would I, but even for "skilled" people it is a bit hard. This is
> already on http://wiki.xensource.com/xenwiki/XenTodoList but the list
is
> quite long and it is not high-priority. Of course, the more people
want
> it, the sooner it will get done.


You mean
"Graphic console support - post 3.0"
?
I don't quiet get:
1 kernel fb mapping? or X server?

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