Re: [RFC] Xen Virtual Framebuffer

[Anthony Liguori <aliguori@us.ibm.com>]

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@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>