[PATCH] neofb patches

[PATCH] neofb patches

[Alex Stewart]

[-- Attachment #1: Type: text/plain, Size: 5093 bytes --]

Sorry I took a little while to get these out..  Had a bit busier weekend than I
expected..

Attached are my patches for the neofb driver.  All of these are against the
2.6.5 kernel.  I'm still kinda new to the whole framebuffer subsystem, so if
I've done something horribly wrong, let me know.  

All of my testing has been against the Neomagic NM2200 (MagicMedia 256AV) chip
in my laptop.  I think all of these changes should be safe for other chips too,
although it's possible a couple of the workarounds for bugs implemented here
aren't necessary with some of the other chips and could be more carefully
special-cased..

Anyway, the attached patches are as follows:

neofb.1.copyarea.patch  - Fix copyarea positioning bug

  It appears that the naming of the NEO_BC0_X_DEC and NEO_BC0_Y_*_DEC bitflags
  is wrong, or at the very least misleading, as their behavior is not as
  one would expect from the names.  On the NM2200, NEO_BC0_X_DEC apparently
  enables both X and Y decrementing of addresses during a copy, so the
  positioning is relative to the lower right corner, not the upper right.  I
  don't know exactly what the other flags do do, but they apparently don't
  affect Y decrementing, so the case where we were setting just these flags
  without NEO_BC0_X_DEC didn't work and corrupted the data while copying (are
  these flags perhaps used differently in later chips than in the 2200 I'm
  testing against?)
 
  In any case, I didn't look into it horribly deeply, I just changed the
  routine to be a little less clever about what it tries to do (this is
  consistent with what the XFree86 driver does as well, and will hopefully work
  with all chips, whichever way they might treat these flags)

neofb.2.imageblit.patch - Fix imageblit for color images

  It looks like the imageblit routine was written with only mono blits in mind.
  This patch adds support for color image transfers (Hi Tux!).

neofb.3.16bit.patch     - Misc fixes for 16-bit mode

  Changed the visual reported for 16-bit mode from DirectColor to TrueColor,
  since we don't support changing the colormap, which means we don't really
  support DirectColor.  Also changed the palette entries for to be 32 bits wide
  even for 16-bit mode because this is what the logo code expects, and appears
  to be the correct way of doing things.

neofb.4.24bit.patch     - Make 24-bit mode work

  Added a couple of switch cases needed to make 24-bit mode actually work.
  The colormap setting code also needed to be moved to be after vgaHWRestore,
  so that the DAC would be configured properly (8-bit lookups) for 24-bit
  color before writing to the lookup table.

  Also, it looks like there's a hardware bug with the NM2200 if you try to do a
  color-expanded transfer in 24-bit mode and the width of the image is less
  than 16 pixels wide (The left few pixels of the image seem to get partially
  wrapped onto the right side.  I haven't tested all cases, actually.. I know
  it breaks with 8-pixel-width blits), so in that case we just fall back to
  cfb_imageblit instead.
 
  Actually, the imageblit bug could conceivably be there with color transfers
  too, I haven't tried it.  Would require something trying to imageblit a
  8-pixel-wide 24-bit image, in 24-bit mode.  I suspect the bug is probably
  related to the source-data width in bits and/or the hardware mono->color
  translation, though, and in either case this wouldn't be an issue for 24-bit
  color.

neofb.5.modedb.patch    - Change to use modedb for video mode selection

  Allows specifying the video mode on the kernel/insmod command line now too.


I have also attached an additional patch which is mostly, but not quite
entirely, complete.  I thought it was working until I was packaging all of
this up and discovered that it's actually intermittent.  If anybody has
suggestions for what's missing, please let me know:

neofb.6.blanking.patch  - Add support for DPMS blanking

  I just copied the logic from the XFree86 driver to add DPMS support.  This
  currently works for me some of the time and doesn't other times, and I'm
  still tracking down why.  It looks like I probably need to do something
  more in the initialization stage to turn on this functionality properly (I
  note that there are a _lot_ of registers which the BIOS and the XFree86
  driver have values set for which show up as zero under the neofb driver.  I'm
  guessing this is part of the problem.)

  (Oh, and I also changed the wording of the comments at the beginning of
  things to make a bit more sense in this context.  Between an unfortunate
  renaming one of the function parameters and the fact that the comments were
  copied from a different part of the code (and thus speak from a different
  perspective), these comments were initially very confusing to read.
  Hopefully now they are somewhat less so.)

I'm also still looking into a couple of minor "annoyance" bugs, but these
patches fix most of the real functionality deficiencies I've found so far (or
will, once I figure out why blanking is buggy.. grumble)..

Feedback is welcome.

-alex

