[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: Re: [PATCH 2/2] Virtual frame buffer: user space backend


  • To: "Anthony Liguori" <anthony@xxxxxxxxxxxxx>
  • From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
  • Date: Fri, 7 Jul 2006 23:50:32 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 07 Jul 2006 15:50:56 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ADfbfQlbmwDr545jfPJi+5Bv6hbaZZfQr/qSog6VBotM7AS/yj4sGBEswUNmKRTVfr435bi47cj+E/MQBL21MCzT265V9yS7jM9icVbQINMQDowcrsQLTprKAPYkMyG4p+Ey0tDR8M6gd04+2yVkTYBXQTYstNN+nOYQwuslI1M=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 7/7/06, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
Since the best we can do is page granularity (for now), why not just have
a bitmap represent the dirty pages?

Doesn't your virtual framebuffer already support 2d operations?  Also,
the cirrus driver emulation in qemu already supports copyrect.

Instead of switching bitmaps, why not
just have the backend and frontend share a bitmap and do atomic get/sets
on it?

Because we'd like to avoid atomic operations.

I think the key point is to have the bitmap represent linear regions of
framebuffer memory instead of logical rectangles within the current
resolution.

Well, I don't agree ;-)  Because we want to transport 2D redraw
information from the frontend to the backend.

    christian

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.