CRTC scanout buffer types

CRTC scanout buffer types

[Jon Smirl]

I've included the scanout types for the R200, what other ones are
supported by the various chips? For example I think the R300 can
scanout in floating point.

4bpp Indexed
8bpp Indexed
16bpp aRGB 1555
16bpp RGB 565
24bpp RGB 888
32bpp aRGB 8888
16bpp aRGB 4444
16bpp aIndex 88
32bpp aRGB 2:10:10:10 palette bypassed

Note, the r200 supports a lot more buffer formats, but these are the
only ones valid for scanout.

-- 
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: CRTC scanout buffer types

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

On Friday 05 August 2005 04:19 pm, Jon Smirl wrote:
> I've included the scanout types for the R200, what other ones are
> supported by the various chips? For example I think the R300 can
> scanout in floating point.
>
> 4bpp Indexed
> 8bpp Indexed
> 16bpp aRGB 1555
> 16bpp RGB 565
> 24bpp RGB 888
> 32bpp aRGB 8888
> 16bpp aRGB 4444
> 16bpp aIndex 88
> 32bpp aRGB 2:10:10:10 palette bypassed
>
> Note, the r200 supports a lot more buffer formats, but these are the
> only ones valid for scanout.

What does scanout mean?

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: CRTC scanout buffer types

[Jon Smirl]

On 8/6/05, Patrick McFarland <pmcfarland@downeast.net> wrote:
> On Friday 05 August 2005 04:19 pm, Jon Smirl wrote:
> > I've included the scanout types for the R200, what other ones are
> > supported by the various chips? For example I think the R300 can
> > scanout in floating point.
> >
> > 4bpp Indexed
> > 8bpp Indexed
> > 16bpp aRGB 1555
> > 16bpp RGB 565
> > 24bpp RGB 888
> > 32bpp aRGB 8888
> > 16bpp aRGB 4444
> > 16bpp aIndex 88
> > 32bpp aRGB 2:10:10:10 palette bypassed
> >
> > Note, the r200 supports a lot more buffer formats, but these are the
> > only ones valid for scanout.
> 
> What does scanout mean?

A scanout buffer is a buffer that the graphics chip reads from to
directly display on the screen.  There are other buffer types like
texture and pbuffer that are not directly displayable. For example the
Radeon r200 does not allow floating point colors in scanout buffers
but they can be used in other buffer types.


> 
> --
> Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
> "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
> all be running around in darkened rooms, munching magic pills and listening to
> repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989
> 
> 
> 


-- 
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: CRTC scanout buffer types

[Dave Airlie]

> > Note, the r200 supports a lot more buffer formats, but these are the
> > only ones valid for scanout.
>
> What does scanout mean?

the sending of a graphics buffer from VRAM to monitor via a CRTC... CRTCs
only support certain formats...

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG



-------------------------------------------------------
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: CRTC scanout buffer types

[Geert Uytterhoeven]

On Fri, 5 Aug 2005, Jon Smirl wrote:
> I've included the scanout types for the R200, what other ones are
> supported by the various chips? For example I think the R300 can
> scanout in floating point.

1 bpp monochrome (black = 0 and white = 1 or vice versa)
1 bpp indexed
2 bpp indexed
3 bpp indexed

> 4bpp Indexed

4 bpp greyscale

5 bpp indexed
6 bpp indexed
7 bpp indexed

> 8bpp Indexed

8 bpp monochrome (black is all zeroes and white is all ones or vice versa)
8 bpp greyscale
8 bpp RGB 332

> 16bpp aRGB 1555
> 16bpp RGB 565
> 16bpp aRGB 4444

> 24bpp RGB 888

24 bpp aRGB 6666

> 32bpp aRGB 8888

32 bpp indexed+RGB 888 with color key to enable RGB888

> 16bpp aIndex 88

This one is a new one for me ;-)

> 32bpp aRGB 2:10:10:10 palette bypassed

And of course all the various YCbCr (4:4:4, 4:2:2, 4:2:0) variants, which just
need a few additional FB_VISUAL_* defines :-)

Probably I forgot a few. Feel free to add them.

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: [Linux-fbdev-devel] CRTC scanout buffer types

[Jon Smirl]

