linux-fbdev-users — Generic mailing list for users of frame buffers

Re: [Linux-fbdev-users] Scrambled output with new radeonfb driver

[Jean D. <kh...@li...>]

Quoting myself:

> However, at the moment the driver is initialized, I got scambled
> output in the upper left hand corner of my screen. I've taken a
> snapshot of it using my webcam, available here:
> http://jdelvare.net1.nerim.net/radeonfb/radeonfb.jpeg
> 
> Is it a known problem? Is there some parameter I can pass to the
> driver to prevent the problem? Or do I just have to live with it?

For information, Linux 2.6.6-mm4 seems to fix that.

Thanks.

-- 
Jean Delvare
http://khali.linux-fr.org/

[Linux-fbdev-users] matroxfb: screen messes up after some time of running

[Jonas M. <jo...@fr...>]

hello,

for some reason, my screen gets messed up after some time of working on
the virtual console with matroxfb and mode 1024x768-60, 24bpp.
I have a Matrox G400 AGP graphic card, and this problem also appears
with mode 1280x1024 and (at both) with 32bpp.

The screen generally is unreadable after one new lineprint, what makes
pagers, editors etc unusable. The screen only gets refreshed correctly,
if I change to another tty.
After working in X for some time, the problem sometimes vanishes and
comes back after some time staying on the virtual consoles (tty).

any suggestions and/or experiences how to fix this? it's really
annoying.

bye
 jonas

[Linux-fbdev-users] long time of switch console->X (fast opposite way)

[Miernik <mi...@ct...>]

I use the framebuffer with this line in my /boot/grub/menu.lst :
kernel /boot/vmlinuz-2.4.24-1-386 root=/dev/hda1 ro video=sisfb:mode:1152x864x16,rate:70

My video card is (output of lspci -vv): 

0000:01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 630/730 PCI/AGP VGA Display Adapter (rev 31) (prog-if 00 [VGA])
        Subsystem: Silicon Integrated Systems [SiS] 630/730 PCI/AGP VGA Display Adapter
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        BIST result: 00
        Region 0: Memory at c0000000 (32-bit, prefetchable) [size=128M]
        Region 1: Memory at cfee0000 (32-bit, non-prefetchable) [size=128K]
        Region 2: I/O ports at bc00 [size=128]
        Capabilities: [40] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] AGP version 2.0
                Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

It's a video card build in a PCChips M810L REV7.0 motherboard.
The CPU is AMD Duron 600 MHz. 
Of course I use the fbdev X driver. 

The problem I have it takes 6.7 seconds to switch from console to X 
with <Alt><F7>. The 6.7 s time is very consistent, every time I 
measure it. It's very long and annoying.

The other direction (X->console with <Alt><F1>) its about immediate.

During that 6.7 seconds the a rough outline of what is supposed to be 
on the screen is displayed. For example if the Galeon web browser is 
on the screen, then it displays the area where Galeon menus and other 
controls are in a block of grey, the area of the webpage in a block of 
black, and the URL box as a block of white.

What might be the reason, and is there anything to be done about this?

In kern.log doring boot I get:

May 28 18:25:49 jaworz kernel: sisfb: Video ROM found and mapped to c00c0000
May 28 18:25:49 jaworz kernel: sisfb: Framebuffer at 0xc0000000, mapped to 0xe00ab000, size 8192k
May 28 18:25:49 jaworz kernel: sisfb: MMIO at 0xcfee0000, mapped to 0xe08ac000, size 128k
May 28 18:25:49 jaworz kernel: sisfb: Memory heap starting at 4096K
May 28 18:25:49 jaworz kernel: sisfb: CRT1 DDC supported
May 28 18:25:49 jaworz kernel: sisfb: CRT1 DDC level: 2
May 28 18:25:49 jaworz kernel: sisfb: Monitor range H 31-61KHz, V 60-75Hz, Max. dotclock 78MHz
May 28 18:25:49 jaworz kernel: sisfb: WARNING: Refresh rate exceeds monitor specs!
May 28 18:25:49 jaworz kernel: sisfb: Mode is 1152x864x16 (60Hz)
May 28 18:25:49 jaworz kernel: sisfb: Initial vbflags 0x0
May 28 18:25:49 jaworz kernel: Console: switching to colour frame buffer device 144x54
May 28 18:25:49 jaworz kernel: sisfb: Installed SISFB_GET_INFO ioctl (80046ef8)
May 28 18:25:49 jaworz kernel: sisfb: Installed SISFB_GET_VBRSTATUS ioctl (80046ef9)
May 28 18:25:49 jaworz kernel: sisfb: 2D acceleration is enabled, scrolling mode ypan
May 28 18:25:49 jaworz kernel: fb0: SIS 730 frame buffer device, Version 1.6.16
May 28 18:25:49 jaworz kernel: sisfb: (C) 2001-2003 Thomas Winischhofer. All rights reserved.

And then a line like that appears every several minutes all the time 
the computer is on:

