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: Gerd Knorr <kraxel@xxxxxxx>
Subject: Re: [Xen-devel] [RFC] Xen Virtual Framebuffer
From: Jon Smirl <jonsmirl@xxxxxxxxx>
Date: Fri, 16 Dec 2005 11:16:45 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 16 Dec 2005 16:18:51 +0000
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IfDLUzbndrA84q02OzrYgSCCl91CnIKih4JQSpC3etsJjMMoEAV7cek+yL6RgBi6QNnmlXcY0Z69cykHq63tqWg3bNLX15L24NMiBiGYuGzTIwNi41C/eVlMZyh6t/HLbWG+1oNRNZLOwY5nazoYm9lygxeKxM5vqsnLnwB73xM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43A2A2E9.1060308@xxxxxxx>
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> <43A2A2E9.1060308@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 12/16/05, Gerd Knorr <kraxel@xxxxxxx> wrote:
> 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.
>
> Browsed through the code, looked at the wiki page now ...
>
> First, I've hacked up something very simliar for user-mode-linux,
> patches are at http://www.suse.de/~kraxel/uml/patches/2.6.15-rc5/, you
> might want to have a look and steel some ideas (unless you already did).
> Note that the input system got some sysfs-related changes recently, so
> the patches really work on very latest kernels only.
>
> Some more comments:
>
>   * why do you put the mfn and evtchn into the start page?  IMHO that
>     should be handled by xenstore, like it is done for virtual network
>     and disk.
>
>   * I would create two different input devices for mouse/keyboard
>     (although strictly seen it isn't really needed) to avoid confusing
>     userspace apps.

Another strategy for input would be to use USB input devices and the
USB over IP stack (or Xen USB support) to shift the devices between
domains.

Installing multiple keyboards, USB audio devices, mice and multiple
video cards is one way to achieve multiuser computing.

>
>   * I would simply reuse the input event struct from
>     include/linux/input.h for dom0 -> domU input event delivery
>     instead of creating something new.
>
>   * i18n keyboard is really tricky (that is a huge mess in vmx btw).
>     I think the only sane approach is to let the guest (domU) do
>     all the i18n handling and try to avoid doing any key mapping
>     in the host (dom0).  If you have *two* instances (both host
>     and guest) doing keyboard mapping and both not even knowing
>     what the other one is doing you have absolutely no chance to
>     get it right ...
>
> Keeping track of the in-kernel screen changes (fbcon) is easy, tracking
> userspace is more difficuilt but doable, the uml framebuffer driver does
> that by watching page faults: The no_page handler maps the page and
> marks it "dirty", the update function does zap_pte_range to kill the
> mappings so the no_page handler is called on the next update again.
>
> cheers,
>    Gerd
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>


--
Jon Smirl
jonsmirl@xxxxxxxxx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel