ATI Radeon DIRECTCOLOR -> TRUECOLOR patch

ATI Radeon DIRECTCOLOR -> TRUECOLOR patch

[Jonathan Campbell]

I wrote this patch several months ago against 2.6.27.4 out of personal 
preference (I don't think radeonfb has changed enough that it would fail 
against the current 2.6.28 all that much):

I'm pasting the URL here to avoid another round of discussion on whether 
or not my Mozilla Thunderbird client is mangling the patch:
http://nerdgrounds.com/linux-patches/linux-aty-force-truecolor.patch

I don't know about you but when I ask the framebuffer to set up 16-bit 
or 32-bit RGB modes I expect a video mode to be set up with R, G, and B 
mapped linearly so that I can display images properly, not some odd 
"directcolor" mode that seems to serve no other purpose than to avoid a 
few shifts converting the fbcon palette to an RGB triplet.

Looking at radeonfb: setting the framebuffer palette is accomplished by 
converting fbcon's RGB to 16bpp and storing that in a lookup table. 
Rendering of text for fbcon is done by referring to that lookup table, 
because radeonfb provides the 16bpp RGB values. So what exactly is 
abusing the palette/gamma registers to make a nonstandard RGB ramp 
supposed to accomplish? Is something like this that might make an 
infrequently called function like setcolor() 10 nanoseconds faster 
really worth it?

When my software running and periodically showing what dvgrab last wrote 
to disk the last thing I want clients to see when walking by is a bad 
acid trip rendition of what we're filming on camera just because 
radeonfb decided to use DIRECTCOLOR and some weird RGB ramp.

This patch changes radeonfb to remove DIRECTCOLOR behavior and act like 
a proper TRUECOLOR framebuffer. I consider it a cleaner option than 
having to use KD_GRAPHICS (XFree86), which locks out the framebuffer 
console, or CMAP ioctls (mplayer), which makes the mapping correct but 
then makes the framebuffer console's text dark purple and hard to see.

So far I've tested on three machines that I know have ATI-based video 
chipsets:
     An AMD64 dual-core 32-bit system, and two ppc-based machines, one a 
mac mini and the other a Powerbook G4.

If anyone still needs this weird DIRECTCOLOR behavior I'd be willing to 
make the patch into one that allows you to choose as an option in "make 
menuconfig"

and... a quick glance reveals that nvidiafb pulls this stunt too. anyone 
want a patch for that too?

Re: ATI Radeon DIRECTCOLOR -> TRUECOLOR patch

[David Miller]

From: Jonathan Campbell <jon@nerdgrounds.com>
Date: Wed, 25 Feb 2009 03:24:35 -0800

[ Ben H. is the Radeon driver maintainer, as listed in
  linux/MAINTAINERS, you might want to CC: him ]

> I don't know about you but when I ask the framebuffer to set up
> 16-bit or 32-bit RGB modes I expect a video mode to be set up with
> R, G, and B mapped linearly so that I can display images properly,
> not some odd "directcolor" mode that seems to serve no other purpose
> than to avoid a few shifts converting the fbcon palette to an RGB
> triplet.

It might be using DIRECTCOLOR for compatibility with openfirmware,
BOOTX, or similar on PowerPC.

Ben?

Re: ATI Radeon DIRECTCOLOR -> TRUECOLOR patch

[Benjamin Herrenschmidt]

On Wed, 2009-02-25 at 03:57 -0800, David Miller wrote:
> From: Jonathan Campbell <jon@nerdgrounds.com>
> Date: Wed, 25 Feb 2009 03:24:35 -0800
> 
> [ Ben H. is the Radeon driver maintainer, as listed in
>   linux/MAINTAINERS, you might want to CC: him ]
> 
> > I don't know about you but when I ask the framebuffer to set up
> > 16-bit or 32-bit RGB modes I expect a video mode to be set up with
> > R, G, and B mapped linearly so that I can display images properly,
> > not some odd "directcolor" mode that seems to serve no other purpose
> > than to avoid a few shifts converting the fbcon palette to an RGB
> > triplet.
> 
> It might be using DIRECTCOLOR for compatibility with openfirmware,
> BOOTX, or similar on PowerPC.

Hrm, the kernel fb layer does seem to do strange things with the palette
for >8bpp stuff indeed. I'm not entirely sure why.

The problem if you switch to truecolor is that you remove the ability to
set the gamma ramp completely which some apps use.

