From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC] Xen Virtual Framebuffer Date: Mon, 05 Dec 2005 19:19:01 -0600 Message-ID: <4394E705.2000208@us.ibm.com> References: <4394C683.1070000@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: mark.williamson@cl.cam.ac.uk Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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 >> >