From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Antonino A. Daplas" Subject: Re: [RFC] Does fbdev need a cursor API for userland? Date: Tue, 19 Oct 2004 04:56:31 +0800 Sender: linux-fbdev-devel-admin@lists.sourceforge.net Message-ID: <200410190456.32643.adaplas@hotpop.com> References: <200410172347.15516.adaplas@hotpop.com> <200410181905.56602.adaplas@hotpop.com> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1CJeSW-0005q6-0r for linux-fbdev-devel@lists.sourceforge.net; Mon, 18 Oct 2004 13:50:24 -0700 Received: from smtp-out.hotpop.com ([38.113.3.71]) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.41) id 1CJeSV-0000VU-G7 for linux-fbdev-devel@lists.sourceforge.net; Mon, 18 Oct 2004 13:50:23 -0700 Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id D9A2411605C7 for ; Mon, 18 Oct 2004 20:50:09 +0000 (UTC) In-Reply-To: Content-Disposition: inline Errors-To: linux-fbdev-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Geert Uytterhoeven , adaplas@pol.net Cc: Linux Frame Buffer Device Development , Jon Smirl On Monday 18 October 2004 20:01, Geert Uytterhoeven wrote: > On Mon, 18 Oct 2004, Antonino A. Daplas wrote: > > On Monday 18 October 2004 17:35, Geert Uytterhoeven wrote: > > > On Mon, 18 Oct 2004, Antonino A. Daplas wrote: > > > > The restore_fb_contents/save_fb_contents cannot be done generically. > > > > Not all framebuffers have a linear format, there are some that are > > > > planar such as amifb and vga16fb. This means that we need to add > > > > per-driver hooks just to save and restore the framebuffer contents. > > > > > > Can't we use fb_imageblit() for restore? > > > > fb_imageblit() is limited because it uses the pseudo_palette. Even if > > we expand the palette to 256 entries, it won't be able to handle formats > > > 8bpp. More than 256 is not practical. Plus, fb_imageblit is limited to > > 1->bpp, and 8->bpp expansion. > > What about expanding fb_imageblit() to handle 32-bit ARGB as well? Then it > can handle most canonical formats (1 bpp monochrome, 8-bit CLUT, 32-bit Meaning, fb_imageblit needs to do 32-bit ARGB to native fb format conversion on the fly. How can we do that generically without fb_imageblit knowing the format of the framebuffer? For example, how do we convert 32-bit ARGB to 8-bit Pseudocolor? Isn't it much simpler to just have a set_image() where the source block is in the same format as the framebuffer so it doesn't have to do format conversions? Tony ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl