Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Benjamin Herrenschmidt]

> Hey ben - shouldn't radeonfb_set_par() have been called when we switched 
> out of X?  If that's not getting done, that explains the interlacing in 
> the other reports too -- the accel engine only gets reset if set_par() is 
> called to knock the video card back into console mode...

No, it's not. I posted a patch fixing that. Enclosed again below.

(Doesn't yet switch the case where a single console switches from
KD_GRAPHICS back to KD_TEXT but handle the case of switching from
a KD_GRAPHICS VT to a KD_TEXT VT).

> ps - hey ben, do we need both noaccel and radeonfb_noaccel? 
>       i don't get it...

The "non-static" value is radeonfb_noaccel (to avoid clashing
with other drivers exposing a "noaccel" variable). The module
param is "noaccel", I don't want to change it. Taht all sucks,
I know, I'll see if I can come up with a better solution.

Ben.

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/02/16 09:02:33+11:00 benh@kernel.crashing.org 
#   fbcon resets engine on gfx -> text  switch
# 
# include/linux/fb.h
#   2004/02/16 09:02:20+11:00 benh@kernel.crashing.org +1 -0
#   fbcon resets engine on gfx -> text  switch
# 
# drivers/video/riva/fbdev.c
#   2004/02/16 09:02:19+11:00 benh@kernel.crashing.org +2 -1
#   fbcon resets engine on gfx -> text  switch
# 
# drivers/video/fbmem.c
#   2004/02/16 09:02:19+11:00 benh@kernel.crashing.org +2 -1
#   fbcon resets engine on gfx -> text  switch
# 
# drivers/video/console/fbcon.c
#   2004/02/16 09:02:19+11:00 benh@kernel.crashing.org +23 -6
#   fbcon resets engine on gfx -> text  switch
# 
diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
--- a/drivers/video/console/fbcon.c	Mon Feb 16 09:03:33 2004
+++ b/drivers/video/console/fbcon.c	Mon Feb 16 09:03:33 2004
@@ -1598,8 +1598,8 @@
 			height, width);
 }
 
