From: Jon Smirl <hidden> Date: 2005-08-06 01:47:36
If I understand things correctly the framebuffer config is supposed to
be controlled by the transp/red/blue/green fields of fb_var_screeninfo
during check_var. These fields are then combined to compute the
bits_per_pixel.
radeonfb is working from the other direction, it starts with bpp and
then computes ARGB. This looks wrong to me.
Radeonfb supports these four configs controlled by setting BPP:
DST_8BPP = 8BPP indexed
DST_15BPP = ARGB1555
DST_16BPP = RGB565
DST_32BPP = ARGB8888
The chips actually allow nine configs (maybe more when I get a look at
the R300 doc). It is ambiguous to set these configs based on BPP since
there are multiple configs for various BPP. These configs should
instead be set with the transp/red/blue/green fields.
4bpp Index = /4
8bpp Index = /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
32bpp aRGB 8888 = 8/8/8/8
32bpp aRGB 2:10:10:10 = 2/10/10/10
What is the best way to fix this? The interesting hidden config is 30b color.
I can hack it in by using ARGB if BPP is zero and the old scheme if BPP is set.
Do other fbdev drivers have this problem?
BTW, Xserver is limited to six of the nine configs.
--
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: Petr Vandrovec <hidden> Date: 2005-08-06 23:12:52
Jon Smirl wrote:
If I understand things correctly the framebuffer config is supposed to
be controlled by the transp/red/blue/green fields of fb_var_screeninfo
during check_var. These fields are then combined to compute the
bits_per_pixel.
radeonfb is working from the other direction, it starts with bpp and
then computes ARGB. This looks wrong to me.
It is correct thing to do if you support only one format per depth.
Radeonfb supports these four configs controlled by setting BPP:
DST_8BPP = 8BPP indexed
DST_15BPP = ARGB1555
DST_16BPP = RGB565
DST_32BPP = ARGB8888
The chips actually allow nine configs (maybe more when I get a look at
the R300 doc). It is ambiguous to set these configs based on BPP since
there are multiple configs for various BPP. These configs should
instead be set with the transp/red/blue/green fields.
If you support all of them, I would do:
4bpp Index = /4
Use this if bpp==4, ignore rgba.
8bpp Index = /8
Use this if bpp==8, ignore rgba.
16bpp aRGB 1555 = 1/5/5/5
Use this if bpp==16 and green.length == 5. For backward compatibility
you can support bpp=15 with any rgba...
16bpp RGB 565 = /5/6/5
Use this if bpp==16 and it is not 1/5/5/5 or 4/4/4/4.
16bpp aRGB 4444 = 4/4/4/4
Use this if bpp==16 and green.length == 4.
16bpp aIndex 88 = 8/8
I'm afraid that with this format you run out of luck. I do not think
infrastructure is able to support this. API does not have separate
entry for Index position/width in pseudocolor, and rgb fileds are used
for reporting DAC width in pseudocolor mode. Maybe use this when
nonstd==1 ? Choosing this format when green.length==8 might trigger
when 8/24/32bpp videomode is switched to 16bpp by fbset without rgba
option, so it is probably not good idea to use green.length==8 to select
this videomode.
24bpp RGB 888 = /8/8/8
bpp == 24, any rgba.
32bpp aRGB 8888 = 8/8/8/8
bpp == 24, green.length != 10.
32bpp aRGB 2:10:10:10 = 2/10/10/10
bpp == 32, green.length == 10.
What is the best way to fix this? The interesting hidden config is 30b color.
I can hack it in by using ARGB if BPP is zero and the old scheme if BPP is set.
Apps should be setting both bpp and preferred rgba. Apps which use
garbage rgba (f.e. they ask for 32bit 1:5:5:5 when they are switching
framebuffer from depth == 15 to depth == 32) should get "best" suitable
format, which I tried to express above by green.length tests (*). Upon
successful mode set rgba must be updated with choosen hardware
configuration.
Petr
(*) Maybe you could ignore rgba when sum of rgba lengths does not equal
to bpp.
-------------------------------------------------------
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
The chips actually allow nine configs (maybe more when I get a look at
the R300 doc). It is ambiguous to set these configs based on BPP since
there are multiple configs for various BPP. These configs should
instead be set with the transp/red/blue/green fields.
4bpp Index = /4
8bpp Index = /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
32bpp aRGB 8888 = 8/8/8/8
32bpp aRGB 2:10:10:10 = 2/10/10/10
What is the best way to fix this?
Just follow the FBIOPUT_VSCREENINFO rules:
- If a value doesn't fit, round it up.
- If rounding is impossible, return an error.
So if a user asks for e.g. bpp 16, transp.length = 1,
{red,green,blue}.length = 0, you can give him 1555 if your hardware supports
it. Or 4444 if your hardware doesn't support anything in between 1000 and 4444
(w.r.t. rounding). But you must not give him 565, since this implies you
rounded down transp.length.
The interesting hidden config is 30b color.
Piece of cake!
bpp = 32
transp.length = 2, {red,green,blue}.length = 10
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: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-07 11:00:49
Jon Smirl wrote:
If I understand things correctly the framebuffer config is supposed to
be controlled by the transp/red/blue/green fields of fb_var_screeninfo
during check_var. These fields are then combined to compute the
bits_per_pixel.
radeonfb is working from the other direction, it starts with bpp and
then computes ARGB. This looks wrong to me.
16bpp aIndex 88 = 8/8
Set argb.length = 8, rgb.offset = 0, t.offset = 8.
The transp.offset differentiates ARGB8 from A8_RGB8.
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-07 15:33:54
On 8/7/05, Geert Uytterhoeven [off-list ref] wrote:
On Fri, 5 Aug 2005, Jon Smirl wrote:
quoted
The chips actually allow nine configs (maybe more when I get a look at
the R300 doc). It is ambiguous to set these configs based on BPP since
there are multiple configs for various BPP. These configs should
instead be set with the transp/red/blue/green fields.
4bpp Index = /4
8bpp Index = /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
32bpp aRGB 8888 = 8/8/8/8
32bpp aRGB 2:10:10:10 = 2/10/10/10
What is the best way to fix this?
Just follow the FBIOPUT_VSCREENINFO rules:
- If a value doesn't fit, round it up.
- If rounding is impossible, return an error.
So if a user asks for e.g. bpp 16, transp.length = 1,
{red,green,blue}.length = 0, you can give him 1555 if your hardware supports
it. Or 4444 if your hardware doesn't support anything in between 1000 and 4444
(w.r.t. rounding). But you must not give him 565, since this implies you
rounded down transp.length.
The problem is that the radeonfb driver sees bpp = 32 and then sets
rgbt = 8/8/8/8. It stomps rgbt without looking at it.
Is this a general problem? Do a lot of drivers look at bpp and then
overwrite rgbt? If so I can look at putting better fixup code in base
fbdev and then remove the code that converts from bpp to rgbt in the
various drivers.
The basic problem is what happens if bpp and rgbt are set in
conflicting ways. For example bpp = 16 and rgbt = 8/8/8/8. Which one
should win? I think the config should always be controlled by rgbt and
bpp is read only and computed from rgbt. But fixing everything to work
that way may break some apps. radeonfb is definitely not working in
this manner.
Best fix would be for the core fbdev to zero out bpp before handing it
to check_par. That would force the chip drivers to compute it from
rgbt. Some of the chip drivers will probably need their code adjusted.
This may also break some apps since they are not setting rgbt.
So I guess the fallback position is leave this driver dependent. So
for the radeonfb case if you set bpp it will work like it always has.
I'll then fix radeonfb to look at rgbt if bpp = 0. rgbt with bpp=0
will then be able to select the other configs.
It would also be nice to build a string with the list of legal configs
into each driver. For radeon the string would contain: /4, /8,
1/5/5/5, /5/6/5, 4/4/4/4, 8/8, /8/8/8, 8/8/8/8, 2/10/10/10. This would
let me display the list of legal configs in sysfs.
--
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: Michel Dänzer <hidden> Date: 2005-08-07 16:01:15
On Sun, 2005-08-07 at 11:33 -0400, Jon Smirl wrote:
On 8/7/05, Geert Uytterhoeven [off-list ref] wrote:
quoted
On Fri, 5 Aug 2005, Jon Smirl wrote:
quoted
The chips actually allow nine configs (maybe more when I get a look at
the R300 doc). It is ambiguous to set these configs based on BPP since
there are multiple configs for various BPP. These configs should
instead be set with the transp/red/blue/green fields.
4bpp Index = /4
8bpp Index = /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
32bpp aRGB 8888 = 8/8/8/8
32bpp aRGB 2:10:10:10 = 2/10/10/10
What is the best way to fix this?
Just follow the FBIOPUT_VSCREENINFO rules:
- If a value doesn't fit, round it up.
- If rounding is impossible, return an error.
So if a user asks for e.g. bpp 16, transp.length = 1,
{red,green,blue}.length = 0, you can give him 1555 if your hardware supports
it. Or 4444 if your hardware doesn't support anything in between 1000 and 4444
(w.r.t. rounding). But you must not give him 565, since this implies you
rounded down transp.length.
The problem is that the radeonfb driver sees bpp = 32 and then sets
rgbt = 8/8/8/8. It stomps rgbt without looking at it.
Looks like a radeonfb bug.
The basic problem is what happens if bpp and rgbt are set in
conflicting ways. For example bpp = 16 and rgbt = 8/8/8/8. Which one
should win?
Read what you quoted from Geert above.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
-------------------------------------------------------
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 16:15:15
On 8/7/05, Michel Dänzer [off-list ref] wrote:
On Sun, 2005-08-07 at 11:33 -0400, Jon Smirl wrote:
quoted
On 8/7/05, Geert Uytterhoeven [off-list ref] wrote:
quoted
On Fri, 5 Aug 2005, Jon Smirl wrote:
quoted
The chips actually allow nine configs (maybe more when I get a look at
the R300 doc). It is ambiguous to set these configs based on BPP since
there are multiple configs for various BPP. These configs should
instead be set with the transp/red/blue/green fields.
4bpp Index = /4
8bpp Index = /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
32bpp aRGB 8888 = 8/8/8/8
32bpp aRGB 2:10:10:10 = 2/10/10/10
What is the best way to fix this?
Just follow the FBIOPUT_VSCREENINFO rules:
- If a value doesn't fit, round it up.
- If rounding is impossible, return an error.
So if a user asks for e.g. bpp 16, transp.length = 1,
{red,green,blue}.length = 0, you can give him 1555 if your hardware supports
it. Or 4444 if your hardware doesn't support anything in between 1000 and 4444
(w.r.t. rounding). But you must not give him 565, since this implies you
rounded down transp.length.
The problem is that the radeonfb driver sees bpp = 32 and then sets
rgbt = 8/8/8/8. It stomps rgbt without looking at it.
Looks like a radeonfb bug.
quoted
The basic problem is what happens if bpp and rgbt are set in
conflicting ways. For example bpp = 16 and rgbt = 8/8/8/8. Which one
should win?
Read what you quoted from Geert above.
I'm just verifying everything before changing things. Sometimes there
are disagreements on what rules we should be following.
So from Geert's rules 16bpp doesn't fit with 8/8/8/8 so round it up to
32bpp. Are we sure that is what applications are expecting to happen?
--
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: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-08-07 16:19:56
quoted
The problem is that the radeonfb driver sees bpp = 32 and then sets
rgbt = 8/8/8/8. It stomps rgbt without looking at it.
Looks like a radeonfb bug.
It's not a bug :) radeonfb doesn't support anything but that format for
now. If you want to do something else, implement it :)
quoted
The basic problem is what happens if bpp and rgbt are set in
conflicting ways. For example bpp = 16 and rgbt = 8/8/8/8. Which one
should win?
Read what you quoted from Geert above.
-------------------------------------------------------
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: Michel Dänzer <hidden> Date: 2005-08-07 16:32:42
On Sun, 2005-08-07 at 18:14 +0200, Benjamin Herrenschmidt wrote:
quoted
quoted
The problem is that the radeonfb driver sees bpp = 32 and then sets
rgbt = 8/8/8/8. It stomps rgbt without looking at it.
Looks like a radeonfb bug.
It's not a bug :) radeonfb doesn't support anything but that format for
now.
According to Geert's rules, it should fail instead of rounding down
r/g/b.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
-------------------------------------------------------
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 16:53:08
On 8/7/05, Michel Dänzer [off-list ref] wrote:
On Sun, 2005-08-07 at 18:14 +0200, Benjamin Herrenschmidt wrote:
quoted
quoted
quoted
The problem is that the radeonfb driver sees bpp = 32 and then sets
rgbt = 8/8/8/8. It stomps rgbt without looking at it.
Looks like a radeonfb bug.
It's not a bug :) radeonfb doesn't support anything but that format for
now.
According to Geert's rules, it should fail instead of rounding down
r/g/b.
One problem with these rules is that it makes it hard to determine
what is the best config available. I can't just set in 255BPP and then
let it tell me the best available config.
What config should I get if everything is zero, BPP and rgbt?
According to the rules this is an error, should it instead return the
best config?
--
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: Michel Dänzer <hidden> Date: 2005-08-07 20:38:46
On Sun, 2005-08-07 at 12:53 -0400, Jon Smirl wrote:
On 8/7/05, Michel Dänzer [off-list ref] wrote:
quoted
On Sun, 2005-08-07 at 18:14 +0200, Benjamin Herrenschmidt wrote:
quoted
quoted
quoted
The problem is that the radeonfb driver sees bpp = 32 and then sets
rgbt = 8/8/8/8. It stomps rgbt without looking at it.
Looks like a radeonfb bug.
It's not a bug :) radeonfb doesn't support anything but that format for
now.
According to Geert's rules, it should fail instead of rounding down
r/g/b.
One problem with these rules is that it makes it hard to determine
what is the best config available. I can't just set in 255BPP and then
let it tell me the best available config.
If an app doesn't know its _minimum_ requirements, I doubt it wants 16
bits per component. If an app really needs the 'best' (how is that
defined?) config, it can try setting the best it supports and then lower
the requirements until it hits something that the driver supports.
What config should I get if everything is zero, BPP and rgbt?
According to the rules this is an error,
I haven't seen such a rule, where is it?
should it instead return the best config?
That sounds to me like the app doesn't care, so the driver can return
whatever it pleases.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
-------------------------------------------------------
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 Sun, 2005-08-07 at 18:14 +0200, Benjamin Herrenschmidt wrote:
quoted
quoted
quoted
The problem is that the radeonfb driver sees bpp = 32 and then sets
rgbt = 8/8/8/8. It stomps rgbt without looking at it.
Looks like a radeonfb bug.
It's not a bug :) radeonfb doesn't support anything but that format for
now.
According to Geert's rules, it should fail instead of rounding down
r/g/b.
They are not really `my' rules, just the original fbdev rules from 1994.
One problem with these rules is that it makes it hard to determine
what is the best config available. I can't just set in 255BPP and then
let it tell me the best available config.
Indeed. But you can more-or-less scan for modes.
What config should I get if everything is zero, BPP and rgbt?
According to the rules this is an error, should it instead return the
best config?
It's not an error, since you can round up from 0.
It depends on your hardware.
Monochrome or pseudocolor 1 bpp, if the hardware supports it.
Or 32 bpp ARGB8888, if that's all the hardware does.
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
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2005-08-07 20:47:24
Jon Smirl wrote:
On 8/7/05, Michel Dänzer [off-list ref] wrote:
quoted
On Sun, 2005-08-07 at 18:14 +0200, Benjamin Herrenschmidt wrote:
quoted
quoted
quoted
The problem is that the radeonfb driver sees bpp = 32 and then sets
rgbt = 8/8/8/8. It stomps rgbt without looking at it.
Looks like a radeonfb bug.
It's not a bug :) radeonfb doesn't support anything but that format for
now.
According to Geert's rules, it should fail instead of rounding down
r/g/b.
One problem with these rules is that it makes it hard to determine
what is the best config available. I can't just set in 255BPP and then
let it tell me the best available config.
What config should I get if everything is zero, BPP and rgbt?
According to the rules this is an error, should it instead return the
best config?
Rule is you can round-up but not round-down.
If bpp = 255, error.
If bpp = 0, return the nearest config ie, bpp8, argb8.
Also, drivers look at bpp first. Then it only looks at argb if there are
more than one format per bpp. That's what most user apps expect.
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