I'm trying to work out a syntax for the sysfs attribute that will
control the config. My first idea is to use a alpha/red/blue/green
syntax. When red is set and blue/green are missing index mode is set.
When green is set and red/blue are missing gray scale is set.

Are there chips that can scanout from buffers not packed at a power of two?
How should I work different color spaces (YCbCr) into this?

4bpp Index = /4
4bpp greyscale = //4
8bpp Index = /8
8bpp RGB 332 = /3/3/2
8bpp greyscale = //8
16bpp aRGB 1555 = 1/5/5/5
16bpp RGB 565 = /5/6/5
16bpp aRGB 4444 = 4/4/4/4
16bpp aIndex 88 = 8/8
24bpp RGB 888 = /8/8/8
24bpp aRGB 6666 = 6/6/6/6
32bpp aRGB 8888 = 8/8/8/8
32bpp aRGB 2:10:10:10 = 2/10/10/10

How are these packed?
1 bpp monochrome (black = 0 and white = 1 or vice versa)
1 bpp indexed
2 bpp indexed
3 bpp indexed
5 bpp indexed
6 bpp indexed
7 bpp indexed

These would have the same config, //8, right? You then just control
what you write to the byte.
8 bpp monochrome (black is all zeroes and white is all ones or vice versa)
8 bpp greyscale

How does this work, is one 24 bit color the key?
32 bpp indexed+RGB 888 with color key to enable RGB888

-- 
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: CRTC scanout buffer types

[Geert Uytterhoeven]

On Sun, 7 Aug 2005, Jon Smirl wrote:
> I'm trying to work out a syntax for the sysfs attribute that will
> control the config. My first idea is to use a alpha/red/blue/green
> syntax. When red is set and blue/green are missing index mode is set.
> When green is set and red/blue are missing gray scale is set.

Ugh, sounds complex and non-intuitive...

> Are there chips that can scanout from buffers not packed at a power of two?

Yes, planar frame buffers can.

> How should I work different color spaces (YCbCr) into this?

That's more like a visual thing. Using a YCbCr visual, we could say the red,
green, and blue bitfields actually control Y, Cb, and Cr.

> 4bpp Index = /4
> 4bpp greyscale = //4
> 8bpp Index = /8
> 8bpp RGB 332 = /3/3/2
> 8bpp greyscale = //8
> 16bpp aRGB 1555 = 1/5/5/5
> 16bpp RGB 565 = /5/6/5
> 16bpp aRGB 4444 = 4/4/4/4
> 16bpp aIndex 88 = 8/8
> 24bpp RGB 888 = /8/8/8
> 24bpp aRGB 6666 = 6/6/6/6
> 32bpp aRGB 8888 = 8/8/8/8
> 32bpp aRGB 2:10:10:10 = 2/10/10/10

BTW, the numbers still control the lengths of the color bitfields only, not
their positions. E.g. some hardware does ARGB, other does ABGR, or BGRA...

> 1 bpp monochrome (black = 0 and white = 1 or vice versa)
> 1 bpp indexed
> 2 bpp indexed
> 3 bpp indexed
> 5 bpp indexed
> 6 bpp indexed
> 7 bpp indexed
> 
> These would have the same config, //8, right? You then just control
> what you write to the byte.

No, they use bitplanes.

> How does this work, is one 24 bit color the key?
> 32 bpp indexed+RGB 888 with color key to enable RGB888

Actually one of the CLUT index values is the color key.

So if the pixel has [ i | r | g | b ], the actual color is:

    if (i == key)
	color = [ r, g, b ];
    else
	color = [ clut.r[i], clut.g[i], clut.b[i] ];

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: [Linux-fbdev-devel] CRTC scanout buffer types

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Smirl wrote:
> I'm trying to work out a syntax for the sysfs attribute that will
> control the config. My first idea is to use a alpha/red/blue/green
> syntax. When red is set and blue/green are missing index mode is set.
> When green is set and red/blue are missing gray scale is set.
> 
> Are there chips that can scanout from buffers not packed at a power of two?
> How should I work different color spaces (YCbCr) into this?
> 
> 4bpp Index = /4
> 4bpp greyscale = //4
> 8bpp Index = /8
> 8bpp RGB 332 = /3/3/2
> 8bpp greyscale = //8
> 16bpp aRGB 1555 = 1/5/5/5
> 16bpp RGB 565 = /5/6/5
> 16bpp aRGB 4444 = 4/4/4/4
> 16bpp aIndex 88 = 8/8
> 24bpp RGB 888 = /8/8/8
> 24bpp aRGB 6666 = 6/6/6/6
> 32bpp aRGB 8888 = 8/8/8/8
> 32bpp aRGB 2:10:10:10 = 2/10/10/10

