From: Jon Smirl <hidden> Date: 2005-08-05 20:19:25
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
--
From: Patrick McFarland <hidden> Date: 2005-08-06 23:23:53
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
From: Jon Smirl <hidden> Date: 2005-08-06 23:27:24
On 8/6/05, Patrick McFarland [off-list ref] wrote:
On Friday 05 August 2005 04:19 pm, Jon Smirl wrote:
quoted
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
From: Dave Airlie <hidden> Date: 2005-08-06 23:45:16
quoted
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
--
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
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
From: Jon Smirl <hidden> Date: 2005-08-07 13:41:53
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
--
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.
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
From: Ian Romanick <hidden> Date: 2005-08-07 21:03:21
-----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
--
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-07 21:45:39
Ian Romanick wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jon Smirl wrote:
quoted
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
From: Vladimir Dergachev <hidden> Date: 2005-08-07 22:31:27
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
--
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-08 01:15:13
Vladimir Dergachev wrote:
quoted
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
From: Vladimir Dergachev <hidden> Date: 2005-08-08 02:05:24
On Mon, 8 Aug 2005, Antonino A. Daplas wrote:
Vladimir Dergachev wrote:
quoted
quoted
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
--
From: Jon Smirl <hidden> Date: 2005-08-08 02:33:33
On 8/7/05, Antonino A. Daplas [off-list ref] wrote:
Vladimir Dergachev wrote:
quoted
quoted
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.
quoted
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
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-08 06:23:51
Jon Smirl wrote:
On 8/7/05, Antonino A. Daplas [off-list ref] wrote:
quoted
Vladimir Dergachev wrote:
quoted
quoted
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
On 8/7/05, Antonino A. Daplas [off-list ref] wrote:
quoted
Vladimir Dergachev wrote:
quoted
quoted
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
From: Jon Smirl <hidden> Date: 2005-08-08 13:14:45
On 8/8/05, Geert Uytterhoeven [off-list ref] wrote:
On Sun, 7 Aug 2005, Jon Smirl wrote:
quoted
On 8/7/05, Antonino A. Daplas [off-list ref] wrote:
quoted
Vladimir Dergachev wrote:
quoted
quoted
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.
quoted
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
--
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-07 21:10:18
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.
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
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