-static int fbcon_resize(struct vc_data *vc, unsigned int width, 
-			unsigned int height)
+static int fbcon_do_resize(struct vc_data *vc, unsigned int width, 
+			   unsigned int height, int force)
 {
 	struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
 	struct display *p = &fb_display[vc->vc_num];
@@ -1607,13 +1607,14 @@
 	int err; int x_diff, y_diff;
 	int fw = vc->vc_font.width;
 	int fh = vc->vc_font.height;
+	int rc = 0;
 
 	var.xres = width * fw;
 	var.yres = height * fh;
 	x_diff = info->var.xres - var.xres;
 	y_diff = info->var.yres - var.yres;
 	if (x_diff < 0 || x_diff > fw ||
-	   (y_diff < 0 || y_diff > fh)) {
+	    y_diff < 0 || y_diff > fh || force) {
 		var.activate = FB_ACTIVATE_TEST;
 		err = fb_set_var(info, &var);
 		if (err || width > var.xres/fw ||
@@ -1621,18 +1622,28 @@
 			return -EINVAL;
 		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
 		var.activate = FB_ACTIVATE_NOW;
-		fb_set_var(info, &var);
+		if (force)
+			var.activate |= FB_ACTIVATE_FORCE;
+		if (fb_set_var(info, &var) == 0)
+			rc = 1;
 	}
 	p->vrows = var.yres_virtual/fh;
 	if (var.yres > (fh * (height + 1)))
 		p->vrows -= (var.yres - (fh * height)) / fh;
-	return 0;
+	return rc;
+}
+
+static int fbcon_resize(struct vc_data *vc, unsigned int width, 
+			unsigned int height)
+{
+	return fbcon_do_resize(vc, width, height, 0);
 }
 
 static int fbcon_switch(struct vc_data *vc)
 {
 	struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
 	struct display *p = &fb_display[vc->vc_num];
+	int gfx_to_text = 0;
 
 	if (softback_top) {
 		int l = fbcon_softback_size / vc->vc_size_row;
@@ -1659,7 +1670,13 @@
 	}
 	if (info)
 		info->var.yoffset = p->yscroll = 0;
-        fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
+
+	if (info->currcon == -1 ||
+	    (vt_cons[info->currcon]->vc_mode != KD_TEXT &&
+	     vt_cons[vc->vc_num]->vc_mode == KD_TEXT))
+		gfx_to_text = 1;
+
+        fbcon_do_resize(vc, vc->vc_cols, vc->vc_rows, gfx_to_text);
 	switch (p->scrollmode & __SCROLL_YMASK) {
 	case __SCROLL_YWRAP:
 		scrollback_phys_max = p->vrows - vc->vc_rows;
diff -Nru a/drivers/video/fbmem.c b/drivers/video/fbmem.c
--- a/drivers/video/fbmem.c	Mon Feb 16 09:03:33 2004
+++ b/drivers/video/fbmem.c	Mon Feb 16 09:03:33 2004
@@ -938,7 +938,8 @@
 {
 	int err;
 
-	if (memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
+	if ((var->activate & FB_ACTIVATE_FORCE) ||
+	    memcmp(&info->var, var, sizeof(struct fb_var_screeninfo))) {
 		if (!info->fbops->fb_check_var) {
 			*var = info->var;
 			return 0;
diff -Nru a/drivers/video/riva/fbdev.c b/drivers/video/riva/fbdev.c
--- a/drivers/video/riva/fbdev.c	Mon Feb 16 09:03:33 2004
+++ b/drivers/video/riva/fbdev.c	Mon Feb 16 09:03:33 2004
@@ -1615,8 +1615,9 @@
 }
 
 #ifdef CONFIG_PPC_OF
-static int riva_get_EDID_OF(struct riva_par *par, struct pci_dev *pd)
+static int riva_get_EDID_OF(struct fb_info *info, struct pci_dev *pd)
 {
+	struct riva_par *par = (struct riva_par *) info->par;
 	struct device_node *dp;
 	unsigned char *pedid = NULL;
 
diff -Nru a/include/linux/fb.h b/include/linux/fb.h
--- a/include/linux/fb.h	Mon Feb 16 09:03:33 2004
+++ b/include/linux/fb.h	Mon Feb 16 09:03:33 2004
@@ -152,6 +152,7 @@
 #define FB_ACTIVATE_VBL	       16	/* activate values on next vbl  */
 #define FB_CHANGE_CMAP_VBL     32	/* change colormap on vbl	*/
 #define FB_ACTIVATE_ALL	       64	/* change all VCs on this fb	*/
+#define FB_ACTIVATE_FORCE     128	/* force apply even when no change*/
 
 #define FB_ACCELF_TEXT		1	/* text mode acceleration */
 

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Linus Torvalds]

On Mon, 16 Feb 2004, Benjamin Herrenschmidt wrote:
> 
> No, it's not. I posted a patch fixing that. Enclosed again below.

I don't think this is right.

It gets the same-tty case wrong, and the reason it gets it wrong is that 
it does its thing in entirely the wrong place.

The console layer already always calls "unblank_screen()" on any switch to
text mode, _regardless_ of whether it was switching from another console
or not. That should be the place where this is done, and perhaps by
changing the console layer to be a bit more helpful about things (mainly
re-name the damn thing, since it has nothing to do with "unblank" any
more).

"unblank_screen()" is really the same as "reset_screen" - it's also called
on resume. While "do_blank_screen()" is basically "go away".

So why don't you just reset the thing in "con_blank()" that gets called in 
all the right cases?

		Linus

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Benjamin Herrenschmidt]

On Tue, 2004-02-17 at 04:56, Linus Torvalds wrote:

> The console layer already always calls "unblank_screen()" on any switch to
> text mode, _regardless_ of whether it was switching from another console
> or not. That should be the place where this is done, and perhaps by
> changing the console layer to be a bit more helpful about things (mainly
> re-name the damn thing, since it has nothing to do with "unblank" any
> more).
> 
> "unblank_screen()" is really the same as "reset_screen" - it's also called
> on resume. While "do_blank_screen()" is basically "go away".

That's interesting... I didn't want to do a full mode + engine restore
in unblank_screen though as this can be called from interrupt time by
printk... But then, with the LVDS blanking, I already have to delay
up to 1 second in this function, so .... I think I'll have to find a
way to abstract a delay function that schedules in normal case _but_
when called from printk....

> So why don't you just reset the thing in "con_blank()" that gets called in 
> all the right cases?

Do we want to pay the cost (in time) of a full mode set + engine reset
on each unblank ? I could limit myself to restoring the accel engine,
that faster, but with X also not always restoring the console mode
properly, I'd have preferred re-setting the whole mode... 

Maybe we should go that way for now (engine only in unblank), then try
to fix X for the mode thing (if doable.... there is some VGA magic in
there that I don't understand)

Ben.

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Linus Torvalds]

On Tue, 17 Feb 2004, Benjamin Herrenschmidt wrote:
> 
> Do we want to pay the cost (in time) of a full mode set + engine reset
> on each unblank ? I could limit myself to restoring the accel engine,
> that faster, but with X also not always restoring the console mode
> properly, I'd have preferred re-setting the whole mode... 

Well, on blanking, we do actually already pass in a parameter that says
"this is not a full blank, it's just a move to graphics mode". It would
make 100% sense to add the _same_ parameter to the unblank code.

That would just make the code more logical, and it should fix your 
concerns, no?

		Linus

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Benjamin Herrenschmidt]

On Tue, 2004-02-17 at 09:13, Linus Torvalds wrote:
> On Tue, 17 Feb 2004, Benjamin Herrenschmidt wrote:
> > 
> > Do we want to pay the cost (in time) of a full mode set + engine reset
> > on each unblank ? I could limit myself to restoring the accel engine,
> > that faster, but with X also not always restoring the console mode
> > properly, I'd have preferred re-setting the whole mode... 
> 
> Well, on blanking, we do actually already pass in a parameter that says
> "this is not a full blank, it's just a move to graphics mode". It would
> make 100% sense to add the _same_ parameter to the unblank code.
> 
> That would just make the code more logical, and it should fix your 
> concerns, no?

Yes, I was looking into this at the moment. Who else but fbcon and
vgacon will need fixing ? I suppose all the xxxxcon in
drivers/video/console, do you "see" any other ?

Ben.

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Linus Torvalds]

On Tue, 17 Feb 2004, Benjamin Herrenschmidt wrote:
> > 
> > That would just make the code more logical, and it should fix your 
> > concerns, no?
> 
> Yes, I was looking into this at the moment. Who else but fbcon and
> vgacon will need fixing ? I suppose all the xxxxcon in
> drivers/video/console, do you "see" any other ?

I don't see that anybody else can possibly care. In fact, I doubt even 
vgacon actually cares. It's just a regular unblank, but with the 
information that we came from graphics mode. I think it would be cleaner 
to add a new parameter to the "con_blank()" function, which would also 
cause compiler warnings for non-converted consoles, which is good.

Right now we encode multiple things into the one existing "blank"
parameter, which is just confusing. We have

   -1: /* enter graphics mode (just save whatever state we need to save, 
          possibly clear state to be polite) */
    0: /* regular unblank (restore screen contents, enable backlight) */
    1: /* regular blank */
    2..x: VESA blank type x-1.

and I'd suggest that the new case would be the "regular unblank", but with 
the new parameter saying that we're coming from graphics mode. For 
example, I don't think the vgacon_blank() function would change at _all_ 
(except for the new parameter that it would just ignore).

As far as I can tell, fbcon is the _only_ thing that wouldn't ignore the 
new information, exactly because fbcon might want to reset things like the 
graphics engine.

		Linus

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Benjamin Herrenschmidt]

> I don't see that anybody else can possibly care. In fact, I doubt even 
> vgacon actually cares. It's just a regular unblank, but with the 
> information that we came from graphics mode. I think it would be cleaner 
> to add a new parameter to the "con_blank()" function, which would also 
> cause compiler warnings for non-converted consoles, which is good.
> 
That's what I was talking about: what drivers should I convert :) On
PPC, I don't build things like vgacon etc... Anyway, patch coming soon.

Note that a mode_switch separate from blank would have made sense
too some way...

> Right now we encode multiple things into the one existing "blank"
> parameter, which is just confusing. We have
> 
>    -1: /* enter graphics mode (just save whatever state we need to save, 
>           possibly clear state to be polite) */

And make sure accel engine is idle...

>     0: /* regular unblank (restore screen contents, enable backlight) */
>     1: /* regular blank */
>     2..x: VESA blank type x-1.
> 
> and I'd suggest that the new case would be the "regular unblank", but with 
> the new parameter saying that we're coming from graphics mode. For 
> example, I don't think the vgacon_blank() function would change at _all_ 
> (except for the new parameter that it would just ignore).
>
> As far as I can tell, fbcon is the _only_ thing that wouldn't ignore the 
> new information, exactly because fbcon might want to reset things like the 
> graphics engine.

Yup.

Ben.

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Linus Torvalds]

On Tue, 17 Feb 2004, Benjamin Herrenschmidt wrote:
> 
> That's what I was talking about: what drivers should I convert :) On
> PPC, I don't build things like vgacon etc... Anyway, patch coming soon.

I'd suggest converting all the ones you can find - on the assumption that 
adding the extra argument (and ignoring it) is the always the right thing 
to do. 

So the "conversion" would be to just change the function declaration, and 
none of the code. Except for fbdev (and even there that conversion would 
be "correct" - it just wouldn't take advantage of the new information).

> Note that a mode_switch separate from blank would have made sense
> too some way...

Yes. I agree. The naming is crap. We're not blanking, we're changing 
state.

But it's not a mode switch either - _sometimes_ it's a mode switch, but 
sometimes the state change is that we're switching to another backing 
store (ie a VC switch) but with the same mode.

So _logically_ the interface should be more of a "con_notify_change()"  
one, with a bitmap of which states have changed (where "graphics vs text"
is just one set of states - resultion is another, VC backing store is one,
etc etc).

(I call it "notify_change()", because we have exactly that in VFS terms,
where the inode change descriptor has an attribute table and a "valid"  
bitmap).

		Linus

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Benjamin Herrenschmidt]

> Yes. I agree. The naming is crap. We're not blanking, we're changing 
> state.
> 
> But it's not a mode switch either - _sometimes_ it's a mode switch, but 
> sometimes the state change is that we're switching to another backing 
> store (ie a VC switch) but with the same mode.
> 
> So _logically_ the interface should be more of a "con_notify_change()"  
> one, with a bitmap of which states have changed (where "graphics vs text"
> is just one set of states - resultion is another, VC backing store is one,
> etc etc).
> 
> (I call it "notify_change()", because we have exactly that in VFS terms,
> where the inode change descriptor has an attribute table and a "valid"  
> bitmap).

Ok, if it's ok to delay it to 2.6.4, i'd prefer going all the way trough
calling it properly and passing the proper "state" flags instead of
hacking more on broken blank/unblank semantics. It can stay in -mm for
a while if we want enough testing.

Ben.

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Linus Torvalds]

