| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
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
|
|
|
| |
|
Home