May 28 18:26:04 jaworz kernel: sisfb: Unsupported rate 60 for 1152x864
May 28 18:26:04 jaworz kernel: sisfb: WARNING: Refresh rate exceeds monitor specs!
May 28 18:26:07 jaworz kernel: sisfb: Unsupported rate 60 for 1152x864
May 28 18:26:07 jaworz kernel: sisfb: WARNING: Refresh rate exceeds monitor specs!
May 28 18:26:27 jaworz kernel: sisfb: Unsupported rate 60 for 1152x864
May 28 18:26:27 jaworz kernel: sisfb: WARNING: Refresh rate exceeds monitor specs!

-- 
    Miernik         _________________________  xmpp:mi...@am...
___________________/__ tel: +48888299997 __/      mailto:mi...@ct...
http://www.miernik.ctnet.pl/

[Linux-fbdev-users] how to display the message of the system boot on lcd?????

[xuhaoz <xu...@ne...>]

hello
	I want to put the boot message onto the lcd, would you please tell me what
to do?
             I use uclinux 2.4, and my framebuffer device is adapted from
the vfb.c , 320*240, 4 bit packed pixel

_________________________________________
zhang xuhao
ICQ#: 116926669
More ways to contact me: http://wwp.icq.com/116926669
_________________________________________

[Linux-fbdev-users] help: radeonfb display is mixed with X display

[Dominique D. <dom...@fr...>]

Hello

I'm trying to set up a framebuffer for my Radeon 9200 board.

After doing 'fbset -x -depth 32 "1280x1024-70"', my X display changes
colors.

The weird thing is that I'm able to move the mouse cursor and open or
close windows under X.

If I try to use vdr with framebuffer plugin, the output of vdr is
mixed with X display. 

My set up is:
- kernel 2.6.5
- radeonfb modules
- booted with :"video=radeonfb:800x600-24" 
- X server from dri project
- XF86Config-4 use "radeon" device _without_ UseFBDev option.

Shouldn't I be able to switch from X to fb output with CRTL-ALT-F8 ?

Can someone help me ?

Thanks

[Linux-fbdev-users] pm2fb status and kernel panic

[Marcelo R. <mr...@mo...>]

Hi.

I want to know status of pm2fb. When I want to use it I get a
kernel panic right on boot.

Kernel: 2.6.5

Card: 
Creative Blaster Extreme PCI - 8mb
00:0c.0 Display controller: Texas Instruments TVP4020 [Permedia 2] (rev 01)   


TIA

-- 
 _____________________________________________________________
                                        _____  ____________
  Marcelo Ramos                        |     \/      __    |
  Fedora Core 1 | Linux 2.6.5          |            |_/    /
  Socio UYLUG Nro 125                  |                   \
  Linux registered user #118109        |____|\/|____|\______\

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

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

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

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

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

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

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

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

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

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

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

[Jean D. <kh...@li...>]

> 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/

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

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

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

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

[Benjamin H. <be...@ke...>]

> 
> 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.

Re: [Linux-fbdev-users] radeonfb: s

[Petr V. <van...@vc...>]

On Thu, Apr 08, 2004 at 12:42:39AM +0200, Petr Vandrovec wrote:
> > 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!
> 
> Did you tried that it does not work on 16bpp? I would be really
> surprised if it did not work for 16/8bpp too. Maybe better to
> apply this patch and try it...

Hm, I'm stupid... Patch below works IFF you are using my matroxfb
patches. I've packed them all (except patch below) and put them
at ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/jurriaan.gz.
In addition to matroxfb patches it also contains fixes to get vesafb to
work in 8bpp with Matrox Parhelia, and some additional output
for 'vga=ask'.

Without my patches layout of pseudo_palette varies between
color depths, and you need to use if () or switch () instead of
simple inline array lookup. Or you have to compose hardware color
at fillrect time from RGB bitfields.

For properly working with my patches it also needs to support ROP_ZERO
fillrect, which I use in clear_margins() to clear right/bottom
margin with black and not with some color picked from currently
choosen color palette. But you should not need clear_margins() unless
you are using 12x22 font.
							Petr


diff -urN linux-2.6.5-rc3-c1777.dist/drivers/video/aty/radeon_accel.c linux-2.6.5-rc3-c1777/drivers/video/aty/radeon_accel.c
--- linux-2.6.5-rc3-c1777.dist/drivers/video/aty/radeon_accel.c	2004-04-03 18:37:51.000000000 +0200
+++ linux-2.6.5-rc3-c1777/drivers/video/aty/radeon_accel.c	2004-04-08 00:41:56.000000000 +0200
@@ -7,13 +7,15 @@
 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);
+	color = rinfo->info->pseudo_palette[region->color];
+	OUTREG(DP_BRUSH_FRGD_CLR, color);
 	OUTREG(DP_WRITE_MSK, 0xffffffff);
 	OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM));
 