On Tue, 17 Feb 2004, Benjamin Herrenschmidt wrote:
> > 
> > So _logically_ the interface should be more of a "con_notify_change()"  
> > one, with a bitmap of which states have changed (where "graphics vs text"
> > is just one set of states - resultion is another, VC backing store is one,
> > etc etc).
>
> Ok, if it's ok to delay it to 2.6.4, i'd prefer going all the way trough
> calling it properly and passing the proper "state" flags instead of
> hacking more on broken blank/unblank semantics. It can stay in -mm for
> a while if we want enough testing.

Oh, there is no hurry with this. In fact, I'd rather take it slow than try 
to make any big changes to something that _largely_ works but has problems 
in some special cases.

In fact, I'd be happiest if the first step would be to just rename the
interface and change the argument infrastructure, but actually keep all
the behaviour "obviously the same". Bugs and all, if it comes to that. So
I'd rather take several small steps (and let people use it for a while in
between) than try to do everything. And yes, 2.6.3 is not even a target.

			Linus

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Benjamin Herrenschmidt]

> Oh, there is no hurry with this. In fact, I'd rather take it slow than try 
> to make any big changes to something that _largely_ works but has problems 
> in some special cases.
> 
> In fact, I'd be happiest if the first step would be to just rename the
> interface and change the argument infrastructure, but actually keep all
> the behaviour "obviously the same". Bugs and all, if it comes to that. So
> I'd rather take several small steps (and let people use it for a while in
> between) than try to do everything. And yes, 2.6.3 is not even a target.

