typo errors in the modedb.c video mode tables

I believe there are a few typos in the mode tables in modedb.c   -   in the 
current 2.6.22 :

  .  line 77
	/* 1152x864 @ 89 Hz interlaced, 44 kHz hsync */
	NULL, 69, 1152, 864, 15384, 96, 16, 110, 1, 216, 10,
should be
	/* 1152x864 @ 89 Hz interlaced, 44 kHz hsync */
	NULL, 89, 1152, 864, 15384, 96, 16, 110, 1, 216, 10,

. line 125

	/* 1400x1050 @ 60Hz, 63.9 kHz hsync */
	NULL, 68, 1400, 1050, 9259, 136, 40, 13, 1, 112, 3,
should be
	/* 1400x1050 @ 60Hz, 63.9 kHz hsync */
	NULL, 60, 1400, 1050, 9259, 136, 40, 13, 1, 112, 3,

. line 129
	/* 1400x1050 @ 75,107 Hz, 82,392 kHz +hsync +vsync*/
	NULL, 75, 1400, 1050, 9271, 120, 56, 13, 0, 112, 3,
is wrong somewhere but I don't know what should be changed

. line 258
	/* 1152x768, 60 Hz, PowerBook G4 Titanium I and II */
	NULL, 60, 1152, 768, 15386, 158, 26, 29, 3, 136, 6,
is wrong somewhere but I don't know what should be changed

. line 311
        /* 12 1024x768i-43 VESA */
	{ NULL, 53, 1024, 768, 22271, 56, 8, 41, 0, 176, 8,
should be
        /* 12 1024x768i-43 VESA */
	{ NULL, 43, 1024, 768, 22271, 56, 8, 41, 0, 176, 8,

. line 388
	/* 33 1920x1440-75 VESA */
	{ NULL, 60, 1920, 1440, 3367, 352, 144, 56, 1, 224, 3,
should be
	/* 33 1920x1440-75 VESA */
	{ NULL, 75, 1920, 1440, 3367, 352, 144, 56, 1, 224, 3,

In the cases where I've stated the correction, in every case it's the v_sync 
refresh rate which is wrong and it's pretty obvious as the preceding comment 
has the correct value.      In the other cases, I'm not sure but my 
calculations indicates the refresh is not consistent with the other values 
(but I could be wrong).

I also don't know what effect these errors are having - I found them from 
studying the code after I could not get my desired 1400x1050@60 for my 
supersavage framebuffer console.       One of the above entries is the one I 
want.    Is the refresh value in these tables used for matching modes?      
It seems so from my reading of fb_find_mode() in the same file.

John

_________________________________________________________________
Tell us your tech love story in the Summer Lovin Competition for your chance 
to win laptop loaded with Windows Vista, Office 2007 and Windows Live 
OneCare. 
http://www.microsoft.com/canada/home/contests/summerlovin/default.aspx


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

On Sat, 2007-07-21 at 18:59 -0400, John Lumby wrote:

I believe there are a few typos in the mode tables in modedb.c   -   in the 
current 2.6.22 :

I also don't know what effect these errors are having - I found them from 
studying the code after I could not get my desired 1400x1050@60 for my 
supersavage framebuffer console.       One of the above entries is the one I 
want.    Is the refresh value in these tables used for matching modes? 

Yes, the refresh field is used for matching.    
 

It seems so from my reading of fb_find_mode() in the same file.

I'll review those values again and apply the appropriate corrections.
You can also avoid the table lookup and use 1400x1050M@60 instead.  The
timings will be computed.

Tony 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Antonino wrote :

You can also avoid the table lookup and use 1400x1050M@60 instead.  The
timings will be computed.

Thanks Antonio.    However, on my SuperSavage IX/C SDR rev 5 (a LCD), mode 
1400x1050M@60 results in a completely blank display.    mode 
11400x1050-32@60 gives me a barely-readable display (i.e. characters do 
appear) but with a shadow-zone  in the central columns of the display.

The only good display I have been able to achieve at this resolution was by 
hacking savagefb_driver.c and plugging in my own mode directly -
static struct fb_var_screeninfo __devinitdata savagefb_var1400x1050x32 = {
	.accel_flags =	FB_ACCELF_TEXT,
	.xres =		1400,
	.yres =		1050,
	.xres_virtual =  1400,
	.yres_virtual =  1050,
	.bits_per_pixel = 32,
	.pixclock =	9259,
	.left_margin =	136,
	.right_margin =	40,
	.upper_margin =	13,
	.lower_margin =	1,
	.hsync_len =	112,
	.vsync_len =	3,
	.sync =		0,
	.vmode =	FB_VMODE_NONINTERLACED
};
This worked almost ok - or rather, completely ok when running only the 
framebuffer consoles - but as soon as I started X, (XFree86),  and then 
VT-switching back to my framebuffer consoles - they had gone fuzzy and 
rippling.       Maybe because the XFree86 mode had a different refresh rate. 
      I also then tried to construct yet another explicit framebuffer mode 
to correspond to the XFree86 mode as displayed by xvidtune --show, but that 
also resulted in completely blank console display.

I would be interested to hear if anyone has been able to get high resolution 
(preferably 1400x1050 although I'd settle for 1280x1024 at this point) in 
the linux framebuffer console on a SuperSavage IX/C SDR rev 5 LCD  while X 
is running in virtual console 7.

John

Tony

_________________________________________________________________
Tell us your tech love story in the Summer Lovin Competition for your chance 
to win laptop loaded with Windows Vista, Office 2007 and Windows Live 
OneCare. 
http://www.microsoft.com/canada/home/contests/summerlovin/default.aspx


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/