Re: [RFC] Xen Virtual Framebuffer

[John Byrne <john.l.byrne@hp.com>]

> Now that's 3.0.0's out, I thought it would be a good time to bring up 
> the topic of framebuffer virtualization.
> 
> I threw together a proof-of-concept over the weekend of a simple virtual 
> framebuffer/keyboard/mouse.  The basic design is have a vmalloc()'d 
> buffer in the guest exposed as /dev/fb0 and mmap()'d in dom0.  There's 
> also a simple message system for keyboard/mouse events.
> 
> The first frontend is a GTK widget with python bindings (so it can 
> easily be embedded in a larger management app) and a small python app.  
> Right now, the VT system seems to work fine and X starts quite happily 
> (using the fbdev driver).  Clicking in the app captures the 
> mouse/keyboard and ctrl+alt will release the capture.
> 
> There's a readme and an hg bundle in the tarball below that explains how 
> to set things up.
> 
> Some interesting topics in this area are acceleration, whether we should 
> implement our own X driver (or just enhance the fbdev driver since it 
> uses no acceleration right now), and how to properly expose it over 
> something like VNC.
> 
> As always, feedback is greatly appreciated.
> 
> http://www.cs.utexas.edu/users/aliguori/xen-vfb-20051205.tar.gz
> 
> Regards,
> 
> Anthony Liguori
> 

Anthony,

Looking at Xen from the perspective of managing a farm of machines, what 
I want is a single method for remotely accessing the console/graphics 
for a guest domain, regardless of whether the domain is PV/VT. (A method 
of connect a VNC client to dom0 port 5900 + domid would be just fine. 
[From the code, this seems to be way qemu does it for VNC.]) The current 
model of "xm console" and Xvnc for PV domains is annoying. Unless, I am 
misunderstanding what you are doing, once you add the VNC support, your 
work provides what I want.

So, what are the prospects of getting it finished and in, in the near 
future? Is there any chance of getting it into the 3.0.x code base?

Thanks,

John Byrne