fixing fbdev for various framebuffer configs

fixing fbdev for various framebuffer configs

[Jon Smirl]

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.

Ideas on how to adjust the fbdev interface?

What is the effect of alpha bits on the scanout buffer, do they do anything?

-- 
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

Re: fixing fbdev for various framebuffer configs

[Geert Uytterhoeven]

On Fri, 29 Jul 2005, 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
> 64   GL_RGBA16

All above (and many more) can be handled fine, cfr.
fb_var_screeninfo.{red,green,blue,transp}.

> 48   GL_FLOAT_RGB16
> 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.
> 
> Ideas on how to adjust the fbdev interface?

Floating point pixel values could be handled by a new nonstd flag:

    #define FB_NONSTD_FLOAT	2
    fb_var_screeninfo.nonstd |= FB_NONSTD_FLOAT

> What is the effect of alpha bits on the scanout buffer, do they do anything?

They determine the transparency of the pixel w.r.t. to the underlying plane, if
the hardware supports it.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
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

Re: fixing fbdev for various framebuffer configs

[Jon Smirl]

On 7/29/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, 29 Jul 2005, 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
> > 64   GL_RGBA16
> 
> All above (and many more) can be handled fine, cfr.
> fb_var_screeninfo.{red,green,blue,transp}.
> 
> > 48   GL_FLOAT_RGB16
> > 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.
> >
> > Ideas on how to adjust the fbdev interface?
> 
> Floating point pixel values could be handled by a new nonstd flag:

Why non-standard? All of the current higher end ATI/Nvidia cards support it.

> 
>     #define FB_NONSTD_FLOAT     2
>     fb_var_screeninfo.nonstd |= FB_NONSTD_FLOAT
> 
> > What is the effect of alpha bits on the scanout buffer, do they do anything?
> 
> They determine the transparency of the pixel w.r.t. to the underlying plane, if
> the hardware supports it.
> 
> Gr{oetje,eeting}s,
> 
>                                                 Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                                             -- Linus Torvalds
> 


-- 
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

Re: fixing fbdev for various framebuffer configs

[Antonino A. Daplas]

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, the
offsets to 0, 16, 32, 48, and bits_per_pixel to 64.  Then let the driver
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.

> 
> What is the effect of alpha bits on the scanout buffer, do they do anything?
> 

I think if there is another layer such as an overlay, the alpha bits can
control the transparency between the framebuffer and the overlay. If only
the framebuffer is active,  I don't believe it has any effects.

Tony


-------------------------------------------------------
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

Re: fixing fbdev for various framebuffer configs

[Jon Smirl]

On 7/29/05, Antonino A. Daplas <adaplas@gmail.com> 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, the
> offsets to 0, 16, 32, 48, and bits_per_pixel to 64.  Then let the driver
> 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.

We can change fb_info since the only thing that sees it is fbconsole.
That will let me set the 32bit modes via sysfs. We leave the ioctl's
alone at 16 bits so that the old apps don't notice.

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.


> 
> >
> > What is the effect of alpha bits on the scanout buffer, do they do anything?
> >
> 
> I think if there is another layer such as an overlay, the alpha bits can
> control the transparency between the framebuffer and the overlay. If only
> the framebuffer is active,  I don't believe it has any effects.
> 
> Tony
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 


-- 
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

Re: fixing fbdev for various framebuffer configs

[Geert Uytterhoeven]

On Fri, 29 Jul 2005, Jon Smirl wrote:
> On 7/29/05, Antonino A. Daplas <adaplas@gmail.com> 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, the
> > offsets to 0, 16, 32, 48, and bits_per_pixel to 64.  Then let the driver
> > 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 component,
right? The color components in pixel values can be much larger (up to 2^31 bits
:-).

> 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 values,
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?

> > > What is the effect of alpha bits on the scanout buffer, do they do anything?
> > 
> > I think if there is another layer such as an overlay, the alpha bits can
> > control the transparency between the framebuffer and the overlay. If only
> > the framebuffer is active,  I don't believe it has any effects.