Normally, I'd say it's the responsibility of your application, when it's
displaying pictures, to set an appropriate cmap. If you don't like the
one set by fbcon for displaying text, just set another one. Ie. You
aren't -supposed- to mix graphics and fbcon text from an application...
if you're going to blast to the fb, you should switch to KD_GRAPHICS (ie
take ownership of the VT) and set a linear ramp yourself.

Cheers,
Ben.

Re: ATI Radeon DIRECTCOLOR -> TRUECOLOR patch

[Jonathan Campbell]

  But at the very least could radeonfb default to truecolor-like 
behavior and leave the bizarre ramp mapping for programs that want it?
> On Wed, 2009-02-25 at 03:57 -0800, David Miller wrote:
>> From: Jonathan Campbell <jon@nerdgrounds.com>
>> Date: Wed, 25 Feb 2009 03:24:35 -0800
>>
>> [ Ben H. is the Radeon driver maintainer, as listed in
>>   linux/MAINTAINERS, you might want to CC: him ]
>>
>>> I don't know about you but when I ask the framebuffer to set up
>>> 16-bit or 32-bit RGB modes I expect a video mode to be set up with
>>> R, G, and B mapped linearly so that I can display images properly,
>>> not some odd "directcolor" mode that seems to serve no other purpose
>>> than to avoid a few shifts converting the fbcon palette to an RGB
>>> triplet.
>> It might be using DIRECTCOLOR for compatibility with openfirmware,
>> BOOTX, or similar on PowerPC.
>
> Hrm, the kernel fb layer does seem to do strange things with the palette
> for >8bpp stuff indeed. I'm not entirely sure why.
>
> The problem if you switch to truecolor is that you remove the ability to
> set the gamma ramp completely which some apps use.
>
> Normally, I'd say it's the responsibility of your application, when it's
> displaying pictures, to set an appropriate cmap. If you don't like the
> one set by fbcon for displaying text, just set another one. Ie. You
> aren't -supposed- to mix graphics and fbcon text from an application...
> if you're going to blast to the fb, you should switch to KD_GRAPHICS (ie
> take ownership of the VT) and set a linear ramp yourself.
>
> Cheers,
> Ben.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

Re: ATI Radeon DIRECTCOLOR -> TRUECOLOR patch

[Benjamin Herrenschmidt]

On Wed, 2009-02-25 at 13:00 -0800, Jonathan Campbell wrote:
> But at the very least could radeonfb default to truecolor-like
> behavior and leave the bizarre ramp mapping for programs that want it?

I don't understand your problem. Radeonfb does like other fbdev's in
that area. It has settable gamma ramp for which there's an API, and the
fbdev core is making use of it....

Just stick a linear ramp in from your program, that's the way to do go.

Cheers,
Ben.

> > On Wed, 2009-02-25 at 03:57 -0800, David Miller wrote:
> >   
> > > From: Jonathan Campbell <jon@nerdgrounds.com>
> > > Date: Wed, 25 Feb 2009 03:24:35 -0800
> > > 
> > > [ Ben H. is the Radeon driver maintainer, as listed in
> > >   linux/MAINTAINERS, you might want to CC: him ]
> > > 
> > >     
> > > > I don't know about you but when I ask the framebuffer to set up
> > > > 16-bit or 32-bit RGB modes I expect a video mode to be set up with
> > > > R, G, and B mapped linearly so that I can display images properly,
> > > > not some odd "directcolor" mode that seems to serve no other purpose
> > > > than to avoid a few shifts converting the fbcon palette to an RGB
> > > > triplet.
> > > >       
> > > It might be using DIRECTCOLOR for compatibility with openfirmware,
> > > BOOTX, or similar on PowerPC.
> > >     
> > 
> > Hrm, the kernel fb layer does seem to do strange things with the palette
> > for >8bpp stuff indeed. I'm not entirely sure why.
> > 
> > The problem if you switch to truecolor is that you remove the ability to
> > set the gamma ramp completely which some apps use.
> > 
> > Normally, I'd say it's the responsibility of your application, when it's
> > displaying pictures, to set an appropriate cmap. If you don't like the
> > one set by fbcon for displaying text, just set another one. Ie. You
> > aren't -supposed- to mix graphics and fbcon text from an application...
> > if you're going to blast to the fb, you should switch to KD_GRAPHICS (ie
> > take ownership of the VT) and set a linear ramp yourself.
> > 
> > Cheers,
> > Ben.
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
> >   
>