From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Byrne Subject: Re: [RFC] Xen Virtual Framebuffer Date: Tue, 06 Dec 2005 12:41:38 -0800 Message-ID: <4395F782.2070608@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: xen-devel List-Id: xen-devel@lists.xenproject.org > 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