WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: mark.williamson@xxxxxxxxxxxx
Subject: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Mon, 05 Dec 2005 19:19:01 -0600
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 06 Dec 2005 01:19:33 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <Prayer.1.0.16.0512060050260.15311@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4394C683.1070000@xxxxxxxxxx> <Prayer.1.0.16.0512060050260.15311@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
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