Re: [Xen-devel] [RFC] Xen Virtual Framebuffer

[Anthony Liguori <aliguori@xxxxxxxxxx>]

M.A. Williamson wrote:

> Wow!  That was fast work ;-)
Linux rocks :-)  The fb driver infrastructure is really easy to work with.

> Sounds like really good stuff. Is there any chance of a couple of 
> screenshots?
Yeah, I can post some (I'll link on the wiki page) tomorrow as I forgot 
to re-enable VNC on my dev machine so I have to wait to head back in the 
office.  It looks a lot like VT or Qemu right now as you can imagine :-)
> Have you had a chance to check out comparable X.org drivers? How hairy 
> are they to put together? I agree it seems nicest (in terms of 
> compatibility with Xen-unaware X servers) to use a kernel-based 
> framebuffer as a basis for things (as opposed to having X talk to the 
> virtual display directly). It also allows us automagic compatibility 
> with toolkits and apps that can render to the framebuffer directly.
What's nice is that the fbdev device maps the memory directly to 
userspace, so you don't take a hit at all by going through the kernel 
interface.  My current line of thinking is to use an fb device with 
special device-specific ioctls for the couple non-standard accelerations 
we could implement.
The X.org code doesn't look so bad.  Interestingly, VMware has a driver 
in the X.org tree so I don't think we'll have a problem just working 
with those guys to get our own driver :-)
> Side note: it'd be really nice to be able to have an option to export 
> the guest framebuffer display over VNC using libvncserver. The intent 
> would be to allow management software on another node to access domain 
> consoles, without needing the domain to mess about running VNC (or 
> indeed, having a working network setup). I'm sure you've thought of 
> that, though ;-)
Absolutely.  libvncserver is not a pleasant library but a reasonable 
place to start.  We really need to implement a few accelerations first 
before VNC is a reasonable option (at least copyrect) since otherwise 
we'll have to do a lot of computation to figure out what portions of the 
screen have changed.
> Other side note: it'd be really neat to be able to support 
> copy-and-paste operations from text mode consoles to other windows in 
> dom0. Does the kernel have hooks in the right places to make this 
> workable?
I'm not sure.  I think there may be some clever approachs to it.  If 
nothing else, some patches to gpm could achieve the desired effect.  
copy/paste would be an awesome feature to have so I'm definitely 
interested in making it work.
The same is true for drag and drop :-)  There are a lot of cool things 
we can do...
Regards,

Anthony Liguori

> Cheers,
> Mark
>
> On Dec 5 2005, Anthony Liguori wrote:
>
> > 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
> >
> > _______________________________________________
> > 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