What would be wrong with using a letter, a colon, and a number to
describe the field?  So, instead of 2/10/10/10 you'd have
A:2/R:10/G:10/B:10.  Or A:8/I:8 for aIndex 88.  I'm not familiar with
how sysfs attributes work, so this may be pure nonsense.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFC9ncYX1gOwKyEAw8RAnjwAJ4mVXa5RGo/1yja036IdUi8U+2wyACfe8gg
mloAzlOC33YqPCP6zM6BHKM=
=Qr6o
-----END PGP SIGNATURE-----


-------------------------------------------------------
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: CRTC scanout buffer types

[Antonino A. Daplas]

Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jon Smirl wrote:
>> I'm trying to work out a syntax for the sysfs attribute that will
>> control the config. My first idea is to use a alpha/red/blue/green
>> syntax. When red is set and blue/green are missing index mode is set.
>> When green is set and red/blue are missing gray scale is set.
>>
>> Are there chips that can scanout from buffers not packed at a power of two?
>> How should I work different color spaces (YCbCr) into this?
>>
>> 4bpp Index = /4
>> 4bpp greyscale = //4
>> 8bpp Index = /8
>> 8bpp RGB 332 = /3/3/2
>> 8bpp greyscale = //8
>> 16bpp aRGB 1555 = 1/5/5/5
>> 16bpp RGB 565 = /5/6/5
>> 16bpp aRGB 4444 = 4/4/4/4
>> 16bpp aIndex 88 = 8/8
>> 24bpp RGB 888 = /8/8/8
>> 24bpp aRGB 6666 = 6/6/6/6
>> 32bpp aRGB 8888 = 8/8/8/8
>> 32bpp aRGB 2:10:10:10 = 2/10/10/10
> 
> What would be wrong with using a letter, a colon, and a number to
> describe the field?  So, instead of 2/10/10/10 you'd have
> A:2/R:10/G:10/B:10.  Or A:8/I:8 for aIndex 88.  I'm not familiar with
> how sysfs attributes work, so this may be pure nonsense.

I agree that something like the above is acceptable, exept that we need
an extra field for offset and another if indexed color or not. So something like:

A:2/0/R:10/2/G:10/12/B:10/22//I

is ARGB2888. The I means it's indexed (directcolor), differentiating it from
truecolor.

A:8/0/R:8/0/G:8/0/B:8/0//I

is ARGB8 indexed, because offset's are all equal to 0 and len's are all
equal to 8.  The 'I' here is probably redundant, but it can be used to
differentiate it from static pseudocolor.

From here, you can get the color depth which usually translates to bpp:

