From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Smirl Subject: Re: fixing fbdev for various framebuffer configs Date: Fri, 29 Jul 2005 09:39:41 -0400 Message-ID: <9e47339105072906397941b8e0@mail.gmail.com> References: <9e473391050729035370d76cc5@mail.gmail.com> <42EA16A4.2050709@gmail.com> <9e47339105072904523afe0b9f@mail.gmail.com> <42EA2FDB.8030400@gmail.com> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1DyV5Y-0007MO-DB for linux-fbdev-devel@lists.sourceforge.net; Fri, 29 Jul 2005 06:39:48 -0700 Received: from wproxy.gmail.com ([64.233.184.205]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1DyV5Y-0000DJ-72 for linux-fbdev-devel@lists.sourceforge.net; Fri, 29 Jul 2005 06:39:48 -0700 Received: by wproxy.gmail.com with SMTP id 36so606045wra for ; Fri, 29 Jul 2005 06:39:42 -0700 (PDT) In-Reply-To: <42EA2FDB.8030400@gmail.com> Content-Disposition: inline Sender: linux-fbdev-devel-admin@lists.sourceforge.net 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: "Antonino A. Daplas" Cc: linux-fbdev-devel@lists.sourceforge.net, "Antonino A. Daplas" , James Simmons On 7/29/05, Antonino A. Daplas wrote: > Geert Uytterhoeven wrote: > > On Fri, 29 Jul 2005, Jon Smirl wrote: > >> On 7/29/05, Antonino A. Daplas wrote: > >>> Jon Smirl wrote: > >>>> It has been determined that bits per pixel is insuffucient to > >>>> enumerate all the needed fbconfigs. Here are the possible fgconfigs > >>>> from the OpenGL headers: > >>>> > >>>> total bits > >>>> 8 GL_R3_G3_B2 > >>>> 8 GL_RGBA2 > >>>> 12 GL_RGB4 > >>>> 15 GL_RGB5 > >>>> 16 GL_R5_G6_B5 > >>>> 16 GL_RGBA4 > >>>> 16 GL_RGB5_A1 > >>>> 24 GL_RGB8 > >>>> 30 GL_RGB10 > >>>> 32 GL_RGBA8 > >>>> 32 GL_RGB10_A2 > >>>> 36 GL_RGB12 > >>>> 48 GL_RGB16 > >>>> 48 GL_RGBA12 > >>>> 48 GL_FLOAT_RGB16 > >>>> 64 GL_RGBA16 > >>>> 64 GL_FLOAT_RGBA16 > >>>> 96 GL_FLOAT_RGB32 > >>>> 128 GL_FLOAT_RGBA32 > >>>> > >>>> We need to be able to set any of these through the fbdev interface. = We > >>>> also need to allow for possible future expansion. > >>> To set for example, RGBA16, set {transp|green|red|blue}.len to 16, th= e > >>> offsets to 0, 16, 32, 48, and bits_per_pixel to 64. Then let the dri= ver > >>> sort it out. I don't know what we can do about the FLOAT formats... > >>> > >>>> Ideas on how to adjust the fbdev interface? > >>> Well, no need to adjust the interface. But it is limited though to > >>> 16 bits per channel. Redefining them to 32 will break a lot of apps. > > > > It's only the colormap entries that are limited to 16 bits per color co= mponent, > > right? The color components in pixel values can be much larger (up to 2= ^31 bits > > :-). >=20 > Yes, but struct fb_cmap has entries of u16 and this is used by struct > fb_var_screeninfo and by the cmap functions. fb_setcolreg is also passed > with u16 values. ioctls affected will be FBIO{GET|PUT}_VSCREENINFO , > FBIO{GET|PUT}CMAP, all used in userspace. I was going to leave the IOCTL interface alone and only adjust the internal data structures. The IOCTL data would convert to the new internal buffers inside of fbdev. The more advanced fbconfigs would only be accessible from the sysfs interface. No one is going to build 32bit cmaps anytime soon, you need gigabytes of memory to do it. I think we are fine right now with 16b cmap entries. > >> My current idea is to get rid of the bit_per_pixel attribute and > >> replace it with config. Config would take strings like 8,8,8 or > >> 5,5,5,1 or 32.,32.,32. > > > > That's not acceptable. How do you differentiate between RGB888 (without= alpha) > > using 24 or 32 bits per pixel? > > > > Or more general, what with hardware that has unused bits in its pixel v= alues, > > e.g. hardware that has 8 bits per pixel but uses only 1 bit per byte in > > monochrome mode and 4 bits in 16-color mode? >=20 > Agree, >=20 > Tony >=20 --=20 Jon Smirl jonsmirl@gmail.com ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf