RE: radeonfb: strange blue lines after 'setterm -inversescreen on'

I D/L the 2.6.5 kernel,
And in drivers/video/console/ you want to look at fbcon.c
It has some cool functions: fbcon_invert_region, fbcon_putc[s], and
fbcon_erase

It sounds like for the drawn area, everything is working right. It's
only the overhang on the line that is not working right - its getting
filled with blue.

What happens on another manufacturer's card? The reason I ask that is I
saw no special stuff with the ATI card drivers. I think all of linux may
have this problem.

Can others out there on this list with 2.6 try -inverse?


-----Original Message-----
From: Jurriaan [mailto:[email protected]] 
Sent: Monday, April 05, 2004 2:38 PM
To: Hihn, Jason
Cc: [email protected]
Subject: Re: [Linux-fbdev-users] radeonfb: strange blue lines after
'setterm -inversescreen on'

From: Hihn, Jason <[email protected]>
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


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Linux-fbdev-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click