if (offset's = 0 && red.len == green.len && green.len == blue.len)
	if (transp.offset == 0) //ARGB8 bpp8
		depth = green.len ; 
	else			//A8_RGB8 bpp16
		depth = green.len + transp.len
else
	depth = red.len + green.len + blue.len + transp.len

If depth returns 15 (RGB555), the driver can easily round that up to bpp16.

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: [Linux-fbdev-devel] CRTC scanout buffer types

[Vladimir Dergachev]

> I agree that something like the above is acceptable, exept that we need
> an extra field for offset and another if indexed color or not. So something 
> like:
>
> A:2/0/R:10/2/G:10/12/B:10/22//I

This is getting more cryptic by the minute.

Can't we have a simple field: value lines ? Something like:
AlphaBits: 2
AlphaOffset: 0

                    best

                       Vladimir Dergachev



-------------------------------------------------------
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: CRTC scanout buffer types

[Antonino A. Daplas]

Vladimir Dergachev wrote:
>> I agree that something like the above is acceptable, exept that we need
>> an extra field for offset and another if indexed color or not. So 
>> something like:
>>
>> A:2/0/R:10/2/G:10/12/B:10/22//I
> 
> This is getting more cryptic by the minute.
> 
> Can't we have a simple field: value lines ? Something like:
> AlphaBits: 2
> AlphaOffset: 0
> 

The problem with doing that is you need to set everything in one go.
Separating all those fields into different sysfs attributes will have
a problem with synchronization.

One workaround is to have another attribute 'Activate'. Nothing is set
until the 'Activate' attribute is written to.  There is still the problem
of another process changing the other attributes behind the back of the
original process.

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: [Linux-fbdev-devel] CRTC scanout buffer types

[Vladimir Dergachev]

On Mon, 8 Aug 2005, Antonino A. Daplas wrote:

> Vladimir Dergachev wrote:
>>> I agree that something like the above is acceptable, exept that we need
>>> an extra field for offset and another if indexed color or not. So 
>>> something like:
>>> 
>>> A:2/0/R:10/2/G:10/12/B:10/22//I
>> 
>> This is getting more cryptic by the minute.
>> 
>> Can't we have a simple field: value lines ? Something like:
>> AlphaBits: 2
>> AlphaOffset: 0
>> 
>
> The problem with doing that is you need to set everything in one go.
> Separating all those fields into different sysfs attributes will have
> a problem with synchronization.
>
> One workaround is to have another attribute 'Activate'. Nothing is set
> until the 'Activate' attribute is written to.  There is still the problem
> of another process changing the other attributes behind the back of the
> original process.

I think "Activate" is a good idea and it kinda mimics what graphics chips 
themselves do, so another reason to like it.

As for simultaneous access - does it actually make sense that two programs
would want to change screen format at the same time ?

Even if access is serialized in some fashion, at most one of the programs 
will get format that it requested, so we lose nothing by allowing it to be 
none.

                         best

                              Vladimir Dergachev

>
> 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: CRTC scanout buffer types

[Jon Smirl]

On 8/7/05, Antonino A. Daplas <adaplas@gmail.com> wrote:
> Vladimir Dergachev wrote:
> >> I agree that something like the above is acceptable, exept that we need
> >> an extra field for offset and another if indexed color or not. So
> >> something like:
> >>
> >> A:2/0/R:10/2/G:10/12/B:10/22//I

The offsets are not needed as part of the input, they should be part
of the output display. It is the chip driver that will determine the
offsets, not the user.

The only exception I can think of is that the radeon hardware can
control which nibble is used in 4bpp. I'd say if you need that kind of
control use the ioctl and keep the sysfs input string simpler. If the
config is set from sysfs let the driver pick the nibble order.

This also implies that you don't need to control RGB vs BGR on input,
just let the driver choose and check what you got on output.

> >
> > This is getting more cryptic by the minute.
> >
> > Can't we have a simple field: value lines ? Something like:
> > AlphaBits: 2
> > AlphaOffset: 0
> >
> 
> The problem with doing that is you need to set everything in one go.
> Separating all those fields into different sysfs attributes will have
> a problem with synchronization.
> 
> One workaround is to have another attribute 'Activate'. Nothing is set
> until the 'Activate' attribute is written to.  There is still the problem
> of another process changing the other attributes behind the back of the
> original process.
> 
> 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

Re: CRTC scanout buffer types

[Antonino A. Daplas]

Jon Smirl wrote:
> On 8/7/05, Antonino A. Daplas <adaplas@gmail.com> wrote:
>> Vladimir Dergachev wrote:
>>>> I agree that something like the above is acceptable, exept that we need
>>>> an extra field for offset and another if indexed color or not. So
>>>> something like:
>>>>
>>>> A:2/0/R:10/2/G:10/12/B:10/22//I
> 
> The offsets are not needed as part of the input, they should be part
> of the output display. It is the chip driver that will determine the
> offsets, not the user.
> 

Without the offsets, how will it differentiate ARGB2222/8bpp vs ARGB2/8bpp?

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: CRTC scanout buffer types

[Geert Uytterhoeven]

On Sun, 7 Aug 2005, Jon Smirl wrote:
> On 8/7/05, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > Vladimir Dergachev wrote:
> > >> I agree that something like the above is acceptable, exept that we need
> > >> an extra field for offset and another if indexed color or not. So
> > >> something like:
> > >>
> > >> A:2/0/R:10/2/G:10/12/B:10/22//I
> 
> The offsets are not needed as part of the input, they should be part
> of the output display. It is the chip driver that will determine the
> offsets, not the user.

So you cannot select between RGB and BGR on hardware that allows to select
that?

> The only exception I can think of is that the radeon hardware can
> control which nibble is used in 4bpp. I'd say if you need that kind of

This is something completely different, since each nibble is a different pixel.

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: [Linux-fbdev-devel] CRTC scanout buffer types

[Jon Smirl]

On 8/8/05, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sun, 7 Aug 2005, Jon Smirl wrote:
> > On 8/7/05, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > > Vladimir Dergachev wrote:
> > > >> I agree that something like the above is acceptable, exept that we need
> > > >> an extra field for offset and another if indexed color or not. So
> > > >> something like:
> > > >>
> > > >> A:2/0/R:10/2/G:10/12/B:10/22//I
> >
> > The offsets are not needed as part of the input, they should be part
> > of the output display. It is the chip driver that will determine the
> > offsets, not the user.
> 
> So you cannot select between RGB and BGR on hardware that allows to select
> that?

If you need that fine of control use the ioctl instead of sysfs.

> > The only exception I can think of is that the radeon hardware can
> > control which nibble is used in 4bpp. I'd say if you need that kind of
> 
> This is something completely different, since each nibble is a different pixel.
> 
> 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: CRTC scanout buffer types

[Antonino A. Daplas]

Jon Smirl wrote:
> I'm trying to work out a syntax for the sysfs attribute that will
> control the config. My first idea is to use a alpha/red/blue/green
> syntax. When red is set and blue/green are missing index mode is set.
> When green is set and red/blue are missing gray scale is set.

No, if r.offset = g.offset = b.offset = 0 and
r.len = g.len = b.len = n, then set index mode (pseudocolor).  For grayscale,
check if var.grayscale is set.

> 
> Are there chips that can scanout from buffers not packed at a power of two?

Yes, rgb888 (Intel 810).

> How should I work different color spaces (YCbCr) into this?

Create a new visual FB_VISUAL_YUV, then treat rgb as yuv.

> 
> 4bpp Index = /4
> 4bpp greyscale = //4
> 8bpp Index = /8
> 8bpp RGB 332 = /3/3/2
> 8bpp greyscale = //8
> 16bpp aRGB 1555 = 1/5/5/5
> 16bpp RGB 565 = /5/6/5
> 16bpp aRGB 4444 = 4/4/4/4
> 16bpp aIndex 88 = 8/8
> 24bpp RGB 888 = /8/8/8
> 24bpp aRGB 6666 = 6/6/6/6
> 32bpp aRGB 8888 = 8/8/8/8
> 32bpp aRGB 2:10:10:10 = 2/10/10/10
> 
> How are these packed?

How each pixel is packed in the framebuffer is determined by bpp.
How each color component is packed within the pixel is determined by
{red|green|blue|transp}.{offset|len} 

> 1 bpp monochrome (black = 0 and white = 1 or vice versa)
> 1 bpp indexed
> 2 bpp indexed
> 3 bpp indexed
> 5 bpp indexed
> 6 bpp indexed
> 7 bpp indexed
> 
> These would have the same config, //8, right? You then just control

No, packing is determined by bpp. So 7bpp has 7 bits per pixel.  However
a color depth of 7 with bpp8 has 8 bits per pixel but only 7 significant bits.

> what you write to the byte.
> 8 bpp monochrome (black is all zeroes and white is all ones or vice versa)
> 8 bpp greyscale
> 
> How does this work, is one 24 bit color the key?
> 32 bpp indexed+RGB 888 with color key to enable RGB888
> 

This is directcolor. Each component is indexed.


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: CRTC scanout buffer types

[Geert Uytterhoeven]

On Mon, 8 Aug 2005, Antonino A. Daplas wrote:
> Jon Smirl wrote:
> > How does this work, is one 24 bit color the key?
> > 32 bpp indexed+RGB 888 with color key to enable RGB888
> 
> This is directcolor. Each component is indexed.

No, directcolor is different. This is a mode that combines a pseudocolor
CLUT256 visual (but only 255 colors, because of the color key) with a truecolor
RGB888 visual.

E.g. the Matrox Millennium can do this, and IIRC at least Accelerated X
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