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

[Geert U. <ge...@li...>]

On Thu, 8 Apr 2004, Jurriaan wrote:
> From: Benjamin Herrenschmidt <be...@ke...>
> Date: Thu, Apr 08, 2004 at 09:41:24AM +1000
> > > This is obviously a hack, and only works in 32-bits color.
> > >
> > > I would be interested in the view of the maintainer. If this is the
> > > right solution, do you want a patch that tries to fix this?
> > >
> > > Thanks everyone for mailing back-and-forth, and testing. Please test if
> > > this fixes the problem on your radeon-machine as well, if possible.
> >
> > I haven't done any work related to accel functions, so you
> > are welcome to experiment and fix ;)
> >
> > Ben.
> >
> Ben, could you please push this patch into the vanilla kernel? Or better
> still, in Andrew Morton's -mc tree?
>
> It fixes the problems with 32bpp for me and other people, and also works
> for me in 16bpp.
>
> diff -Br -b -U 3 -N linux-2.6.5/drivers/video/aty/radeon_accel.c linux-2.6.5-new/drivers/video/aty/radeon_accel.c
> --- linux-2.6.5/drivers/video/aty/radeon_accel.c	2004-02-18 04:58:34.000000000 +0100
> +++ linux-2.6.5-new/drivers/video/aty/radeon_accel.c	2004-04-08 20:58:01.000000000 +0200
> @@ -7,13 +7,33 @@
>  static void radeonfb_prim_fillrect(struct radeonfb_info *rinfo,
>  				   const struct fb_fillrect *region)
>  {
> +	u32 color;
> +
>  	radeon_fifo_wait(4);
>
>  	OUTREG(DP_GUI_MASTER_CNTL,
>  		rinfo->dp_gui_master_cntl  /* contains, like GMC_DST_32BPP */
>                  | GMC_BRUSH_SOLID_COLOR
>                  | ROP3_P);
> -	OUTREG(DP_BRUSH_FRGD_CLR, region->color);
> +	switch(radeon_get_dstbpp(rinfo->depth)) {
> +	        case DST_32BPP:
> +			color = region->color | (region->color << 8);
> +			color = color | (color << 16);
> +			break;
> +                /* DST_24BPP isn't implemented */
> +	        case DST_16BPP:
> +			color = region->color | (region->color << 11) | (region->color << 5);
> +			break;
> +	        case DST_15BPP:
> +			color = region->color | (region->color << 10) | (region->color << 5);
> +			break;
> +	        case DST_8BPP:
> +		default:
> +			color = region->color;
> +			break;
> +	}
> +
> +	OUTREG(DP_BRUSH_FRGD_CLR, color);
>  	OUTREG(DP_WRITE_MSK, 0xffffffff);
>  	OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM));

So why can't you just use pseudo_palette[region->color], for truecolor and
directcolor visuals? Saves some switches and bit manipulations.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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