It has on e.g. Set Top Box hardware.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
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

Re: fixing fbdev for various framebuffer configs

[Jon Smirl]

On 7/29/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Fri, 29 Jul 2005, Jon Smirl wrote:
> > On 7/29/05, Antonino A. Daplas <adaplas@gmail.com> 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, the
> > > offsets to 0, 16, 32, 48, and bits_per_pixel to 64.  Then let the driver
> > > 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 component,
> right? The color components in pixel values can be much larger (up to 2^31 bits
> :-).
> 
> > 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?

Isn't that the driver's problem? You can't differentiate using OpenGL.
This does imply that I need a read only bits_per_pixel to allow apps
to caculate the stride.

> Or more general, what with hardware that has unused bits in its pixel values,
> 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?
> 
> > > > What is the effect of alpha bits on the scanout buffer, do they do anything?
> > >
> > > I think if there is another layer such as an overlay, the alpha bits can
> > > control the transparency between the framebuffer and the overlay. If only
> > > the framebuffer is active,  I don't believe it has any effects.
> 
> It has on e.g. Set Top Box hardware.
> 
> Gr{oetje,eeting}s,
> 
>                                                 Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                                             -- Linus Torvalds
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 


-- 
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

Re: fixing fbdev for various framebuffer configs

[Geert Uytterhoeven]

On Fri, 29 Jul 2005, Jon Smirl wrote:
> On 7/29/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, 29 Jul 2005, Jon Smirl wrote:
> > > On 7/29/05, Antonino A. Daplas <adaplas@gmail.com> 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, the
> > > > offsets to 0, 16, 32, 48, and bits_per_pixel to 64.  Then let the driver
> > > > 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 component,
> > right? The color components in pixel values can be much larger (up to 2^31 bits
> > :-).
> > 
> > > 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?
> 
> Isn't that the driver's problem? You can't differentiate using OpenGL.
> This does imply that I need a read only bits_per_pixel to allow apps
> to caculate the stride.

You can use fb_fix_screeninfo.line_length (if non-zero) for that.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
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

Re: fixing fbdev for various framebuffer configs

[Geert Uytterhoeven]

On Fri, 29 Jul 2005, Jon Smirl wrote:
> On 7/29/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, 29 Jul 2005, 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
> > > 64   GL_RGBA16
> > 
> > All above (and many more) can be handled fine, cfr.
> > fb_var_screeninfo.{red,green,blue,transp}.
> > 
> > > 48   GL_FLOAT_RGB16
> > > 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.
> > >
> > > Ideas on how to adjust the fbdev interface?
> > 
> > Floating point pixel values could be handled by a new nonstd flag:
> 
> Why non-standard? All of the current higher end ATI/Nvidia cards support it.

It's non-standard in the sense that it's not an integer value.

I don't see a better place to advertise this. Anyone with a better idea?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
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

Re: fixing fbdev for various framebuffer configs

[Antonino A. Daplas]

Geert Uytterhoeven wrote:
> On Fri, 29 Jul 2005, Jon Smirl wrote:
>> On 7/29/05, Antonino A. Daplas <adaplas@gmail.com> 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, the
>>> offsets to 0, 16, 32, 48, and bits_per_pixel to 64.  Then let the driver
>>> 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 component,
> right? The color components in pixel values can be much larger (up to 2^31 bits
> :-).

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.

> 
>> 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 values,
> 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?

Agree,

Tony


-------------------------------------------------------
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

Re: fixing fbdev for various framebuffer configs

[Jon Smirl]

On 7/29/05, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Geert Uytterhoeven wrote:
> > On Fri, 29 Jul 2005, Jon Smirl wrote:
> >> On 7/29/05, Antonino A. Daplas <adaplas@gmail.com> 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, the
> >>> offsets to 0, 16, 32, 48, and bits_per_pixel to 64.  Then let the driver
> >>> 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 component,
> > right? The color components in pixel values can be much larger (up to 2^31 bits
> > :-).
> 
> 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 values,
> > 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?
> 
> Agree,
> 
> Tony
> 


-- 
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