linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] Question on imageblit

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

> I have written a framebuffer driver for the i810/i815 chipsets for
> linux-2.5.12.  It entirely uses fbgen, and for accelerated drawing
> functions, fbcon-accel (copyarea, fillrect and imageblit).  It works
> quite well in my system.

Yeah!!!!!

> My question:  Imageblit is used primarily for putc and putcs, right?  

  That AND for drawing the penguin. The code doesn't exist in fbcon.c yet
to handle drawing the penguin when using only the accel wrapper. I need to
add that.  
  To draw the pengiun using the accel wrapper I need to set the color map
to the what the penguin needs. Then I create fb_image where each piece of 
data in char* field are a value that represents where in the struct
fb_cmap that data is. I think this is the best approach to that. Any
suggestions other wise?

> basically, a monochrome bitmap located in system memory is copied to
> the framebuffer memory which also undergoes color expansion depending
> on the pixelformat of the framebuffer.

Yeap!

> So, is it necessary to support other color conversions (such as a copy
> from 8bpp to 32bpp, or even from a higher bpp to a lower bpp)?

Hm.
  
> The patch is at
> http://prdownloads.sourceforge.net/i810fb/linux-2.5.12-i810fb.tar.bz2
> The patch already includes James Simmons' fbdev_fixs.diff for 2.5.12.

Will try.

[Linux-fbdev-devel] Question on imageblit

[Antonino D. <ad...@po...>]

Hi,

I have written a framebuffer driver for the i810/i815 chipsets for
linux-2.5.12.  It entirely uses fbgen, and for accelerated drawing
functions, fbcon-accel (copyarea, fillrect and imageblit).  It works
quite well in my system.

My question:  Imageblit is used primarily for putc and putcs, right?  So
basically, a monochrome bitmap located in system memory is copied to the
framebuffer memory which also undergoes color expansion depending on the
pixelformat of the framebuffer. So, is it necessary to support other
color conversions (such as a copy from 8bpp to 32bpp, or even from a
higher bpp to a lower bpp)?  

The patch is at
http://prdownloads.sourceforge.net/i810fb/linux-2.5.12-i810fb.tar.bz2
The patch already includes James Simmons' fbdev_fixs.diff for 2.5.12. 

Tony 

[Linux-fbdev-devel] Re: 2.5.11 framebuffer compilation error

[Paul M. <pa...@au...>]

James Simmons writes:

> Diff:
> 
> http://www.transvirtual.com/~jsimmons/fbdev_fixs.diff

I tried 2.5.12 with this patch on PPC, with most of the mac
framebuffers selected, and got a few errors.  Here is a patch that
fixes the compilation errors plus a few other things.

The files affected are:

chipsfb.c   )
controlfb.c )		fix compile errors from recent changes
platinumfb.c)
valkyriefb.c)

offb.c			fix a problem with colormap corruption on blank
			add support for IBM GXT2000P display
			fix compile errors from recent changes

aty128.h		remove duplicate definition
aty128fb.c		add btext_update_display call
			add Rage128 Pro TR
			eliminate compile warnings
			make aty128fb_blank be actually used
			add more default resolutions based on
			  which type of powermac we have

imsttfb.c		eliminate compile warning

aty/atyfb_base.c	add btext_update_display call

Some of these changes have come from Ben Herrenschmidt.

I have changes to the radeon driver too but I haven't included them in
this patch since I am using version 0.1.4 in my tree at the moment
whereas Linus' tree only has version 0.1.1.

James, it would be good if you could look at this and either apply it,
or let me know if there is anything you don't like so we can discuss
it.

Regards,
Paul.

diff -urN ltest/drivers/video/aty/atyfb_base.c pmac-2.5/drivers/video/aty/atyfb_base.c
--- ltest/drivers/video/aty/atyfb_base.c	Thu May  2 22:08:08 2002
+++ pmac-2.5/drivers/video/aty/atyfb_base.c	Thu May  2 21:44:26 2002
@@ -87,6 +87,9 @@
 #include <linux/adb.h>
 #include <linux/pmu.h>
 #endif
+#ifdef CONFIG_BOOTX_TEXT
+#include <asm/btext.h>
+#endif
 #ifdef CONFIG_NVRAM
 #include <linux/nvram.h>
 #endif
@@ -815,6 +818,13 @@
 	display_info.disp_reg_address = info->ati_regbase_phys;
     }
 #endif /* CONFIG_FB_COMPAT_XPMAC */