diff -urN linux-2.6.5-rc3-c1777.dist/drivers/video/aty/radeon_base.c linux-2.6.5-rc3-c1777/drivers/video/aty/radeon_base.c
--- linux-2.6.5-rc3-c1777.dist/drivers/video/aty/radeon_base.c	2004-04-03 18:35:39.000000000 +0200
+++ linux-2.6.5-rc3-c1777/drivers/video/aty/radeon_base.c	2004-04-08 00:53:51.000000000 +0200
@@ -1060,6 +1060,9 @@
  	if (regno < 16) {
 		u32 *pal = info->pseudo_palette;
         	switch (rinfo->depth) {
+		case 8:
+			pal[regno] = regno;
+			break;
 		case 15:
 			pal[regno] = (regno << 10) | (regno << 5) | regno;
 			break;

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

[James S. <jsi...@in...>]

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
> 

Re: [Linux-fbdev-users] radeonfb: strange blue lines after

[Petr V. <VAN...@vc...>]

On  7 Apr 04 at 22:44, 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!

Did you tried that it does not work on 16bpp? I would be really
surprised if it did not work for 16/8bpp too. Maybe better to
apply this patch and try it...
                                                    Petr

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

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

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

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

[Jean D. <kh...@li...>]

> 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/

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

[Hihn, J. <Jas...@ve...>]

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

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

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

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

Re: [Linux-fbdev-users] radeonfb: strange blue lines after

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

From: Petr Vandrovec <VAN...@vc...>
Date: Wed, Apr 07, 2004 at 07:11:46PM +0200
> 
> I was able to reproduce it on my Compaq EVO with Radeon Mobility 7500.
> 
> In 8bpp everything works correctly. In 32bpp "clear" immediately fills
> screen with blue instead of white (if I get it correctly, it is actually
> not clearing with blue: it clears with $CORRECT_BACKGROUND & BLUE).
> In 16bpp it behaves randomly: sometime it clears with correct color,
> sometime with $CORRECT_BACKGROUND & BLUE... Strangest is that going
> with up arrow through bash history causes bash line displayed on essentially
> random place - left to correct position, sometime even so left that it
> is displayed on right side of screen one pixel up.... (I did not notice
> this problem with 8/32bpp; 'fbset -accel false' has no impact on
> behavior)
> 
> Only thing worth noting is that it is on kernel with my matroxfb patches...
> I do not know whether Jurriaan uses stock kernel or my patch.

I use the stock kernel.

Jurriaan
-- 
She said, "Poor man. All you wanted to do here was leave your dead behind
and make a mosaic overhead."
"I was ... overly ambitious," he said.
	Guy Gavriel Kay - Lord of Emperors
Debian (Unstable) GNU/Linux 2.6.5-mm1 2x6062 bogomips 1.36 1.16

Re: [Linux-fbdev-users] radeonfb: strange blue lines after

[Petr V. <VAN...@vc...>]

On  7 Apr 04 at 18:33, Jurriaan wrote:
> > 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?
> I repeat my offer: I'll send an Ati video-card free of charge to anyone
> who offers to track this bug down.

I was able to reproduce it on my Compaq EVO with Radeon Mobility 7500.

In 8bpp everything works correctly. In 32bpp "clear" immediately fills
screen with blue instead of white (if I get it correctly, it is actually
not clearing with blue: it clears with $CORRECT_BACKGROUND & BLUE).
In 16bpp it behaves randomly: sometime it clears with correct color,
sometime with $CORRECT_BACKGROUND & BLUE... Strangest is that going
with up arrow through bash history causes bash line displayed on essentially
random place - left to correct position, sometime even so left that it
is displayed on right side of screen one pixel up.... (I did not notice
this problem with 8/32bpp; 'fbset -accel false' has no impact on
behavior)

Only thing worth noting is that it is on kernel with my matroxfb patches...
I do not know whether Jurriaan uses stock kernel or my patch.
                                                Best regards,
                                                    Petr Vandrovec
                                                    van...@vc...
                                                    

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

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

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

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

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

On Tue, 6 Apr 2004, Hihn, Jason wrote:
> 15bit I think dates back to some [matrox?] cards, circa 1995. No one
> else really had/supported that.

Many cards do both 15 (5/5/5) and 16 (5/6/5), e.g. ATI Mach64. The main
disadvantage of 5/6/5 is that you cannot have accurate greyscales. Grey will
always be a bit greenish or purplish, since there are no integer values x and y
for which x/31 = y/63.

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

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

[Hihn, J. <Jas...@ve...>]

Even LCDs have frequencies. The signaling is slightly different, but you
still have a H&V sync signals, among other things. So yeah, that's
probably it.=20


-----Original Message-----
From: Jean Delvare [mailto:kh...@li...]=20
Sent: Tuesday, April 06, 2004 3:00 PM
To: lin...@li...
Subject: Re: [Linux-fbdev-users] radeonfb: strange blue lines
after'setterm-inversescreen on'

> There is a i2c interface between the card and the monitor that tells
> it what the monitor's capabilities are. If your monitor can't do it,
> it won't let you, because you can damage hardware that way.

It's a Hyundai Q17, capable of 1280x1024@75. But the docs say that 60Hz
is recommended so maybe that's what it says to the Radeon board over the
I2C bus.

After all, it's a TFT display, maybe it doesn't really care about the
frequency?

--=20
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/


-------------------------------------------------------
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