Re: [Linux-fbdev-users] radeonfb: strange blue lines after 'setterm -inversescreen on'

[Jurriaan <thu...@xs...>]

From: Hihn, Jason <Jas...@ve...>
Date: Mon, Apr 05, 2004 at 02:46:43PM -0400

[sorry for remailing this private mail to the list again, but I hope
others will chime in]

> I don't know the 2.6 kernel tree, but I'd suspect radeonfb.c

unfortunately, that file doesn't exist in 2.6, which proves your first
point :-)

> 
> The low-level pixel get/set routines probably have a simple bit shift
> (<< >>) or mask (& |) error. "-inverse" was probably not taken into
> account when the code was written so the math is a little off. As far as
> I know, linux treats 24b as the same as 32, so maybe that's why your 24b
> isn't working, no one bothered to code it because you have to align on
> 4-byte boundaries  anyway (no one packs 3 bytes adjacent to 3 bytes,
> because it is too much work, you'd have to move then shift, and it gets
> messy and slow.). So someone would have written for 24, but in the end
> called it 32, so it's that extra byte that isn't being handled right.
> 
> I could probably fix it, if I had a radeon card and a 2.6 kernel and
> some time. Sorry.

I've since found out that the 24-bits is disallowed on purpose.

drivers/video/aty/radeon_base.c:
static int radeonfb_check_var (struct fb_var_screeninfo *var, struct fb_info *info)
{
		case 17 ... 24:
#if 0 /* Doesn't seem to work */
			v.bits_per_pixel = 24;
			break;
#endif			
			return -EINVAL;

I'm willing to send a radeon-card to somebody who is willing to invest
some time and install a 2.6 kernel. You perhaps?

A quick look through the radeon source doesn't show me any bit shift or
masks - all I see is using the acceleration engine, which is kind of
mumbo-jumbo for the un-initiated.

Could you perhaps point at certain routines that would be prime
suspects?

Thanks,
Jurriaan
-- 
A seminar on Time Travel will be held two weeks ago.
Debian (Unstable) GNU/Linux 2.6.5-rc3-mm3 2x6062 bogomips 0.06 0.39