+#ifdef CONFIG_BOOTX_TEXT
+    btext_update_display(info->frame_buffer_phys,
+		    (((par->crtc.h_tot_disp>>16) & 0xff)+1)*8,
+		    ((par->crtc.v_tot_disp>>16) & 0x7ff)+1,
+		    par->crtc.bpp,
+		    par->crtc.vxres*par->crtc.bpp/8);
+#endif /* CONFIG_BOOTX_TEXT */
 }
 
 static int atyfb_decode_var(const struct fb_var_screeninfo *var,
diff -urN ltest/drivers/video/aty128.h pmac-2.5/drivers/video/aty128.h
--- ltest/drivers/video/aty128.h	Wed Feb  6 04:40:16 2002
+++ pmac-2.5/drivers/video/aty128.h	Fri Feb 15 22:04:12 2002
@@ -267,7 +267,6 @@
 #define DAC_MASK				0xFF000000
 #define DAC_BLANKING				0x00000004
 #define DAC_RANGE_CNTL				0x00000003
-#define DAC_RANGE_CNTL				0x00000003
 #define DAC_PALETTE_ACCESS_CNTL			0x00000020
 #define DAC_PDWN				0x00008000
 
diff -urN ltest/drivers/video/aty128fb.c pmac-2.5/drivers/video/aty128fb.c
--- ltest/drivers/video/aty128fb.c	Mon Apr 29 16:25:24 2002
+++ pmac-2.5/drivers/video/aty128fb.c	Thu May  2 19:43:03 2002
@@ -70,6 +70,9 @@
 #ifdef CONFIG_FB_COMPAT_XPMAC
 #include <asm/vc_ioctl.h>
 #endif
+#ifdef CONFIG_BOOTX_TEXT
+#include <asm/btext.h>
+#endif /* CONFIG_BOOTX_TEXT */
 
 #include <video/fbcon.h>
 #include <video/fbcon-cfb8.h>
@@ -154,6 +157,7 @@
     {"Rage128 RL (AGP)", PCI_DEVICE_ID_ATI_RAGE128_RL, rage_128},
     {"Rage128 Pro PF (AGP)", PCI_DEVICE_ID_ATI_RAGE128_PF, rage_128_pro},
     {"Rage128 Pro PR (PCI)", PCI_DEVICE_ID_ATI_RAGE128_PR, rage_128_pro},
+    {"Rage128 Pro TR (AGP)", PCI_DEVICE_ID_ATI_RAGE128_U3, rage_128_pro},
     {"Rage Mobility M3 (PCI)", PCI_DEVICE_ID_ATI_RAGE128_LE, rage_M3},
     {"Rage Mobility M3 (AGP)", PCI_DEVICE_ID_ATI_RAGE128_LF, rage_M3},
     {NULL, 0, rage_128}
@@ -216,9 +220,13 @@
 static char fontname[40] __initdata = { 0 };
 
 static int  noaccel __initdata = 0;
+#ifdef MODULE
 static char *font __initdata = NULL;
 static char *mode __initdata = NULL;
+#ifdef CONFIG_MTRR
 static int  nomtrr __initdata = 0;
+#endif
+#endif /* MODULE */
 
 static char *mode_option __initdata = NULL;
 
@@ -418,6 +426,7 @@
 	fb_set_cmap:	gen_set_cmap,
 	fb_setcolreg:	aty128fb_setcolreg,
 	fb_pan_display:	aty128fb_pan_display,
+	fb_blank:	aty128fb_blank,
 	fb_rasterimg:	aty128fb_rasterimg,
 };
 
@@ -1243,6 +1252,13 @@
 	display_info.disp_reg_address = info->regbase_phys;
     }
 #endif /* CONFIG_FB_COMPAT_XPMAC */
+#if defined(CONFIG_BOOTX_TEXT)
+    btext_update_display(info->frame_buffer_phys,
+		    (((par->crtc.h_total>>16) & 0xff)+1)*8,
+		    ((par->crtc.v_total>>16) & 0x7ff)+1,
+		    par->crtc.bpp,
+		    par->crtc.vxres*par->crtc.bpp/8);
+#endif /* CONFIG_BOOTX_TEXT */
 }
 
     /*
@@ -1584,7 +1600,7 @@
     if (!options || !*options)
 	return 0;
 
-    while (this_opt = strsep(&options, ",")) {
+    while ((this_opt = strsep(&options, ",")) != NULL) {
 	if (!strncmp(this_opt, "font:", 5)) {
 	    char *p;
 	    int i;
@@ -1686,6 +1702,29 @@
         } else {
             if (default_vmode <= 0 || default_vmode > VMODE_MAX)
                 default_vmode = VMODE_1024_768_60;
+
+	    /* iMacs need that resolution
+	     * PowerMac2,1 first r128 iMacs
+	     * PowerMac2,2 summer 2000 iMacs
+	     * PowerMac4,1 january 2001 iMacs "flower power"
+	     */
+	    if (machine_is_compatible("PowerMac2,1") ||
+		machine_is_compatible("PowerMac2,2") ||
+		machine_is_compatible("PowerMac4,1"))
+		default_vmode = VMODE_1024_768_75;
+
+	    /* iBook SE */
+	    if (machine_is_compatible("PowerBook2,2"))
+		default_vmode = VMODE_800_600_60;
+ 
+	    /* PowerBook Firewire (Pismo), iBook Dual USB */
+	    if (machine_is_compatible("PowerBook3,1") ||
+	    	machine_is_compatible("PowerBook4,1"))
+		default_vmode = VMODE_1024_768_60;
+
+	    /* PowerBook Titanium */
+	    if (machine_is_compatible("PowerBook3,2"))
+		default_vmode = VMODE_1152_768_60;
 
             if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
                 default_cmode = CMODE_8;
