All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] Virtual frame buffer
@ 2006-06-26 13:38 Markus Armbruster
  2006-06-26 13:39 ` [PATCH 1/2] Virtual frame buffer: frontend Markus Armbruster
                   ` (2 more replies)
  0 siblings, 3 replies; 34+ messages in thread
From: Markus Armbruster @ 2006-06-26 13:38 UTC (permalink / raw)
  To: xen-devel

I ported Anthony Liguori's virtual frame buffer to current kernels and
converted it to use Xenstore.

Here's a brief sketch of how it works.
http://wiki.xensource.com/xenwiki/VirtualFramebuffer has more detail,
and also also outlines future work, but the stuff on startup there no
longer applies.

The VFB's architecture is comparable to the common split device driver
architecture: xenfb and xenkbd modules serve as frontend in domU, and
the user space vncfb server serves as backend in dom0.

xenfb and xenkbd don't use the Xenbus infrastructure for frontends,
because it doesn't quite fit.  They publish their shared memory page
and event channel in Xenstore entries
{vfb,vkbd}/{page-ref,event-channel}.

As usual, the shared memory page contains information about the
device, input event ring and output event ring.

xenkbd defines pointer motion events, button events and keyboard
events.  xenfb defines events to optionally signal frame buffer page
updates.

vncfb runs in dom0.  It takes the domain to watch as argument.  It
then watches /local/domain/DOMID/{vfb,vkbd} until everything it needs
is there.  It maps the shared memory and connects the event channels.
Use of event ring and event channel follows the common patterns.

xenfb actually shares more memory than just a page.  It also shares
the frame buffer itself.  The page shared through Xenstore has enough
information so that vncfb can map the frame buffer as well.

^ permalink raw reply	[flat|nested] 34+ messages in thread
* RE: Re: [PATCH 2/2] Virtual frame buffer: user space backend
@ 2006-07-07 19:56 Ian Pratt
  0 siblings, 0 replies; 34+ messages in thread
From: Ian Pratt @ 2006-07-07 19:56 UTC (permalink / raw)
  To: Anthony Liguori, xen-devel

> On Fri, 07 Jul 2006 17:57:52 +0100, Christian Limpach wrote:
> 
> > On 6/26/06, Markus Armbruster <armbru@redhat.com> wrote:
> >> Straightforward conversion to Xenstore.
> >>
> >> Applies to hg repository at http://hg.codemonkey.ws/vncfb
> >
> > Ideally, we'd move qemu's vnc support into a library to make it
reusable.
> 
> I had considered this.  It's a little awkward since b/c of the
dependence
> on QEMU's async IO routines but it wouldn't be that bad.
> 
> At this point, it probably makes most sense to communicate the linear
> offsets within the framebuffer that are dirty instead of computing a
rect.
>  Since the QEMU VNC code already does rectangle finding and maintains
>  dirty tile bitmap, we don't really have to attempt to find the rect
in
> the frontend at all.

The generic interface I'd opt for would be to round up the framebuffer's
size in each direction to the next power of 2, then divide the region
into 32 tiles by 32 i.e. for a 1280x1024 the size of each tile would be
64x32. 

Just using page-level protection to find the updated area in the
frontend we'll be setting runs of bits, but for e.g. a smart Xserver the
2D nature of the bitmap should enable us to do better.

Ian

^ permalink raw reply	[flat|nested] 34+ messages in thread
* RE: Re: [PATCH 2/2] Virtual frame buffer: user space backend
@ 2006-07-09  0:22 Ian Pratt
  0 siblings, 0 replies; 34+ messages in thread
From: Ian Pratt @ 2006-07-09  0:22 UTC (permalink / raw)
  To: Anthony Liguori, xen-devel

> > Well, I don't agree ;-)  Because we want to transport 2D redraw
> > information from the frontend to the backend.
> 
> So 2D information is very useful, especially for VNC.  I think for Xen
> though, we may need to abandon the shared framebuffer completely and
> develop a lightweight framebuffer protocol.
> 
> The idea would be to push the dirty'ing analysis to the frontend and
have
> it communicate data over a higher bandwidth ring queue.  This avoids
> having to deal with synchronizing the shared framebuffer for 2d ops.
> 
> This is quite a bit different from the code today though.
> 
> What do you think about getting rid of the shared framebuffer
altogether?

The shared framebuffer approach has the advantage that its very easy to
render locally (e.g. SDL), and allows the front and backends to be quite
decoupled.

I've thought about having a generic byte stream front/backend transport
and using something very VNC-like over it, but it would make the
frontend driver rather more complex (we'd need to implement one
in-kernel, and one for X). The front end would still need to have a
private framebuffer, and the communication area between front and
backend would likely need to be fairly big to avoid overrun (which would
result in a full screen resend). 

Anyhow, I really don't think its worth getting too hung up optimizing 2D
graphics performance. We need to make sure that the VNC commands that go
on the wire have the fill/copyrect optimizations, but deriving that
information in the backend isn't too expensive (with hints from the
front end).


Ian

 

^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2006-08-04  8:34 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-26 13:38 [PATCH 0/2] Virtual frame buffer Markus Armbruster
2006-06-26 13:39 ` [PATCH 1/2] Virtual frame buffer: frontend Markus Armbruster
2006-07-07  7:18   ` Markus Armbruster
2006-07-07 16:45   ` Christian Limpach
2006-07-10  7:37     ` Markus Armbruster
2006-07-10 10:57       ` Christian Limpach
2006-07-10 18:29     ` Markus Armbruster
2006-07-26 20:28       ` Christian Limpach
2006-07-27  5:11         ` Markus Armbruster
2006-07-27  7:26           ` Gerd Hoffmann
2006-08-04  8:00           ` Markus Armbruster
2006-08-04  8:34             ` Christian Limpach
2006-07-28 13:52   ` Laurent Vivier
2006-08-04  7:54     ` Markus Armbruster
2006-06-26 13:40 ` [PATCH 2/2] Virtual frame buffer: user space backend Markus Armbruster
2006-07-07  7:18   ` Markus Armbruster
2006-07-28 15:55     ` Laurent Vivier
2006-08-04  7:57       ` Markus Armbruster
2006-07-07 16:57   ` Christian Limpach
2006-07-07 17:31     ` Anthony Liguori
2006-07-07 18:33       ` Christian Limpach
2006-07-07 18:50         ` Anthony Liguori
2006-07-07 22:50           ` Christian Limpach
2006-07-07 23:05             ` Anthony Liguori
2006-07-08  1:10               ` Christian Limpach
2006-07-08  1:49                 ` Anthony Liguori
2006-07-08 10:20                   ` Christian Limpach
2006-07-08  0:35             ` Rik van Riel
2006-07-08  1:38               ` Christian Limpach
2006-07-10  7:37     ` Markus Armbruster
2006-07-10 18:29     ` Markus Armbruster
2006-07-07  7:17 ` [PATCH 0/2] Virtual frame buffer Markus Armbruster
  -- strict thread matches above, loose matches on Subject: below --
2006-07-07 19:56 Re: [PATCH 2/2] Virtual frame buffer: user space backend Ian Pratt
2006-07-09  0:22 Ian Pratt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.