From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: Re: More virtio users Date: Tue, 12 Jun 2007 09:19:43 +1000 Message-ID: <1181603983.16428.100.camel@localhost.localdomain> References: <466BA965.6050208@qumranet.com> <1181463220.16428.24.camel@localhost.localdomain> <466D04C2.8010403@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: kvm-devel , Benjamin Herrenschmidt , xen-devel , Avi Kivity , virtualization To: Gerd Hoffmann Return-path: In-Reply-To: <466D04C2.8010403@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com List-Id: kvm.vger.kernel.org On Mon, 2007-06-11 at 10:16 +0200, Gerd Hoffmann wrote: > Hi, > > > Framebuffer is an interesting one. Virtio doesn't assume shared memory, > > so naively the fb you would just send outbufs describing changed memory. > > This would work, but describing rectangles is better. A helper might be > > the right approach here > > Rectangles work just fine for a framebuffer console. They stop working > once you plan to run any graphical stuff such as an X-Server on top of > the framebuffer. Only way to get notified about changes is page faults, > i.e. 4k granularity on the linear framebuffer memory. Yes, I discussed this with Ben Herrenschmidt a couple of months ago. It would be better to provide a fb ioctl which X could use to describe changed rectangles if available. In the virtio case we could hand that information through, and other virtualized framebuffers would be able to use it similarly. Cheers, Rusty.