diff -urN ltest/drivers/video/chipsfb.c pmac-2.5/drivers/video/chipsfb.c
--- ltest/drivers/video/chipsfb.c	Thu May  2 22:08:08 2002
+++ pmac-2.5/drivers/video/chipsfb.c	Thu May  2 21:44:26 2002
@@ -312,7 +312,7 @@
 	struct fb_var_screeninfo* var = &p->var;
 	
 	if (bpp == 16) {
-		if (con == info->currcon) {
+		if (con == p->info.currcon) {
 			write_cr(0x13, 200);		// Set line length (doublewords)
 			write_xr(0x81, 0x14);		// 15 bit (555) color mode
 			write_xr(0x82, 0x00);		// Disable palettes
@@ -334,7 +334,7 @@
 		disp->dispsw = &fbcon_dummy;
 #endif
 	} else if (bpp == 8) {
-		if (con == info->currcon) {
+		if (con == p->info.currcon) {
 			write_cr(0x13, 100);		// Set line length (doublewords)
 			write_xr(0x81, 0x12);		// 8 bit color mode
 			write_xr(0x82, 0x08);		// Graphics gamma enable
diff -urN ltest/drivers/video/controlfb.c pmac-2.5/drivers/video/controlfb.c
--- ltest/drivers/video/controlfb.c	Thu May  2 22:08:08 2002
+++ pmac-2.5/drivers/video/controlfb.c	Thu May  2 21:46:35 2002
@@ -149,7 +149,7 @@
 	struct fb_info *info);
 static int control_get_cmap(struct fb_cmap *cmap, int kspc, int con,
 	struct fb_info *info);
-static int controlfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
+static int control_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
 	u_int transp, struct fb_info *info);
 static int controlfb_blank(int blank_mode, struct fb_info *info);
 static int control_mmap(struct fb_info *info, struct file *file,
@@ -225,7 +225,7 @@
 	fb_set_var:	control_set_var,
 	fb_get_cmap:	control_get_cmap,
 	fb_set_cmap:	gen_set_cmap,
-	fb_setcolreg:	controlfb_setcolreg,
+	fb_setcolreg:	control_setcolreg,
 	fb_pan_display:	control_pan_display,
 	fb_blank:	controlfb_blank,
 	fb_mmap:	control_mmap,
@@ -520,7 +520,7 @@
 	return 0;
 }
 
-static int controlfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
+static int control_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
 			     u_int transp, struct fb_info *info)
 {
 	struct fb_info_control *p = (struct fb_info_control *) info;
@@ -1238,7 +1238,7 @@
     u8 *dest;
     int bytes = p->next_line, rows;
 
-    dest = p->info.screen_base + yy * fontheight(p) * bytes + xx * fontwidth(p)*2;
+    dest = p->fb_info->screen_base + yy * fontheight(p) * bytes + xx * fontwidth(p)*2;
     for (rows = fontheight(p); rows--; dest += bytes) {
        switch (fontwidth(p)) {
        case 16:
@@ -1261,7 +1261,7 @@
     u8 *dest;
     int bytes = p->next_line, rows;
 
-    dest = p->info.screen_base + yy * fontheight(p) * bytes + xx * fontwidth(p) * 4;
+    dest = p->fb_info->screen_base + yy * fontheight(p) * bytes + xx * fontwidth(p) * 4;
     for (rows = fontheight(p); rows--; dest += bytes) {
        switch (fontwidth(p)) {
        case 16:
diff -urN ltest/drivers/video/imsttfb.c pmac-2.5/drivers/video/imsttfb.c
--- ltest/drivers/video/imsttfb.c	Mon Apr 29 16:25:24 2002
+++ pmac-2.5/drivers/video/imsttfb.c	Wed May  1 10:54:14 2002
@@ -1908,7 +1908,7 @@
 			p->ramdac = TVP;
 			break;
 		default:
-			printk(KERN_INFO "imsttfb: Device 0x%lx unknown, "
+			printk(KERN_INFO "imsttfb: Device 0x%x unknown, "
 					 "contact maintainer.\n", pdev->device);
 			return -ENODEV;
 	}
diff -urN ltest/drivers/video/offb.c pmac-2.5/drivers/video/offb.c
--- ltest/drivers/video/offb.c	Mon Apr 29 16:25:24 2002
+++ pmac-2.5/drivers/video/offb.c	Thu May  2 21:46:47 2002
@@ -49,7 +49,8 @@
 	cmap_r128,	/* ATI Rage128 */
 	cmap_M3A,	/* ATI Rage Mobility M3 Head A */
 	cmap_M3B,	/* ATI Rage Mobility M3 Head B */
-	cmap_radeon	/* ATI Radeon */
+	cmap_radeon,	/* ATI Radeon */
+	cmap_gxt2000	/* IBM GXT2000 */
 };
 
 struct fb_info_offb {
@@ -61,6 +62,7 @@
     volatile unsigned char *cmap_adr;
     volatile unsigned char *cmap_data;
     int cmap_type;
+    int blanked;
     union {
 #ifdef FBCON_HAS_CFB16
 	u16 cfb16[16];
@@ -207,9 +209,11 @@
 static int offb_get_cmap(struct fb_cmap *cmap, int kspc, int con,
 			 struct fb_info *info)
 {
-    if (con == info->currcon) /* current console? */
+    struct fb_info_offb *info2 = (struct fb_info_offb *)info;
+
+    if (con == info->currcon && !info2->blanked) /* current console? */
 	return fb_get_cmap(cmap, kspc, offb_getcolreg, info);
-    else if (fb_display[con].cmap.len) /* non default colormap? */
+    if (fb_display[con].cmap.len) /* non default colormap? */
 	fb_copy_cmap(&fb_display[con].cmap, cmap, kspc ? 0 : 2);
     else
     {
@@ -237,7 +241,7 @@
 	if ((err = fb_alloc_cmap(&fb_display[con].cmap, size, 0)))
 	    return err;
     }
-    if (con == info->currcon)			/* current console? */
+    if (con == info->currcon && !info2->blanked)	/* current console? */
 	return fb_set_cmap(cmap, kspc, info);
     else
 	fb_copy_cmap(cmap, &fb_display[con].cmap, kspc ? 0 : 1);
@@ -254,7 +258,16 @@
     int i, j;
 
     if (!info2->cmap_adr)
-	return;
+	return 0;
+
+    if (!info2->blanked) {
+	if (!blank)
+	    return 0;
+	if (fb_display[info->currcon].cmap.len)
+	    fb_get_cmap(&fb_display[info->currcon].cmap, 1, offb_getcolreg, info);
+    }
+
+    info2->blanked = blank;
 
     if (blank)
 	for (i = 0; i < 256; i++) {
@@ -288,6 +301,9 @@
     	        out_8(info2->cmap_adr + 0xb0, i);
 	    	out_le32((unsigned *)(info2->cmap_adr + 0xb4), 0);
 	    	break;
+	    case cmap_gxt2000:
+		out_le32((unsigned *)info2->cmap_adr + i, 0);
+		break;
 	    }
 	}
     else
@@ -496,6 +512,10 @@
 		info->cmap_adr = ioremap(base + 0x7ff000, 0x1000) + 0xcc0;
 		info->cmap_data = info->cmap_adr + 1;
 		info->cmap_type = cmap_m64;
+	} else if (device_is_compatible(dp, "pci1014,b7")) {
+		unsigned long regbase = dp->addrs[0].address;
+		info->cmap_adr = ioremap(regbase + 0x6000, 0x1000);
+		info->cmap_type = cmap_gxt2000;
 	}
         fix->visual = info->cmap_adr ? FB_VISUAL_PSEUDOCOLOR
 				     : FB_VISUAL_STATIC_PSEUDOCOLOR;
@@ -667,8 +687,10 @@
 
 static int offbcon_switch(int con, struct fb_info *info)
 {
+    struct fb_info_offb *info2 = (struct fb_info_offb *)info;
+
     /* Do we have to save the colormap? */
-    if (fb_display[info->currcon].cmap.len)
+    if (fb_display[info->currcon].cmap.len && !info2->blanked)
 	fb_get_cmap(&fb_display[info->currcon].cmap, 1, offb_getcolreg, info);
 
     info->currcon = con;
@@ -765,6 +787,10 @@
 	out_8(info2->cmap_adr + 0xb0, regno);
   	out_le32((unsigned *)(info2->cmap_adr + 0xb4),
     		(red << 16 | green << 8 | blue));
+	break;
+    case cmap_gxt2000:
+	out_le32((unsigned *)info2->cmap_adr + regno,
+		 (red << 16 | green << 8 | blue));
 	break;
     }
 
diff -urN ltest/drivers/video/platinumfb.c pmac-2.5/drivers/video/platinumfb.c
--- ltest/drivers/video/platinumfb.c	Thu May  2 22:08:08 2002
+++ pmac-2.5/drivers/video/platinumfb.c	Thu May  2 21:44:26 2002
@@ -329,10 +329,10 @@
 	struct fb_info_platinum *info = (struct fb_info_platinum *) fb;
 	struct fb_par_platinum par;
 
-	if (fb_display[info->currcon].cmap.len)
-		fb_get_cmap(&fb_display[info->currcon].cmap, 1, platinum_getcolreg,
+	if (fb_display[fb->currcon].cmap.len)
+		fb_get_cmap(&fb_display[fb->currcon].cmap, 1, platinum_getcolreg,
 			    fb);
-	info->currcon = con;
+	fb->currcon = con;
 
 	platinum_var_to_par(&fb_display[con].var, &par, info);
 	platinum_set_par(&par, info);
diff -urN ltest/drivers/video/valkyriefb.c pmac-2.5/drivers/video/valkyriefb.c
--- ltest/drivers/video/valkyriefb.c	Mon Apr 29 16:25:25 2002
+++ pmac-2.5/drivers/video/valkyriefb.c	Thu May  2 21:37:03 2002
@@ -260,7 +260,7 @@
 			    fb);
 	fb->currcon = con;
 #if 1
-	valkyrie_var_to_par(&fb_display[currcon].var, &par, fb);
+	valkyrie_var_to_par(&fb_display[fb->currcon].var, &par, fb);
 	valkyrie_set_par(&par, info);
 	do_install_cmap(con, fb);
 #else

Re: [pm3fb] Re: [Linux-fbdev-devel] FB console clears with large white area

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

> This very problem was mentioned for pm3fb. Answer by James Simmons:
> 
> > _set_var must be called before register_framebuffer. Otherwise the machien
> > will oops. regsiter_framebuffer calls take_over_console which calls
> > fbcon_startup which expects a struct display disp in fb_info to be
> > initialized. info->disp is initalized in xxxfb_set_var.
> 
> So the initializations I'm doing in pm3fb are mandatory...

Yipes!!! Its broken both ways. I know ruby fixes this and I plan to fix
this soon for 2.5.X.

[Linux-fbdev-devel] Re: [PATCH] fddev fixes due to massive change.

[Christian N. <Chr...@we...>]

The correct bk-url is:
http://fbdev.bkbits.net:8080/fbdev-2.5
thanks for the great work :-)

see you,
Christian Neumair

[Linux-fbdev-devel] [PATCH] fddev fixes due to massive change.

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

Due to massive changes and few testers a few things where missed. THis
patches fixes all the problems that where reported to me. I have both a
classic diff and a BK url to work with. The patch is against 2.5.12

http://fbdev.bkbits.net/fbdev-2.5

http://www.transvirtual.com/~jsimmons/fbdev_fixs.diff

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

[pm3fb] Re: [Linux-fbdev-devel] FB console clears with large white area

[<dol...@cl...>]

> I found similar with pm2fb; moving the call to register_framebuffer to
> before mode setup caused the kernel to hang. No time in investigate
> further yet.

Search the archives for this mailinglist for "pm3fb questions/problesm".
It was about 10 months ago.

This very problem was mentioned for pm3fb. Answer by James Simmons:

> _set_var must be called before register_framebuffer. Otherwise the machien
> will oops. regsiter_framebuffer calls take_over_console which calls
> fbcon_startup which expects a struct display disp in fb_info to be
> initialized. info->disp is initalized in xxxfb_set_var.

So the initializations I'm doing in pm3fb are mandatory...

-- 
DOLBEAU Romain               | You won't break me
ENS Cachan / Ker Lann        | You won't make me
Thesard IRISA / CAPS         | You won't take me
dol...@cl...    | -- Judas Priest, 'Blood Red Skies'

Re: [Linux-fbdev-devel] FB console clears with large white area

[Jim H. <jim...@ac...>]

On 30-Apr-2002 Sven wrote:
>> the reason was discovered to be from calling set_var before
>> register_framebuffer. 
> 
> Not sure about this one, because applying the patch from roman to 2.4.18 +
> pm3fb did hang the kernel early one (before registering the fbdev i think, it
> never switched away from the console text mode). That said, i don't get a
> white space stuff, but a green/black vertical stripes with some char embedded
> in the green ones.

I found similar with pm2fb; moving the call to register_framebuffer to before
mode setup caused the kernel to hang. No time in investigate further yet.

-- 
Jim Hague - jim...@in... (Work), ji...@be... (Play)
Never trust a computer you can't lift or you don't control.

Re: [Linux-fbdev-devel] FB console clears with large white area

[Jim H. <jim...@ac...>]

On 30-Apr-2002 Antonino Daplas wrote:
>> As far as I can tell at the moment, in take_over_console the outgoing
>> console
>> is suppose to save its screen contents (if visible) and these will be put
>> onto
>> the new console when update_screen() is called. Dumping the saved VGA
>> screen,
>> it seems that the saved screen consists entirely of 0x720, which I think
>> explains the white. Why the VGA screen contents are like that I have, as
>> yet, no
>> idea.
>> 
> If I remember PC text mode correctly, 0x720 is the correct code for
> space.  7 is the attribute (I forgot what it stands for though -
> probably normal) and 20 is just the ASCII code for space.  So, the
> console essentially blanked your screen, but is misinterpreted when
> switched to graphics mode.

Sorry, I got that detail wrong in the original message. The 0x720s are what is
in vc_screenbuf *before* calling save_screen(). save_screen() produces 0xffff
(for me on pm2fb), which I am sure is responsible for the white rectangle I see.

-- 
Jim Hague - jim...@in... (Work), ji...@be... (Play)
Never trust a computer you can't lift or you don't control.

Re: [Linux-fbdev-devel] FB console clears with large white area at startup

[Antonino D. <ad...@po...>]

> 
> As far as I can tell at the moment, in take_over_console the outgoing console
> is suppose to save its screen contents (if visible) and these will be put onto
> the new console when update_screen() is called. Dumping the saved VGA screen,
> it seems that the saved screen consists entirely of 0x720, which I think
> explains the white. Why the VGA screen contents are like that I have, as yet, no
> idea.
> 
If I remember PC text mode correctly, 0x720 is the correct code for
space.  7 is the attribute (I forgot what it stands for though -
probably normal) and 20 is just the ASCII code for space.  So, the
console essentially blanked your screen, but is misinterpreted when
switched to graphics mode.

Tony  

Re: [Linux-fbdev-devel] FB console clears with large white area at startup

[Antonino D. <ad...@po...>]

On Wed, 2002-05-01 at 01:46, Sven wrote:
> On Tue, Apr 30, 2002 at 10:26:08AM -0700, James Simmons wrote:
> > 
> > > > Except what actually happens is that most of the screen is cleared to white,
> > > > and console messages appear on the bottom line of the white area. As the
> > > > console scrolls the white area scrolls up the screen, though that part of it to
> > > > the right of Tux remains as long as Tux remains.
> > > 
> > > I have the same problem with pm3fb.
> > 
> > the reason was discovered to be from calling set_var before
> > register_framebuffer. 
> 
> Not sure about this one, because applying the patch from roman to 2.4.18 +
> pm3fb did hang the kernel early one (before registering the fbdev i think, it
> never switched away from the console text mode). That said, i don't get a
> white space stuff, but a green/black vertical stripes with some char embedded
> in the green ones.
> 

>From what I have observed, the critical point is setting up the driver
just enough so everything is initialized, but reserve switching the
hardware to graphics mode only during or after register_framebuffer. 
Some drivers do this by checking a flag which tells if the driver is in
initialization stage or not. In the case of aty128fb.c, it checks if
'con' is valid or not. It has this in set_var:

    if (!info->fb_info.display_fg || info->fb_info.display_fg->vc_num
==  con)
	aty128_set_par(&par, info);

Probably, a similar check in pm3fb_set_par might work?

Tony

Re: [Linux-fbdev-devel] FB console clears with large white area at startup

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

> > the reason was discovered to be from calling set_var before
> > register_framebuffer. 
> 
> Not sure about this one, because applying the patch from roman to 2.4.18 +
> pm3fb did hang the kernel early one (before registering the fbdev i think, it
> never switched away from the console text mode). That said, i don't get a
> white space stuff, but a green/black vertical stripes with some char embedded
> in the green ones.

I couldn't do the patch over night. Not with the current fbdev system. The
approach will be to migrate all fbdev drivers over to the new api. Then
the stuff in fbgen.c can be intergrated into fbcon.c. See fbgen.c has its
own generic switch_con function. Once every driver uses that it will be
easier to change one function then many functions.

> > Hm. The console system should be handling restoring the fonts. Unfortunely
> > it doesn't. I can see this when I use the vesa framebuffer and X. 
> 
> Yes, it did not work for. The problem for X was that the vga mmio interface of
> the chip was broken, so we copy the data by hand.

Yuck!!

> I would do the same for pm3fb, but i don't know where the char data is held in
> the vga memory (which is part of the framebuffer memory, i think), and copying
> all 64K of it like is done in the X driver would not help us.

Hm. I have to think about that one.

Re: [pm3fb] Re: [Linux-fbdev-devel] FB console clears with large white area

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

> Either 2.4.x or the older 2.5.y w/ the older fbdev.
> (I assume your patch for 2.5.2 works for you :-)

I still lift hooks for the old api. At present both apis can exist at the
same time. I didn't want to break every fbdev driver at one time. 

> I tried 2.5.11, it doesn't even compile the IDE stuff
> on my laptop now... 2.5.y on PPC is getting worse with
> each new release :-(

The PPC stuff I can't help you with. Is this with the PPC tree as well? 
At present 2.5.11 is really broken. I expect 2.5.12 to be much better once
all the fixes go in.

Re: [Linux-fbdev-devel] FB console clears with large white area

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

> The problem is, essentially, that the outgoing VGA console and the incoming FB
> console are the same card. Initialise that card to a graphics mode and *blam*
> the card remaps to the graphics mode and fishing around in the text mode
> screen memory to find the contents of the outgoing console produces random
> garbage.

Correct. On ix86 before you set the video hardware we are at 0xA000 in
text mode. Once you change to graphics mode it is somewhere in PCI memory
space, plus the data format is completely different. Then calling
register_framebuffer then calls take_over_console whcih in turn calls the
old video driver (vgacon) to grab the data (save_screen). Now that the
hardware is in a different state the data is invalid. Then it updates the
screen with the new data.  

> So Antonio's suggestion that the card should not be in graphics mode when
> registering the FB is correct; registering needs to happen before the card is
> switched away from VGA mode in any way. Simply removing the call to do_set_var
> doesn't work for pm2fb; I think too much initialisation has happened by then.
> Sven, pmfb is (I think) similar in this respect; any ideas?

The key is to not touch the hardware at all before register_framebuffer.
fbcon_init could do it instead. The problem we have to watch out for is
con_switch. This is where alot of problems lie.

Re: [pm3fb] Re: [Linux-fbdev-devel] FB console clears with large white area

[Sven <lu...@dp...>]

On Tue, Apr 30, 2002 at 11:46:18AM +0200, Romain Dolbeau wrote:
> Sven wrote:
> 
> > Yes, but i have not tried it yet, it would be better to work on 2.4.x for this
> > now (is 2.4.19 already released ?) 
> 
> 2.4.19 hasn't been released yet. I'll try the patch on
> my box tonight. It it doesn't break anything and improves
> thing for you, I'll try to get it integrated to 2.4.19.

Nope, the patch didn't work, andeven worse, the kernel would not boot anymore
with it applied. it never did the switch to pm3fb (but vesafb was fine) (and
frooze juste before it).

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] FB console clears with large white area at startup

[Sven <lu...@dp...>]

On Tue, Apr 30, 2002 at 10:26:08AM -0700, James Simmons wrote:
> 
> > > Except what actually happens is that most of the screen is cleared to white,
> > > and console messages appear on the bottom line of the white area. As the
> > > console scrolls the white area scrolls up the screen, though that part of it to
> > > the right of Tux remains as long as Tux remains.
> > 
> > I have the same problem with pm3fb.
> 
> the reason was discovered to be from calling set_var before
> register_framebuffer. 

Not sure about this one, because applying the patch from roman to 2.4.18 +
pm3fb did hang the kernel early one (before registering the fbdev i think, it
never switched away from the console text mode). That said, i don't get a
white space stuff, but a green/black vertical stripes with some char embedded
in the green ones.

> > i don't know, but while writing the pm3 X driver, i noticed that may board
> > will not save/restore the fonts correctly when doing MMIO (and when not doing
> > MMIO it would not work in dual pm3 configuration) so we (Well Alan Hourihane
> > actually) did change the code to read/save font memory using a special memcopy
> > instead of resorting to the vga interface, which seemed broken in this
> > respect. Maybe the pm2 chip shares this problem ?
> 
> Hm. The console system should be handling restoring the fonts. Unfortunely
> it doesn't. I can see this when I use the vesa framebuffer and X. 

Yes, it did not work for. The problem for X was that the vga mmio interface of
the chip was broken, so we copy the data by hand.

I would do the same for pm3fb, but i don't know where the char data is held in
the vga memory (which is part of the framebuffer memory, i think), and copying
all 64K of it like is done in the X driver would not help us.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] FB console clears with large white area

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

I plan to move set_var in every driver into fbcon.c. 

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'_   _/`\
 ___)=(___/

On Mon, 29 Apr 2002, Jani Monoses wrote:

> The way it disappeared for me was by not calling do_set_var in trident
> init.It was called before register_frambuffer.I thought I posted to the
> list last week but it seems I only replied to Jim.
> Antonio Daplas suggested that the card should not be in graphics mode when
> registering the fb.See the list archives subject: tridentfb review some
> months ago)
> 
> 
>  > I suspect that all/most FB drivers (I think Jani works
> round it with
> > tridentfb) will show this problem. But to see it you need to be switching from
> > a VGA console to a FB console - if I remove the VGA console from my kernel
> > everything looks fine - so this problem will only practically be seen on PCs.
> > And there are not many reasons to use FB on a PC.
> 
> 
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 

Re: [Linux-fbdev-devel] FB console clears with large white area at startup

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

> > Except what actually happens is that most of the screen is cleared to white,
> > and console messages appear on the bottom line of the white area. As the
> > console scrolls the white area scrolls up the screen, though that part of it to
> > the right of Tux remains as long as Tux remains.
> 
> I have the same problem with pm3fb.

the reason was discovered to be from calling set_var before
register_framebuffer. 

> i don't know, but while writing the pm3 X driver, i noticed that may board
> will not save/restore the fonts correctly when doing MMIO (and when not doing
> MMIO it would not work in dual pm3 configuration) so we (Well Alan Hourihane
> actually) did change the code to read/save font memory using a special memcopy
> instead of resorting to the vga interface, which seemed broken in this
> respect. Maybe the pm2 chip shares this problem ?

Hm. The console system should be handling restoring the fonts. Unfortunely
it doesn't. I can see this when I use the vesa framebuffer and X. 

Re: [Linux-fbdev-devel] FB console clears with large white area at startup

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

> I had this problem with the trident driver and the problem went away if
> I did not set_var() before register_framebuffer.This was suggested by
> Antonio Daplas on this list .So I think the video mode should not be set
> until the fb is registered.

I agree. In fact I like to see the set_var stuff moved into fbcon.c. It
can be done since I already have done it. 

Re: [pm3fb] Re: [Linux-fbdev-devel] FB console clears with large white area

[Romain D. <do...@ir...>]

Sven wrote:

> Yes, but i have not tried it yet, it would be better to work on 2.4.x for this
> now (is 2.4.19 already released ?) 

2.4.19 hasn't been released yet. I'll try the patch on
my box tonight. It it doesn't break anything and improves
thing for you, I'll try to get it integrated to 2.4.19.

-- 
DOLBEAU Romain               |   I have lost the will to live           
ENS Cachan / Ker Lann        |    Simply nothing more to give           
Thesard IRISA / CAPS         |       -- Metallica,                      
dol...@cl...    |            'Fade to Black'

Re: [pm3fb] Re: [Linux-fbdev-devel] FB console clears with large white area

[Sven <lu...@dp...>]

On Tue, Apr 30, 2002 at 11:41:31AM +0200, Romain Dolbeau wrote:
> 
> > Ok, i will try it (i suppose this is the 2.4.x tree, not yet thew 2.5.x ones,
> > am i right ?
> 
> Either 2.4.x or the older 2.5.y w/ the older fbdev.
> (I assume your patch for 2.5.2 works for you :-)

Yes, but i have not tried it yet, it would be better to work on 2.4.x for this
now (is 2.4.19 already released ?) and try again 2.5.x once this is solved
(and i have more time).

> I tried 2.5.11, it doesn't even compile the IDE stuff
> on my laptop now... 2.5.y on PPC is getting worse with
> each new release :-(

I had troubles also, but then it was before the new fbdev stuff got merged in,
so i will have to test again, but i have not a lot of time.

Friendly,

Sven Luther

Re: [pm3fb] Re: [Linux-fbdev-devel] FB console clears with large white area

[Romain D. <do...@ir...>]

> Ok, i will try it (i suppose this is the 2.4.x tree, not yet thew 2.5.x ones,
> am i right ?

Either 2.4.x or the older 2.5.y w/ the older fbdev.
(I assume your patch for 2.5.2 works for you :-)

I tried 2.5.11, it doesn't even compile the IDE stuff
on my laptop now... 2.5.y on PPC is getting worse with
each new release :-(

-- 
DOLBEAU Romain               | The Gods made Heavy Metal                
ENS Cachan / Ker Lann        |     and it's never gonna die             
Thesard IRISA / CAPS         |           -- Manowar,                    
dol...@cl...    |    'The Gods made Heavy Metal'

Re: [pm3fb] Re: [Linux-fbdev-devel] FB console clears with large white area

[Sven <lu...@dp...>]

On Tue, Apr 30, 2002 at 11:33:36AM +0200, Romain Dolbeau wrote:
> Jim Hague wrote:
> 
> > So Antonio's suggestion that the card should not be in graphics mode when
> > registering the FB is correct; registering needs to happen before the card is
> > switched away from VGA mode in any way. Simply removing the call to do_set_var
> > doesn't work for pm2fb; I think too much initialisation has happened by then.
> > Sven, pmfb is (I think) similar in this respect; any ideas?
> 
> Well, pm3fb definitely does do a bunch of initializations
> before registering. The attached patch *might* solve the
> problem (I use a PPC box so all that VGA crap is unknown to me...)
> All those who see the problem, please test and report.

Ok, i will try it (i suppose this is the 2.4.x tree, not yet thew 2.5.x ones,
am i right ?

Friendly,

Sven Luther

[pm3fb] Re: [Linux-fbdev-devel] FB console clears with large white area

[Romain D. <do...@ir...>]

Jim Hague wrote:

> So Antonio's suggestion that the card should not be in graphics mode when
> registering the FB is correct; registering needs to happen before the card is
> switched away from VGA mode in any way. Simply removing the call to do_set_var
> doesn't work for pm2fb; I think too much initialisation has happened by then.
> Sven, pmfb is (I think) similar in this respect; any ideas?

Well, pm3fb definitely does do a bunch of initializations
before registering. The attached patch *might* solve the
problem (I use a PPC box so all that VGA crap is unknown to me...)
All those who see the problem, please test and report.

-- 
DOLBEAU Romain               |        Long live rock and roll           
ENS Cachan / Ker Lann        |        Long live rock 'n' roll           
Thesard IRISA / CAPS         |        Long live rock and roll           
dol...@cl...    | -- Rainbow, 'Long Live Rock 'N' Roll'

Re: [Linux-fbdev-devel] FB console clears with large white area

[Jani M. <ja...@iv...>]

On Tue, 30 Apr 2002, Jim Hague wrote:

> catch on. BTW, I can't find the 'tridentfb review' thread in the archives.

ok I didn't remember the subject

---------- Forwarded message ----------
Date: 28 Nov 2001 10:53:46 +0800
From: Antonino Daplas <ad...@po...>
To: Jani Monoses <ja...@as...>
Subject: Re: [Linux-fbdev-devel] driver review please :) (beware,size =
30K)

On Tue, 2001-11-27 at 22:14, Jani Monoses wrote:

>
> * when  I insmod it the console is cleared with white(maybe that's OK
> I haven't seen other modular fb's?)
>
I think that can happen if your display is already in graphics mode
before you register the framebuffer.

Tony