[-- Attachment #2: neofb.1.copyarea.patch --]
[-- Type: text/plain, Size: 730 bytes --]

--- ./drivers/video/neofb.c.copyarea	2004-04-03 19:37:24.000000000 -0800
+++ ./drivers/video/neofb.c	2004-04-20 15:22:04.012544952 -0700
@@ -1367,18 +1367,13 @@
 
 	bltCntl = NEO_BC3_FIFO_EN | NEO_BC3_SKIP_MAPPING | 0x0C0000;
 
-	if (sy < dy) {
-		sy += (area->height - 1);
-		dy += (area->height - 1);
-
-		bltCntl |= NEO_BC0_DST_Y_DEC | NEO_BC0_SRC_Y_DEC;
-	}
-
-	if (area->sx < area->dx) {
+	if ((sy < dy) || (sy == dy && sx < dx)) {
 		sx += (area->width - 1);
 		dx += (area->width - 1);
+		sy += (area->height - 1);
+		dy += (area->height - 1);
 
-		bltCntl |= NEO_BC0_X_DEC;
+		bltCntl |= NEO_BC0_DST_Y_DEC | NEO_BC0_SRC_Y_DEC | NEO_BC0_X_DEC;
 	}
 
 	src = sx * (info->var.bits_per_pixel >> 3) + sy*info->fix.line_length;

[-- Attachment #3: neofb.2.imageblit.patch --]
[-- Type: text/plain, Size: 1335 bytes --]

--- ./drivers/video/neofb.c.imageblit	2004-04-20 15:22:04.012544952 -0700
+++ ./drivers/video/neofb.c	2004-04-20 15:22:04.089533248 -0700
@@ -1394,9 +1394,23 @@
 neo2200_imageblit(struct fb_info *info, const struct fb_image *image)
 {
 	struct neofb_par *par = (struct neofb_par *) info->par;
+	int bltCntl_flags, data_len;
 
 	neo2200_sync(info);
 
+	if (image->depth == 1) {
+		bltCntl_flags = NEO_BC0_SRC_MONO;
+		data_len = (image->width * image->height) >> 3;
+	} else if (image->depth == info->var.bits_per_pixel) {
+		bltCntl_flags = 0;
+		data_len = (image->width * image->height) *
+		    (info->var.bits_per_pixel >> 3);
+	} else {
+		/* We don't currently support hardware acceleration if image
+		 * depth is different from display */
+		return cfb_imageblit(info, image);
+	}
+
 	switch (info->var.bits_per_pixel) {
 	case 8:
 		par->neo2200->fgColor = image->fg_color;
@@ -1411,7 +1425,7 @@
 	}
 
 	par->neo2200->bltCntl = NEO_BC0_SYS_TO_VID |
-	    NEO_BC0_SRC_MONO | NEO_BC3_SKIP_MAPPING |
+	    NEO_BC3_SKIP_MAPPING | bltCntl_flags |
 	    //                      NEO_BC3_DST_XY_ADDR |
 	    0x0c0000;
 
@@ -1424,7 +1438,7 @@
 	    (image->height << 16) | (image->width & 0xffff);
 
 	memcpy(par->mmio_vbase + 0x100000, image->data,
-	       (image->width * image->height) >> 3);
+	       data_len);
 }
 
 static void

[-- Attachment #4: neofb.3.16bit.patch --]
[-- Type: text/plain, Size: 1294 bytes --]

--- ./drivers/video/neofb.c.16bit	2004-04-20 15:22:04.089533248 -0700
+++ ./drivers/video/neofb.c	2004-04-20 15:22:04.179519568 -0700
@@ -952,8 +952,10 @@
 		info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
 		break;
 	case 16:
-		/* DirectColor, 64k */
-		info->fix.visual = FB_VISUAL_DIRECTCOLOR;
+		/* TrueColor, 64k */
+		/* Note, this is NOT DirectColor, because we don't support
+		 * setting the hardware colormap. */
+		info->fix.visual = FB_VISUAL_TRUECOLOR;
 
 		for (i = 0; i < 64; i++) {
 			outb(i, 0x3c8);
@@ -1240,7 +1242,7 @@
 		break;
 	case 16:
 		if (regno < 16)
-			((u16 *) fb->pseudo_palette)[regno] =
+			((u32 *) fb->pseudo_palette)[regno] =
 			    ((red & 0xf800)) | ((green & 0xfc00) >> 5) |
 			    ((blue & 0xf800) >> 11);
 		break;
@@ -1348,7 +1350,7 @@
 		break;
 	case 16:
 		par->neo2200->fgColor =
-		    ((u16 *) (info->pseudo_palette))[rect->color];
+		    ((u32 *) (info->pseudo_palette))[rect->color];
 		break;
 	}
 
@@ -1418,9 +1420,9 @@
 		break;
 	case 16:
 		par->neo2200->fgColor =
-		    ((u16 *) (info->pseudo_palette))[image->fg_color];
+		    ((u32 *) (info->pseudo_palette))[image->fg_color];
 		par->neo2200->bgColor =
-		    ((u16 *) (info->pseudo_palette))[image->bg_color];
+		    ((u32 *) (info->pseudo_palette))[image->bg_color];
 		break;
 	}
 

[-- Attachment #5: neofb.4.24bit.patch --]
[-- Type: text/plain, Size: 3405 bytes --]

--- drivers/video/neofb.c.24bit	2004-04-20 16:02:07.055251672 -0700
+++ drivers/video/neofb.c	2004-04-20 16:03:08.500910512 -0700
@@ -522,6 +522,10 @@
 		bltMod = NEO_MODE1_DEPTH16;
 		pitch = var->xres_virtual * 2;
 		break;
+	case 24:
+		bltMod = NEO_MODE1_DEPTH24;
+		pitch = var->xres_virtual * 3;
+		break;
 	default:
 		printk(KERN_ERR
 		       "neofb: neo2200_accel_init: unexpected bits per pixel!\n");
@@ -643,6 +647,7 @@
 		var->green.offset = 8;
 		var->green.length = 8;
 		var->blue.offset = 0;
+		var->blue.length = 8;
 		break;
 
 #ifdef NO_32BIT_SUPPORT_YET
@@ -945,43 +950,6 @@
 	/* Since we program the clocks ourselves, always use VCLK3. */
 	par->MiscOutReg |= 0x0C;
 
-	/* linear colormap for non palettized modes */
-	switch (info->var.bits_per_pixel) {
-	case 8:
-		/* PseudoColor, 256 */
-		info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
-		break;
-	case 16:
-		/* TrueColor, 64k */
-		/* Note, this is NOT DirectColor, because we don't support
-		 * setting the hardware colormap. */
-		info->fix.visual = FB_VISUAL_TRUECOLOR;
-
-		for (i = 0; i < 64; i++) {
-			outb(i, 0x3c8);
-
-			outb(i << 1, 0x3c9);
-			outb(i, 0x3c9);
-			outb(i << 1, 0x3c9);
-		}
-		break;
-	case 24:
-#ifdef NO_32BIT_SUPPORT_YET
-	case 32:
-#endif
-		/* TrueColor, 16m */
-		info->fix.visual = FB_VISUAL_TRUECOLOR;
-
-		for (i = 0; i < 256; i++) {
-			outb(i, 0x3c8);
-
-			outb(i, 0x3c9);
-			outb(i, 0x3c9);
-			outb(i, 0x3c9);
-		}
-		break;
-	}
-
 	/* alread unlocked above */
 	/* BOGUS  VGAwGR (0x09, 0x26); */
 
@@ -1043,6 +1011,42 @@
 	 * This function handles restoring the generic VGA registers.  */
 	vgaHWRestore(info, par);
 
+	/* linear colormap for non palettized modes */
+	switch (info->var.bits_per_pixel) {
+	case 8:
+		/* PseudoColor, 256 */
+		info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
+		break;
+	case 16:
+		/* TrueColor, 64k */
+		/* Note, this is NOT DirectColor, because we don't support
+		 * setting the hardware colormap. */
+		info->fix.visual = FB_VISUAL_TRUECOLOR;
+
+		for (i = 0; i < 64; i++) {
+			outb(i, 0x3c8);
+
+			outb(i << 1, 0x3c9);
+			outb(i, 0x3c9);
+			outb(i << 1, 0x3c9);
+		}
+		break;
+	case 24:
+#ifdef NO_32BIT_SUPPORT_YET
+	case 32:
+#endif
+		/* TrueColor, 16m */
+		info->fix.visual = FB_VISUAL_TRUECOLOR;
+
+		for (i = 0; i < 256; i++) {
+			outb(i, 0x3c8);
+
+			outb(i, 0x3c9);
+			outb(i, 0x3c9);
+			outb(i, 0x3c9);
+		}
+		break;
+	}
 
 	VGAwGR(0x0E, par->ExtCRTDispAddr);
 	VGAwGR(0x0F, par->ExtCRTOffset);
@@ -1349,6 +1353,7 @@
 		par->neo2200->fgColor = rect->color;
 		break;
 	case 16:
+	case 24:
 		par->neo2200->fgColor =
 		    ((u32 *) (info->pseudo_palette))[rect->color];
 		break;
@@ -1401,6 +1406,13 @@
 	neo2200_sync(info);
 
 	if (image->depth == 1) {
+		if (info->var.bits_per_pixel == 24 && image->width < 16) {
+			/* There is apparently a hardware bug with accelerated
+			 * mono->screen transfers in 24-bit mode if the image
+			 * being transferred is less than 16 bits wide.  Do it
+			 * the old-fashioned way instead. */
+			return cfb_imageblit(info, image);
+		}
 		bltCntl_flags = NEO_BC0_SRC_MONO;
 		data_len = (image->width * image->height) >> 3;
 	} else if (image->depth == info->var.bits_per_pixel) {
@@ -1419,6 +1431,7 @@
 		par->neo2200->bgColor = image->bg_color;
 		break;
 	case 16:
+	case 24:
 		par->neo2200->fgColor =
 		    ((u32 *) (info->pseudo_palette))[image->fg_color];
 		par->neo2200->bgColor =

[-- Attachment #6: neofb.5.modedb.patch --]
[-- Type: text/plain, Size: 6155 bytes --]

--- ./drivers/video/neofb.c.modedb	2004-04-20 16:04:32.172190544 -0700
+++ ./drivers/video/neofb.c	2004-04-20 16:04:32.470145248 -0700
@@ -93,7 +93,7 @@
 static int libretto;
 static int nostretch;
 static int nopciburst;
-
+static char *mode;
 
 #ifdef MODULE
 
@@ -113,6 +113,8 @@
 		 "Disable stretching of modes smaller than LCD.");
 MODULE_PARM(nopciburst, "i");
 MODULE_PARM_DESC(nopciburst, "Disable PCI burst mode.");
+MODULE_PARM(mode, "s");
+MODULE_PARM_DESC(mode, "Preferred Video Mode ('640x480-8@60', etc)");
 
 #endif
 
@@ -1536,48 +1538,9 @@
 
 /* --------------------------------------------------------------------- */
 
-static struct fb_var_screeninfo __devinitdata neofb_var640x480x8 = {
-	.accel_flags    = FB_ACCELF_TEXT,
-	.xres           = 640,
-	.yres           = 480,
-	.xres_virtual   = 640,
-	.yres_virtual   = 30000,
-	.bits_per_pixel = 8,
-	.pixclock       = 39722,
-	.left_margin    = 48,
-	.right_margin   = 16,
-	.upper_margin   = 33,
-	.lower_margin   = 10,
-	.hsync_len      = 96,
-	.vsync_len      = 2,
-	.vmode          = FB_VMODE_NONINTERLACED
-};
-
-static struct fb_var_screeninfo __devinitdata neofb_var800x600x8 = {
-	.accel_flags    = FB_ACCELF_TEXT,
-	.xres           = 800,
-	.yres           = 600,
-	.xres_virtual   = 800,
-	.yres_virtual   = 30000,
-	.bits_per_pixel = 8,
-	.pixclock       = 25000,
-	.left_margin    = 88,
-	.right_margin   = 40,
-	.upper_margin   = 23,
-	.lower_margin   = 1,
-	.hsync_len      = 128,
-	.vsync_len      = 4,
-	.sync           = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
-	.vmode          = FB_VMODE_NONINTERLACED
-};
-
-static struct fb_var_screeninfo __devinitdata neofb_var800x480x8 = {
-	.accel_flags    = FB_ACCELF_TEXT,
+static struct fb_videomode __devinitdata mode800x480 = {
 	.xres           = 800,
 	.yres           = 480,
-	.xres_virtual   = 800,
-	.yres_virtual   = 30000,
-	.bits_per_pixel = 8,
 	.pixclock       = 25000,
 	.left_margin    = 88,
 	.right_margin   = 40,
@@ -1589,44 +1552,6 @@
 	.vmode          = FB_VMODE_NONINTERLACED
 };
 
-static struct fb_var_screeninfo __devinitdata neofb_var1024x768x8 = {
-	.accel_flags    = FB_ACCELF_TEXT,
-	.xres           = 1024,
-	.yres           = 768,
-	.xres_virtual   = 1024,
-	.yres_virtual   = 30000,
-	.bits_per_pixel = 8,
-	.pixclock       = 15385,
-	.left_margin    = 160,
-	.right_margin   = 24,
-	.upper_margin   = 29,
-	.lower_margin   = 3,
-	.hsync_len      = 136,
-	.vsync_len      = 6,
-	.sync           = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
-	.vmode          = FB_VMODE_NONINTERLACED
-};
-
-#ifdef NOT_DONE
-static struct fb_var_screeninfo __devinitdata neofb_var1280x1024x8 = {
-	.accel_flags    = FB_ACCELF_TEXT,
-	.xres           = 1280,
-	.yres           = 1024,
-	.xres_virtual   = 1280,
-	.yres_virtual   = 30000,
-	.bits_per_pixel = 8,
-	.pixclock       = 9260,
-	.left_margin    = 248,
-	.right_margin   = 48,
-	.upper_margin   = 38,
-	.lower_margin   = 1,
-	.hsync_len      = 112,
-	.vsync_len      = 3,
-	.sync           = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
-	.vmode          = FB_VMODE_NONINTERLACED
-};
-#endif
-
 static int __devinit neo_map_mmio(struct fb_info *info,
 				  struct pci_dev *dev)
 {
@@ -1772,24 +1697,29 @@
 	case 0x00:
 		par->NeoPanelWidth = 640;
 		par->NeoPanelHeight = 480;
-		info->var = neofb_var640x480x8;
+		par->default_videomode = &vesa_modes[3]; /* 640x480@60 */
 		break;
 	case 0x01:
 		par->NeoPanelWidth = 800;
-		par->NeoPanelHeight = par->libretto ? 480 : 600;
-		info->var = par->libretto ? neofb_var800x480x8 : neofb_var800x600x8;
+		if (par->libretto) {
+			par->NeoPanelHeight = 480;
+			par->default_videomode = &mode800x480;
+		} else {
+			par->NeoPanelHeight = 600;
+			par->default_videomode = &vesa_modes[8]; /* 800x600@60 */
+		}
 		break;
 	case 0x02:
 		par->NeoPanelWidth = 1024;
 		par->NeoPanelHeight = 768;
-		info->var = neofb_var1024x768x8;
+		par->default_videomode = &vesa_modes[13]; /* 1024x768@60 */
 		break;
 	case 0x03:
 		/* 1280x1024 panel support needs to be added */
 #ifdef NOT_DONE
 		par->NeoPanelWidth = 1280;
 		par->NeoPanelHeight = 1024;
-		info->var = neofb_var1280x1024x8;
+		par->default_videomode = &vesa_modes[20]; /* 1280x1024@60 */
 		break;
 #else
 		printk(KERN_ERR
@@ -1799,7 +1729,7 @@
 	default:
 		par->NeoPanelWidth = 640;
 		par->NeoPanelHeight = 480;
-		info->var = neofb_var640x480x8;
+		par->default_videomode = &vesa_modes[3]; /* 640x480@60 */
 		break;
 	}
 
@@ -1989,6 +1919,7 @@
 				 const struct pci_device_id *id)
 {
 	struct fb_info *info;
+	struct neofb_par *par;
 	u_int h_sync, v_sync;
 	int err;
 	int video_len;
@@ -2018,6 +1949,18 @@
 	if (err)
 		goto failed;
 
+	par = (struct neofb_par *)info->par;
+	if (!fb_find_mode(&info->var, info, mode, NULL, 0,
+			  par->default_videomode, 8)) {
+		printk(KERN_ERR "neofb: Unable to find usable video mode.\n");
+		return -EINVAL;
+	}
+
+	/* Turn on panning for console scroll by default */
+	info->var.yres_virtual = 30000;
+	info->var.accel_flags |= FB_ACCELF_TEXT;
+	neofb_check_var(&info->var, info);
+
 	/*
 	 * Calculate the hsync and vsync frequencies.  Note that
 	 * we split the 1e12 constant up so that we can preserve
@@ -2162,16 +2105,18 @@
 
 		if (!strncmp(this_opt, "disabled", 8))
 			disabled = 1;
-		if (!strncmp(this_opt, "internal", 8))
+		else if (!strncmp(this_opt, "internal", 8))
 			internal = 1;
-		if (!strncmp(this_opt, "external", 8))
+		else if (!strncmp(this_opt, "external", 8))
 			external = 1;
-		if (!strncmp(this_opt, "nostretch", 9))
+		else if (!strncmp(this_opt, "nostretch", 9))
 			nostretch = 1;
-		if (!strncmp(this_opt, "nopciburst", 10))
+		else if (!strncmp(this_opt, "nopciburst", 10))
 			nopciburst = 1;
-		if (!strncmp(this_opt, "libretto", 8))
+		else if (!strncmp(this_opt, "libretto", 8))
 			libretto = 1;
+		else
+			mode = this_opt;
 	}
 
 	return 0;
--- ./include/video/neomagic.h.modedb	2004-04-03 19:36:56.000000000 -0800
+++ ./include/video/neomagic.h	2004-04-20 16:04:32.530136128 -0700
@@ -177,6 +177,8 @@
   int internal_display;
   int external_display;
   int libretto;
+
+  const struct fb_videomode *default_videomode;
 };
 
 typedef struct {

[-- Attachment #7: neofb.6.blanking.patch --]
[-- Type: text/plain, Size: 3608 bytes --]

--- ./drivers/video/neofb.c.blanking	2004-04-20 16:04:32.470145248 -0700
+++ ./drivers/video/neofb.c	2004-04-20 16:04:32.774099040 -0700
@@ -1277,27 +1277,36 @@
 /*
  *    (Un)Blank the display.
  */
-static int neofb_blank(int blank, struct fb_info *info)
+static int neofb_blank(int blank_mode, struct fb_info *info)
 {
+	struct neofb_par *par = (struct neofb_par *)info->par;
+	int reg;
+
 	/*
-	 *  Blank the screen if blank_mode != 0, else unblank. If
-	 *  blank == NULL then the caller blanks by setting the CLUT
-	 *  (Color Look Up Table) to all black. Return 0 if blanking
-	 *  succeeded, != 0 if un-/blanking failed due to e.g. a
-	 *  video mode which doesn't support it. Implements VESA
-	 *  suspend and powerdown modes on hardware that supports
-	 *  disabling hsync/vsync:
-	 *    blank_mode == 2: suspend vsync
-	 *    blank_mode == 3: suspend hsync
-	 *    blank_mode == 4: powerdown
+	 *  Blank the screen if blank_mode != 0, else unblank.
+	 *  Return 0 if blanking succeeded, != 0 if un-/blanking failed due to
+	 *  e.g. a video mode which doesn't support it. Implements VESA suspend
+	 *  and powerdown modes for monitors, and backlight control on LCDs.
+	 *    blank_mode == 0: unblanked (backlight on)
+	 *    blank_mode == 1: blank (backlight on)
+	 *    blank_mode == 2: suspend vsync (backlight off)
+	 *    blank_mode == 3: suspend hsync (backlight off)
+	 *    blank_mode == 4: powerdown (backlight off)
 	 *
-	 *  wms...Enable VESA DMPS compatible powerdown mode
+	 *  wms...Enable VESA DPMS compatible powerdown mode
 	 *  run "setterm -powersave powerdown" to take advantage
 	 */
 
-	switch (blank) {
+	switch (blank_mode) {
 	case 4:		/* powerdown - both sync lines down */
+		reg = VGArSEQ(0x01) | 0x20;		/* Disable sequencer */
+		VGAwSEQ(0x01, reg);
+		reg = VGArGR(0x20) & ~0x02;		/* LCD off */
+		VGAwGR(0x20, reg);
+		reg = (VGArGR(0x01) & ~0xF0) | 0xB0; /* hsync off, vsync off */
+		VGAwGR(0x01, reg);
 #ifdef CONFIG_TOSHIBA
+		/* Do we still need this? */
 		/* attempt to turn off backlight on toshiba; also turns off external */
 		{
 			SMMRegisters regs;
@@ -1310,13 +1319,35 @@
 #endif
 		break;
 	case 3:		/* hsync off */
+		reg = VGArSEQ(0x01) | 0x20;		/* Disable sequencer */
+		VGAwSEQ(0x01, reg);
+		reg = VGArGR(0x20) & ~0x02;		/* LCD off */
+		VGAwGR(0x20, reg);
+		reg = (VGArGR(0x01) & ~0xF0) | 0xA0;   /* hsync off, vsync on */
+		VGAwGR(0x01, reg);
 		break;
 	case 2:		/* vsync off */
-		break;
-	case 1:		/* just software blanking of screen */
-		break;
-	default:		/* case 0, or anything else: unblank */
+		reg = VGArSEQ(0x01) | 0x20;		/* Disable sequencer */
+		VGAwSEQ(0x01, reg);
+		reg = VGArGR(0x20) & ~0x02;		/* LCD off */
+		VGAwGR(0x20, reg);
+		reg = (VGArGR(0x01) & ~0xF0) | 0x90;   /* hsync on, vsync off */
+		VGAwGR(0x01, reg);
+		break;
+	case 1:		/* just blank screen (backlight stays on) */
+		reg = VGArSEQ(0x01) | 0x20;		/* Disable sequencer */
+		VGAwSEQ(0x01, reg);
+		break;
+	case 0:		/* unblank */
+		reg = VGArSEQ(0x01) & ~0x20;		/* Enable sequencer */
+		VGAwSEQ(0x01, reg);
+		reg = VGArGR(0x20) & ~0x02;
+		reg |= (par->PanelDispCntlReg1 & 0x02); /* Set LCD to normal */
+		VGAwGR(0x20, reg);
+		reg = (VGArGR(0x01) & ~0xF0) | 0x80;	/* hsync on, vsync on */
+		VGAwGR(0x01, reg);
 #ifdef CONFIG_TOSHIBA
+		/* Do we still need this? */
 		/* attempt to re-enable backlight/external on toshiba */
 		{
 			SMMRegisters regs;
@@ -1328,6 +1359,9 @@
 		}
 #endif
 		break;
+	default:	/* Anything else we don't understand; return 1 to tell
+			 * fb_blank we didn't actually do anything */
+		return 1;
 	}
 	return 0;
 }

Re: [PATCH] neofb patches

[James Simmons]

> Sorry I took a little while to get these out..  Had a bit busier weekend than I
> expected..
> 
> Attached are my patches for the neofb driver.  All of these are against the
> 2.6.5 kernel.  I'm still kinda new to the whole framebuffer subsystem, so if
> I've done something horribly wrong, let me know.  

I have the same chipset. I have the new driver posted at my website. I 
tried your patchs but I had no luck.

> Anyway, the attached patches are as follows:
> 
> neofb.1.copyarea.patch  - Fix copyarea positioning bug

Yeap. Really bad bug. I fixed it in the new driver.

> neofb.2.imageblit.patch - Fix imageblit for color images
> 
>   It looks like the imageblit routine was written with only mono blits in 
>   mind. This patch adds support for color image transfers (Hi Tux!).

I tried this patch. My boot wouldn't boot with this patch. Mind you I 
never got the imageblit to work right.

> neofb.3.16bit.patch     - Misc fixes for 16-bit mode
>
>   Changed the visual reported for 16-bit mode from DirectColor to TrueColor,
>   since we don't support changing the colormap, which means we don't really
>   support DirectColor.  Also changed the palette entries for to be 32 bits 
>   wide even for 16-bit mode because this is what the logo code expects, 
>   and appears to be the correct way of doing things.

I haven't tried this one yet. Geert is this right?

> neofb.4.24bit.patch     - Make 24-bit mode work
> 
>   Added a couple of switch cases needed to make 24-bit mode actually work.
>   The colormap setting code also needed to be moved to be after vgaHWRestore,
>   so that the DAC would be configured properly (8-bit lookups) for 24-bit
>   color before writing to the lookup table.
> 
>   Also, it looks like there's a hardware bug with the NM2200 if you try to do a
>   color-expanded transfer in 24-bit mode and the width of the image is less
>   than 16 pixels wide (The left few pixels of the image seem to get partially
>   wrapped onto the right side.  I haven't tested all cases, actually.. I know
>   it breaks with 8-pixel-width blits), so in that case we just fall back to
>   cfb_imageblit instead.

This can be handled by struct fb_pixmap. It padded image scan_lines to 
what the hardware can handle or is optimized to.
 
> neofb.5.modedb.patch    - Change to use modedb for video mode selection
> 
>   Allows specifying the video mode on the kernel/insmod command line now too.

Also barfed my machine :-( I really like to get i2c support going. Perhaps 
we should ask neomagic for the full specs for this chipset.
 
> neofb.6.blanking.patch  - Add support for DPMS blanking

Ug. The new neofb driver has been moved over to use the new vga core code.
See vgastate.c and vga.h in include/video.




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

Re: [PATCH] neofb patches

[Antonino A. Daplas]

On Thu, 2004-04-22 at 01:47, James Simmons wrote:

> > neofb.3.16bit.patch     - Misc fixes for 16-bit mode
> >
> >   Changed the visual reported for 16-bit mode from DirectColor to TrueColor,
> >   since we don't support changing the colormap, which means we don't really
> >   support DirectColor.  Also changed the palette entries for to be 32 bits 
> >   wide even for 16-bit mode because this is what the logo code expects, 
> >   and appears to be the correct way of doing things.
> 
> I haven't tried this one yet. Geert is this right?

Yes, _all_ of the generic drawing functions expect the pseudopalette to
be always u32.

Tony






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

Re: [PATCH] neofb patches

[Alex Stewart]

On Wed, Apr 21, 2004 at 06:47:16PM +0100, James Simmons wrote:
> I have the same chipset. I have the new driver posted at my website. I 
> tried your patchs but I had no luck.

I wasn't aware of your patches earlier (or where to get them).. I found the URL
you posted in another message and have just downloaded the diff and will look
into integrating things..

What is your LCD resolution, BTW?

> > neofb.2.imageblit.patch - Fix imageblit for color images
> > 
> >   It looks like the imageblit routine was written with only mono blits in 
> >   mind. This patch adds support for color image transfers (Hi Tux!).
> 
> I tried this patch. My boot wouldn't boot with this patch. Mind you I 
> never got the imageblit to work right.

Could you be a little more specific?

Were you applying this to a stock kernel or to your patched driver?  What
exactly happened when you tried it?  You were booting in 8-bit color mode, I
assume?

> >   Also, it looks like there's a hardware bug with the NM2200 if you try to do a
> >   color-expanded transfer in 24-bit mode and the width of the image is less
> >   than 16 pixels wide (The left few pixels of the image seem to get partially
> >   wrapped onto the right side.  I haven't tested all cases, actually.. I know
> >   it breaks with 8-pixel-width blits), so in that case we just fall back to
> >   cfb_imageblit instead.
> 
> This can be handled by struct fb_pixmap. It padded image scan_lines to 
> what the hardware can handle or is optimized to.

Ok, I'll take a look at this.. I was planning on going back and investigating
this further anyway.  Initially I was just concentrating on getting working
functionality.

> > neofb.5.modedb.patch    - Change to use modedb for video mode selection
> > 
> >   Allows specifying the video mode on the kernel/insmod command line now too.
> 
> Also barfed my machine :-( I really like to get i2c support going. Perhaps 
> we should ask neomagic for the full specs for this chipset.

Hmm.. again, what does "barfed" mean, exactly?  Did you try specifying
different video modes on the command line?

> > neofb.6.blanking.patch  - Add support for DPMS blanking
> 
> Ug. The new neofb driver has been moved over to use the new vga core code.
> See vgastate.c and vga.h in include/video.

Ah, ok.. I'll make the appropriate adjustments.

-alex


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

Re: [PATCH] neofb patches

[Geert Uytterhoeven]

On Wed, 22 Apr 2004, Antonino A. Daplas wrote:
> On Thu, 2004-04-22 at 01:47, James Simmons wrote:
> > > neofb.3.16bit.patch     - Misc fixes for 16-bit mode
> > >
> > >   Changed the visual reported for 16-bit mode from DirectColor to TrueColor,
> > >   since we don't support changing the colormap, which means we don't really
> > >   support DirectColor.  Also changed the palette entries for to be 32 bits
> > >   wide even for 16-bit mode because this is what the logo code expects,
> > >   and appears to be the correct way of doing things.
> >
> > I haven't tried this one yet. Geert is this right?

Not sure whether your question applies to the first or the second part...

> Yes, _all_ of the generic drawing functions expect the pseudopalette to
> be always u32.

... so I'll respond to the first part: yes, truecolor means a fixed (linear)
CLUT, directcolor means a changeable CLUT.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


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

Re: [PATCH] neofb patches

[James Simmons]

> On Wed, Apr 21, 2004 at 06:47:16PM +0100, James Simmons wrote:
> > I have the same chipset. I have the new driver posted at my website. I 
> > tried your patchs but I had no luck.
> 
> I wasn't aware of your patches earlier (or where to get them).. I found the URL
> you posted in another message and have just downloaded the diff and will look
> into integrating things..
> 
> What is your LCD resolution, BTW?

1024x768. Its a IBM thinkpad 600X.

> 
> > > neofb.2.imageblit.patch - Fix imageblit for color images
> > > 
> > >   It looks like the imageblit routine was written with only mono blits in 
> > >   mind. This patch adds support for color image transfers (Hi Tux!).
> > 
> > I tried this patch. My boot wouldn't boot with this patch. Mind you I 
> > never got the imageblit to work right.
> 
> Could you be a little more specific?
> 
> Were you applying this to a stock kernel or to your patched driver?  What
> exactly happened when you tried it?  You were booting in 8-bit color mode, I
> assume?

Patched driver. I manually applied your patches. I start in 8 bpp mode. 
Nothing appeared on the screen.

> > This can be handled by struct fb_pixmap. It padded image scan_lines to 
> > what the hardware can handle or is optimized to.
> 
> Ok, I'll take a look at this.. I was planning on going back and investigating
> this further anyway.  Initially I was just concentrating on getting working
> functionality.

Okay. Cool We can work on a solution for this problem.
 
> > > neofb.5.modedb.patch    - Change to use modedb for video mode selection
> > > 
> > >   Allows specifying the video mode on the kernel/insmod command line now too.
> > 
> > Also barfed my machine :-( I really like to get i2c support going. Perhaps 
> > we should ask neomagic for the full specs for this chipset.
> 
> Hmm.. again, what does "barfed" mean, exactly?  Did you try specifying
> different video modes on the command line?

Blank screen.

> > > neofb.6.blanking.patch  - Add support for DPMS blanking
> > 
> > Ug. The new neofb driver has been moved over to use the new vga core code.
> > See vgastate.c and vga.h in include/video.
> 
> Ah, ok.. I'll make the appropriate adjustmen
> 
> -alex
> 



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[Alex Stewart]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

Well, I downloaded your diff for the neofb driver and tried it out.  I did
notice there appears to be a slight bug in it.  Whenever anything (such as
fbset) closes /dev/fb0, the driver clobbers the device registers (resulting in
a blank screen).

I'm assuming the attached correction is more what was intended..

I'm currently merging our two sets of patches into one driver.  I do note that
patch gets a little confused when trying to do it itself and places a couple of
bits of code in really odd places, which might have been part of why it didn't
work for you.  I think I should have an updated patchset ready to post later
tonight..

-alex

[-- Attachment #2: neofb-js.1.releasebug.patch --]
[-- Type: text/plain, Size: 414 bytes --]

--- drivers/video/neofb.c.jsimmons	2004-04-22 18:32:19.000000000 -0700
+++ drivers/video/neofb.c	2004-04-22 21:21:02.000000000 -0700
@@ -562,7 +562,7 @@
 	struct neofb_par *par = (struct neofb_par *) info->par;
 	int cnt = atomic_read(&par->ref_count);
 
-	if (cnt) {
+	if (!cnt) {
 		memset(&par->state, 0, sizeof(struct vgastate));
 		par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS;
 		save_vga(&par->state);

Re: [PATCH] neofb patches

[Alex Stewart]

> I'm currently merging our two sets of patches into one driver.  I do
> note that patch gets a little confused when trying to do it itself and
> places a couple of bits of code in really odd places, which might have
> been part of why it didn't work for you.  I think I should have an
> updated patchset ready to post later tonight..

Ok, I've got everything except the blanking patch (which isn't finished
anyway) converted to apply cleanly to James' patched driver source. 
Everything works fine on my laptop as far as I can tell.  Additional
feedback is welcome.

I've put up a web page for the patches.  They can be found at
http://www.foogod.com/~alex/neofb/

-alex




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[James Simmons]

Applied. I wonder if this means that the neofb can go back and forth to 
vga text mode :-)

On Thu, 22 Apr 2004, Alex Stewart wrote:

> Well, I downloaded your diff for the neofb driver and tried it out.  I did
> notice there appears to be a slight bug in it.  Whenever anything (such as
> fbset) closes /dev/fb0, the driver clobbers the device registers (resulting in
> a blank screen).
> 
> I'm assuming the attached correction is more what was intended..
> 
> I'm currently merging our two sets of patches into one driver.  I do note that
> patch gets a little confused when trying to do it itself and places a couple of
> bits of code in really odd places, which might have been part of why it didn't
> work for you.  I think I should have an updated patchset ready to post later
> tonight..
> 
> -alex
> 



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[Alex Stewart]

> Yes, _all_ of the generic drawing functions expect the pseudopalette to
> be always u32.

Just curious, but if this is the case, why isn't pseudo_palette defined as
a "u32 *" (instead of "void *") in struct fb_info?  If anything outside
the driver itself is going to be using this, it really should be more
explicit what format it's supposed to be in.

For that matter, is it really kosher to have the logo code (or other
things external to the driver) setting pseudo_palette directly anyway? 
Shouldn't there be some sort of an interface function for this (at the
very least to let the driver know it's changed, in case it needs to know
that sort of thing)?

-alex




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[James Simmons]

In that case the pacth will be applied.


On 22 Apr 2004, Antonino A. Daplas wrote:

> On Thu, 2004-04-22 at 01:47, James Simmons wrote:
> 
> > > neofb.3.16bit.patch     - Misc fixes for 16-bit mode
> > >
> > >   Changed the visual reported for 16-bit mode from DirectColor to TrueColor,
> > >   since we don't support changing the colormap, which means we don't really
> > >   support DirectColor.  Also changed the palette entries for to be 32 bits 
> > >   wide even for 16-bit mode because this is what the logo code expects, 
> > >   and appears to be the correct way of doing things.
> > 
> > I haven't tried this one yet. Geert is this right?
> 
> Yes, _all_ of the generic drawing functions expect the pseudopalette to
> be always u32.
> 
> Tony
> 
> 
> 
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[James Simmons]

It fixed a color map problem I had :-)


On Fri, 23 Apr 2004, James Simmons wrote:

> 
> In that case the pacth will be applied.
> 
> 
> On 22 Apr 2004, Antonino A. Daplas wrote:
> 
> > On Thu, 2004-04-22 at 01:47, James Simmons wrote:
> > 
> > > > neofb.3.16bit.patch     - Misc fixes for 16-bit mode
> > > >
> > > >   Changed the visual reported for 16-bit mode from DirectColor to TrueColor,
> > > >   since we don't support changing the colormap, which means we don't really
> > > >   support DirectColor.  Also changed the palette entries for to be 32 bits 
> > > >   wide even for 16-bit mode because this is what the logo code expects, 
> > > >   and appears to be the correct way of doing things.
> > > 
> > > I haven't tried this one yet. Geert is this right?
> > 
> > Yes, _all_ of the generic drawing functions expect the pseudopalette to
> > be always u32.
> > 
> > Tony
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[James Simmons]

> Just curious, but if this is the case, why isn't pseudo_palette defined as
> a "u32 *" (instead of "void *") in struct fb_info?  If anything outside
> the driver itself is going to be using this, it really should be more
> explicit what format it's supposed to be in.

Because there can cases when the hardware requires a 16 bit value. Here we 
can optimize the pseudo_palette to a smaller size. This is for the case 
where we have hardware acceleration. 

> For that matter, is it really kosher to have the logo code (or other
> things external to the driver) setting pseudo_palette directly anyway? 
> Shouldn't there be some sort of an interface function for this (at the
> very least to let the driver know it's changed, in case it needs to know
> that sort of thing)?

That is totally bad. In fact the code is broken in that when I attempt to 
draw a 4 bpp image on 16 bpp or 32 bpp framebuffers the colors come out 
all wrong. This is not easy to fix. All the drivers need to be brought up 
to date in creating a 256 palette cmap. As I update drivers you wil see 
this fix. Once the drivers are done the logo hacks can go away.




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[James Simmons]

> Ok, I've got everything except the blanking patch (which isn't finished
> anyway) converted to apply cleanly to James' patched driver source. 
> Everything works fine on my laptop as far as I can tell.  Additional
> feedback is welcome.
> 
> I've put up a web page for the patches.  They can be found at
> http://www.foogod.com/~alex/neofb/

Got it. I merged your patches. I also did a few fixes. The code had issues 
with non byte align images, i.e sparc 12x22 fonts. Now it works. I posted 
at

http://phoenix.infradead.org:~/jsimmons/neofb.diff.gz

This is against the latest kernel.





-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[James Simmons]

> Not sure whether your question applies to the first or the second part...

I was asking which visual is right. His patch is correct thanks to your 
info below. 

 
> > Yes, _all_ of the generic drawing functions expect the pseudopalette to
> > be always u32.
> 
> ... so I'll respond to the first part: yes, truecolor means a fixed (linear)
> CLUT, directcolor means a changeable CLUT.
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> 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
> 



-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [Linux-fbdev-devel] [PATCH] neofb patches

[Randy.Dunlap]

On Sat, 24 Apr 2004 00:00:23 +0100 (BST) James Simmons <jsimmons@infradead.org> wrote:

| 
| > Ok, I've got everything except the blanking patch (which isn't finished
| > anyway) converted to apply cleanly to James' patched driver source. 
| > Everything works fine on my laptop as far as I can tell.  Additional
| > feedback is welcome.
| > 
| > I've put up a web page for the patches.  They can be found at
| > http://www.foogod.com/~alex/neofb/
| 
| Got it. I merged your patches. I also did a few fixes. The code had issues 
| with non byte align images, i.e sparc 12x22 fonts. Now it works. I posted 
| at
| 
| http://phoenix.infradead.org:~/jsimmons/neofb.diff.gz
| 
| This is against the latest kernel.

Hi James,

I think it would help a bit if someone could load
http://phoenix.infradead.org/~jsimmons/ in a web browser
and be able to see a list of files/patches/etc there
instead of having to know an exact file name to grab.

--
~Randy

Re: [PATCH] neofb patches

[Alex Stewart]

> | http://phoenix.infradead.org:~/jsimmons/neofb.diff.gz
> |
> | This is against the latest kernel.
>
> Hi James,
>
> I think it would help a bit if someone could load
> http://phoenix.infradead.org/~jsimmons/ in a web browser
> and be able to see a list of files/patches/etc there
> instead of having to know an exact file name to grab.

Well, since he only seems to have one patch available at any given time,
this doesn't seem like that big a deal to me, personally..  I was,
however, thinking of suggesting that it might be easier to keep track of
things if there were some sort of version numbers or datestamps or
something in the filename so somebody can tell that this "neofb.diff.gz"
is actually a different patch from the "neofb.diff.gz" that was in exactly
the same place yesterday..

-alex




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[Alex Stewart]

> Got it. I merged your patches.

Umm, I would really appreciate it if you didn't silently leave out bits of
my patches and then just say "I merged your patches".  It took me a little
bit to figure out that the reason panning now isn't used for fbconsole
scrolls is because you just didn't bother to put that part of my patch in.

Is there some reason you left out the following piece of my modedb patch?

+       /* Turn on panning for console scroll by default */
+       info->var.yres_virtual = 30000;
+       info->var.accel_flags |= FB_ACCELF_TEXT;
+       if (neofb_check_var(&info->var, info))
+               goto err_map_video;

-alex




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[James Simmons]

> Umm, I would really appreciate it if you didn't silently leave out bits of
> my patches and then just say "I merged your patches".  It took me a little
> bit to figure out that the reason panning now isn't used for fbconsole
> scrolls is because you just didn't bother to put that part of my patch in.
> 
> Is there some reason you left out the following piece of my modedb patch?
> 
> +       /* Turn on panning for console scroll by default */
> +       info->var.yres_virtual = 30000;
> +       info->var.accel_flags |= FB_ACCELF_TEXT;
> +       if (neofb_check_var(&info->var, info))
> +               goto err_map_video;

   The reason is because fb_find_mode calls check_var for us. No reason to 
call it twice. The large yres_virtual being 30000 that is not needed any 
longer. The accel flag is set in neofb_check_var. The current test is

if (var->bits_per_pixel >= 24 || !par->neo2200)
	var->accel_flags &= ~FB_ACCEL_TEXT;

Should we drop the bpp >= 24 test? Do you observe this problem at all 
depths.








-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [Linux-fbdev-devel] [PATCH] neofb patches

[James Simmons]

> Hi James,
> 
> I think it would help a bit if someone could load
> http://phoenix.infradead.org/~jsimmons/ in a web browser
> and be able to see a list of files/patches/etc there
> instead of having to know an exact file name to grab.

Your right. I have to wipe up a web page for that.

Re: [Linux-fbdev-devel] [PATCH] neofb patches

[James Simmons]

> Well, since he only seems to have one patch available at any given time,
> this doesn't seem like that big a deal to me, personally..  I was,
> however, thinking of suggesting that it might be easier to keep track of
> things if there were some sort of version numbers or datestamps or
> something in the filename so somebody can tell that this "neofb.diff.gz"
> is actually a different patch from the "neofb.diff.gz" that was in exactly
> the same place yesterday..

Okay. I can add a date stamp on it.

Re: [PATCH] neofb patches

[Alex Stewart]

>> +       /* Turn on panning for console scroll by default */
>> +       info->var.yres_virtual = 30000;
>> +       info->var.accel_flags |= FB_ACCELF_TEXT;
>> +       if (neofb_check_var(&info->var, info))
>> +               goto err_map_video;
>
>    The reason is because fb_find_mode calls check_var for us. No reason
> to
> call it twice. The large yres_virtual being 30000 that is not needed any
>  longer. The accel flag is set in neofb_check_var. The current test is
>
> if (var->bits_per_pixel >= 24 || !par->neo2200)
> 	var->accel_flags &= ~FB_ACCEL_TEXT;

Actually, look more closely at that code.  That is _unsetting_
FB_ACCEL_TEXT under some circumstances, but under the current new code it
never actually gets set anywhere.  I originally had my code your way, but
then needed to add the extra bit above to get ypanning to actually work.

yres_virtual does need to be set larger than yres in order for ypanning to
function, last I checked.  In order to set it to the correct value for the
particular card, we set it to 30000 (very large), and then call check_var
to have it scale it down to what the hardware can handle (this seems
cleaner to me than duplicating the code to properly size things in two
routines).  This must be done after the correct video mode is found by
fb_find_mode, however.  We could have set FB_ACCEL_TEXT earlier, but I put
it in the same place for clarity.

> Should we drop the bpp >= 24 test? Do you observe this problem at all
> depths.

We probably should change that to a "> 24" yeah (or maybe just get rid of
it all together).. I hadn't caught that before.  I haven't actually tested
it at 24-bit but I don't see why it shouldn't work.

-alex




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[James Simmons]

> >    The reason is because fb_find_mode calls check_var for us. No reason
> > to
> > call it twice. The large yres_virtual being 30000 that is not needed any
> >  longer. The accel flag is set in neofb_check_var. The current test is
> >
> > if (var->bits_per_pixel >= 24 || !par->neo2200)
> > 	var->accel_flags &= ~FB_ACCEL_TEXT;
> 
> Actually, look more closely at that code.  That is _unsetting_
> FB_ACCEL_TEXT under some circumstances, but under the current new code it
> never actually gets set anywhere.  I originally had my code your way, but
> then needed to add the extra bit above to get ypanning to actually work.

Your right. I need to reverse that logic.
 
> yres_virtual does need to be set larger than yres in order for ypanning to
> function, last I checked.  In order to set it to the correct value for the
> particular card, we set it to 30000 (very large), and then call check_var
> to have it scale it down to what the hardware can handle (this seems
> cleaner to me than duplicating the code to properly size things in two
> routines).  This must be done after the correct video mode is found by
> fb_find_mode, however.  We could have set FB_ACCEL_TEXT earlier, but I put
> it in the same place for clarity.

Yipes!!!!! You found a nasty bug in modedb. The present modedb code sets 
both xres/xres_virtual to the same value and yres/yres_virtual to the same
value. This means any driver that uses modedb automatically turns off 
panning. This is bad. 

> > Should we drop the bpp >= 24 test? Do you observe this problem at all
> > depths.
> 
> We probably should change that to a "> 24" yeah (or maybe just get rid of
> it all together).. I hadn't caught that before.  I haven't actually tested
> it at 24-bit but I don't see why it shouldn't work.

The new test I purpose is 

if (par->neo2200 && var->bits_per_pixel != 32)
	var->accel_flags = FB_ACCELF_TEXT;




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[Alex Stewart]

> Yipes!!!!! You found a nasty bug in modedb. The present modedb code sets
>  both xres/xres_virtual to the same value and yres/yres_virtual to the
> same value. This means any driver that uses modedb automatically turns
> off  panning. This is bad.

Heh.. and here I thought that was intentional (I assumed it was because
some drivers (which don't support panning) might balk at a perfectly valid
mode if the virtual and actual numbers weren't the same).  I had rather
assumed that other drivers worked around it like I did :)

> The new test I purpose is
>
> if (par->neo2200 && var->bits_per_pixel != 32)
> 	var->accel_flags = FB_ACCELF_TEXT;

Actually, since we don't have any way currently to get var->bits_per_pixel
== 32 (and the driver would need a lot of work to get to that point at
which point this case could (and should) actually be tested instead of
just assuming it doesn't work), why don't we just simplify it to:

if (par->neo2200)
	var->accel_flags = FB_ACCELF_TEXT;

I've never been too clear on what direction these FB_ACCELF things (and
related values) are supposed to be going.  Are they something set by the
driver to indicate what it can support, or are they something set by the
higher level systems (or the user) to tell the driver what they would like
to do?

I had figured from the previous code that these flags should be set when
calling check_var if the higher-level stuff wanted acceleration for the
particular mode setting, and the driver would unset any it wasn't able to
support.  This changes the behavior to automatically turning it on
whenever the hardware is capable of it, regardless of what the higher
level stuff asks for (which is actually probably a better protocol, but is
it the way all the other stuff is expecting it to work?).

Actually, in any case, the current code is still more correct than the
proposed code above.  Under the proposed code, if something sets
FB_ACCELF_TEXT, then calls check_var, FB_ACCELF_TEXT will stay set even if
the hardware can't do it.  We should probably keep the old test in there
too to prevent this case.

Howabout:

if (par->neo2200)
	var->accel_flags = FB_ACCELF_TEXT;
else
	var->accel_flags = 0;

-alex




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[Geert Uytterhoeven]

On Mon, 26 Apr 2004, Alex Stewart wrote:
> I've never been too clear on what direction these FB_ACCELF things (and
> related values) are supposed to be going.  Are they something set by the
> driver to indicate what it can support, or are they something set by the
> higher level systems (or the user) to tell the driver what they would like
> to do?
>
> I had figured from the previous code that these flags should be set when
> calling check_var if the higher-level stuff wanted acceleration for the
> particular mode setting, and the driver would unset any it wasn't able to
> support.  This changes the behavior to automatically turning it on
> whenever the hardware is capable of it, regardless of what the higher
> level stuff asks for (which is actually probably a better protocol, but is
> it the way all the other stuff is expecting it to work?).

It's used to indicate that the frame buffer device uses hardware acceleration
for rectangle fill/copy and imageblit.

It must be explicitly disabled before a user space application can mmap the
MMIO registers to do its own hardware acceleration, to avoid accelerator access
conflicts.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[Geert Uytterhoeven]

On Mon, 26 Apr 2004, Alex Stewart wrote:
> yres_virtual does need to be set larger than yres in order for ypanning to
> function, last I checked.  In order to set it to the correct value for the
> particular card, we set it to 30000 (very large), and then call check_var
> to have it scale it down to what the hardware can handle (this seems

Hmm, but the `rules' are to round _up_ a value if it doesn't fit, or return an
error.

Rounding down violates this rule.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

> It's used to indicate that the frame buffer device uses hardware acceleration
> for rectangle fill/copy and imageblit.
> 
> It must be explicitly disabled before a user space application can mmap the
> MMIO registers to do its own hardware acceleration, to avoid accelerator access
> conflicts.

I think we should stick to KD_TEXT/KD_GRAPHICS for who owns the engine.

I don't think fbdev should expose any "acclerated" API to userland, that
is a hopeless goal and will lead to nothing. We need some arbitration
layer at one point between whatever accel stuff we use (DRI, userland
accel library) and somebody changing mode though. Lots of stuffs I've
tried to figure out and didn't end up with anything reasonable yet, lack
of time doesn't help...

Ben.




-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[James Simmons]

> > It's used to indicate that the frame buffer device uses hardware acceleration
> > for rectangle fill/copy and imageblit.
> > 
> > It must be explicitly disabled before a user space application can mmap the
> > MMIO registers to do its own hardware acceleration, to avoid accelerator access
> > conflicts.
> 
> I think we should stick to KD_TEXT/KD_GRAPHICS for who owns the engine.

I wouldn't bank on that. I seen this solution fall short. Consider a system 
where we have a serial console, vgacon, and fbcon (say hgafb). Well I 
leave it to the imagination what can go wrong. 
 
> I don't think fbdev should expose any "acclerated" API to userland, that
> is a hopeless goal and will lead to nothing. We need some arbitration
> layer at one point between whatever accel stuff we use (DRI, userland
> accel library) and somebody changing mode though. Lots of stuffs I've
> tried to figure out and didn't end up with anything reasonable yet, lack
> of time doesn't help...

I agree we need arbitration. Eventually fbdev and dri have to merge. Mode 
setting is still best handled kernel side. That is just a reality.






-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

Re: [PATCH] neofb patches

[John Zielinski]

James Simmons wrote:

>I wouldn't bank on that. I seen this solution fall short. Consider a system 
>where we have a serial console, vgacon, and fbcon (say hgafb). Well I 
>leave it to the imagination what can go wrong. 
>  
>
I can see how vgacon and fbcon would walk all over each other but how 
would a serial console
mess things up?

>I agree we need arbitration. Eventually fbdev and dri have to merge. Mode 
>setting is still best handled kernel side. That is just a reality.
>
>  
>
Arbitration would be best.  How would it be done generally?  Some 
mechanism that arbitrates based on mem/io ranges or something else?

John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

On Wed, 2004-04-28 at 08:48, John Zielinski wrote:
> James Simmons wrote:
> 
> >I wouldn't bank on that. I seen this solution fall short. Consider a system 
> >where we have a serial console, vgacon, and fbcon (say hgafb). Well I 
> >leave it to the imagination what can go wrong. 
> >  
> >
> I can see how vgacon and fbcon would walk all over each other but how 
> would a serial console
> mess things up?

Same question... Where is the problem ?

> >I agree we need arbitration. Eventually fbdev and dri have to merge. Mode 
> >setting is still best handled kernel side. That is just a reality.
> >
> >  
> >
> Arbitration would be best.  How would it be done generally?  Some 
> mechanism that arbitrates based on mem/io ranges or something else?

We need several level of arbitration, I'm not sure hwo to do that at
this point and I don't have time to dive into the DRI side of things.

Jon Smirl has been working on embedded mesa & moving DRI outside of
X. Unfortunately, last I heard, he was still on his trip of re-inventing
everything including replacing the fbdev's with his own stuff instead
of moving from what we have ...

Ben,



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[James Simmons]

> > I can see how vgacon and fbcon would walk all over each other but how 
> > would a serial console
> > mess things up?
> 
> Same question... Where is the problem ?

Say two people are logged in. One on a serial console and another on the 
framebuffer console. The person starts X fbdev from the serial console. 
Ooops the fbcon user lost his console.

> We need several level of arbitration, I'm not sure hwo to do that at
> this point and I don't have time to dive into the DRI side of things.
> 
> Jon Smirl has been working on embedded mesa & moving DRI outside of
> X. Unfortunately, last I heard, he was still on his trip of re-inventing
> everything including replacing the fbdev's with his own stuff instead
> of moving from what we have ...

Ug. This is sad :-(





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

On Wed, 2004-04-28 at 09:21, James Simmons wrote:
> > > I can see how vgacon and fbcon would walk all over each other but how 
> > > would a serial console
> > > mess things up?
> > 
> > Same question... Where is the problem ?
> 
> Say two people are logged in. One on a serial console and another on the 
> framebuffer console. The person starts X fbdev from the serial console. 
> Ooops the fbcon user lost his console.

And ? Where is the problem ? I can do that today with ssh ... That's
normal console switch. X will trigger a console switch to a new VT,
it will not just tap on the current console "as is".

> > We need several level of arbitration, I'm not sure hwo to do that at
> > this point and I don't have time to dive into the DRI side of things.
> > 
> > Jon Smirl has been working on embedded mesa & moving DRI outside of
> > X. Unfortunately, last I heard, he was still on his trip of re-inventing
> > everything including replacing the fbdev's with his own stuff instead
> > of moving from what we have ...
> 
> Ug. This is sad :-(
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[John Zielinski]

James Simmons wrote:

>Say two people are logged in. One on a serial console and another on the 
>framebuffer console. The person starts X fbdev from the serial console. 
>Ooops the fbcon user lost his console.
>  
>
That's another thing I'm adding to my kernel.  I didn't mention it as 
I'm still trying to nail down a few details.  My current experiment is 
that I've made device number 5,255 for now (later I'm either going to 
make it 5,0 or just make fb0 point to it but that's one of the things 
I'm debating) and call it just fb (for now).  Now when a user opens this 
fb it will figure out what console they're on and refuse to run if it's 
they're not on a physical console (unless fbcon is not compiled then it 
will default to fb0 - these are the details I'm working on).

Now if the user really wants to start something from a serial console or 
even a ssh session for that matter they can just use an explicit frame 
buffer device like fb0, fb1, etc.  These would then be root only for 
example.

An added bonus is that if you have multiple video cards or a dual head 
configuration with each head on a different fbx device the 5,255 device 
would figure out which console you are on when you start the program and 
use the appropriate fb device.  Once the radeon dual head code gets 
written I'll have to try to start X on fb0 (head 1) and leave the fbcon 
running on fb1 (head two).

But this is just a fun little experiment on my part.  If I succeed I'll 
let everyone know.

John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

> That's another thing I'm adding to my kernel.  I didn't mention it as 
> I'm still trying to nail down a few details.  My current experiment is 
> that I've made device number 5,255 for now (later I'm either going to 
> make it 5,0 or just make fb0 point to it but that's one of the things 
> I'm debating) and call it just fb (for now).  Now when a user opens this 
> fb it will figure out what console they're on and refuse to run if it's 
> they're not on a physical console (unless fbcon is not compiled then it 
> will default to fb0 - these are the details I'm working on).

Hrm... I'm not fully confortable with this. I don't see why we need
anything different but what we had today.

> Now if the user really wants to start something from a serial console or 
> even a ssh session for that matter they can just use an explicit frame 
> buffer device like fb0, fb1, etc.  These would then be root only for 
> example.

Nah, software like X, MacOnLinux, etc... should open a VT and trigger a
console switch. Or at least switch to KD_GRAPHICS if they don't, but
then, having a user doing that to your console is only a matter of
setting the proper permissions. Again, I don't see what problem you
are trying to solve.

> An added bonus is that if you have multiple video cards or a dual head 
> configuration with each head on a different fbx device the 5,255 device 
> would figure out which console you are on when you start the program and 
> use the appropriate fb device.  Once the radeon dual head code gets 
> written I'll have to try to start X on fb0 (head 1) and leave the fbcon 
> running on fb1 (head two).
> 
> But this is just a fun little experiment on my part.  If I succeed I'll 
> let everyone know.
> 
> John
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Wed, Apr 28, 2004 at 09:10:55AM +1000, Benjamin Herrenschmidt wrote:
> Jon Smirl has been working on embedded mesa & moving DRI outside of
> X. Unfortunately, last I heard, he was still on his trip of re-inventing
> everything including replacing the fbdev's with his own stuff instead
> of moving from what we have ...

Ooops! that will break my software that relies on fbdev and                                                                                                                       
mesa-solo!

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Wed, Apr 28, 2004 at 12:21:13AM +0100, James Simmons wrote:
> Say two people are logged in. One on a serial console and another on the 
> framebuffer console. The person starts X fbdev from the serial console. 
> Ooops the fbcon user lost his console.

User logged in from serial console should not be a member
of the 'video' group.  PAM solved that a while ago with
/etc/security/group.conf assuming a well configured box.

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Tue, Apr 27, 2004 at 07:46:33PM -0400, John Zielinski wrote:
> An added bonus is that if you have multiple video cards or a dual head 
> configuration with each head on a different fbx device the 5,255 device 
> would figure out which console you are on when you start the program and 
> use the appropriate fb device.  Once the radeon dual head code gets 
> written I'll have to try to start X on fb0 (head 1) and leave the fbcon 
> running on fb1 (head two).

I was wondering if it is possible currently (kernel 2.6.5) to
have 2 differents video cards in 2 differents VCs and in 2
differents fbdev's.  I have an old trident pci card and one
radeon agp card.  I want to run X (Xfbdev) in the trident one
and mesa-solo in the radeon one, is that possible? how?

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

On Wed, 2004-04-28 at 10:20, Otto Solares wrote:
> On Wed, Apr 28, 2004 at 09:10:55AM +1000, Benjamin Herrenschmidt wrote:
> > Jon Smirl has been working on embedded mesa & moving DRI outside of
> > X. Unfortunately, last I heard, he was still on his trip of re-inventing
> > everything including replacing the fbdev's with his own stuff instead
> > of moving from what we have ...
> 
> Ooops! that will break my software that relies on fbdev and                                                                                                                       
> mesa-solo!

Well, I'm sure there is some good in what he is doing too, I don't 
have time to deal with that at the moment, it would be interesting
to synchronise properly though.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[John Zielinski]

Benjamin Herrenschmidt wrote:

>Hrm... I'm not fully confortable with this. I don't see why we need
>anything different but what we had today.
>
>  
>
For stuff like X, MacOnLinux, etc that totally take over it doesn't make 
too much sense.  But for framebuffer programs like picture viewers, 
movie players, games, and other non desktop single purpose applications 
it makes a lot of sense.

For example lets say I have odd numbered consoles mapped on my AGP 
Radeon card and even numbered consoles mapped to my PCI Riva card.  I 
switch to console 1 and fire up a fb dvd player app.  It opens /dev/fb 
(29,255) and switches to KD_GRAPHICS.   LOTR starts playing on my big 
21" monitor hooked up to the Radeon.  As a user I didn't have to know 
that /dev/fb0 was really my 21" monitor and didn't have to give any 
command line switches to do this.  The cursor was blinking on my 21" and 
all I had to do is type dvdplay and away I went.  I would also be 
prevented from switching to odd numbered consoles now.

No problem.  ALT-F2 and now my 19" monitor has a blinking cursor.  I 
type in picview and again the jpeg viewing program opens /dev/fb and 
switches to KD_GRAPHICS and now I'm looking a vacation photos on my old 
riva card.  Again, I didn't have to know that /dev/fb1 is my 19" monitor 
and no command line arguments.  The app fires up on the monitor that had 
the focus (forground console doesn't sound right on multi monitor setups 
IMHO).

Now I can only switch between console 1 and 2.  Consoles 3 and up can't 
be switched to as both fb devices are in use.

BTW, this is just an example.  I don't know if a fb dvd player is out 
there but I do belive there's a picture viewing fb app.

>Nah, software like X, MacOnLinux, etc... should open a VT and trigger a
>console switch. Or at least switch to KD_GRAPHICS if they don't, but
>then, having a user doing that to your console is only a matter of
>setting the proper permissions. Again, I don't see what problem you
>are trying to solve.
>  
>

Normally yes.  But let's say a switch was added to X or X's fb driver to 
tell it to not open a new VT and just start on the current console.  If 
I fire it up on console 1 X starts on my 21" monitor but if I start it 
on console 2 it fires up on my 19" monitor.  The other monitor would 
still have a console.

This was just a fun thought to see if it would actually work.  But the 
dvd/picture example above is very practical.

John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

> For example lets say I have odd numbered consoles mapped on my AGP 
> Radeon card and even numbered consoles mapped to my PCI Riva card.  I 
> switch to console 1 and fire up a fb dvd player app.  It opens /dev/fb 
> (29,255) and switches to KD_GRAPHICS.   LOTR starts playing on my big 
> 21" monitor hooked up to the Radeon.  As a user I didn't have to know 
> that /dev/fb0 was really my 21" monitor and didn't have to give any 
> command line switches to do this.  The cursor was blinking on my 21" and 
> all I had to do is type dvdplay and away I went.  I would also be 
> prevented from switching to odd numbered consoles now.

Why ? Your player doesn't support proper console switching ?

> No problem.  ALT-F2 and now my 19" monitor has a blinking cursor.  I 
> type in picview and again the jpeg viewing program opens /dev/fb and 
> switches to KD_GRAPHICS and now I'm looking a vacation photos on my old 
> riva card.  Again, I didn't have to know that /dev/fb1 is my 19" monitor 
> and no command line arguments.  The app fires up on the monitor that had 
> the focus (forground console doesn't sound right on multi monitor setups 
> IMHO).
> 
> Now I can only switch between console 1 and 2.  Consoles 3 and up can't 
> be switched to as both fb devices are in use.
> 
> BTW, this is just an example.  I don't know if a fb dvd player is out 
> there but I do belive there's a picture viewing fb app.

You don't need a /dev/fb for that do you ? You need to map the current
vt to it's fb via the existing fbdev ioctls, isn't that possible ? (just
asking , I've never actually done that).

> Normally yes.  But let's say a switch was added to X or X's fb driver to 
> tell it to not open a new VT and just start on the current console.  If 
> I fire it up on console 1 X starts on my 21" monitor but if I start it 
> on console 2 it fires up on my 19" monitor.  The other monitor would 
> still have a console.
> 
> This was just a fun thought to see if it would actually work.  But the 
> dvd/picture example above is very practical.

Yup, but I don't think we need to change much of the actual code to
acheive this result. We still have the KD_GRAPHICS/KD_TEXT thing for
arbitrating who owns the accel engine and it would just work.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Antonino A. Daplas]

On Wednesday 28 April 2004 08:29, Otto Solares wrote:
> On Tue, Apr 27, 2004 at 07:46:33PM -0400, John Zielinski wrote:
> > An added bonus is that if you have multiple video cards or a dual head
> > configuration with each head on a different fbx device the 5,255 device
> > would figure out which console you are on when you start the program and
> > use the appropriate fb device.  Once the radeon dual head code gets
> > written I'll have to try to start X on fb0 (head 1) and leave the fbcon
> > running on fb1 (head two).
>
> I was wondering if it is possible currently (kernel 2.6.5) to
> have 2 differents video cards in 2 differents VCs and in 2
> differents fbdev's.  I have an old trident pci card and one
> radeon agp card.  I want to run X (Xfbdev) in the trident one
> and mesa-solo in the radeon one, is that possible? how?
>

Yes, I've tried that in 2.5.x, assuming nothing broke in between.  You need a 
utility to map which console to which fbdev (con2fbmap?).  However, you can't 
use them simultaneously (switching to one console inactivates the other), 
that's for the ruby project.

Tony





-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Wed, Apr 28, 2004 at 08:54:47AM +0800, Antonino A. Daplas wrote:
> On Wednesday 28 April 2004 08:29, Otto Solares wrote:
> > On Tue, Apr 27, 2004 at 07:46:33PM -0400, John Zielinski wrote:
> > > An added bonus is that if you have multiple video cards or a dual head
> > > configuration with each head on a different fbx device the 5,255 device
> > > would figure out which console you are on when you start the program and
> > > use the appropriate fb device.  Once the radeon dual head code gets
> > > written I'll have to try to start X on fb0 (head 1) and leave the fbcon
> > > running on fb1 (head two).
> >
> > I was wondering if it is possible currently (kernel 2.6.5) to
> > have 2 differents video cards in 2 differents VCs and in 2
> > differents fbdev's.  I have an old trident pci card and one
> > radeon agp card.  I want to run X (Xfbdev) in the trident one
> > and mesa-solo in the radeon one, is that possible? how?
> >
> 
> Yes, I've tried that in 2.5.x, assuming nothing broke in between.  You need a 
> utility to map which console to which fbdev (con2fbmap?).  However, you can't 
> use them simultaneously (switching to one console inactivates the other), 
> that's for the ruby project.

I have written a graphics server that scans for video cards (via
libHAL from fd.o) and spawns a thread for each card, I have the
support in place for differents cards (with multi-desktops or
Xinerama like in the same box).  All I want to acomplish is to
have 2 (or more) differents fbdevs rendering to different monitors
in the same time.  Currently my server enables DRI (old mesa-solo)
for supported cards (mostly AGP ones) or mesa-fbdev for unaccelerated
ones.  The problem is that without X i can access only the primary
card (the one set it up in the bios) but if i try to load the fbdev
module for the second card it simply will not work.

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[John Zielinski]

Otto Solares wrote:

>I was wondering if it is possible currently (kernel 2.6.5) to
>have 2 differents video cards in 2 differents VCs and in 2
>differents fbdev's.  I have an old trident pci card and one
>radeon agp card.  I want to run X (Xfbdev) in the trident one
>and mesa-solo in the radeon one, is that possible? how?
>  
>

That's what I'm currently working on and is partially what's behind my 
messages about multiple vars and whatnot.  It looks like most of the 
stuff is already in the kernel.  I'm just going through the various 
subsystems trying to figure out what still needs to be changed.  One 
things is the the vt driver's notion of which vt is visible.  Currently 
that's fg_console == visible but with multiple monitors that doesn't 
hold true.

I'll post when I succeed.  :)

John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[John Zielinski]

Benjamin Herrenschmidt wrote:

>You don't need a /dev/fb for that do you ? You need to map the current
>vt to it's fb via the existing fbdev ioctls, isn't that possible ? (just
>asking , I've never actually done that).
>
>  
>
But how does the app find this out?  It would have to figure out if it's 
running on a real console then figure out which console is mapped to 
which fb and then try to find out which /dev/fbx device points to that 
fb.  Programmer's are lazy, they'll just make it a command line switch 
to specify what device to use which is not very user friendly.

What I'm proposing is that you open /dev/fb.  If it fails you're running 
on a serial line or shh or whatever.  If it succedes you issue 
KD_GRAPHICS ioctl on the /dev/fb device and that's it.  Very simple for 
the programmer.

The kernel does all the work.  It figures out what vt you're on and 
prevents access from serial or a pty.  It also would figure out which 
framebuffer device to connect to based on the con2fb map specified by 
the fbdev ioctls.  It would pass the KD_TEXT/KD_GRAPHICS calls to the 
appropriate vt.

This makes it very user friendly.  The user just switches to the vt 
that's on the moitor they want and starts the app.  The kernel figures 
out how to route this to the appropriate fb driver according to the 
con2fb map.

I might also be possible to use /dev/tty as the starting point if you 
want to make everything start at the vt layer and work down.   The fb 
ioctls would just have to be passed down.  Once a KD_GRAPHICS was issued 
on /dev/tty then read/write/mmap would pass down to the fb layer as well. 

John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Alex Stewart]

> Benjamin Herrenschmidt wrote:
>
>>You don't need a /dev/fb for that do you ? You need to map the current
>> vt to it's fb via the existing fbdev ioctls, isn't that possible ?
>> (just asking , I've never actually done that).
>>
>>
>>
> But how does the app find this out?  It would have to figure out if it's
>  running on a real console then figure out which console is mapped to
> which fb and then try to find out which /dev/fbx device points to that
> fb.  Programmer's are lazy, they'll just make it a command line switch
> to specify what device to use which is not very user friendly.
>
> What I'm proposing is that you open /dev/fb.  If it fails you're running
>  on a serial line or shh or whatever.  If it succedes you issue
> KD_GRAPHICS ioctl on the /dev/fb device and that's it.  Very simple for
> the programmer.

I like the idea of having graphical apps automatically open on the same
framebuffer device as the console they were started from, but I agree with
Ben, I think this approach is way more complicated than it needs to be.

Firstly, all of the graphical apps you're describing should be VT-aware. 
If they aren't, you shouldn't be using them on anything other than
dedicated framebuffers anyway, really.  It's not hard to make an app work
with VTs and it really is the correct way to do things for anything that
is likely to be run in a VT-console environment.

With this issue solved, all that needs to be done is to make it so that
apps which open up a new VT, automatically get it on the same framebuffer
as the currently active console (or better yet, the console associated
with the app) is on (which is really the most intuitive thing anyway, and
should probably be done on general principle).  Problem solved.

You really don't need all the complex machinations of a magic /dev/fb
device to achieve this.  If the rest of the system is designed well the
right behavior should be automatic without this extra effort.

-alex




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

> Firstly, all of the graphical apps you're describing should be VT-aware. 
> If they aren't, you shouldn't be using them on anything other than
> dedicated framebuffers anyway, really.  It's not hard to make an app work
> with VTs and it really is the correct way to do things for anything that
> is likely to be run in a VT-console environment.

A good idea would be to produce a library that implement most of the
ground VT handling work in fact... That would simplify things for
apps tremendously. Though it should probably sit between the app
and the kernel for console input as well.

It would basically callback into the app for things like beeing swithout
out and back in.

> With this issue solved, all that needs to be done is to make it so that
> apps which open up a new VT, automatically get it on the same framebuffer
> as the currently active console (or better yet, the console associated
> with the app) is on (which is really the most intuitive thing anyway, and
> should probably be done on general principle).  Problem solved.
> 
> You really don't need all the complex machinations of a magic /dev/fb
> device to achieve this.  If the rest of the system is designed well the
> right behavior should be automatic without this extra effort.
> 
> -alex
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[John Zielinski]

Alex Stewart wrote:

>I like the idea of having graphical apps automatically open on the same
>framebuffer device as the console they were started from, but I agree with
>Ben, I think this approach is way more complicated than it needs to be.
>
>  
>
I don't believe it will be complicated but I'll find out after I try to 
implement it.  I just like the fact the the kernel would be able to keep 
applications from doing silly things.  Hey, if it turns out to be an 
ugly patch I'll be the first to delete it.  Who knows, parts of it might 
be useful.  And it's a great way for me to learn more of the innards of 
the vt/fb systems.

>Firstly, all of the graphical apps you're describing should be VT-aware. 
>If they aren't, you shouldn't be using them on anything other than
>dedicated framebuffers anyway, really.  It's not hard to make an app work
>with VTs and it really is the correct way to do things for anything that
>is likely to be run in a VT-console environment.
>  
>
Hmm, I'll have to do some hunting.  What is the easy way to find out if 
you're on a physical console and what vc num it is in user space?  I can 
do it easily in kernel space...

>With this issue solved, all that needs to be done is to make it so that
>apps which open up a new VT, automatically get it on the same framebuffer
>as the currently active console (or better yet, the console associated
>with the app) is on (which is really the most intuitive thing anyway, and
>should probably be done on general principle).  Problem solved.
>
>  
>
That might be tricky as you'd probably have to change the con2fb map to 
remap the unused console to the right fb.

>You really don't need all the complex machinations of a magic /dev/fb
>device to achieve this.  If the rest of the system is designed well the
>right behavior should be automatic without this extra effort.
>
>  
>
Unfortunately it's not automatic.  The programmer has to jump through a 
few hoops that it would take a couple of dozen lines of code in kernel 
space to do.   This is just off the top of my head so it's probably not 
entirely correct:

if( fbidx == 255 ) {
    if( current->tty->driver != console_driver )    
       return -ENODEV;
    fbidx  = con2fb_map[ current->tty->index ];
}

Add another dozen lines to do the the KD_TEXT/KD_GRAPHICS and that's 90% 
of the functionality of the /dev/fb device.

Like I said, it's just a small experiment on my part.  Maybe someone 
will find it useful or maybe they'll get some other ideas from it.  The 
only reason I haven't tried it yet is I have to hunt down where my PCI 
video card disappeared to so I can try it on a dual fb setup.

John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Alex Stewart]

>> Firstly, all of the graphical apps you're describing should be
>> VT-aware.  If they aren't, you shouldn't be using them on anything
>> other than dedicated framebuffers anyway, really.  It's not hard to
>> make an app work with VTs and it really is the correct way to do things
>> for anything that is likely to be run in a VT-console environment.
>>
> Hmm, I'll have to do some hunting.  What is the easy way to find out if
> you're on a physical console and what vc num it is in user space?  I can
>  do it easily in kernel space...

Umm, the point is you don't have to.  Just create a new VT for whatever
you're doing.  If you have permission to do it, you will get a VT you can
work with.  If you don't, you'll get an error.  Ultimately, it shouldn't
matter whether you're being started from a VT to begin with anyway (a user
_should_ be able to login via ssh or serial console or whatever and start
up a framebuffer app if they want to and have the permissions to.  This is
one of the fundamental principles of unix (the user knows what they want
to do better than the OS does.  The OS shouldn't get in the way of
that.)).  If a different user is currently using the framebuffer for their
console (or app or whatever), the permissions should be set to protect it,
otherwise it's fair game.

>> With this issue solved, all that needs to be done is to make it so that
>> apps which open up a new VT, automatically get it on the same
>> framebuffer as the currently active console (or better yet, the console
>> associated with the app) is on (which is really the most intuitive
>> thing anyway, and should probably be done on general principle).
>> Problem solved.
>>
> That might be tricky as you'd probably have to change the con2fb map to
> remap the unused console to the right fb.

Actually, no, the point I was making is that we should change the
VT/console code to automatically copy the "current" mapping to a new VT
when it gets created, so you don't need to remap anything for this case.

Basically what I'm suggesting pretty much the same thing you are, I'm just
saying we should do it with the existing VT infrastructure instead of
creating a new /dev/fb for what's basically a very similar thing to what
VT is already supposed to handle more generally (controlling which screens
consoles/apps access and when).

-alex




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[John Zielinski]

Alex Stewart wrote:

>Umm, the point is you don't have to.  Just create a new VT for whatever
>you're doing.  If you have permission to do it, you will get a VT you can
>work with.  If you don't, you'll get an error.  Ultimately, it shouldn't
>matter whether you're being started from a VT to begin with anyway (a user
>_should_ be able to login via ssh or serial console or whatever and start
>up a framebuffer app if they want to and have the permissions to.  This is
>one of the fundamental principles of unix (the user knows what they want
>to do better than the OS does.  The OS shouldn't get in the way of
>that.)).  If a different user is currently using the framebuffer for their
>console (or app or whatever), the permissions should be set to protect it,
>otherwise it's fair game.
>
>  
>
Depends on how you look at it.  If a user is on console 1 and starts a 
simple app (not a desktop environment) having that jump to console 9 is 
a little confusing.  And there are only so many function keys.  Several 
X sessions will eat up the remaining function keys.  Once all the 
function keys are used then it becomes a royal pain switching VTs. 

As for not mattering whether you're being started from a VT, I'm on the 
other side of the fence here.  When I ssh into a machine, the text 
apears on my local maching and not on the remote.  Same goes for the 
terminal bell and led status.  And when you run an X app the display is 
local as well.   Now the framebuffer breaks away from that.  When I fire 
up a framebuffer app the output doesn't appear locally but on the remote 
machine.  Now I agree that the system shouldn't stop someone from doing 
this if they really want to.  That's why the fb0, fb1, etc devices 
wouldn't stop you running them remote and would have the stricter 
permissions on them (root only for example).

Besides, the person that stole my console from under me remotely would 
be in a world of hurt once I got back into my machine.  :)

>Actually, no, the point I was making is that we should change the
>VT/console code to automatically copy the "current" mapping to a new VT
>when it gets created, so you don't need to remap anything for this case.
>
>  
>
We're both saying the same thing.  When I said "remap" I meant telling 
fbcon to assign a particular framebuffer to that console.

>Basically what I'm suggesting pretty much the same thing you are, I'm just
>saying we should do it with the existing VT infrastructure instead of
>creating a new /dev/fb for what's basically a very similar thing to what
>VT is already supposed to handle more generally (controlling which screens
>consoles/apps access and when).
>  
>

Pretty much.  The only differences are is that I want the app to always 
stay on the same VT number and that the programmer only have to deal 
with one interface.  Why should every frame buffer program be required 
to carry extra VT code and most programmers will be too lazy or won't 
know how to include it.  Even fbtest doesn't have any VT code in it.  
With the code in the kernel even legacy apps will start using the new 
correct behaviour.

John


John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Wed, Apr 28, 2004 at 10:36:06AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2004-04-28 at 10:20, Otto Solares wrote:
> > On Wed, Apr 28, 2004 at 09:10:55AM +1000, Benjamin Herrenschmidt wrote:
> > > Jon Smirl has been working on embedded mesa & moving DRI outside of
> > > X. Unfortunately, last I heard, he was still on his trip of re-inventing
> > > everything including replacing the fbdev's with his own stuff instead
> > > of moving from what we have ...
> > 
> > Ooops! that will break my software that relies on fbdev and
> > mesa-solo!
> 
> Well, I'm sure there is some good in what he is doing too, I don't 
> have time to deal with that at the moment, it would be interesting
> to synchronise properly though.

Yea, I remember he was trying to solve the very same problems
I currently have now.  I like the fbdev abstraction but it has
too many limitations:

- Improper video mode handling.  Simply the device driver should
  hint about valid modes, EDID, etc.
- When an app crashes the layer is unable to recover it's
  previous state even when proper semantics exist (KD_TEXT/GRAPH),
  when the kernel closes the fbdev it must trigger a return to
  KD_TEXT if in KD_GRAPHICS and set the fix and var settings
  remembering that settings before leaving KD_TEXT.
- It should exist a field in the fixed info for the bus_id, so
  intelligent apps will realize which card is attached to a fbdev.
- Cards with various display ports must be handled by the layer,
  with a new API just to handle ports.
- It dangerously coexists currently with the DRM queues and
  SAREA areas.  Both must merge in fbdev.
- VCs mess.
- Wasted effort in accel engines handling is only useful to fbcon,
  nobody needs acceleration to drive a X x Y character matrix
  in fbcon.  The argument that hw without a framebuffer will
  exist and that's why the accel engine must be used is BS,
  the PC, the BIOS and the video framebuffers will never die,
  framebuffer exists in the best video cards money can buy
  today and it exists in planned cards from major manufacturers
  for tomorrow, probably the framebuffer can't be accessed when
  the accel engine is being used in forthcoming cards but that
  is completely a different story.

IMHO this must be addressed ASAP if we want to compete with
Longhorn and MacOSX.  People should realize that fbdev is a
linux standard that needs to be modernized and it must be fixed,
we should not devote more resources to implement complex accel
engines in the fbdev drivers, acceleration has it's place in
userspace layers like DirectFB or DRI (mesa-solo), not in the
kernel where a light, simple and elegant solution for graphics
should exists.

I now understand why Jon Smirl took that hard but neccesary
path.  Even if we start this for 2.7 it will be too late as
linux 2.8/3.0 will ship 2-3 years late.

C'mon James, Ben, Geert, driver writers, let's fix the layer!

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Geert Uytterhoeven]

On Tue, 27 Apr 2004, John Zielinski wrote:
> For example lets say I have odd numbered consoles mapped on my AGP
> Radeon card and even numbered consoles mapped to my PCI Riva card.  I
> switch to console 1 and fire up a fb dvd player app.  It opens /dev/fb
> (29,255) and switches to KD_GRAPHICS.   LOTR starts playing on my big
> 21" monitor hooked up to the Radeon.  As a user I didn't have to know
> that /dev/fb0 was really my 21" monitor and didn't have to give any
> command line switches to do this.  The cursor was blinking on my 21" and
> all I had to do is type dvdplay and away I went.  I would also be
> prevented from switching to odd numbered consoles now.
>
> No problem.  ALT-F2 and now my 19" monitor has a blinking cursor.  I
> type in picview and again the jpeg viewing program opens /dev/fb and
> switches to KD_GRAPHICS and now I'm looking a vacation photos on my old
> riva card.  Again, I didn't have to know that /dev/fb1 is my 19" monitor
> and no command line arguments.  The app fires up on the monitor that had
> the focus (forground console doesn't sound right on multi monitor setups
> IMHO).
>
> Now I can only switch between console 1 and 2.  Consoles 3 and up can't
> be switched to as both fb devices are in use.

So you break the virtualization layer of the VTs. I still want to be able to
switch to consoles 3 and up.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Geert Uytterhoeven]

On Wed, 28 Apr 2004, Otto Solares wrote:
> I currently have now.  I like the fbdev abstraction but it has
> too many limitations:
>
> - It should exist a field in the fixed info for the bus_id, so
>   intelligent apps will realize which card is attached to a fbdev.

Should be fixed soon with sysfs in 2.6.

> C'mon James, Ben, Geert, driver writers, let's fix the layer!

Time, time, time...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Michel Dänzer]

On Wed, 2004-04-28 at 09:08, Otto Solares wrote:
> 
> I like the fbdev abstraction but it has too many limitations:

[...]

> - It dangerously coexists currently with the DRM queues and
>   SAREA areas.  

How does a DRM SAREA matter to a framebuffer device?

> Both must merge in fbdev.

I agree that they should cooperate properly, but I don't see how it
follows that they must merge.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Wed, Apr 28, 2004 at 12:16:56PM +0200, Michel Dänzer wrote:
> On Wed, 2004-04-28 at 09:08, Otto Solares wrote:
> > 
> > I like the fbdev abstraction but it has too many limitations:
> 
> [...]
> 
> > - It dangerously coexists currently with the DRM queues and
> >   SAREA areas.  
> 
> How does a DRM SAREA matter to a framebuffer device?

It matters as long as the SAREA have a hardware lock
to synchronize access to the hardware.  That lock must
be owned by a single entity in the kernel, or at least
the fbdev drivers must be aware of that lock, it would
be more simple if the fbdev drivers take care of it being
the single entity in the kernel taking care of the
hardware.

> > Both must merge in fbdev.
> 
> I agree that they should cooperate properly, but I don't see how it
> follows that they must merge.

DRM and fbdev must merge so i repeat: just a single
kernel entity should own FIFO queues, shared locks,
DMA, the framebuffer, IO registers, interrupts, etc.

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[James Simmons]

> > > Both must merge in fbdev.
> > 
> > I agree that they should cooperate properly, but I don't see how it
> > follows that they must merge.
> 
> DRM and fbdev must merge so i repeat: just a single
> kernel entity should own FIFO queues, shared locks,
> DMA, the framebuffer, IO registers, interrupts, etc.

I agree. That is why I create a par abstraction in fbdev. The idea is dri 
and fbdev coudl share the same core data structure.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[James Simmons]

> That's what I'm currently working on and is partially what's behind my 
> messages about multiple vars and whatnot.  It looks like most of the 
> stuff is already in the kernel.  I'm just going through the various 
> subsystems trying to figure out what still needs to be changed.  One 
> things is the the vt driver's notion of which vt is visible.  Currently 
> that's fg_console == visible but with multiple monitors that doesn't 
> hold true.

What your doing is alot of work. Trust me because I already have reworked 
the VT layer to support multiple terminals. Its more than fixing 
fg_console.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[James Simmons]

> > If they aren't, you shouldn't be using them on anything other than
> > dedicated framebuffers anyway, really.  It's not hard to make an app work
> > with VTs and it really is the correct way to do things for anything that
> > is likely to be run in a VT-console environment.
> 
> A good idea would be to produce a library that implement most of the
> ground VT handling work in fact... That would simplify things for
> apps tremendously. Though it should probably sit between the app
> and the kernel for console input as well.

That would be nice. The only problem is history has shown that lots of 
people think the library should be done one way verses another and we need 
up with lots of libraries. 
 



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[James Simmons]

> I currently have now.  I like the fbdev abstraction but it has
> too many limitations:
> 
> - Improper video mode handling.  Simply the device driver should
>   hint about valid modes, EDID, etc.

Being worked on. We have fbmon.c and modedb.c

> - When an app crashes the layer is unable to recover it's
>   previous state even when proper semantics exist (KD_TEXT/GRAPH),
>   when the kernel closes the fbdev it must trigger a return to
>   KD_TEXT if in KD_GRAPHICS and set the fix and var settings
>   remembering that settings before leaving KD_TEXT.

This has always been. In the old days when X crashed you lost your 
display. That was life. The X drivers are better but its up to X to 
restore the console.

> - It should exist a field in the fixed info for the bus_id, so
>   intelligent apps will realize which card is attached to a fbdev.

Sysfs will solve this.

> - Cards with various display ports must be handled by the layer,
>   with a new API just to handle ports.

Create a fb_info for each display port.

> - It dangerously coexists currently with the DRM queues and
>   SAREA areas.  Both must merge in fbdev.

Agree.

> - VCs mess.

2.7.X. I have been working on that for a couple of years.

> - Wasted effort in accel engines handling is only useful to fbcon,
>   nobody needs acceleration to drive a X x Y character matrix
>   in fbcon.  The argument that hw without a framebuffer will
>   exist and that's why the accel engine must be used is BS,
>   the PC, the BIOS and the video framebuffers will never die,
>   framebuffer exists in the best video cards money can buy
>   today and it exists in planned cards from major manufacturers
>   for tomorrow, probably the framebuffer can't be accessed when
>   the accel engine is being used in forthcoming cards but that
>   is completely a different story.

I disagree. It's also a performace issue. Even if we use software
drawing routines the fbcon layer still needs to draw a image, fill 
a region and copy a area. We can't just dump that into fbcon easily.
Plus with the software cursor we do use fb_imageblit. Also I'm 
beginning to realize we need to clear out the framebuffer memory.
People complain about left over junk on there screen when the console 
takes over. 

> IMHO this must be addressed ASAP if we want to compete with
> Longhorn and MacOSX.  People should realize that fbdev is a
> linux standard that needs to be modernized and it must be fixed,

I agree.

> we should not devote more resources to implement complex accel
> engines in the fbdev drivers, 

I'm not focusing on that. We have a basic api and that's it. If 
you don't want to program the accel engine just use the software 
routines. Look at the debate about how to handle setting the resolution.
Yipes it been fierce.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Geert Uytterhoeven]

On Wed, 28 Apr 2004, James Simmons wrote:
> > - Wasted effort in accel engines handling is only useful to fbcon,
> >   nobody needs acceleration to drive a X x Y character matrix
> >   in fbcon.  The argument that hw without a framebuffer will
> >   exist and that's why the accel engine must be used is BS,
> >   the PC, the BIOS and the video framebuffers will never die,
> >   framebuffer exists in the best video cards money can buy
> >   today and it exists in planned cards from major manufacturers
> >   for tomorrow, probably the framebuffer can't be accessed when
> >   the accel engine is being used in forthcoming cards but that
> >   is completely a different story.
>
> I disagree. It's also a performace issue. Even if we use software
> drawing routines the fbcon layer still needs to draw a image, fill
> a region and copy a area. We can't just dump that into fbcon easily.

Indeed. Try to work for a while on an unaccelerated fbcon console and you'll
notice why you want acceleration.

Hardware without a CPU-accessible frame buffer is not the reason, so far those
hardware was not driven by fbcon/fbdev but by their own console drivers (e.g.
Indy Newport and the never merged TI34010 GSP driver).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[John Zielinski]

Geert Uytterhoeven wrote:

>>Now I can only switch between console 1 and 2.  Consoles 3 and up can't
>>be switched to as both fb devices are in use.
>>    
>>
>
>So you break the virtualization layer of the VTs. I still want to be able to
>switch to consoles 3 and up.
>  
>
Nope, nothing is broken.  The limitation is the fb application.  If the 
app using the framebuffer knows how to handle being switched away from 
(releasing the fb after getting the switch away signal and reacquiring 
the fb and repainting when getting the switch to signal) then switching 
to the other consoles would work.

John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Michel Dänzer]

On Wed, 2004-04-28 at 18:37, Otto Solares wrote:
> On Wed, Apr 28, 2004 at 12:16:56PM +0200, Michel Dänzer wrote:
> > On Wed, 2004-04-28 at 09:08, Otto Solares wrote:
> > > 
> > > I like the fbdev abstraction but it has too many limitations:
> > 
> > [...]
> > 
> > > - It dangerously coexists currently with the DRM queues and
> > >   SAREA areas.  
> > 
> > How does a DRM SAREA matter to a framebuffer device?
> 
> It matters as long as the SAREA have a hardware lock
> to synchronize access to the hardware.  That lock must
> be owned by a single entity in the kernel, or at least
> the fbdev drivers must be aware of that lock, 

Why? The purpose of the DRM lock is arbitration and state management
between DRM clients. It's not necessarily connected to direct hardware
access.

> it would be more simple if the fbdev drivers take care of it being
> the single entity in the kernel taking care of the hardware.

Jon Smirl thinks it should be the DRM...

> > > Both must merge in fbdev.
> > 
> > I agree that they should cooperate properly, but I don't see how it
> > follows that they must merge.
> 
> DRM and fbdev must merge so i repeat: just a single
> kernel entity should own FIFO queues, shared locks,
> DMA, the framebuffer, IO registers, interrupts, etc.

A small low-level driver could handle this, which both the framebuffer
device and the DRM use. Linus has proposed this approach, and I must say
I like it.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[John Zielinski]

James Simmons wrote:

>This has always been. In the old days when X crashed you lost your 
>display. That was life. The X drivers are better but its up to X to 
>restore the console.
>
>  
>
By that logic we'd still be using kernel 1.0.  ;)   I still don't see a 
problem with fbcon resetting the video card to what it thinks it should 
be when it regains control of the framebuffer.   But like everything 
else in the kernel, we'll prove it works first before suggesting it be 
included in the official release.

>Plus with the software cursor we do use fb_imageblit. Also I'm 
>beginning to realize we need to clear out the framebuffer memory.
>People complain about left over junk on there screen when the console 
>takes over. 
>
>  
>
No, no, no!  :)   I want to see my boot up messages before the console 
takes over, especially if the kernel dies during bootup.  I've already 
posted a fix for this a while back for just the radeon driver but it's 
very easy to modify the other drivers.  It's just one line of code per 
driver and one line to fb.h . 

What happens is that the vga console tries to copy screen memory to it's 
save buffer when it's being shut down but the fb driver has already 
reconfigured the memory aperature layout.  A call to do_blank_screen(1) 
right before the mode switch will cause the vga console to save screen 
memory at that point.  This needs to be done in the drivers.  If it were 
done in fbcon then any prink's in the drivers would "unblank" the vga 
console and mess things up again.

>routines. Look at the debate about how to handle setting the resolution.
>Yipes it been fierce.
>
>  
>
Sorry!  I seem to have a nack at starting these things....  :)

John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

> 
> DRM and fbdev must merge so i repeat: just a single
> kernel entity should own FIFO queues, shared locks,
> DMA, the framebuffer, IO registers, interrupts, etc.

Right. I've been discussing that problem for a while. I think we really
need some common work here. When a mode change is requested by userland,
we need to take that lock, but we also need to set some flag in the DRM
to invalidate all state. I'm not sure what is the best way to do that at
this point though.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

> > 
> > DRM and fbdev must merge so i repeat: just a single
> > kernel entity should own FIFO queues, shared locks,
> > DMA, the framebuffer, IO registers, interrupts, etc.
> 
> A small low-level driver could handle this, which both the framebuffer
> device and the DRM use. Linus has proposed this approach, and I must say
> I like it.

The idea here is to have a small per-card low level driver (no common
API or little of it) used to do the IRQ, fifo/ring management & blasting
of registers. Everything else is client of this driver, including
possibly fbcon. That also means we move all of mode management to
userland, which I tend to slowly agree with. Remember that in 2.7, we
may have an initramfs with klibc etc... thus we can have userland code
shipping along with the kernel.

I started working on a userland API do deal with all of the mode
management cruft that could be implemented either on top of fbdev or
something else, but I didn't have time to finish. And I think Jon Smirl
started his own different thing (of course) there...

One of the ideas we had after discussing with Keith Packard that the
model should be a library that deals with all the settings of the
displays, the geometry of the desktop(s) (relative position of screens),
modes, etc... That library would interface to the various drivers via
backend libraries and would broadcast via dbus the environment changes
so that things like window managers, x servers, or whatever else can
adapt. Applications would talk directly to the library.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[James Simmons]

>  That also means we move all of mode management to
> userland, which I tend to slowly agree with. Remember that in 2.7, we
> may have an initramfs with klibc etc... thus we can have userland code
> shipping along with the kernel.

Wow!!!!! Linux is going to end up a micro kernel after all. We could move the 
tcp stack and even all the filesystems to userland as well. The kernel will
shrink to such a small size. Then bus setup could be done in userland. All 
we need to do is setup the cpu. No more device drivers.



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Thu, Apr 29, 2004 at 09:42:50AM +1000, Benjamin Herrenschmidt wrote:
> The idea here is to have a small per-card low level driver (no common
> API or little of it) used to do the IRQ, fifo/ring management & blasting
> of registers. Everything else is client of this driver, including
> possibly fbcon. That also means we move all of mode management to
> userland, which I tend to slowly agree with. Remember that in 2.7, we
> may have an initramfs with klibc etc... thus we can have userland code
> shipping along with the kernel.

The fbdev is low-level, i vote for fbdev to be the single entity
for graphics in linux.

> I started working on a userland API do deal with all of the mode
> management cruft that could be implemented either on top of fbdev or
> something else, but I didn't have time to finish. And I think Jon Smirl
> started his own different thing (of course) there...

I would like to see that basic stuff being done in the kernel like
mode setting.  The drivers should have a better idea of modes than
libraries in userspace.

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Thu, Apr 29, 2004 at 12:26:41AM +0200, Michel Dänzer wrote:
> Why? The purpose of the DRM lock is arbitration and state management
> between DRM clients. It's not necessarily connected to direct hardware
> access.

Agree, fbdev is too low-level to use the lock.

> A small low-level driver could handle this, which both the framebuffer
> device and the DRM use. Linus has proposed this approach, and I must say
> I like it.

That should be fbdev without fbcon.

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

> I would like to see that basic stuff being done in the kernel like
> mode setting.  The drivers should have a better idea of modes than
> libraries in userspace.

Not really. The driver can extract the EDID infos from the card,
but as far as building mode lists, at one point, we really want
that to be moved down to userspace. One of the problems is that
a lot of monitors have bogus EDID blocks. We need a mecanism to
provide "overrides" based on manufacturer/product ID for example,
I don't think it's something that should be in the kernel.

Also, for something like dbus notification of clients, userspace
is better suited.

Finally, the geometry of screens is something that has nothing to
do in the kernel imho.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1874 bytes --]

On Thu, 2004-04-29 at 11:07, Otto Solares wrote:
> On Thu, Apr 29, 2004 at 12:26:41AM +0200, Michel Dänzer wrote:
> > Why? The purpose of the DRM lock is arbitration and state management
> > between DRM clients. It's not necessarily connected to direct hardware
> > access.
> 
> Agree, fbdev is too low-level to use the lock.

Yes and No. We _DO_ need an arbitration mecanism between fbdev (or
whoever changes the mode) and other "clients" like DRI and the DRI
lock would be well suited for that too. Right now, you can very easily
lockup the whole box solid by just sending a mode switch down to the
fbdev while DRI is active.

And since the model we are aiming too is just that: sending mode
switches at any time and have all clients adapt properly, we need a
solution for that. One of the reasons is hotplug displays. The hotplug
is equivalent to a mode switch in this regard and will happen whatever
the card is doing.
 
> > A small low-level driver could handle this, which both the framebuffer
> > device and the DRM use. Linus has proposed this approach, and I must say
> > I like it.
> 
> That should be fbdev without fbcon.

Yes, except that I'd like to see most of the mode list processing moved
to userland. But I agree that the low level driver could/should be fbdev
without the accel hooks. Those are really fbcon specific accel hooks,
I would even like to separate it from the fbdev completely. In that sense,
fbcon would just be another "client" of the framebuffer. But in this regard
too, we need some arbitration.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=click

Re: [PATCH] neofb patches

[Geert Uytterhoeven]

On Thu, 29 Apr 2004, Benjamin Herrenschmidt wrote:
> One of the ideas we had after discussing with Keith Packard that the
> model should be a library that deals with all the settings of the
> displays, the geometry of the desktop(s) (relative position of screens),
> modes, etc... That library would interface to the various drivers via

And it could also handle the blending of multiple planes (one fbdev per plane)?
In some sense blending (possibly scaled) planes is similar to the relative
position of screens.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Michel Dänzer]

On Thu, 2004-04-29 at 03:07, Otto Solares wrote:
> On Thu, Apr 29, 2004 at 12:26:41AM +0200, Michel Dänzer wrote:
> 
> > A small low-level driver could handle this, which both the framebuffer
> > device and the DRM use. Linus has proposed this approach, and I must say
> > I like it.
> 
> That should be fbdev without fbcon.

I'm not sure that works: keep in mind that the DRM works on other OSs
than Linux, and even on Linux some people may want to use the DRM
without a framebuffer device. Neither should be a problem with a minimal
base driver which does nothing more than hardware resource management
and arbitration.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[James Simmons]

> > I would like to see that basic stuff being done in the kernel like
> > mode setting.  The drivers should have a better idea of modes than
> > libraries in userspace.

I agree. Mode setting is one of those things you have to do kernel side.

> Not really. The driver can extract the EDID infos from the card,
> but as far as building mode lists, at one point, we really want
> that to be moved down to userspace. One of the problems is that
> a lot of monitors have bogus EDID blocks. We need a mecanism to
> provide "overrides" based on manufacturer/product ID for example,
> I don't think it's something that should be in the kernel.

We already have such things in the kernel. DMI blacklist in the kernel on 
the x86 platform. Also we have PCI fixups in the kernel. Should we move 
those to userland as well. Now if you believe in a micro kernel design 
then that is a yes. In struct fb_monspecs we have a monitor identity 
field. So we can deal with this. Also if we have a corrupt EDID block then 
we can default to using the default modedb. Its not a hard problem.

> Finally, the geometry of screens is something that has nothing to
> do in the kernel imho.

I don't like micro kernel designs. This is way micro kernels handle this 
problem.



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Thu, Apr 29, 2004 at 03:01:13PM +0200, Michel Dänzer wrote:
> On Thu, 2004-04-29 at 03:07, Otto Solares wrote:
> > On Thu, Apr 29, 2004 at 12:26:41AM +0200, Michel Dänzer wrote:
> > 
> > > A small low-level driver could handle this, which both the framebuffer
> > > device and the DRM use. Linus has proposed this approach, and I must say
> > > I like it.
> > 
> > That should be fbdev without fbcon.
> 
> I'm not sure that works: keep in mind that the DRM works on other OSs
> than Linux, and even on Linux some people may want to use the DRM
> without a framebuffer device. Neither should be a problem with a minimal
> base driver which does nothing more than hardware resource management
> and arbitration.

Differents OSs have differents sources for DRM kernel side so
that's not a problem nor will affect others OSs than linux.

I would like to see fbdev becoming the defacto standard for
graphics management in linux but:

1. It must mature and be modernized a lot to be accepted as such.
2. People tend to not agree.

So I see the current DRM/FBDEV/X cooperative schema for the foreseeable
future.

Yes, a minimal driver would do the work _NOW_.  I just think
that for the long term a solution like fbdev with asteroids
is needed to standarize graphics management in linux.

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Benjamin Herrenschmidt]

> > Finally, the geometry of screens is something that has nothing to
> > do in the kernel imho.
> 
> I don't like micro kernel designs. This is way micro kernels handle this 
> problem.

This has nothing to do with microkernel design and everything to do with
not bloating the kernel with things that don't to be there.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Michel Dänzer]

On Thu, 2004-04-29 at 19:52, Otto Solares wrote:
> On Thu, Apr 29, 2004 at 03:01:13PM +0200, Michel Dänzer wrote:
> > On Thu, 2004-04-29 at 03:07, Otto Solares wrote:
> > > On Thu, Apr 29, 2004 at 12:26:41AM +0200, Michel Dänzer wrote:
> > > 
> > > > A small low-level driver could handle this, which both the framebuffer
> > > > device and the DRM use. Linus has proposed this approach, and I must say
> > > > I like it.
> > > 
> > > That should be fbdev without fbcon.
> > 
> > I'm not sure that works: keep in mind that the DRM works on other OSs
> > than Linux, and even on Linux some people may want to use the DRM
> > without a framebuffer device. Neither should be a problem with a minimal
> > base driver which does nothing more than hardware resource management
> > and arbitration.
> 
> Differents OSs have differents sources for DRM kernel side so
> that's not a problem nor will affect others OSs than linux.

Nope. Most of the code in the DRI CVS drm module is shared between OSs.
Most of the shared code is hardware specific though, so if you change
the interface to the hardware, either all the OSs will have to provide
the new interface, or the code can no longer be shared, which would get
us back to the code duplication horrors. I'd very much like to avoid
that.


> Yes, a minimal driver would do the work _NOW_.

Why wouldn't it in the future?


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Fri, Apr 30, 2004 at 01:12:17AM +0200, Michel Dänzer wrote:
> On Thu, 2004-04-29 at 19:52, Otto Solares wrote:
> > On Thu, Apr 29, 2004 at 03:01:13PM +0200, Michel Dänzer wrote:
> > > On Thu, 2004-04-29 at 03:07, Otto Solares wrote:
> > > > On Thu, Apr 29, 2004 at 12:26:41AM +0200, Michel Dänzer wrote:
> > > > 
> > > > > A small low-level driver could handle this, which both the framebuffer
> > > > > device and the DRM use. Linus has proposed this approach, and I must say
> > > > > I like it.
> > > > 
> > > > That should be fbdev without fbcon.
> > > 
> > > I'm not sure that works: keep in mind that the DRM works on other OSs
> > > than Linux, and even on Linux some people may want to use the DRM
> > > without a framebuffer device. Neither should be a problem with a minimal
> > > base driver which does nothing more than hardware resource management
> > > and arbitration.
> > 
> > Differents OSs have differents sources for DRM kernel side so
> > that's not a problem nor will affect others OSs than linux.
> 
> Nope. Most of the code in the DRI CVS drm module is shared between OSs.
> Most of the shared code is hardware specific though, so if you change
> the interface to the hardware, either all the OSs will have to provide
> the new interface, or the code can no longer be shared, which would get
> us back to the code duplication horrors. I'd very much like to avoid
> that.

I don't see your point, nothing prevents using the shared code,
the idea is not to change the interface, just to have a single
graphics layer that handle that same interface.  I know it could be
a pain to duplicate the fbdev into the cvs drm module, but with
proper file separations there could live the fbdev's drm code.

> > Yes, a minimal driver would do the work _NOW_.
> 
> Why wouldn't it in the future?

Because we need a single and unified graphics layer for linux
in the very same way like the sound and input layers exists now.

A proper graphics layer based on fbdev_sysfs + libraries like the
ones Ben or Jon are working on + dri + hotplug + hal + udev + dbus
+ a good graphics servers (based on the unified layer) + toolkits
= a chance for linux to compete in the future with longhorn and
OSX.  The graphics layer I am describing here is low-level and
must contain the basics needed for a graphics server.  I am
working on one but i'm sure it would be useful to any Xserver
like the xserver from fd.o.

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Michel Dänzer]

On Fri, 2004-04-30 at 03:18, Otto Solares wrote:
> On Fri, Apr 30, 2004 at 01:12:17AM +0200, Michel D채nzer wrote:
> > On Thu, 2004-04-29 at 19:52, Otto Solares wrote:
> > > On Thu, Apr 29, 2004 at 03:01:13PM +0200, Michel D채nzer wrote:
> > > > On Thu, 2004-04-29 at 03:07, Otto Solares wrote:
> > > > > On Thu, Apr 29, 2004 at 12:26:41AM +0200, Michel D채nzer wrote:
> > > > > 
> > > > > > A small low-level driver could handle this, which both the framebuffer
> > > > > > device and the DRM use. Linus has proposed this approach, and I must say
> > > > > > I like it.
> > > > > 
> > > > > That should be fbdev without fbcon.
> > > > 
> > > > I'm not sure that works: keep in mind that the DRM works on other OSs
> > > > than Linux, and even on Linux some people may want to use the DRM
> > > > without a framebuffer device. Neither should be a problem with a minimal
> > > > base driver which does nothing more than hardware resource management
> > > > and arbitration.
> > > 
> > > Differents OSs have differents sources for DRM kernel side so
> > > that's not a problem nor will affect others OSs than linux.
> > 
> > Nope. Most of the code in the DRI CVS drm module is shared between OSs.
> > Most of the shared code is hardware specific though, so if you change
> > the interface to the hardware, either all the OSs will have to provide
> > the new interface, or the code can no longer be shared, which would get
> > us back to the code duplication horrors. I'd very much like to avoid
> > that.
> 
> I don't see your point, nothing prevents using the shared code,
> the idea is not to change the interface, just to have a single
> graphics layer that handle that same interface.  I know it could be
> a pain to duplicate the fbdev into the cvs drm module, but with
> proper file separations there could live the fbdev's drm code.

I don't see how that can be done without changing the shared code,
effectively un-sharing it. Could just be me though.


-- 
Earthling Michel D채nzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Ville Syrjälä]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1990 bytes --]

On Fri, Apr 30, 2004 at 07:57:20AM +1000, Benjamin Herrenschmidt wrote:
> 
> > > Finally, the geometry of screens is something that has nothing to
> > > do in the kernel imho.
> > 
> > I don't like micro kernel designs. This is way micro kernels handle this 
> > problem.
> 
> This has nothing to do with microkernel design and everything to do with
> not bloating the kernel with things that don't to be there.

I would like the kernel to handle CRTCs and overlays in the same way, and 
that way IMHO should be to calculate register values in userspace and just 
have a few ioctls to have the kernel write them.

Set all registers ioctl:
Nothing special needed here I think.

Set buffer offset (pan/flip) ioctl:
This one should return the current vertical blank counter. It's needed for 
proper triple buffering. It should also be able to choose when to flip 
(immediately or vblank, on top/bottom/any field).

Wait for vertical blank ioctl:
This one should also return the current vblank counter. It should also be 
able to wait for absolute and relative vblank counter values. Waiting for 
relative=1 would insure you're at the vblank when it returns and waiting 
for absolute=last_flip_counter_value+1 would help with double buffering.


The main reason for userspace register calculation is that there are a lot 
of knobs in some hardware (especially with overlays). Trying to abstract 
those without loosing any features would be a problem. And even the API 
would cover all of todays graphics chip something new might come along in 
the future and the API might become too limited.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=click

Re: [PATCH] neofb patches

[James Simmons]

> > > I don't like micro kernel designs. This is way micro kernels handle this 
> > > problem.
> > 
> > This has nothing to do with microkernel design and everything to do with
> > not bloating the kernel with things that don't to be there.
> 
> I would like the kernel to handle CRTCs and overlays in the same way, and 
> that way IMHO should be to calculate register values in userspace and just 
> have a few ioctls to have the kernel write them.
> 
> Set all registers ioctl:
> Nothing special needed here I think.
> 
> Set buffer offset (pan/flip) ioctl:
> This one should return the current vertical blank counter. It's needed for 
> proper triple buffering. It should also be able to choose when to flip 
> (immediately or vblank, on top/bottom/any field).
> 
> Wait for vertical blank ioctl:
> This one should also return the current vblank counter. It should also be 
> able to wait for absolute and relative vblank counter values. Waiting for 
> relative=1 would insure you're at the vblank when it returns and waiting 
> for absolute=last_flip_counter_value+1 would help wi

Reason why a "universal" library will not work.

1) There will never be a universal library. I have worked with:

EmbeddedQT
framebuffer based Gtk
directfb
sdl
Embedded OpenGL
GGI
Java j2me
lots of home brewed solutions

The latest thing now is OpenML. Next year it will be something else.

Ben you can create your library all you want but the reality is very few 
will end up using it.

2) Several of the above libraries depend on mode changing being avaliable 
   in fbdev. Take that away and alot of companies will be very upset. I 
   tell you if I owned/worked for a company that wrote embedded software 
   that changed the video mode via fbdev (which BTW I do) and that was 
   taken away I would be very upset!!!! The only we use the fbdev interface
   is because it is easy to port our software from one box to another and 
   second it does mode switching for us. We don't need to write the mode 
   switching for each box. You take that away and the reality is companies
   will have no real reason to use the fbdev api anymore. We will just come 
   up with our own thing. Do you really want that to happen?

3) The BIGGEST issue is the license issue. Sorry but GPL and even LPGL 
   doesn't fly at most companies. Most likely your library will be one
   of these license. Most comapnies like to use there own license. Using 
   the fbdev api doesn't require dealing with a license but using a 
   userland library does. This is one of the major reasons for the above
   libraries.

	




  



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Fri, Apr 30, 2004 at 03:28:57AM +0200, Michel Dänzer wrote:
> I don't see how that can be done without changing the shared code,
> effectively un-sharing it. Could just be me though.

Nobody says it would be easy, opossition will be fierce!

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Re: [PATCH] neofb patches

[Otto Solares]

On Fri, Apr 30, 2004 at 05:50:07PM +0100, James Simmons wrote:
> 2) Several of the above libraries depend on mode changing being avaliable 
>    in fbdev. Take that away and alot of companies will be very upset. I 
>    tell you if I owned/worked for a company that wrote embedded software 
>    that changed the video mode via fbdev (which BTW I do) and that was 
>    taken away I would be very upset!!!! The only we use the fbdev interface
>    is because it is easy to port our software from one box to another and 
>    second it does mode switching for us. We don't need to write the mode 
>    switching for each box. You take that away and the reality is companies
>    will have no real reason to use the fbdev api anymore. We will just come 
>    up with our own thing. Do you really want that to happen?

I agree.  Mode switching is a core function for a low-level graphics layer.

-otto



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click

Mobility M1 refresh code problem 2.4.26?

[Richard Smith]

I'm trying to get the Mobility M1 atyfb in 2.4.26 to work on Dell 
Latitude CPx.

If I boot he laptop with a CRT connected and run X windows everything 
works.  The x windows log reports its using a refresh rate code of 12

Compile atyfb without generic LCD support.

If I load atyfb the screen is almost there but lots of the text is 
messed up.  Line spacing seems correct but the actual text is 
unreadable.  Like a clock is off or something

If I now load the X windows driver (Still using ATI driver and not FB) 
the same type issues apears on the graphics.  It's almost there but some 
pixels appear to be mssing or in the wrong spot.

The X log now is pretty much identical but says that its useing a 
refresh rate code of 7.  XCLK and reference clocks are the same.

If I boot under the LCD and run X I get refresh rate of 12
When I load atyfb the LCD blanks out. But if I "modprobe atyfb;startx"
I get the same wiggy screen as under an CRT and again a refresh code of
7.

If I enable the Generic LCD support and load atyfb the LCD now displays 
data but has the same problem as the CRT and againg a refresh rate code 
of 7 if I run X and similar issues as the CRT setup yet the wiggyness is 
different.  Still mostly recognizeable though.

Where does atyfb calculate what it need to to set the refresh rate code 
and any idea why it might be doing it incorrectly on this laptop?

Its my understanding that the atyfb tree in 2.4 currently has the best 
M1 support and not 2.6.x.  If not then can someone point me to where I 
can find the latest patch for 2.6




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Mobility M1 refresh code problem 2.4.26?

[Mikael Eriksson]

Richard Smith wrote:
> I'm trying to get the Mobility M1 atyfb in 2.4.26 to work on Dell 
> Latitude CPx.

I have the same laptop over here, and it works perfectly with 2.4.26.

dmesg:
atyfb: using auxiliary register aperture
atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
atyfb: BIOS contains driver information table.
atyfb: colour active matrix monitor detected: Samsung LT141X4-156
         id=2, 1024x768 pixels, 262144 colours (LT mode)
         supports 60 Hz refresh rates, default 60 Hz
         LCD CRTC parameters: 15384 167 127 130 0 17 805 767 769 6
atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz 
XTAL, 230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK

.config:
CONFIG_FB_ATY=y
# CONFIG_FB_ATY_GX is not set
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
# CONFIG_FB_ATY128 is not set

boot-param:
video=atyfb:1024x768-32

> 
> If I boot he laptop with a CRT connected and run X windows everything 
> works.  The x windows log reports its using a refresh rate code of 12
> 
> Compile atyfb without generic LCD support.
> 
> If I load atyfb the screen is almost there but lots of the text is 
> messed up.  Line spacing seems correct but the actual text is 
> unreadable.  Like a clock is off or something
> 
> If I now load the X windows driver (Still using ATI driver and not FB) 
> the same type issues apears on the graphics.  It's almost there but some 
> pixels appear to be mssing or in the wrong spot.
> 
> The X log now is pretty much identical but says that its useing a 
> refresh rate code of 7.  XCLK and reference clocks are the same.
> 
> If I boot under the LCD and run X I get refresh rate of 12
> When I load atyfb the LCD blanks out. But if I "modprobe atyfb;startx"
> I get the same wiggy screen as under an CRT and again a refresh code of
> 7.
> 
> If I enable the Generic LCD support and load atyfb the LCD now displays 
> data but has the same problem as the CRT and againg a refresh rate code 
> of 7 if I run X and similar issues as the CRT setup yet the wiggyness is 
> different.  Still mostly recognizeable though.
> 
> Where does atyfb calculate what it need to to set the refresh rate code 
> and any idea why it might be doing it incorrectly on this laptop?
> 
> Its my understanding that the atyfb tree in 2.4 currently has the best 
> M1 support and not 2.6.x.  If not then can someone point me to where I 
> can find the latest patch for 2.6
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Mobility M1 refresh code problem 2.4.26?

[Richard Smith]

Mikael Eriksson wrote:

> dmesg:
> atyfb: using auxiliary register aperture
> atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
> atyfb: BIOS contains driver information table.
> atyfb: colour active matrix monitor detected: Samsung LT141X4-156
>         id=2, 1024x768 pixels, 262144 colours (LT mode)
>         supports 60 Hz refresh rates, default 60 Hz
>         LCD CRTC parameters: 15384 167 127 130 0 17 805 767 769 6
> atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 MHz 
> XTAL, 230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK
> 
> .config:
> CONFIG_FB_ATY=y
> # CONFIG_FB_ATY_GX is not set
> CONFIG_FB_ATY_CT=y
> CONFIG_FB_ATY_GENERIC_LCD=y
> # CONFIG_FB_ATY128 is not set
> 
> boot-param:
> video=atyfb:1024x768-32

Hmmm... I had GX set.  Unsetting and rebuilding did change things.  the 
text is almost readable but its still not quite right.

I was doing it as a module rather than at boot time but changing to the 
driver compiled in still has the same result.

My dmesg output is identical to yours.  But X still logs a differnt 
refresh rate code of 7.  What refresh rate code is in your X windows log 
file?

I'm doing a make clean;make bzImage right not to be sure its not some 
holdover of haveing GX enabled on my original build.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Mobility M1 refresh code problem 2.4.26?

[Geert Uytterhoeven]

On Thu, 6 May 2004, Richard Smith wrote:
> Hmmm... I had GX set.  Unsetting and rebuilding did change things.  the

Strange, {en,dis}abling GX should matter for Mach64 GX chips only.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Mobility M1 refresh code problem 2.4.26?

[Richard Smith]

Geert Uytterhoeven wrote:

> On Thu, 6 May 2004, Richard Smith wrote:
> 
>>Hmmm... I had GX set.  Unsetting and rebuilding did change things.  the
> 
> 
> Strange, {en,dis}abling GX should matter for Mach64 GX chips only.

Could be some randomness in what I'm seeing.  I haven't done it enough 
times repeatedly to verify it does the same thing every time.

I rebuilt from a make clean and got the same result.  I enabled DEBUG in 
the driver now and heres the output.  Can you enable debug and check 
against your good setup.

atyfb: using auxiliary register aperture
atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
atyfb: BIOS contains driver information table.
atyfb: colour active matrix monitor detected: Samsung LT141X4-156
ati kernel:         id=2, 1024x768 pixels, 262144 colours (LT mode)
ati kernel:         supports 60 Hz refresh rates, default 60 Hz
ati kernel:         LCD CRTC parameters: 15384 167 127 130 0 17 805 767 
769 6
ati kernel: atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 
29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK
ati kernel: BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL 
DSP_CONFIG DSP_ON_OFF CLOCK_CNTL
ati kernel: 7333a001 8601200a 10c57a3b e0000c81     02402200 
00570628   049e05f8   00400a00
ati kernel: PLL ac ac 40 4c 87 03 c0 d4 d4 d4 00 f9 80 1b 00 00 0e cf 40 
00 50 f6 ac 03 40 00 24 fd 00 00 00 02 06 ac 06 ac 03 24 fd 00
ati kernel: BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL 
DSP_CONFIG DSP_ON_OFF
ati kernel: 7333a001 8601200a 10c57a3b e0000c81     02402200 
00570628   049e05f8
ati kernel: PLL ac ac 41 ec 89 03 c0 d4 d4 d4 00 00 80 1b 00 00 0e cf 40 
00 50 b6 ac 10 40 00 24 fd 00 00 00 02 06 ac 06 ac 03 24 fd 00
ati kernel: Console: switching to colour frame buffer device 128x48




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Mobility M1 refresh code problem 2.4.26?

[Mikael Eriksson]

Richard Smith wrote:
> Geert Uytterhoeven wrote:
> 
>> On Thu, 6 May 2004, Richard Smith wrote:
>>
>>> Hmmm... I had GX set.  Unsetting and rebuilding did change things.  the
>>
>>
>>
>> Strange, {en,dis}abling GX should matter for Mach64 GX chips only.
> 
> 
> Could be some randomness in what I'm seeing.  I haven't done it enough 
> times repeatedly to verify it does the same thing every time.
> 
> I rebuilt from a make clean and got the same result.  I enabled DEBUG in 
> the driver now and heres the output.  Can you enable debug and check 
> against your good setup.
> 
> atyfb: using auxiliary register aperture
> atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
> atyfb: BIOS contains driver information table.
> atyfb: colour active matrix monitor detected: Samsung LT141X4-156
> ati kernel:         id=2, 1024x768 pixels, 262144 colours (LT mode)
> ati kernel:         supports 60 Hz refresh rates, default 60 Hz
> ati kernel:         LCD CRTC parameters: 15384 167 127 130 0 17 805 767 
> 769 6
> ati kernel: atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 
> 29.498928 MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK
> ati kernel: BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL 
> DSP_CONFIG DSP_ON_OFF CLOCK_CNTL
> ati kernel: 7333a001 8601200a 10c57a3b e0000c81     02402200 00570628   
> 049e05f8   00400a00
> ati kernel: PLL ac ac 40 4c 87 03 c0 d4 d4 d4 00 f9 80 1b 00 00 0e cf 40 
> 00 50 f6 ac 03 40 00 24 fd 00 00 00 02 06 ac 06 ac 03 24 fd 00
> ati kernel: BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL 
> DSP_CONFIG DSP_ON_OFF
> ati kernel: 7333a001 8601200a 10c57a3b e0000c81     02402200 00570628   
> 049e05f8
> ati kernel: PLL ac ac 41 ec 89 03 c0 d4 d4 d4 00 00 80 1b 00 00 0e cf 40 
> 00 50 b6 ac 10 40 00 24 fd 00 00 00 02 06 ac 06 ac 03 24 fd 00
> ati kernel: Console: switching to colour frame buffer device 128x48
> 
This is what I get:
<6>devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
<6>devfs: boot_options: 0x0
<6>atyfb: using auxiliary register aperture
<6>atyfb: Mach64 BIOS is located at c0000, mapped at c00c0000.
<6>atyfb: BIOS contains driver information table.
<6>atyfb: colour active matrix monitor detected: Samsung LT141X4-156
<4>        id=2, 1024x768 pixels, 262144 colours (LT mode)
<6>        supports 60 Hz refresh rates, default 60 Hz
<6>        LCD CRTC parameters: 15384 167 127 130 0 17 805 767 769 6
<4>atyfb: 3D RAGE Mobility (PCI) [0x4c4d rev 0x64] 8M SDRAM, 29.498928 
MHz XTAL, 230 MHz PLL, 83 Mhz MCLK, 125 Mhz XCLK
<4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG 
DSP_ON_OFF CLOCK_CNTL
<4>7333a001 8601200a 10c57a3b e0000c81     02402200      00570628 
049e05f8   00400a00
<4>PLL ac ac 40 4c 87 03 c0 d4 d4 d4 00 f9 80 1b 00 00 0e cf 40 00 50 f6 
ac 03 40 00 24 fd 00 00 00 02 06 ac 06 ac 03 24 fd 00
<4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG 
DSP_ON_OFF
<4>7333a001 8601200a 10c57a3b e0000c81     02402200      00570628   049e05f8
<4>PLL ac ac 41 ec 89 03 c0 d4 d4 d4 00 00 80 1b 00 00 0e cf 40 00 50 b6 
ac 10 40 00 24 fd 00 00 00 02 06 ac 06 ac 03 24 fd 00
<4>Console: switching to colour frame buffer device 80x25

Also XFree reports refresh rate code 7
Btw, which bios version do you have?


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Mobility M1 refresh code problem 2.4.26?

[Richard Smith]

Mikael Eriksson wrote:

It seems our settings are identical.

> Also XFree reports refresh rate code 7

Ok so its not the refresh rate either. What else can we check?

 > Btw, which bios version do you have?

A05




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Mobility M1 refresh code problem 2.4.26?

[Mikael Eriksson]

Richard Smith wrote:
> Mikael Eriksson wrote:
> 
> It seems our settings are identical.
> 
>> Also XFree reports refresh rate code 7
> 
> 
> Ok so its not the refresh rate either. What else can we check?
> 
>  > Btw, which bios version do you have?
> 
> A05

Hmm, try to update, I have A16

> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Mobility M1 refresh code problem 2.4.26?

[Richard Smith]

Mikael Eriksson wrote:

>> It seems our settings are identical.
>>
>>> Also XFree reports refresh rate code 7
>>
>> Ok so its not the refresh rate either. What else can we check?
>>
>>  > Btw, which bios version do you have?
>>
>> A05
> 
> 
> Hmm, try to update, I have A16
> 

Where did you find that at.  All I get when I enter my service tag of 
7bpap on the website is an A14.

I'm also not sure yet how I'm going to do this.  There's no windows 
partition and I don't have a floppy drive.

Perhaps I can do something creative with a bootable CD and a bootable 
floppy image.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

Re: Mobility M1 refresh code problem 2.4.26?

[Mikael Eriksson]

Richard Smith wrote:
> Mikael Eriksson wrote:
> 
>>> It seems our settings are identical.
>>>
>>>> Also XFree reports refresh rate code 7
>>>
>>>
>>> Ok so its not the refresh rate either. What else can we check?
>>>
>>>  > Btw, which bios version do you have?
>>>
>>> A05
>>
>>
>>
>> Hmm, try to update, I have A16
>>
> 
> Where did you find that at.  All I get when I enter my service tag of 
> 7bpap on the website is an A14.

Seems you have an CPx H, while I have a CPx J.
But I don't know what the difference is.

> 
> I'm also not sure yet how I'm going to do this.  There's no windows 
> partition and I don't have a floppy drive.
> 
> Perhaps I can do something creative with a bootable CD and a bootable 
> floppy image.

That should be possible.


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3