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

[Linux-fbdev-devel] PATCH: rivafb minor fixes

[Jindrich M. <mak...@km...>]

Hi all,

I changed the register setup in riva_tbl.h to MSB bit order so the ugly order-reversing 
routine in accel.c is not needed anymore.

In fbdev.c, I changed the cursor handling stuff to use only a 50Hz timer, instead of 100Hz.

Best regards,

-- 
Jindrich Makovicka

8<--snip
diff -urN ../vanilla/linux/drivers/video/riva/accel.c linux/drivers/video/riva/accel.c
--- ../vanilla/linux/drivers/video/riva/accel.c	Mon Oct 15 22:47:13 2001
+++ linux/drivers/video/riva/accel.c	Tue Oct 30 22:20:13 2001
@@ -86,34 +86,6 @@
 			      bottom_width, right_start, bgx);
 }
 
-static u8 byte_rev[256] = {
-	0x00, 0x80, 0x40, 0xc0, 0x20, 0xa0, 0x60, 0xe0, 0x10, 0x90, 0x50, 0xd0, 0x30, 0xb0, 0x70, 0xf0,
-	0x08, 0x88, 0x48, 0xc8, 0x28, 0xa8, 0x68, 0xe8, 0x18, 0x98, 0x58, 0xd8, 0x38, 0xb8, 0x78, 0xf8, 
-	0x04, 0x84, 0x44, 0xc4, 0x24, 0xa4, 0x64, 0xe4, 0x14, 0x94, 0x54, 0xd4, 0x34, 0xb4, 0x74, 0xf4, 
-	0x0c, 0x8c, 0x4c, 0xcc, 0x2c, 0xac, 0x6c, 0xec, 0x1c, 0x9c, 0x5c, 0xdc, 0x3c, 0xbc, 0x7c, 0xfc, 
-	0x02, 0x82, 0x42, 0xc2, 0x22, 0xa2, 0x62, 0xe2, 0x12, 0x92, 0x52, 0xd2, 0x32, 0xb2, 0x72, 0xf2, 
-	0x0a, 0x8a, 0x4a, 0xca, 0x2a, 0xaa, 0x6a, 0xea, 0x1a, 0x9a, 0x5a, 0xda, 0x3a, 0xba, 0x7a, 0xfa, 
-	0x06, 0x86, 0x46, 0xc6, 0x26, 0xa6, 0x66, 0xe6, 0x16, 0x96, 0x56, 0xd6, 0x36, 0xb6, 0x76, 0xf6, 
-	0x0e, 0x8e, 0x4e, 0xce, 0x2e, 0xae, 0x6e, 0xee, 0x1e, 0x9e, 0x5e, 0xde, 0x3e, 0xbe, 0x7e, 0xfe, 
-	0x01, 0x81, 0x41, 0xc1, 0x21, 0xa1, 0x61, 0xe1, 0x11, 0x91, 0x51, 0xd1, 0x31, 0xb1, 0x71, 0xf1, 
-	0x09, 0x89, 0x49, 0xc9, 0x29, 0xa9, 0x69, 0xe9, 0x19, 0x99, 0x59, 0xd9, 0x39, 0xb9, 0x79, 0xf9, 
-	0x05, 0x85, 0x45, 0xc5, 0x25, 0xa5, 0x65, 0xe5, 0x15, 0x95, 0x55, 0xd5, 0x35, 0xb5, 0x75, 0xf5, 
-	0x0d, 0x8d, 0x4d, 0xcd, 0x2d, 0xad, 0x6d, 0xed, 0x1d, 0x9d, 0x5d, 0xdd, 0x3d, 0xbd, 0x7d, 0xfd, 
-	0x03, 0x83, 0x43, 0xc3, 0x23, 0xa3, 0x63, 0xe3, 0x13, 0x93, 0x53, 0xd3, 0x33, 0xb3, 0x73, 0xf3, 
-	0x0b, 0x8b, 0x4b, 0xcb, 0x2b, 0xab, 0x6b, 0xeb, 0x1b, 0x9b, 0x5b, 0xdb, 0x3b, 0xbb, 0x7b, 0xfb, 
-	0x07, 0x87, 0x47, 0xc7, 0x27, 0xa7, 0x67, 0xe7, 0x17, 0x97, 0x57, 0xd7, 0x37, 0xb7, 0x77, 0xf7, 
-	0x0f, 0x8f, 0x4f, 0xcf, 0x2f, 0xaf, 0x6f, 0xef, 0x1f, 0x9f, 0x5f, 0xdf, 0x3f, 0xbf, 0x7f, 0xff,
-};
-
-static inline void fbcon_reverse_order(u32 *l)
-{
-	u8 *a = (u8 *)l;
-	*a++ = byte_rev[*a];
-/*	*a++ = byte_rev[*a];
-	*a++ = byte_rev[*a];*/
-	*a = byte_rev[*a];
-}
-
 static void fbcon_riva_writechr(struct vc_data *conp, struct display *p,
 			        int c, int fgx, int bgx, int yy, int xx)
 {
@@ -153,7 +125,6 @@
 				cdat2 = *cdat++;
 			else
 				cdat2 = *((u16*)cdat)++;
-			fbcon_reverse_order(&cdat2);
 			d[j] = cdat2;
 		}
 	}
diff -urN ../vanilla/linux/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- ../vanilla/linux/drivers/video/riva/fbdev.c	Sun Oct 21 19:14:38 2001
+++ linux/drivers/video/riva/fbdev.c	Thu Nov  1 08:39:01 2001
@@ -91,8 +91,8 @@
 #define Set8Bits(value)		((value)&0xff)
 
 /* HW cursor parameters */
-#define DEFAULT_CURSOR_BLINK_RATE	(40)
-#define CURSOR_HIDE_DELAY		(20)
+#define DEFAULT_CURSOR_BLINK_RATE	(20)
+#define CURSOR_HIDE_DELAY		(10)
 #define CURSOR_SHOW_DELAY		(3)
 
 #define CURSOR_COLOR		0x7fff
@@ -230,7 +230,7 @@
 	int enable;
 	int on;
 	int vbl_cnt;