That's fine with me. 

Ben.

[PATCH] Remove debug cruft from via-pmu.c driver

[Benjamin Herrenschmidt]

===== drivers/macintosh/via-pmu.c 1.29 vs edited =====
--- 1.29/drivers/macintosh/via-pmu.c	Sun Feb 15 04:11:03 2004
+++ edited/drivers/macintosh/via-pmu.c	Sun Feb 15 17:14:06 2004
@@ -72,13 +72,6 @@
 /* How many iterations between battery polls */
 #define BATTERY_POLLING_COUNT	2
 
-/* Some debugging tools */
-#ifdef CONFIG_XMON
-//#define LIVE_DEBUG(req) ((req) && (req)->data[0] == 0x7d)
-#define LIVE_DEBUG(req) (0)
-static int whacky_debug;
-#endif /* CONFIG_XMON */
-
 static volatile unsigned char *via;
 
 /* VIA registers - spaced 0x200 bytes apart */
@@ -1218,12 +1211,6 @@
 	wait_for_ack();
 	/* set the shift register to shift out and send a byte */
 	send_byte(req->data[0]);
-#ifdef CONFIG_XMON
-	if (LIVE_DEBUG(req))
-		xmon_printf("R");
-	else
-		whacky_debug = 0;
-#endif /* CONFIG_XMON */
 }
 
 void __openfirmware
