From: Hihn, J. <Jas...@ve...> - 2004-04-05 17:34:30
|
Just a guess... I'm not in 2.6, but it looks like the math to do the inverse screen is only using 24 bits, not 32. What is it like in 24bpp? Visually: *** (inverse mask) aRGB =3D 00 00 00 FF ^^^ (normal mask) So it looks like there may be some 24/32 bit shifting going awry when -inversescreen is set. Dunno. -----Original Message----- From: Jurriaan [mailto:thu...@xs...]=20 Sent: Monday, April 05, 2004 12:23 PM To: lin...@li... Subject: [Linux-fbdev-users] radeonfb: strange blue lines after 'setterm -inversescreen on' If I boot linux-2.6.5, with a radeonfb framebuffer 1600x1200-32@75, I get white letters on a black background. Fine. If I issue the command setterm -inversescreen on, I get black letters on a white background. So far so good. Now if I press enter, I get a new line with black letters on a white background, but everything after the cursor is blue. Switching consoles (alt-f2, alt-f1) removes the blue line. Issuing 'clear' gives an entire blue screen after the cursor (so a small part, the prompt, stays black-on-white). This is with a radeon 9000 and with a radeon 7000, so it must be something in general. Incidentally, blue is also the color the overscan area gets. This has been happening on all 2.6.x kernels going back months. Is there something obvious I can check? A newer and better radeonfb driver to download somewhere? Thanks, Jurriaan --=20 The reason that lightning doesn't strike twice in the same place is that the same place isn't there the second time. Debian (Unstable) GNU/Linux 2.6.5-rc3-mm3 2x6356 bogomips 0.30 0.13 ------------------------------------------------------- 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=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Linux-fbdev-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users |
From: Hihn, J. <Jas...@ve...> - 2004-04-05 18:46:54
|
I don't know the 2.6 kernel tree, but I'd suspect radeonfb.c 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. -----Original Message----- From: Jurriaan [mailto:thu...@xs...]=20 Sent: Monday, April 05, 2004 1:30 PM To: Hihn, Jason Cc: lin...@li... Subject: Re: [Linux-fbdev-users] radeonfb: strange blue lines after 'setterm -inversescreen on' From: Hihn, Jason <Jas...@ve...> Date: Mon, Apr 05, 2004 at 01:34:16PM -0400 > Just a guess... I'm not in 2.6, but it looks like the math to do the > inverse screen is only using 24 bits, not 32. What is it like in 24bpp? > Visually: > *** (inverse mask) > aRGB =3D 00 00 00 FF > ^^^ (normal mask) > So it looks like there may be some 24/32 bit shifting going awry when > -inversescreen is set. >=20 This is a step in the right direction: 1600x1200-8@75: ok 1600x1200-16@75: blue screen 1600x1200-24@75: 'no mode found' in dmesg? 1600x1200-32@75: blue screen apropos 24 bits: Kernel command line: root=3D/dev/hda3 video=3Dradeonfb:1600x1200-24@75 acpi=3Dforce radeonfb_pci_register BEGIN radeonfb: probed DDR SGRAM 65536k videoram radeonfb: mapped 16384k videoram radeonfb: Found Intel x86 BIOS ROM Image radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=3D27.00 MHz (RefDiv=3D60) Memory=3D166.00 Mhz, System=3D166.00 MHz radeonfb: No connector info table detected Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... not found radeonfb: I2C (port 4) ... not found radeonfb: Monitor 1 type CRT found radeonfb: ATI Radeon QD DDR SGRAM 64 MB radeonfb_pci_register END Starting balanced_irq ikconfig 0.7 with /proc/config* Installing knfsd (copyright (C) 1996 ok...@mo...). udf: registering filesystem Limiting direct PCI/PCI transfers. ACPI: Power Button (FF) [PWRF] ACPI: Processor [CPU] (supports C1) ACPI: Processor [CPU1] (supports C1) ACPI: Thermal Zone [THRM] (28 C) hStart =3D 664, hEnd =3D 760, hTotal =3D 800 vStart =3D 491, vEnd =3D 493, vTotal =3D 525 h_total_disp =3D 0x4f0063 hsync_strt_wid =3D 0x8c02a2 v_total_disp =3D 0x1df020c vsync_strt_wid =3D 0x8201ea pixclock =3D 39721 freq =3D 2517 post div =3D 0x3 fb_div =3D 0x1bf ppll_div_3 =3D 0x301bf lvds_gen_cntl: 00000000 Console: switching to colour frame buffer device 53x21 Well, b*gger. Did I mention I use the 12x22 font from sun? Anyway, going to 8 bits color-depth solves my problem, but I'd rather watch some photo's in at least 16-bit color depth. What part of the driver is suspect? Thanks, Jurriaan > If I boot linux-2.6.5, with a radeonfb framebuffer 1600x1200-32@75, I > get white letters on a black background. Fine. If I issue the command > setterm -inversescreen on, I get black letters on a white background. >=20 > So far so good. >=20 > Now if I press enter, I get a new line with black letters on a white > background, but everything after the cursor is blue. >=20 > Switching consoles (alt-f2, alt-f1) removes the blue line. > Issuing 'clear' gives an entire blue screen after the cursor (so a small > part, the prompt, stays black-on-white). >=20 > This is with a radeon 9000 and with a radeon 7000, so it must be > something in general. Incidentally, blue is also the color the overscan > area gets. >=20 > This has been happening on all 2.6.x kernels going back months. >=20 --=20 Someone's stained Someone's gained Us or was it them? The men they couldn't hang - Rosettes Debian (Unstable) GNU/Linux 2.6.5-rc3-mm3 2x6062 bogomips 0.52 0.19 ------------------------------------------------------- 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=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Linux-fbdev-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users |
From: Jurriaan <thu...@xs...> - 2004-04-05 19:37:47
|
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 |
From: Hihn, J. <Jas...@ve...> - 2004-04-06 16:10:26
|
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:thu...@xs...]=20 Sent: Monday, April 05, 2004 2:38 PM To: Hihn, Jason Cc: lin...@li... Subject: Re: [Linux-fbdev-users] radeonfb: strange blue lines after 'setterm -inversescreen on' 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 :-) >=20 > 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. >=20 > 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 =3D 24; break; #endif =09 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 --=20 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=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Linux-fbdev-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users |
From: Jurriaan <thu...@xs...> - 2004-04-06 17:52:48
|
From: Hihn, Jason <Jas...@ve...> Date: Tue, Apr 06, 2004 at 12:10:12PM -0400 > 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 yes, but (*) > > 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. correct > > 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. * my matrox framebuffer has never had this problem, so the 'general' routines in fbcon.c should be OK. Also, I don't remember this from tdfx (Voodoo 4500) framebuffer testing. > > Can others out there on this list with 2.6 try -inverse? > At the moment, I only have Ati and Matrox cards, Ati has the problem, Matrox doesn't. I also tested with a 8x16 font, instead of my regular 12x22 font, but that didn't make any difference. Kind regards, Jurriaan -- "Bother", said Pooh, as he scrambled his partition table. Debian (Unstable) GNU/Linux 2.6.5-rc3-mm3 2x6062 bogomips 0.54 0.29 |
From: Jurriaan <thu...@xs...> - 2004-04-07 16:34:22
|
From: Jurriaan <thu...@xs...> Date: Tue, Apr 06, 2004 at 07:52:25PM +0200 > > At the moment, I only have Ati and Matrox cards, Ati has the problem, > Matrox doesn't. I also tested with a 8x16 font, instead of my regular > 12x22 font, but that didn't make any difference. > Small update: if I set the default cursor to CUR_NONE in include/linux/console_struct.h, the problem stays the same. That would rule out anything to do with cursor generation, right? Also, a vesafb framebuffer on laptop's S3 Savage doesn't show the problem. I repeat my offer: I'll send an Ati video-card free of charge to anyone who offers to track this bug down. Kind regards, Jurriaan -- Debian (Unstable) GNU/Linux 2.6.5-mm1 2x6062 bogomips 1.03 1.00 |
From: Jurriaan <thu...@xs...> - 2004-04-07 19:32:15
|
From: Jurriaan <thu...@xs...> Date: Wed, Apr 07, 2004 at 06:33:52PM +0200 > From: Jurriaan <thu...@xs...> > Date: Tue, Apr 06, 2004 at 07:52:25PM +0200 > > > > At the moment, I only have Ati and Matrox cards, Ati has the problem, > > Matrox doesn't. I also tested with a 8x16 font, instead of my regular > > 12x22 font, but that didn't make any difference. > > Carefull experimentation, and browsing in the 2.4.25 and xfree86 sources has shown: 1) in radeon_accel.c, calling cfb_fillrect() in radeonfb_fillrect makes the problem go away, but this disables (part of) the accelerated routines. void radeonfb_fillrect(struct fb_info *info, const struct fb_fillrect *region) { struct radeonfb_info *rinfo = info->par; struct fb_fillrect modded; int vxres, vyres; if (info->state != FBINFO_STATE_RUNNING) return; - if (radeon_accel_disabled()) { + if (1 || radeon_accel_disabled()) { cfb_fillrect(info, region); return; } 2) in 2.4.25, there is something different about the color handling. In particular, radeonfb.c:rectfill() operates on clr, where clr is defined differently, depending on the color-depth of the display: #ifdef FBCON_HAS_CFB32 static void fbcon_radeon32_clear(struct vc_data *conp, struct display *p, int srcy, int srcx, int height, int width) { struct radeonfb_info *rinfo = (struct radeonfb_info *)(p->fb_info); u32 clr; clr = ((u32 *)p->dispsw_data)[attr_bgcol_ec(p, conp)]; srcx *= fontwidth(p); srcy *= fontheight(p); width *= fontwidth(p); height *= fontheight(p); radeon_rectfill(rinfo, srcy, srcx, height, width, clr); } essentially, p_dispsw_data contains for a given 8-bit color value x x | (x << 8) | (x << 16) | (x << 24) so 0x07 becomes 0x07070707 3) If I adapt 2.6's radeon_accel.c:radeonfb_prim_fillrect() like this: static void radeonfb_prim_fillrect(struct radeonfb_info *rinfo, const struct fb_fillrect *region) { int 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); color = region->color | (region->color << 8); color = color | (color << 16); OUTREG(DP_BRUSH_FRGD_CLR, color); OUTREG(DP_WRITE_MSK, 0xffffffff); OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM)); radeon_fifo_wait(2); OUTREG(DST_Y_X, (region->dy << 16) | region->dx); OUTREG(DST_WIDTH_HEIGHT, (region->width << 16) | region->height); } my problem is solved. Previously, it just read OUTREG(DP_BRUSH_FRGD_CLR, region->color); 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. Jurriaan -- And all the while, all the while, I still hear that call To the land of gold and poison that beckons to us all Do you think you're so brave just to go running to that which beckons to us all? New Model Army - Valleys of Green and Grey Debian (Unstable) GNU/Linux 2.6.5-mm1 2x6062 bogomips 0.14 0.11 |
From: Jean D. <kh...@li...> - 2004-04-07 20:24:18
|
> Thanks everyone for mailing back-and-forth, and testing. Please test > if this fixes the problem on your radeon-machine as well, if possible. Please provide a clean patch against 2.6.5 if you want me to test. Thanks. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ |
From: Benjamin H. <be...@ke...> - 2004-04-07 23:42:22
|
> > 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. |
From: Jurriaan <thu...@xs...> - 2004-04-08 19:09:08
|
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)); Thanks, Jurriaan -- Did you save your face Did you breach your faith Midnight Oil - My Country Debian (Unstable) GNU/Linux 2.6.5-mm1 2x6062 bogomips 2.76 1.66 |
From: Geert U. <ge...@li...> - 2004-04-09 08:47:14
|
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 |
From: Jurriaan <thu...@xs...> - 2004-04-09 17:44:39
|
From: Geert Uytterhoeven <ge...@li...> Date: Fri, Apr 09, 2004 at 10:46:54AM +0200 > > So why can't you just use pseudo_palette[region->color], for truecolor and > directcolor visuals? Saves some switches and bit manipulations. > Ok, new try: 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-09 19:26:43.000000000 +0200 @@ -13,6 +13,9 @@ rinfo->dp_gui_master_cntl /* contains, like GMC_DST_32BPP */ | GMC_BRUSH_SOLID_COLOR | ROP3_P); + if (radeon_get_dstbpp(rinfo->depth) != DST_8BPP) + OUTREG(DP_BRUSH_FRGD_CLR, rinfo->pseudo_palette[region->color]); + else OUTREG(DP_BRUSH_FRGD_CLR, region->color); OUTREG(DP_WRITE_MSK, 0xffffffff); OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM)); Everybody happy with this? Then please push it into the kernel! Thanks, Jurriaan -- This Vintage Whine was fermented from two years worth of sour grapes harvested in the northern regions of The British Isles. Its bitter aftertaste makes it the ideal accompaniment for hard cheese and humble pie. Perfect for divorces, suicides and all other antisocial occasions. Serve chilled. Inlay from Skyclad - Vintage Whine Debian (Unstable) GNU/Linux 2.6.5-mm1 2x6062 bogomips load av: 1.79 3.65 3.06 |
From: Jurriaan <thu...@xs...> - 2004-04-09 18:02:52
|
From: Jurriaan <thu...@xs...> Date: Fri, Apr 09, 2004 at 07:44:07PM +0200 Bah, new try with correct whitespace: diff -Br -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-09 19:26:43.000000000 +0200 @@ -13,7 +13,10 @@ rinfo->dp_gui_master_cntl /* contains, like GMC_DST_32BPP */ | GMC_BRUSH_SOLID_COLOR | ROP3_P); - OUTREG(DP_BRUSH_FRGD_CLR, region->color); + if (radeon_get_dstbpp(rinfo->depth) != DST_8BPP) + OUTREG(DP_BRUSH_FRGD_CLR, rinfo->pseudo_palette[region->color]); + else + OUTREG(DP_BRUSH_FRGD_CLR, region->color); OUTREG(DP_WRITE_MSK, 0xffffffff); OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM)); Jurriaan -- Don't ever trust the needle It lies Queensryche - Operation Mindcrime Debian (Unstable) GNU/Linux 2.6.5-mm1 2x6062 bogomips 0.88 0.90 |
From: Jurriaan <thu...@xs...> - 2004-04-07 20:45:16
|
From: Jean Delvare <kh...@li...> Date: Wed, Apr 07, 2004 at 10:24:15PM +0200 > > Thanks everyone for mailing back-and-forth, and testing. Please test > > if this fixes the problem on your radeon-machine as well, if possible. > > Please provide a clean patch against 2.6.5 if you want me to test. > Try this (warning: this only works in 32bpp, and will probably do strange things with other color depths; it's a proof-of-concept). 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-07 22:40:41.000000000 +0200 @@ -7,13 +7,16 @@ static void radeonfb_prim_fillrect(struct radeonfb_info *rinfo, const struct fb_fillrect *region) { + int 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); + color = region->color | (region->color << 8); + color = color | (color << 16); + OUTREG(DP_BRUSH_FRGD_CLR, color); OUTREG(DP_WRITE_MSK, 0xffffffff); OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM)); Let me know if it works for you! Jurriaan -- I'd like to, but I've been scheduled for a karma transplant. Debian (Unstable) GNU/Linux 2.6.5-mm1 2x6062 bogomips 0.32 0.15 |
From: Geert U. <ge...@li...> - 2004-04-08 08:08:14
|
On Wed, 7 Apr 2004, Jurriaan wrote: > From: Jean Delvare <kh...@li...> > Date: Wed, Apr 07, 2004 at 10:24:15PM +0200 > > > Thanks everyone for mailing back-and-forth, and testing. Please test > > > if this fixes the problem on your radeon-machine as well, if possible. > > > > Please provide a clean patch against 2.6.5 if you want me to test. > > > Try this (warning: this only works in 32bpp, and will probably do > strange things with other color depths; it's a proof-of-concept). > > 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-07 22:40:41.000000000 +0200 > @@ -7,13 +7,16 @@ > static void radeonfb_prim_fillrect(struct radeonfb_info *rinfo, > const struct fb_fillrect *region) > { > + int color; ^^^ You better make this u32. > 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); > + color = region->color | (region->color << 8); > + color = color | (color << 16); > + OUTREG(DP_BRUSH_FRGD_CLR, color); > OUTREG(DP_WRITE_MSK, 0xffffffff); > OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM)); > > Let me know if it works for you! 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 |
From: James S. <jsi...@in...> - 2004-04-07 21:32:44
|
You are really close. The problem is mapping rect->color to the real color. Take a look at cfbfillrect.c. We have if (p->fix.visual == FB_VISUAL_TRUECOLOR || p->fix.visual == FB_VISUAL_DIRECTCOLOR) fg = ((u32 *) (p->pseudo_palette))[rect->color]; else fg = rect->color; Give this a try. fg is u32. On Wed, 7 Apr 2004, Jurriaan wrote: > From: Jean Delvare <kh...@li...> > Date: Wed, Apr 07, 2004 at 10:24:15PM +0200 > > > Thanks everyone for mailing back-and-forth, and testing. Please test > > > if this fixes the problem on your radeon-machine as well, if possible. > > > > Please provide a clean patch against 2.6.5 if you want me to test. > > > Try this (warning: this only works in 32bpp, and will probably do > strange things with other color depths; it's a proof-of-concept). > > 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-07 22:40:41.000000000 +0200 > @@ -7,13 +7,16 @@ > static void radeonfb_prim_fillrect(struct radeonfb_info *rinfo, > const struct fb_fillrect *region) > { > + int 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); > + color = region->color | (region->color << 8); > + color = color | (color << 16); > + OUTREG(DP_BRUSH_FRGD_CLR, color); > OUTREG(DP_WRITE_MSK, 0xffffffff); > OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM)); > > Let me know if it works for you! > > Jurriaan > |
From: Jean D. <kh...@li...> - 2004-04-08 18:28:48
|
> Try this (warning: this only works in 32bpp, and will probably do > strange things with other color depths; it's a proof-of-concept). Confirmed, it fixes the blue screen issue in 32bpp for me too. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ |
From: Hihn, J. <Jas...@ve...> - 2004-04-07 19:50:49
|
I knew you could do it! And I'm glad I was barking up the right tree! (It makes me look like I know my stuff ;-) ) -----Original Message----- From: Jurriaan [mailto:thu...@xs...]=20 Sent: Wednesday, April 07, 2004 2:32 PM To: Hihn, Jason Cc: lin...@li...; be...@ke... Subject: Re: [Linux-fbdev-users] radeonfb: strange blue lines after 'setterm -inversescreen on' From: Jurriaan <thu...@xs...> Date: Wed, Apr 07, 2004 at 06:33:52PM +0200 > From: Jurriaan <thu...@xs...> > Date: Tue, Apr 06, 2004 at 07:52:25PM +0200 > >=20 > > At the moment, I only have Ati and Matrox cards, Ati has the problem, > > Matrox doesn't. I also tested with a 8x16 font, instead of my regular > > 12x22 font, but that didn't make any difference. > >=20 Carefull experimentation, and browsing in the 2.4.25 and xfree86 sources has shown: 1) in radeon_accel.c, calling cfb_fillrect() in radeonfb_fillrect makes the problem go away, but this disables (part of) the accelerated routines. void radeonfb_fillrect(struct fb_info *info, const struct fb_fillrect *region) { struct radeonfb_info *rinfo =3D info->par; struct fb_fillrect modded; int vxres, vyres; if (info->state !=3D FBINFO_STATE_RUNNING) return; - if (radeon_accel_disabled()) { + if (1 || radeon_accel_disabled()) { cfb_fillrect(info, region); return; } 2) in 2.4.25, there is something different about the color handling. In particular, radeonfb.c:rectfill() operates on clr, where clr is defined differently, depending on the color-depth of the display: #ifdef FBCON_HAS_CFB32 static void fbcon_radeon32_clear(struct vc_data *conp, struct display *p, int srcy, int srcx, int height, int width) { struct radeonfb_info *rinfo =3D (struct radeonfb_info *)(p->fb_info); u32 clr; clr =3D ((u32 *)p->dispsw_data)[attr_bgcol_ec(p, conp)]; srcx *=3D fontwidth(p); srcy *=3D fontheight(p); width *=3D fontwidth(p); height *=3D fontheight(p); radeon_rectfill(rinfo, srcy, srcx, height, width, clr); } essentially, p_dispsw_data contains for a given 8-bit color value x x | (x << 8) | (x << 16) | (x << 24) so 0x07 becomes 0x07070707 3) If I adapt 2.6's radeon_accel.c:radeonfb_prim_fillrect() like this: static void radeonfb_prim_fillrect(struct radeonfb_info *rinfo, const struct fb_fillrect *region) { int 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); color =3D region->color | (region->color << 8); color =3D color | (color << 16); OUTREG(DP_BRUSH_FRGD_CLR, color); OUTREG(DP_WRITE_MSK, 0xffffffff); OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM)); radeon_fifo_wait(2); OUTREG(DST_Y_X, (region->dy << 16) | region->dx); OUTREG(DST_WIDTH_HEIGHT, (region->width << 16) | region->height); } my problem is solved. Previously, it just read OUTREG(DP_BRUSH_FRGD_CLR, region->color); This is obviously a hack, and only works in 32-bits color.=20 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. Jurriaan --=20 And all the while, all the while, I still hear that call To the land of gold and poison that beckons to us all Do you think you're so brave just to go running to that which beckons to us all? New Model Army - Valleys of Green and Grey Debian (Unstable) GNU/Linux 2.6.5-mm1 2x6062 bogomips 0.14 0.11 ------------------------------------------------------- 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=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Linux-fbdev-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-fbdev-users |
From: Jurriaan <thu...@xs...> - 2004-04-05 18:30:16
|
From: Hihn, Jason <Jas...@ve...> Date: Mon, Apr 05, 2004 at 01:34:16PM -0400 > Just a guess... I'm not in 2.6, but it looks like the math to do the > inverse screen is only using 24 bits, not 32. What is it like in 24bpp? > Visually: > *** (inverse mask) > aRGB = 00 00 00 FF > ^^^ (normal mask) > So it looks like there may be some 24/32 bit shifting going awry when > -inversescreen is set. > This is a step in the right direction: 1600x1200-8@75: ok 1600x1200-16@75: blue screen 1600x1200-24@75: 'no mode found' in dmesg? 1600x1200-32@75: blue screen apropos 24 bits: Kernel command line: root=/dev/hda3 video=radeonfb:1600x1200-24@75 acpi=force radeonfb_pci_register BEGIN radeonfb: probed DDR SGRAM 65536k videoram radeonfb: mapped 16384k videoram radeonfb: Found Intel x86 BIOS ROM Image radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=166.00 Mhz, System=166.00 MHz radeonfb: No connector info table detected Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... not found radeonfb: I2C (port 4) ... not found radeonfb: Monitor 1 type CRT found radeonfb: ATI Radeon QD DDR SGRAM 64 MB radeonfb_pci_register END Starting balanced_irq ikconfig 0.7 with /proc/config* Installing knfsd (copyright (C) 1996 ok...@mo...). udf: registering filesystem Limiting direct PCI/PCI transfers. ACPI: Power Button (FF) [PWRF] ACPI: Processor [CPU] (supports C1) ACPI: Processor [CPU1] (supports C1) ACPI: Thermal Zone [THRM] (28 C) hStart = 664, hEnd = 760, hTotal = 800 vStart = 491, vEnd = 493, vTotal = 525 h_total_disp = 0x4f0063 hsync_strt_wid = 0x8c02a2 v_total_disp = 0x1df020c vsync_strt_wid = 0x8201ea pixclock = 39721 freq = 2517 post div = 0x3 fb_div = 0x1bf ppll_div_3 = 0x301bf lvds_gen_cntl: 00000000 Console: switching to colour frame buffer device 53x21 Well, b*gger. Did I mention I use the 12x22 font from sun? Anyway, going to 8 bits color-depth solves my problem, but I'd rather watch some photo's in at least 16-bit color depth. What part of the driver is suspect? Thanks, Jurriaan > If I boot linux-2.6.5, with a radeonfb framebuffer 1600x1200-32@75, I > get white letters on a black background. Fine. If I issue the command > setterm -inversescreen on, I get black letters on a white background. > > So far so good. > > Now if I press enter, I get a new line with black letters on a white > background, but everything after the cursor is blue. > > Switching consoles (alt-f2, alt-f1) removes the blue line. > Issuing 'clear' gives an entire blue screen after the cursor (so a small > part, the prompt, stays black-on-white). > > This is with a radeon 9000 and with a radeon 7000, so it must be > something in general. Incidentally, blue is also the color the overscan > area gets. > > This has been happening on all 2.6.x kernels going back months. > -- Someone's stained Someone's gained Us or was it them? The men they couldn't hang - Rosettes Debian (Unstable) GNU/Linux 2.6.5-rc3-mm3 2x6062 bogomips 0.52 0.19 |
From: Jean D. <kh...@li...> - 2004-04-06 17:13:17
|
> This is a step in the right direction: > > 1600x1200-8@75: ok > 1600x1200-16@75: blue screen > 1600x1200-24@75: 'no mode found' in dmesg? > 1600x1200-32@75: blue screen Just tried, same here (Radeon 9200 Ya). If I ask for 15-bit I get 16, if I ask for 24 I get 8. 8 is OK WRT blue background, 16 and 32 are not. BTW, how do you get 75Hz vertical refresh? I just can't. Whatever I ask through lilo, I end up with 60Hz (both fbset and the screen's OSD agree). Thanks. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/ |