-	int last_move_delay;
+	int last_slice_moves, prev_slice_moves;
 	int blink_rate;
 	struct {
 		u16 x, y;
@@ -407,26 +407,28 @@
 static void riva_cursor_timer_handler(unsigned long dev_addr)
 {
 	struct rivafb_info *rinfo = (struct rivafb_info *)dev_addr;
+	struct riva_cursor *c;
 
 	if (!rinfo->cursor) return;
+	c = rinfo->cursor;
 
-	if (!rinfo->cursor->enable) goto out;
+	if (!c->enable) goto out;
 
-	if (rinfo->cursor->last_move_delay < 1000)
-		rinfo->cursor->last_move_delay++;
+	c->prev_slice_moves = c->last_slice_moves;
+	c->last_slice_moves = 0;
 
-	if (rinfo->cursor->vbl_cnt && --rinfo->cursor->vbl_cnt == 0) {
-		rinfo->cursor->on ^= 1;
-		if (rinfo->cursor->on)
-			*(rinfo->riva.CURSORPOS) = (rinfo->cursor->pos.x & 0xFFFF)
-						   | (rinfo->cursor->pos.y << 16);
-		rinfo->riva.ShowHideCursor(&rinfo->riva, rinfo->cursor->on);
+	if (c->vbl_cnt && --c->vbl_cnt == 0) {
+		c->on ^= 1;
+		if (c->on)
+			*(rinfo->riva.CURSORPOS) = (c->pos.x & 0xFFFF)
+						   | (c->pos.y << 16);
+		rinfo->riva.ShowHideCursor(&rinfo->riva, c->on);
 		if (!noblink)
-			rinfo->cursor->vbl_cnt = rinfo->cursor->blink_rate;
+			c->vbl_cnt = c->blink_rate;
 	}
 out:
-	rinfo->cursor->timer->expires = jiffies + (HZ / 100);
-	add_timer(rinfo->cursor->timer);
+	c->timer->expires = jiffies + (HZ / 50);
+	add_timer(c->timer);
 }
 
 /**
@@ -460,7 +462,7 @@
 	cursor->blink_rate = DEFAULT_CURSOR_BLINK_RATE;
 
 	init_timer(cursor->timer);
-	cursor->timer->expires = jiffies + (HZ / 100);
+	cursor->timer->expires = jiffies + (HZ / 50);
 	cursor->timer->data = (unsigned long)rinfo;
 	cursor->timer->function = riva_cursor_timer_handler;
 	add_timer(cursor->timer);
@@ -616,7 +618,7 @@
 		break;
 	case CM_DRAW:
 	case CM_MOVE:
-		if (c->last_move_delay <= 1) { /* rapid cursor movement */
+		if (c->last_slice_moves > 2 || c->prev_slice_moves > 2) { /* rapid cursor movement */
 			c->vbl_cnt = CURSOR_SHOW_DELAY;
 		} else {
 			*(rinfo->riva.CURSORPOS) = (x & 0xFFFF) | (y << 16);
@@ -624,7 +626,7 @@
 			if (!noblink) c->vbl_cnt = CURSOR_HIDE_DELAY;
 			c->on = 1;
 		}
-		c->last_move_delay = 0;
+		c->last_slice_moves++;
 		c->enable = 1;
 		break;
 	}
diff -urN ../vanilla/linux/drivers/video/riva/riva_tbl.h linux/drivers/video/riva/riva_tbl.h
--- ../vanilla/linux/drivers/video/riva/riva_tbl.h	Tue Feb 13 22:15:05 2001
+++ linux/drivers/video/riva/riva_tbl.h	Wed Oct 31 13:13:38 2001
@@ -48,6 +48,9 @@
 /*
  * RIVA Fixed Functionality Init Tables.
  */
+ 
+/* Bit order changed to MSB.  -- JM */
+
 static unsigned RivaTablePMC[][2] =
 {
     {0x00000050, 0x00000000},
@@ -216,37 +219,37 @@
 {
     /*           0xXXXXX3XX For  MSB mono format */
     /*           0xXXXXX2XX For  LSB mono format */
-    {0x00000D04, 0x10110203},
-    {0x00000D08, 0x10110203},
-    {0x00000D0C, 0x1011020B},
-    {0x00000D10, 0x10118203},
-    {0x00000D14, 0x10110203},
-    {0x00000D18, 0x10110203},
-    {0x00000D1C, 0x10419208}
+    {0x00000D04, 0x10110303},
+    {0x00000D08, 0x10110303},
+    {0x00000D0C, 0x1011030B},
+    {0x00000D10, 0x10118303},
+    {0x00000D14, 0x10110303},
+    {0x00000D18, 0x10110303},
+    {0x00000D1C, 0x10419308}
 };
 static unsigned nv3TablePRAMIN_15BPP[][2] =
 {
     /*           0xXXXXX2XX For  MSB mono format */
     /*           0xXXXXX3XX For  LSB mono format */
-    {0x00000D04, 0x10110200},
-    {0x00000D08, 0x10110200},
-    {0x00000D0C, 0x10110208},
-    {0x00000D10, 0x10118200},
-    {0x00000D14, 0x10110200},
-    {0x00000D18, 0x10110200},
-    {0x00000D1C, 0x10419208}
+    {0x00000D04, 0x10110300},
+    {0x00000D08, 0x10110300},
+    {0x00000D0C, 0x10110308},
+    {0x00000D10, 0x10118300},
+    {0x00000D14, 0x10110300},
+    {0x00000D18, 0x10110300},
+    {0x00000D1C, 0x10419308}
 };
 static unsigned nv3TablePRAMIN_32BPP[][2] =
 {
     /*           0xXXXXX3XX For  MSB mono format */
     /*           0xXXXXX2XX For  LSB mono format */
-    {0x00000D04, 0x10110201},
-    {0x00000D08, 0x10110201},
-    {0x00000D0C, 0x10110209},
-    {0x00000D10, 0x10118201},
-    {0x00000D14, 0x10110201},
-    {0x00000D18, 0x10110201},
-    {0x00000D1C, 0x10419208}
+    {0x00000D04, 0x10110301},
+    {0x00000D08, 0x10110301},
+    {0x00000D0C, 0x10110309},
+    {0x00000D10, 0x10118301},
+    {0x00000D14, 0x10110301},
+    {0x00000D18, 0x10110301},
+    {0x00000D1C, 0x10419308}
 };
 static unsigned nv4TableFIFO[][2] =
 {
@@ -443,14 +446,14 @@
 {
     /*           0xXXXXXX01 For  MSB mono format */
     /*           0xXXXXXX02 For  LSB mono format */
-    {0x00000509, 0x00000302},
-    {0x0000050D, 0x00000302},
-    {0x00000511, 0x00000202},
-    {0x00000515, 0x00000302},
-    {0x00000519, 0x00000302},
-    {0x0000051D, 0x00000302},
-    {0x0000052D, 0x00000302},
-    {0x0000052E, 0x00000302},
+    {0x00000509, 0x00000301},
+    {0x0000050D, 0x00000301},
+    {0x00000511, 0x00000201},
+    {0x00000515, 0x00000301},
+    {0x00000519, 0x00000301},
+    {0x0000051D, 0x00000301},
+    {0x0000052D, 0x00000301},
+    {0x0000052E, 0x00000301},
     {0x00000535, 0x00000000},
     {0x00000539, 0x00000000} 
 };
@@ -458,46 +461,46 @@
 {
     /*           0xXXXXXX01 For  MSB mono format */
     /*           0xXXXXXX02 For  LSB mono format */
-    {0x00000509, 0x00000902},
-    {0x0000050D, 0x00000902},
-    {0x00000511, 0x00000802},
-    {0x00000515, 0x00000902},
-    {0x00000519, 0x00000902},
-    {0x0000051D, 0x00000902},
-    {0x0000052D, 0x00000902},
-    {0x0000052E, 0x00000902},
-    {0x00000535, 0x00000702},
-    {0x00000539, 0x00000702} 
+    {0x00000509, 0x00000901},
+    {0x0000050D, 0x00000901},
+    {0x00000511, 0x00000801},
+    {0x00000515, 0x00000901},
+    {0x00000519, 0x00000901},
+    {0x0000051D, 0x00000901},
+    {0x0000052D, 0x00000901},
+    {0x0000052E, 0x00000901},
+    {0x00000535, 0x00000701},
+    {0x00000539, 0x00000701} 
 };
 static unsigned nv4TablePRAMIN_16BPP[][2] =
 {
     /*           0xXXXXXX01 For  MSB mono format */
     /*           0xXXXXXX02 For  LSB mono format */
-    {0x00000509, 0x00000C02},
-    {0x0000050D, 0x00000C02},
-    {0x00000511, 0x00000B02},
-    {0x00000515, 0x00000C02},
-    {0x00000519, 0x00000C02},
-    {0x0000051D, 0x00000C02},
-    {0x0000052D, 0x00000C02},
-    {0x0000052E, 0x00000C02},
-    {0x00000535, 0x00000702},
-    {0x00000539, 0x00000702} 
+    {0x00000509, 0x00000C01},
+    {0x0000050D, 0x00000C01},
+    {0x00000511, 0x00000B01},
+    {0x00000515, 0x00000C01},
+    {0x00000519, 0x00000C01},
+    {0x0000051D, 0x00000C01},
+    {0x0000052D, 0x00000C01},
+    {0x0000052E, 0x00000C01},
+    {0x00000535, 0x00000701},
+    {0x00000539, 0x00000701} 
 };
 static unsigned nv4TablePRAMIN_32BPP[][2] =
 {
     /*           0xXXXXXX01 For  MSB mono format */
     /*           0xXXXXXX02 For  LSB mono format */
-    {0x00000509, 0x00000E02},
-    {0x0000050D, 0x00000E02},
-    {0x00000511, 0x00000D02},
-    {0x00000515, 0x00000E02},
-    {0x00000519, 0x00000E02},
-    {0x0000051D, 0x00000E02},
-    {0x0000052D, 0x00000E02},
-    {0x0000052E, 0x00000E02},
-    {0x00000535, 0x00000E02},
-    {0x00000539, 0x00000E02} 
+    {0x00000509, 0x00000E01},
+    {0x0000050D, 0x00000E01},
+    {0x00000511, 0x00000D01},
+    {0x00000515, 0x00000E01},
+    {0x00000519, 0x00000E01},
+    {0x0000051D, 0x00000E01},
+    {0x0000052D, 0x00000E01},
+    {0x0000052E, 0x00000E01},
+    {0x00000535, 0x00000E01},
+    {0x00000539, 0x00000E01} 
 };
 static unsigned nv10TableFIFO[][2] =
 {
@@ -888,14 +891,14 @@
 {
     /*           0xXXXXXX01 For  MSB mono format */
     /*           0xXXXXXX02 For  LSB mono format */
-    {0x00000509, 0x00000302},
-    {0x0000050D, 0x00000302},
-    {0x00000511, 0x00000202},
-    {0x00000515, 0x00000302},
-    {0x00000519, 0x00000302},
-    {0x0000051D, 0x00000302},
-    {0x0000052D, 0x00000302},
-    {0x0000052E, 0x00000302},
+    {0x00000509, 0x00000301},
+    {0x0000050D, 0x00000301},
+    {0x00000511, 0x00000201},
+    {0x00000515, 0x00000301},
+    {0x00000519, 0x00000301},
+    {0x0000051D, 0x00000301},
+    {0x0000052D, 0x00000301},
+    {0x0000052E, 0x00000301},
     {0x00000535, 0x00000000},
     {0x00000539, 0x00000000},
     {0x0000053D, 0x00000000} 
@@ -904,48 +907,48 @@
 {
     /*           0xXXXXXX01 For  MSB mono format */
     /*           0xXXXXXX02 For  LSB mono format */
-    {0x00000509, 0x00000902},
-    {0x0000050D, 0x00000902},
-    {0x00000511, 0x00000802},
-    {0x00000515, 0x00000902},
-    {0x00000519, 0x00000902},
-    {0x0000051D, 0x00000902},
-    {0x0000052D, 0x00000902},
-    {0x0000052E, 0x00000902},
-    {0x00000535, 0x00000902},
-    {0x00000539, 0x00000902}, 
-    {0x0000053D, 0x00000902} 
+    {0x00000509, 0x00000901},
+    {0x0000050D, 0x00000901},
+    {0x00000511, 0x00000801},
+    {0x00000515, 0x00000901},
+    {0x00000519, 0x00000901},
+    {0x0000051D, 0x00000901},
+    {0x0000052D, 0x00000901},
+    {0x0000052E, 0x00000901},
+    {0x00000535, 0x00000901},
+    {0x00000539, 0x00000901}, 
+    {0x0000053D, 0x00000901} 
 };
 static unsigned nv10TablePRAMIN_16BPP[][2] =
 {
     /*           0xXXXXXX01 For  MSB mono format */
     /*           0xXXXXXX02 For  LSB mono format */
-    {0x00000509, 0x00000C02},
-    {0x0000050D, 0x00000C02},
-    {0x00000511, 0x00000B02},
-    {0x00000515, 0x00000C02},
-    {0x00000519, 0x00000C02},
-    {0x0000051D, 0x00000C02},
-    {0x0000052D, 0x00000C02},
-    {0x0000052E, 0x00000C02},
-    {0x00000535, 0x00000C02},
-    {0x00000539, 0x00000C02},
-    {0x0000053D, 0x00000C02} 
+    {0x00000509, 0x00000C01},
+    {0x0000050D, 0x00000C01},
+    {0x00000511, 0x00000B01},
+    {0x00000515, 0x00000C01},
+    {0x00000519, 0x00000C01},
+    {0x0000051D, 0x00000C01},
+    {0x0000052D, 0x00000C01},
+    {0x0000052E, 0x00000C01},
+    {0x00000535, 0x00000C01},
+    {0x00000539, 0x00000C01},
+    {0x0000053D, 0x00000C01} 
 };
 static unsigned nv10TablePRAMIN_32BPP[][2] =
 {
     /*           0xXXXXXX01 For  MSB mono format */
     /*           0xXXXXXX02 For  LSB mono format */
-    {0x00000509, 0x00000E02},
-    {0x0000050D, 0x00000E02},
-    {0x00000511, 0x00000D02},
-    {0x00000515, 0x00000E02},
-    {0x00000519, 0x00000E02},
-    {0x0000051D, 0x00000E02},
-    {0x0000052D, 0x00000E02},
-    {0x0000052E, 0x00000E02},
-    {0x00000535, 0x00000E02},
-    {0x00000539, 0x00000E02},
-    {0x0000053D, 0x00000E02} 
+    {0x00000509, 0x00000E01},
+    {0x0000050D, 0x00000E01},
+    {0x00000511, 0x00000D01},
+    {0x00000515, 0x00000E01},
+    {0x00000519, 0x00000E01},
+    {0x0000051D, 0x00000E01},
+    {0x0000052D, 0x00000E01},
+    {0x0000052E, 0x00000E01},
+    {0x00000535, 0x00000E01},
+    {0x00000539, 0x00000E01},
+    {0x0000053D, 0x00000E01} 
 };

8<--snip

[Linux-fbdev-devel] Re: Linux-fbdev-devel digest, Vol 1 #197 - 5 msgs

[<chr...@ph...>]

Hello,

Your driver uses PSEUDOCOLOR, so it uses a palette. You have to store the colors (red, green, blue) in your palette (usually palette contains 256 colors=2^8 ) and then to store the color number (a byte) in the framebuffer memory.

For using a such palette, look at fbtest.c below  (written by James Simmons AFAIK)
Hope it will help you...

Cut here:
------------------------------------
/*
* fbtest.c
*
* build: gcc fbtest.c -o fbtest
*/


#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <linux/fb.h>
#include <sys/ioctl.h>
#include <sys/mman.h>


int init(void);
void clear(void);
int setrgb(int, int, int, int);


unsigned char *vmem;
int fd = -1;
int buffer_size;


static u_int16_t red[256], blue[256], green[256], transp[256];


static struct fb_cmap pal;


int init(void)
{
struct fb_var_screeninfo info;


if ((fd = open("/dev/fb0", O_RDWR)) == -1)
{
fprintf(stderr, "cannot open framebuffer device (%s)\n",
strerror(errno));
return -1;
}


if (ioctl(fd, FBIOGET_VSCREENINFO, &info))
{
fprintf(stderr, "ioctl failed on framebuffer device (%s)\n",
strerror(errno));
close(fd);
return -1;
}


/* we're only going to try 8-bit pixels: */


if (info.bits_per_pixel == 8)
buffer_size = info.xres * info.yres;
else
{
fprintf(stderr, "we don't do % bits per pixel mode\n",
info.bits_per_pixel);
close(fd);
return -1;
}


if ((vmem = mmap(NULL, buffer_size, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, 0)) == MAP_FAILED)
{
fprintf(stderr, "cannot mmap() framebuffer device (%s)\n",
strerror(errno));
close(fd);
return -1;
}


pal.start = 0;
pal.len = 256;
pal.red = red;
pal.green = green;
pal.blue = blue;
pal.transp = transp;


if (ioctl(fd, FBIOGETCMAP, &pal))
{
fprintf(stderr, "couldn't get cmap\n");
close(fd);
return -1;
}


return 0;
}


void clear(void)
{
memset(vmem, 0, buffer_size);
}


int setrgb(int n, int r, int g, int b)
{
pal.red[n] = r << 8;
pal.green[n] = g << 8;
pal.blue[n] = b << 8;
pal.transp[n] = 0;


return ioctl(fd, FBIOPUTCMAP, &pal);
}


int main(int argc, char **argv)
{
if (!init())
{
setrgb(0, 255, 0, 0);
clear();
}


return 0;
}
------------------------------------------





hi

i'm new to framebuffer development. i want to write a small library for
my embedded system(MPC823L) with a lcd(SHARP LQ64D341). i use the
framebufferdriver(lcd823.c) from the denx.de kernel tree.

my problem now is to get control over the colors. i use this to open the
framebuffer:

int fbfd = 0;
long int screensize = 0;
unsigned char *fbp = 0;
struct fb_fix_screeninfo finfo;
struct fb_var_screeninfo vinfo;

...

fbfd = open("/dev/fb", O_RDWR);
if (ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo)) {
if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)) {
screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;
fbp = (unsigned char*)mmap(0, screensize, PROT_READ | PROT_WRITE,
                    MAP_SHARED, fbfd, 0);


to set a pixel i use something like this:

setPixel(int x, int y, int color){
     long int location;
     location = (x+vinfo.xoffset) * (vinfo.bits_per_pixel/8)                          + (y+vinfo.yoffset) * finfo.line_length;                          *(fbp
+ location) = color;
     }
}

but what is the structure of the var color(should the type be unsigned
char?)? what is red, green and blue?
i know that the driver uses pseudocolor and 8bit per pixel.

thanks for helping

stefan

[Linux-fbdev-devel] Re: Radeon Frame Buffer

[Alan C. <al...@lx...>]

> I'm having a weird problem with the version that comes with the latest
> -ac kernels. Once the driver read the bios it stops scrolling during
> boot.

 *	drivers/video/radeonfb.c
 *	framebuffer driver for ATI Radeon chipset video boards
 *
 *	Copyright 2000	Ani Joshi <aj...@un...>

[Linux-fbdev-devel] Radeon Frame Buffer

[Louis G. <lou...@be...>]

Anyone know who is the maintainer of the Radeonfb?? Can 
you point me to a download site.

I'm having a weird problem with the version that comes with the latest
-ac kernels. Once the driver read the bios it stops scrolling during
boot.

Louis

Re: [Linux-fbdev-devel] Fixed-frequency monitor, and G45 se

[Carlo E. P. <fl...@fl...>]

	Subject: Re: [Linux-fbdev-devel] Fixed-frequency monitor, and G45 se
	Date: Fri, Oct 26, 2001 at 01:15:21PM +0000

Quoting Petr Vandrovec (VAN...@vc...):

> All changes should be limited to matroxfb_dh_restore() in
> drivers/video/matrox/matroxfb_crtc2.c.
> 
> Before line ~133 apply (by hand):
> 
> + if (mt->interlaced) tmp |= 0x02000000;
>   mga_outl(0x3C10, tmp | 0x10000000);
>   ...
>   mga_outl(0x3C28, pos);
> + {
> +   u_int32_t linelen = p->var.xres_virtual * (p->var.bits_per_pixel >> 3);
> +   if (mt->interlaced) {
> +     mga_outl(0x3C2C, pos + linelen);
> +     linelen *= 2;
> +   }
> +   mga_outl(0x3C40, linelen);
> + }
> - mga_outl(0x3C40, p->var.xres_virtual * (p->var.bits_per_pixel >> 3));
> 
> and unless I missed something somewhere, it should work.

I am very thankful for your help. Sadly I have no time now to
investigate further the situation. I patched matroxfb_crtc2.c,
recompiled the kernel, rebooted, but still, when my configuration is
applied to video output#1 it generates a signal with 16.0 kHz horiz
and 51 Hz vert, but when applied to video output#2 it generates a
signal with 13.2 kHz horiz and 21 Hz vert... 

I will go on exploring this problem one week from now. Now I must
pack...

Thanks again

Carlo 

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fl...@fl...             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

Re: [Linux-fbdev-devel] Fixed-frequency monitor, and G45 se

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

On 26 Oct 01 at 13:04, Carlo E. Prelz wrote:
> Quoting Petr Vandrovec (VAN...@vc...):
> 
> > Well, documentation says that it is possible, but I thought that nobody
> > uses interlaced picture now... If you want to do some experiments, you
> > can try:
> > 
> > (0) make sure that yres+upper+lower+vslen is odd
> > (1) set bit 25 (0x02000000) in register 0x3C10 (== enable interlace)
> > (2) program register 0x3C28 with start of even field (== leave current value)
> > (3) program register 0x3C2C with start of odd field (== 0x3C28+vxres*bpp/8)
> > (4) program register 0x3C40 with value twice as large as currently
> >     (== line offset)
> > 
> > and you'll see. I'm not sure whether step (4) is needed or not, documentation
> > is not clear on this.
> 
> First of all thanks. I won't be able to experiment on this for at
> least 1 week. But I would like your advice about how best to
> proceed. I mean, can these values be changed at will, or once at the
> loading of the module? Is it wise to just set the second screen to
> interlace at the beginning (possibly with a module parameter) or to
> switch to/from interlace with some sort of ioctl?

All changes should be limited to matroxfb_dh_restore() in
drivers/video/matrox/matroxfb_crtc2.c.

Before line ~133 apply (by hand):

+ if (mt->interlaced) tmp |= 0x02000000;
  mga_outl(0x3C10, tmp | 0x10000000);
  ...
  mga_outl(0x3C28, pos);
+ {
+   u_int32_t linelen = p->var.xres_virtual * (p->var.bits_per_pixel >> 3);
+   if (mt->interlaced) {
+     mga_outl(0x3C2C, pos + linelen);
+     linelen *= 2;
+   }
+   mga_outl(0x3C40, linelen);
+ }
- mga_outl(0x3C40, p->var.xres_virtual * (p->var.bits_per_pixel >> 3));

and unless I missed something somewhere, it should work.
                                                Petr Vandrovec
                                                van...@vc...
                                                

Re: [Linux-fbdev-devel] Fixed-frequency monitor, and G45 se

[Carlo E. P. <fl...@fl...>]

	Subject: Re: [Linux-fbdev-devel] Fixed-frequency monitor, and G45 se
	Date: Fri, Oct 26, 2001 at 12:52:13AM +0000

Quoting Petr Vandrovec (VAN...@vc...):

> Well, documentation says that it is possible, but I thought that nobody
> uses interlaced picture now... If you want to do some experiments, you
> can try:
> 
> (0) make sure that yres+upper+lower+vslen is odd
> (1) set bit 25 (0x02000000) in register 0x3C10 (== enable interlace)
> (2) program register 0x3C28 with start of even field (== leave current value)
> (3) program register 0x3C2C with start of odd field (== 0x3C28+vxres*bpp/8)
> (4) program register 0x3C40 with value twice as large as currently
>     (== line offset)
> 
> and you'll see. I'm not sure whether step (4) is needed or not, documentation
> is not clear on this.

First of all thanks. I won't be able to experiment on this for at
least 1 week. But I would like your advice about how best to
proceed. I mean, can these values be changed at will, or once at the
loading of the module? Is it wise to just set the second screen to
interlace at the beginning (possibly with a module parameter) or to
switch to/from interlace with some sort of ioctl?

> If you'll manage to create patch, please send it to me.

I will. 

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fl...@fl...             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

[Linux-fbdev-devel] colors

[<ste...@nt...>]

hi

i'm new to framebuffer development. i want to write a small library for 
my embedded system(MPC823L) with a lcd(SHARP LQ64D341). i use the 
framebufferdriver(lcd823.c) from the denx.de kernel tree.

my problem now is to get control over the colors. i use this to open the 
framebuffer:

int fbfd = 0;
long int screensize = 0;
unsigned char *fbp = 0;
struct fb_fix_screeninfo finfo;
struct fb_var_screeninfo vinfo;

...

fbfd = open("/dev/fb", O_RDWR);
if (ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo)) {
if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)) {
screensize = vinfo.xres * vinfo.yres * vinfo.bits_per_pixel / 8;
fbp = (unsigned char*)mmap(0, screensize, PROT_READ | PROT_WRITE,
				MAP_SHARED, fbfd, 0);


to set a pixel i use something like this:

setPixel(int x, int y, int color){
	long int location;
	location = (x+vinfo.xoffset) * (vinfo.bits_per_pixel/8) 					+ (y+vinfo.yoffset) * finfo.line_length;					*(fbp 
+ location) = color;
	}
}

but what is the structure of the var color(should the type be unsigned 
char?)? what is red, green and blue?
i know that the driver uses pseudocolor and 8bit per pixel.

thanks for helping

stefan

Re: [Linux-fbdev-devel] Fixed-frequency monitor, and G45 se

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

On 25 Oct 01 at 22:32, Carlo E. Prelz wrote:
>     fvs.yres=fvs.yres_virtual=576;
>     fvs.vmode=FB_VMODE_INTERLACED;
> 
> and I have a good image - exactly what I needed. 
> I have one problem, though... I would like to use both screens of a
> Matrox G450 with two independent framebuffers. Well, the first (main)
> screen is set correctly, but it seems that the second one does not
> accept to go interlaced. Is this something well-known? Am I forgetting
> something? 

Well, documentation says that it is possible, but I thought that nobody
uses interlaced picture now... If you want to do some experiments, you
can try:

(0) make sure that yres+upper+lower+vslen is odd
(1) set bit 25 (0x02000000) in register 0x3C10 (== enable interlace)
(2) program register 0x3C28 with start of even field (== leave current value)
(3) program register 0x3C2C with start of odd field (== 0x3C28+vxres*bpp/8)
(4) program register 0x3C40 with value twice as large as currently
    (== line offset)

and you'll see. I'm not sure whether step (4) is needed or not, documentation
is not clear on this.

If you'll manage to create patch, please send it to me.
                                                Best regards,
                                                    Petr Vandrovec
                                                    van...@vc...
                                                    

[Linux-fbdev-devel] Fixed-frequency monitor, and G45 second screen

[Carlo E. P. <fl...@fl...>]

Hi all. A few days ago, I asked for info regarding the configuration
to use for a TV-standard fixed-frequency monitor. Well,today at last I
got the monitor, and I verified that the numbers that we exchanged
work Ok. I eventually used C code to set the framebuffer. This is how
I set an instance of struct fb_var_screeninfo:

    fvs.xres=fvs.xres_virtual=736;
    fvs.yres=fvs.yres_virtual=576;
    fvs.xoffset=fvs.yoffset=0;
    fvs.bits_per_pixel=16;
    fvs.height=fvs.width=-1;
    fvs.accel_flags=0;
    fvs.pixclock=62500;
    fvs.left_margin=144;
    fvs.right_margin=64;
    fvs.upper_margin=34;
    fvs.lower_margin=10;
    fvs.hsync_len=80;
    fvs.vsync_len=5;
    fvs.vmode=FB_VMODE_INTERLACED;

and I have a good image - exactly what I needed. 
I have one problem, though... I would like to use both screens of a
Matrox G450 with two independent framebuffers. Well, the first (main)
screen is set correctly, but it seems that the second one does not
accept to go interlaced. Is this something well-known? Am I forgetting
something? 

Some help is (as usual) highly appreciated...

Carlo

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fl...@fl...             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

Re: [Linux-fbdev-devel] [announce] framebuffer twiki

[Paul M. <le...@Ch...>]

On Sun, Oct 21, 2001 at 01:01:01AM -0400, cw...@so... wrote:
> after the brief flurry of activity in regards to making hardware accelera=
tion=20
> standardized for /dev/fb, things seemed to have stopped (mailwise).
>=20
> to assist in advancing/standardizing development of this, we've set up a
> twiki (web-based collaborative discussion environment) for discussions of
> updating fb to standardize acceleration and other hardware access.  there
> isn't much there now, but we have plans, and i'm sure you all do too.
>=20
> we would really like to see this materialize.  The added functionality wo=
uld
> greatly enhance future applications and and standardized interface would =
make=20
> coding drivers for it relatively easy.

A lot of discussion about expermental things has been and is being done on =
the
linuxconsole-dev list. See http://lists.sf.net/lists/listinfo/linuxconsole-=
dev
for more information and archives.

Regards,

--=20
Paul Mundt <le...@ch...>

[Linux-fbdev-devel] fb twiki

[<cw...@so...>]

Hello again!

in my haste to announce this, I forgot to actually tell you where to find it :^/

so here's where it's at:
http://prj.softpixel.com/bin/view

sorry to leave that out *blush*

chris

[Linux-fbdev-devel] [announce] framebuffer twiki

[<cw...@so...>]

Hello all!

after the brief flurry of activity in regards to making hardware acceleration 
standardized for /dev/fb, things seemed to have stopped (mailwise).

to assist in advancing/standardizing development of this, we've set up a twiki 
(web-based collaborative discussion environment) for discussions of updating fb 
to standardize acceleration and other hardware access.  there isn't much there 
now, but we have plans, and i'm sure you all do too.

we would really like to see this materialize.  The added functionality would 
greatly enhance future applications and and standardized interface would make 
coding drivers for it relatively easy.

at the moment, the server hosting the twiki is very low powered, and chokes 
under the stress of twiki, but we will be upgrading the server in the next few 
weeks.

hope to see y'all there :^)

chris

[Linux-fbdev-devel] Re: ATI Technologies Inc 3D Rage P/M Mobility AGP 2x (rev 64)

[Frank N. <fra...@gm...>]

On 17 Oct 2001, Bruno Clermont wrote:

Many thanks Bruno,
a bad information is better then nothing.
I will check out the XFree86 framebuffer driver.

Frank

> I switched to a SVGA framebuffer and used XFree86 framebuffer driver...
> Slow as hell, but better than nothing, especialy for non-gaming use.
> 
> I tried a vanilla 2.4.9 couple of months later, hoping to see a
> difference. It still fade to black and need a reboot.
> 
> I finally stop using the laptop and didn't tried until then.
> 
> On Wed, 2001-10-17 at 09:05, Frank Neuber wrote:
>     Hi Bruno and all fbdev gurus,
>     I have exactly the same problem with my COMPAQ Presario laptop.
>     After loading the module "atyfb" the screen go black and only display some
>     colored pixels at the bottom line :-(.
>     The X-Display is then also broken ...
>     I did my tests wit the 2.4.9 kernel. The patch atyfb-new-20010117.diff
>     don't work with 2.4.9 kernel. I think the patch is present in this
>     kernel  version.
>     
>     lspci:
>     01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M
>     Mobility AGP 2x (rev 64)
>     
>     lspci -nvvv
>     
>     01:00.0 Class 0300: 1002:4c4d (rev 64)
>     	Subsystem: 0e11:b11b
>     	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>     ParErr- Stepping+ SERR- FastB2B-
>     	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
>     <TAbort- <MAbort- >SERR- <PERR-
>     	Latency: 66 (2000ns min), cache line size 08
>     	Interrupt: pin A routed to IRQ 5
>     	Region 0: Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
>     	Region 1: I/O ports at 9000 [size=256]
>     	Region 2: Memory at f4200000 (32-bit, non-prefetchable) [size=4K]
>     	Expansion ROM at <unassigned> [disabled] [size=128K]
>     	Capabilities: [50] AGP version 1.0
>     		Status: RQ=255 SBA+ 64bit- FW- Rate=x1,x2
>     		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
>     	Capabilities: [5c] Power Management version 1
>     		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
>     PME(D0-,D1-,D2-,D3hot-,D3cold-)
>     		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>     
>     Did you solve your fbdev problem?
>     At last I have the same questions:
>     	is it a know problem by you?
>     	if not, are you interested to fix it?
>     	if yes, how can i be usefull?

[Linux-fbdev-devel] Re: ATI Technologies Inc 3D Rage P/M Mobility AGP 2x (rev 64)

[Bruno C. <po...@gn...>]

I switched to a SVGA framebuffer and used XFree86 framebuffer driver...
Slow as hell, but better than nothing, especialy for non-gaming use.

I tried a vanilla 2.4.9 couple of months later, hoping to see a
difference. It still fade to black and need a reboot.

I finally stop using the laptop and didn't tried until then.

On Wed, 2001-10-17 at 09:05, Frank Neuber wrote:
    Hi Bruno and all fbdev gurus,
    I have exactly the same problem with my COMPAQ Presario laptop.
    After loading the module "atyfb" the screen go black and only display some
    colored pixels at the bottom line :-(.
    The X-Display is then also broken ...
    I did my tests wit the 2.4.9 kernel. The patch atyfb-new-20010117.diff
    don't work with 2.4.9 kernel. I think the patch is present in this
    kernel  version.
    
    lspci:
    01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M
    Mobility AGP 2x (rev 64)
    
    lspci -nvvv
    
    01:00.0 Class 0300: 1002:4c4d (rev 64)
    	Subsystem: 0e11:b11b
    	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
    ParErr- Stepping+ SERR- FastB2B-
    	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
    <TAbort- <MAbort- >SERR- <PERR-
    	Latency: 66 (2000ns min), cache line size 08
    	Interrupt: pin A routed to IRQ 5
    	Region 0: Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
    	Region 1: I/O ports at 9000 [size=256]
    	Region 2: Memory at f4200000 (32-bit, non-prefetchable) [size=4K]
    	Expansion ROM at <unassigned> [disabled] [size=128K]
    	Capabilities: [50] AGP version 1.0
    		Status: RQ=255 SBA+ 64bit- FW- Rate=x1,x2
    		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
    	Capabilities: [5c] Power Management version 1
    		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
    PME(D0-,D1-,D2-,D3hot-,D3cold-)
    		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
    
    Did you solve your fbdev problem?
    At last I have the same questions:
    	is it a know problem by you?
    	if not, are you interested to fix it?
    	if yes, how can i be usefull?
    
    Best regards 
    Frank
    
    -- 
         _/_/_/_/ _//   _/ Frank Neuber
        _/       _/_/  _/  fra...@gm... (private)
       _/_/_/   _/ _/ _/
      _/       _/  _/_/    ne...@op...
     _/       _/    // http://www.opensource-systemberatung.de
    
    
    

[Linux-fbdev-devel] ATI Technologies Inc 3D Rage P/M Mobility AGP 2x (rev 64)

[Frank N. <fra...@gm...>]

Hi Bruno and all fbdev gurus,
I have exactly the same problem with my COMPAQ Presario laptop.
After loading the module "atyfb" the screen go black and only display some
colored pixels at the bottom line :-(.
The X-Display is then also broken ...
I did my tests wit the 2.4.9 kernel. The patch atyfb-new-20010117.diff
don't work with 2.4.9 kernel. I think the patch is present in this
kernel  version.

lspci:
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M
Mobility AGP 2x (rev 64)

lspci -nvvv

01:00.0 Class 0300: 1002:4c4d (rev 64)
	Subsystem: 0e11:b11b
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 66 (2000ns min), cache line size 08
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: I/O ports at 9000 [size=256]
	Region 2: Memory at f4200000 (32-bit, non-prefetchable) [size=4K]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	Capabilities: [50] AGP version 1.0
		Status: RQ=255 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
	Capabilities: [5c] Power Management version 1
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Did you solve your fbdev problem?
At last I have the same questions:
	is it a know problem by you?
	if not, are you interested to fix it?
	if yes, how can i be usefull?

Best regards 
Frank

-- 
     _/_/_/_/ _//   _/ Frank Neuber
    _/       _/_/  _/  fra...@gm... (private)
   _/_/_/   _/ _/ _/
  _/       _/  _/_/    ne...@op...
 _/       _/    // http://www.opensource-systemberatung.de

Re: [Linux-fbdev-devel] Memory allocation in FB

[M. R. B. <mr...@0x...>]

* so...@ma... <so...@ma...> on Tue, Oct 16, 2001:

>=20
> Is something like this already in place? If not, what do you think about
> the idea? Any implementations already existing?
>=20

Like your video question, this is a 2.5 issue, so you probably want to hang
around linuxconsole-dev for more info.

M. R.

[Linux-fbdev-devel] Memory allocation in FB

[<so...@ma...>]

Hi All,
    This relates to my earlier question about video overlay on the
framebuffer. In many cases, it might not be possible for the video and
graphics drivers to be the same, but they still have to use the same
display memory. Since the framebuffer driver is brought up right in the
beginning, I feel it would make sense for it to have some kind of memory
manager. Other drivers/application which require frame-buffer memory must
ask it for a block of memory. This will ensure that different drivers
don't acidentaly use the same memory region in the frame-buffer. 

Is something like this already in place? If not, what do you think about
the idea? Any implementations already existing?

Thanks and regards
Sojan.

Re: [Linux-fbdev-devel] Framebuffer and Video

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

so...@ma... wrote:

>       This looks good. I would like to suggest an alpha blend
> feature. This might be a hardware specific, but the geode processors
> support three alpha blend windows which can be anywhere within the video
> window. I haven't given a thought to how this can be
> added/implemented. Any ideas?

Well, if you use FB_VIDOVERLAY_CAPABILITY_ALPHAKEY and
FB_VIDOVERLAY_CAPABILITY_BLEND the hardware can do
alpha blending. Anything more sophisticated is probably
hardware-specific / application-specific...

> How long is this going to be a draft? Are there any issues
> in using it before it has been approved?

It's extremely unlikely to be integrated before Ruby itself
get integrated. And even when Ruby will be, it's not sure
that adding video overlay support to the FB device will
be approved by 'those in charge'. And we will need
driver support... But if enough people show interest odds
are better :-)

Issue is, if the interface change, you will need to change
your code :-)

-- 
DOLBEAU Romain               |  Energy derives from both                  
ENS Cachan / Ker Lann        |    the plus and negative                   
Thesard IRISA / CAPS         |       -- Metallica,                        
dol...@cl...    |           'Eye of the Beholder'

Re: [Linux-fbdev-devel] Framebuffer and Video

[<so...@ma...>]

Hi,
      This looks good. I would like to suggest an alpha blend
feature. This might be a hardware specific, but the geode processors
support three alpha blend windows which can be anywhere within the video
window. I haven't given a thought to how this can be
added/implemented. Any ideas?

How long is this going to be a draft? Are there any issues in using it
before it has been approved?

Thanks and regards
Sojan.


 On Fri, 12 Oct 2001, Romain Dolbeau wrote:

> so...@ma... wrote:
> 
> > Is anyone working on a "Video extension" for the frame-buffer?
> 
> I've made a draft proposal that's available as linux/include/fbvid.h
> in the linux-console project (aka 'Ruby'). You can check
> at <http://sourceforge.net/projects/linuxconsole/>
> 
> Any comments welcome.
> 

Re: [Xpert]Re: [Linux-fbdev-devel] ATI Rage Mobility external monitor problem.

[Marc A. La F. <ts...@ua...>]

On Fri, 12 Oct 2001, Branden Robinson wrote:

> On Fri, Oct 12, 2001 at 06:09:49AM -0600, Marc Aurele La France wrote:
> > On Fri, 12 Oct 2001, Geert Uytterhoeven wrote:
> > > XFree86 expects a chip configured to VGA text mode, unless you specify an
> > > `fbdev' option (IIRC).

> > That's not so.  First, there is no 'fbdev' option of any kind.  Second,
> > XFree86's ATI driver assumes all aspects of the mode on entry are
> > correctly programmed, whether or not it's a VGA text mode.

> Perhaps he means:

> Section "Device"
> 	Identifier "Generic Video Card"
> 	Driver "ati"
> 	Option "UseFBDev" "true"
> EndSection

> ...which certainly does exist.

We are talking about the Mobility M1, a Mach64 variant.  My comment above
stays.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Computing and Network Services  |  fax:    1-780-492-1729           |
|  352 General Services Building   |  email:  ts...@ua...          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 Core Team member.  ATI driver and X server internals.

Re: [Xpert]Re: [Linux-fbdev-devel] ATI Rage Mobility external monitor problem.

[Branden R. <br...@de...>]

On Fri, Oct 12, 2001 at 06:09:49AM -0600, Marc Aurele La France wrote:
> On Fri, 12 Oct 2001, Geert Uytterhoeven wrote:
> > XFree86 expects a chip configured to VGA text mode, unless you specify =
an
> > `fbdev' option (IIRC).
>=20
> That's not so.  First, there is no 'fbdev' option of any kind.  Second,
> XFree86's ATI driver assumes all aspects of the mode on entry are
> correctly programmed, whether or not it's a VGA text mode.

Perhaps he means:

Section "Device"
	Identifier "Generic Video Card"
	Driver "ati"
	Option "UseFBDev" "true"
EndSection

=2E..which certainly does exist.

--=20
G. Branden Robinson                |     If God had intended for man to go
Debian GNU/Linux                   |     about naked, we would have been
br...@de...                 |     born that way.
http://people.debian.org/~branden/ |

[Linux-fbdev-devel] Re: [Xpert]ATI Rage Mobility external monitor problem.

[Stelian P. <ste...@fr...>]

On Fri, Oct 12, 2001 at 06:06:28AM -0600, Marc Aurele La France wrote:

> > When the framebuffer code is compiled into the kernel, external
> > monitor picture is blurred. Since is rather hard to explain,
> > here is a picture of the monitor taken with an digital camera:
> > 	http://spop.free.fr/xfree/xfree-monitor.jpg
> 
> > If the framebuffer code is _not_ compiled into the kernel,
> > external monitor works fine (note that this was not the case with
> > XFree 4.1.0, only the CVS version contains the fixes to make it
> > happen).
> 
> > I've also noted that even without launching X, when using the
> > framebuffer, the external display picture is blurred too. However,
> > in text mode this is hardly noticable.
> 
> It sounds to me that atyfb isn't dealing with shadow registers properly.

Marcel, as the original developer of the Vaio specific part of the
code, do you have an idea on what needs to be done ?

I would gladly test any kernel framebuffer patch any time, 
however I'm not good enough in fb / video code to search by
myself the problem.

Thanks,

Stelian.
-- 
Stelian Pop <ste...@fr...>
|---------------- Free Software Engineer -----------------|
| Alcôve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alcôve, liberating software ---------------|

[Linux-fbdev-devel] Re: [Xpert]ATI Rage Mobility external monitor problem.

[Stelian P. <ste...@fr...>]

On Fri, Oct 12, 2001 at 06:06:28AM -0600, Marc Aurele La France wrote:

> > When the framebuffer code is compiled into the kernel, external
> > monitor picture is blurred. Since is rather hard to explain,
> > here is a picture of the monitor taken with an digital camera:
> > 	http://spop.free.fr/xfree/xfree-monitor.jpg
> 
> > If the framebuffer code is _not_ compiled into the kernel,
> > external monitor works fine (note that this was not the case with
> > XFree 4.1.0, only the CVS version contains the fixes to make it
> > happen).
> 
> It sounds to me that atyfb isn't dealing with shadow registers properly.

Ok, it seems clear enough that this is 100% related to the 
framebuffer code, nothing to do with X.

Let's take the discussion out of the X mailing list.

Stelian.
-- 
Stelian Pop <ste...@fr...>
|---------------- Free Software Engineer -----------------|
| Alcôve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alcôve, liberating software ---------------|

Re: [Linux-fbdev-devel] ATI Rage Mobility external monitor problem.

[Stelian P. <ste...@fr...>]

On Fri, Oct 12, 2001 at 01:22:52PM +0200, Geert Uytterhoeven wrote:

> > A somewhat related question for linux framebuffer guys: is it
> > possible to disable the framebuffer on boot (without having to
> > compile two kernels, a framebuffer based one and one without) 
> > with some parameter ? I tried leaving out the vga=0x301 
> > parameter, or put a vga= something else (80x25 text mode) etc,
> > but the framebuffer code seems to initialize itself whatever
> > option I put on the kernel boot line.
> 
> video=atyfb:off

Thanks, it worked. No need for double kernel compiled now :-)

Stelian.
-- 
Stelian Pop <ste...@fr...>
|---------------- Free Software Engineer -----------------|
| Alcôve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alcôve, liberating software ---------------|