@@ -1476,29 +1463,17 @@
 	case sending:
 		req = current_req;
 		if (data_len < 0) {
-#ifdef CONFIG_XMON
-			if (LIVE_DEBUG(req))
-				xmon_printf("s");
-#endif /* CONFIG_XMON */
 			data_len = req->nbytes - 1;
 			send_byte(data_len);
 			break;
 		}
 		if (data_index <= data_len) {
-#ifdef CONFIG_XMON
-			if (LIVE_DEBUG(req))
-				xmon_printf("S");
-#endif /* CONFIG_XMON */
 			send_byte(req->data[data_index++]);
 			break;
 		}
 		req->sent = 1;
 		data_len = pmu_data_len[req->data[0]][1];
 		if (data_len == 0) {
-#ifdef CONFIG_XMON
-			if (LIVE_DEBUG(req))
-				xmon_printf("D");
-#endif /* CONFIG_XMON */
 			pmu_state = idle;
 			current_req = req->next;
 			if (req->reply_expected)
@@ -1506,10 +1481,6 @@
 			else
 				return req;
 		} else {
-#ifdef CONFIG_XMON
-			if (LIVE_DEBUG(req))
-				xmon_printf("-");
-#endif /* CONFIG_XMON */
 			pmu_state = reading;
 			data_index = 0;
 			reply_ptr = req->reply + req->reply_len;
@@ -1532,18 +1503,10 @@
 	case reading:
 	case reading_intr:
 		if (data_len == -1) {
-#ifdef CONFIG_XMON
-			if (LIVE_DEBUG(current_req))
-				xmon_printf("r");
-#endif /* CONFIG_XMON */
 			data_len = bite;
 			if (bite > 32)
 				printk(KERN_ERR "PMU: bad reply len %d\n", bite);
 		} else if (data_index < 32) {
-#ifdef CONFIG_XMON
-			if (LIVE_DEBUG(current_req))
-				xmon_printf("R");
-#endif /* CONFIG_XMON */
 			reply_ptr[data_index++] = bite;
 		}
 		if (data_index < data_len) {
@@ -1551,12 +1514,6 @@
 			break;
 		}
 
-#ifdef CONFIG_XMON
-		if (LIVE_DEBUG(current_req)) {
-			whacky_debug = 1;
-		       	xmon_printf("D");
-		}
-#endif /* CONFIG_XMON */
 		if (pmu_state == reading_intr) {
 			pmu_state = idle;
 			int_data_state[int_data_last] = int_data_ready;
@@ -1603,10 +1560,6 @@
 		intr = in_8(&via[IFR]) & (SR_INT | CB1_INT);
 		if (intr == 0)
 			break;
-#ifdef CONFIG_XMON
-		if (whacky_debug)
-			xmon_printf("|%02x|", intr);
-#endif /* CONFIG_XMON */
 		handled = 1;
 		if (++nloop > 1000) {
 			printk(KERN_DEBUG "PMU: stuck in intr loop, "
@@ -1629,10 +1582,6 @@
 recheck:
 	if (pmu_state == idle) {
 		if (adb_int_pending) {
-#ifdef CONFIG_XMON
-			if (whacky_debug)
-				xmon_printf("!A!");
-#endif /* CONFIG_XMON */
 			if (int_data_state[0] == int_data_empty)
 				int_data_last = 0;
 			else if (int_data_state[1] == int_data_empty)

2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Mike Houston]

Hello

The new radeonfb driver appears to work nicely (except a bit of corruption when it first switches, but it's always done that for me in 2.6), until I start and exit XFree86. I then have display corruption. Text is scrambled and appearing where it's not supposed to be. If I type clear, the display becomes unusable. The text appears with lines through it, and I'm then typing blindly. I can still type commands though.

I then recompiled my kernel to use the old radeonfb driver, but it doesn't seem to work at all. The system won't switch to framebuffer mode during boot, with append = "video=radeonfb:1024x768-8@76".

So I recompiled again with the new driver, as I must have a framebuffer console.

This is a pentium4 system, on an i845 chipset with an ATI Radeon 7500 AGP card. I'm not sure if these are needed, so I've put my config and dmesg output up on my personal web space instead of pasting in this email.

http://www.bitbenderforums.com/~grogan/files/config-2.6.3-rc3.txt
http://www.bitbenderforums.com/~grogan/files/dmesg-2.6.3-rc3.txt

Thanks,
Mike Houston (a.k.a. Grogan)

Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver

[Petr Vandrovec]

On Sun, Feb 15, 2004 at 01:02:14PM -0500, Mike Houston wrote:
> Hello
> 
> The new radeonfb driver appears to work nicely (except a bit of corruption when it first switches, but it's always done that for me in 2.6), until I start and exit XFree86. I then have display corruption. Text is scrambled and appearing where it's not supposed to be. If I type clear, the display becomes unusable. The text appears with lines through it, and I'm then typing blindly. I can still type commands though.

I'm not sure whether it is radeonfb or XFree driver bug. On my system after
I switch from X to console, all "clear rectangle" requests are wrong, like if
line length in hardware was stil 1664*4 (what X do) instead of 1600*1 (what
console wants).

Second problem is that XFree driver (from 4.2.1.1 in Debian unstable) does not
like usefbdev on. It uses fbdev, but somehow it thinks that line length is 1664*4
although fbdev reports that it set 1600*4, and display also looks like that 1600 was
programmed into hardware.

And when console uses 16bpp, after switching from X picture is zoomed by 200%
(giving 800x600).  When console uses 32bpp, it is zoomed by 400% after
switch from X to console. In both cases rerunning fbset fixes problem.

I'm using Compaq Evo 800N, with 1600x1200 DFP.

evon:~# fbset -i

mode "1600x1200-60"
    # D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz
    geometry 1600 1200 1600 1200 8
    timings 6172 304 64 46 1 192 3
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : ATI Radeon LW
    Address     : 0x48000000
    Size        : 67108864
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 1600
    MMIO Address: 0x40300000
    MMIO Size   : 16384
    Accelerator : ATI Radeon family
evon:~#
						Petr Vandrovec