From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-12-02 07:05:26
THe title says it all, is fbcon supposed to work properly in 15/16 bpp
in 2.6 ? I tried making sure my palette was properly reset for the
new bit depth etc... in radeonfb, but I only ever get pink chars on
cyan background, I didn't do the color component math but it could
very well be just an endian bug in the 15/16 bpp drawing routines.
Ben.
(BTW. I never had any useful reply to my previous few questions about
the fbdev initialisation and about the mode settings...)
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
From: John Zielinski <hidden> Date: 2003-12-02 07:32:58
Benjamin Herrenschmidt wrote:
THe title says it all, is fbcon supposed to work properly in 15/16 bpp
in 2.6 ? I tried making sure my palette was properly reset for the
new bit depth etc... in radeonfb, but I only ever get pink chars on
cyan background, I didn't do the color component math but it could
very well be just an endian bug in the 15/16 bpp drawing routines.
I breifly tried it on one machine that had a Nvidia TNT2 in it and it
worked fine. I just tried it on my 9200 and I get the magenta/cyan
thing as well.
John
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-12-02 22:23:27
I breifly tried it on one machine that had a Nvidia TNT2 in it and it
worked fine. I just tried it on my 9200 and I get the magenta/cyan
thing as well.
Little or big endian machine ? Rivafb is accelerated in 2.6 (radeonfb
is not). Can you check if that makes any difference ? I'll do some
more tests here to try to figure it out, but so far, XFree had proper
colors even when using radeonfb (UseFBDev set to "true").
Ben.
-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8
From: John Zielinski <hidden> Date: 2003-12-02 22:53:22
Benjamin Herrenschmidt wrote:
Little or big endian machine ? Rivafb is accelerated in 2.6 (radeonfb
is not). Can you check if that makes any difference ? I'll do some
more tests here to try to figure it out, but so far, XFree had proper
colors even when using radeonfb (UseFBDev set to "true").
Little. It's an single processor Athalon box. I'll do the test later
tonight as I don't want to reboot the other machine at the moment.
John
-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-12-03 00:20:42
Little. It's an single processor Athalon box. I'll do the test later
tonight as I don't want to reboot the other machine at the moment.
Ok, so this isn't an endian problem in the cfb_ routines. Thanks.
I'll try to figure out what's up here as well later this week, I'm
a bit too busy with other things at the moment.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8
From: John Zielinski <hidden> Date: 2003-12-10 06:43:56
Benjamin Herrenschmidt wrote:
quoted
Little. It's an single processor Athalon box. I'll do the test later
tonight as I don't want to reboot the other machine at the moment.
Ok, so this isn't an endian problem in the cfb_ routines. Thanks.
I'll try to figure out what's up here as well later this week, I'm
a bit too busy with other things at the moment.
The riva driver doesn't have a switch to disable acceleration. I tried
changing the source but I keep crashing the machine.
John
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
From: John Zielinski <hidden> Date: 2003-12-23 23:17:12
Benjamin Herrenschmidt wrote:
quoted
Little. It's an single processor Athalon box. I'll do the test later
tonight as I don't want to reboot the other machine at the moment.
Ok, so this isn't an endian problem in the cfb_ routines. Thanks.
I'll try to figure out what's up here as well later this week, I'm
a bit too busy with other things at the moment.
Ben.
Here's a patch that fixed things on my machine. I found it by trial and
error since I don't have a hardware reference document and the code is a
little confusing to me. I don't know if this is the root cause or just
a fix for the symptoms. Changing the u16's to u32's fixed the verticle
grille appearance and most of the color corruption. Commenting out that
small block of code fixed the rest of the color problems.
I have a few questions. Why are we going through the palette instead of
just writing the proper directcolor/truecolor bitvalues for that color?
Does that have to do with the disabled HW acceleration code? Or is it
because the hw palette color components are 8 bits wide so the displayed
colors are more accurate?
And the code that I commented out, why is it accesing palette array
elements that have been set on a previous call or haven't been set yet?
Why is it trying to compensate for the wider green field when we're
programming 8 bit values to the hw palette?
My understanding of the low level video hardware control is very limited
beyond standard VGA register programming so I'm hoping to learn
something with all my questions. :)
John
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-12-24 01:45:39
Here's a patch that fixed things on my machine. I found it by trial and
error since I don't have a hardware reference document and the code is a
little confusing to me. I don't know if this is the root cause or just
a fix for the symptoms. Changing the u16's to u32's fixed the verticle
grille appearance and most of the color corruption. Commenting out that
small block of code fixed the rest of the color problems.
I have a few questions. Why are we going through the palette instead of
just writing the proper directcolor/truecolor bitvalues for that color?
Does that have to do with the disabled HW acceleration code? Or is it
because the hw palette color components are 8 bits wide so the displayed
colors are more accurate?
And the code that I commented out, why is it accesing palette array
elements that have been set on a previous call or haven't been set yet?
Why is it trying to compensate for the wider green field when we're
programming 8 bit values to the hw palette?
My understanding of the low level video hardware control is very limited
beyond standard VGA register programming so I'm hoping to learn
something with all my questions. :)
Intersting. The pseudo palette thing might have to be u32 indeed, I have
to double check. That sounds like a typical misdesign crap vs. endian
assuming a given value can be accessed via any size is a little endian
"feature" that doesn't work on BE.
The HW palette stuff for 16 bits is fine afaik (well, i wrote it ;), and it
works for XFree. What color problems do you have fixed when you comment
it out ?
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
From: John Zielinski <hidden> Date: 2003-12-24 02:55:15
Benjamin Herrenschmidt wrote:
Intersting. The pseudo palette thing might have to be u32 indeed, I have
to double check. That sounds like a typical misdesign crap vs. endian
assuming a given value can be accessed via any size is a little endian
"feature" that doesn't work on BE.
Except that this machine is LE. Perhaps the software blit routine is
writing the entire 32 bit value to the frambuffer?
The HW palette stuff for 16 bits is fine afaik (well, i wrote it ;), and it
works for XFree. What color problems do you have fixed when you comment
it out ?
With the commented code left in or just the OUTREG's commented:
Black -> Black
Blue -> Cyan
Green -> Black
Cyan -> Blue
Red -> Brown
Magenta -> Lt Green
Brown -> Brown
Lt Gray -> Lt Green
Dk Grey -> Dk Purple
Lt Blue -> Lt Blue
Lt Green -> Dk Purple
Lt Cyan -> Lt Blue
Lt Red -> Lt Red
Lt Magenta -> Lt Magenta
Yellow -> Lt Red
White -> Lt Magenta
With the OUTREG's left in and the "green =" line commented out:
Black -> Black
Blue -> Cyan
Green -> Black
Cyan -> Blue
Red -> Brown
Magenta -> Lt Green
Brown -> Brown
Lt Gray -> Lt Green
Dk Gray -> Dk Gray
Lt Blue -> Lt Blue
Lt Green -> Lt Green
Lt Cyan -> Lt Cyan
Lt Red -> Lt Red
Lt Magenta -> Lt Magenta
Yellow -> Yellow
White -> White
John
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-12-24 03:31:56
On Wed, 2003-12-24 at 13:54, John Zielinski wrote:
Benjamin Herrenschmidt wrote:
quoted
Intersting. The pseudo palette thing might have to be u32 indeed, I have
to double check. That sounds like a typical misdesign crap vs. endian
assuming a given value can be accessed via any size is a little endian
"feature" that doesn't work on BE.
Except that this machine is LE. Perhaps the software blit routine is
writing the entire 32 bit value to the frambuffer?
Possible.
quoted
The HW palette stuff for 16 bits is fine afaik (well, i wrote it ;), and it
works for XFree. What color problems do you have fixed when you comment
it out ?
With the commented code left in or just the OUTREG's commented:
Well, the interesting thing is does X using "fbdev" has proper colors
(or X using "ati" driver with UseFBDev option). If yes, then that code
is right. It's the console/blit code that is wrong.
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
From: John Zielinski <hidden> Date: 2003-12-24 04:45:38
Benjamin Herrenschmidt wrote:
Well, the interesting thing is does X using "fbdev" has proper colors
(or X using "ati" driver with UseFBDev option). If yes, then that code
is right. It's the console/blit code that is wrong.
Confirmed using fbtest. With that section commented out fbtest's colors
are messed up.
Hmmm.... Just found something. Here's an updated patch. Notice the 6
changing to a 5 in the 16 bit case. This makes the console and fbtest
look right.... except for the penguins. Their colors are messed up
depending on the test order.
John
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-12-24 05:23:45
On Wed, 2003-12-24 at 15:45, John Zielinski wrote:
Benjamin Herrenschmidt wrote:
quoted
Well, the interesting thing is does X using "fbdev" has proper colors
(or X using "ati" driver with UseFBDev option). If yes, then that code
is right. It's the console/blit code that is wrong.
Confirmed using fbtest. With that section commented out fbtest's colors
are messed up.
Hmmm.... Just found something. Here's an updated patch. Notice the 6
changing to a 5 in the 16 bit case. This makes the console and fbtest
look right.... except for the penguins. Their colors are messed up
depending on the test order.
Looks fine, I'll do tests here. What's up with the penguin ? (what do
you mean by "test order" ?)
Ben.
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
From: John Zielinski <hidden> Date: 2003-12-24 06:02:55
Benjamin Herrenschmidt wrote:
Looks fine, I'll do tests here. What's up with the penguin ? (what do
you mean by "test order" ?)
There are two penguin tests and Tux's colors are wrong in test004 but
not too bad in test009. But if you run test007 (the directcolor test)
before test004 by running "fbtest test007 test004" Tux looks ok for the
most part (has a green outline, looks like the poor fellow got nuked)
because test007 leaves the palette not quite linear.
A quick analysis looking at fbtest's debug output I noticed that before
test007 it uses a 555 color map and a 565 color map after test007. I'm
look at it in more detail tommorrow.
I've attached a couple of snips from the fbtest debug logs. The first
one is test004 only and the second one is test007 followed by test004.
John
On Wed, 24 Dec 2003, Benjamin Herrenschmidt wrote:
quoted
Here's a patch that fixed things on my machine. I found it by trial and
error since I don't have a hardware reference document and the code is a
little confusing to me. I don't know if this is the root cause or just
a fix for the symptoms. Changing the u16's to u32's fixed the verticle
grille appearance and most of the color corruption. Commenting out that
small block of code fixed the rest of the color problems.
Intersting. The pseudo palette thing might have to be u32 indeed, I have
to double check. That sounds like a typical misdesign crap vs. endian
assuming a given value can be accessed via any size is a little endian
"feature" that doesn't work on BE.
Yep, IIRC fb_info.pseudo_palette[] should always be an array of u32s in 2.6.
However, it's still `void *' in <linux/fb.h>. Perhaps this is fixed in James'
BK tree?
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
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
Looks fine, I'll do tests here. What's up with the penguin ? (what do
you mean by "test order" ?)
There are two penguin tests and Tux's colors are wrong in test004 but
not too bad in test009. But if you run test007 (the directcolor test)
before test004 by running "fbtest test007 test004" Tux looks ok for the
most part (has a green outline, looks like the poor fellow got nuked)
because test007 leaves the palette not quite linear.
A quick analysis looking at fbtest's debug output I noticed that before
test007 it uses a 555 color map and a 565 color map after test007. I'm
look at it in more detail tommorrow.
Strange...
I know there are some issues with the penguin in 24 bpp, though (penguin may
have blue feet and mouth).
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
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
From: John Zielinski <hidden> Date: 2003-12-24 21:34:32
Geert Uytterhoeven wrote:
I know there are some issues with the penguin in 24 bpp, though (penguin may
have blue feet and mouth).
I've done some digging and it's definitely because of how many palette
entries are updated for the 565 mode. What's the proper number of
entries that need to be updated for 565 mode, 32 or 64? I'll have to
check what the nvidia driver expects. I can't test 24 bpp as the driver
won't do that currently.
I've included the output of a simulation of the redeonfb_set_colreg
routine so you can see what I mean. I you look at the DAC dump you can
see that only the first 32 green entries actually get a value.
John
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-12-24 22:45:11
On Thu, 2003-12-25 at 08:34, John Zielinski wrote:
Geert Uytterhoeven wrote:
quoted
I know there are some issues with the penguin in 24 bpp, though (penguin may
have blue feet and mouth).
I've done some digging and it's definitely because of how many palette
entries are updated for the 565 mode. What's the proper number of
entries that need to be updated for 565 mode, 32 or 64? I'll have to
check what the nvidia driver expects. I can't test 24 bpp as the driver
won't do that currently.
64 but with only green mattering above 32 iirc, look what XFree does.
If XFree/fbdev works, then the fbdev is ok :)
--
Benjamin Herrenschmidt [off-list ref]
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
From: John Zielinski <hidden> Date: 2003-12-25 00:55:29
Benjamin Herrenschmidt wrote:
64 but with only green mattering above 32 iirc, look what XFree does.
Good. I'll make a patch for fbtest then.
If XFree/fbdev works, then the fbdev is ok :)
I'll have to look at the XFree code then to see what they're up to.
There's a lot of extra dac updates going on that just get overwritten
again. If you look at my simulation you can see that all the updates
by the second set of OUTREGs gets overwritten by the first set later
on. I even disabled the second set in my kernel for 16 bit modes and
everything still looks the same. That code is probably there for a
reason. I'm just trying to figure out why. :)
As you can see, the dac register 08 is written on the second call by the
second set of OUTREGs (OUT2:) and then overwritten by the first on the
third call to the function (OUT1). It's also grabbing a value for the
green component from palette array index 2 which hasn't beet updated yet
(that's what the !! means). I'm just curious why it's doing this and
what special case requires it....
John
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
On Thu, 25 Dec 2003, Benjamin Herrenschmidt wrote:
On Thu, 2003-12-25 at 08:34, John Zielinski wrote:
quoted
I've done some digging and it's definitely because of how many palette
entries are updated for the 565 mode. What's the proper number of
entries that need to be updated for 565 mode, 32 or 64? I'll have to
check what the nvidia driver expects. I can't test 24 bpp as the driver
won't do that currently.
64 but with only green mattering above 32 iirc, look what XFree does.
Yep, I can confirm that. The number of entries is 2 <<
max({red,green,blue,transp}.length).
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
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click