> To be a bit more precise: The position of the picture depends on the
> mode.
Do you have a programmable monitor that can store individual mode parameter
sets, or is it fixed ? In the latter case, you will probably have to use
modeline sto get things nicely centered.
> The vertical position is okay but for some resolutions, e.g.
> 800x600, the left edge is about in the middle of the screen.
This is strange - sounds like a driver bug. A few cm to the left or right
would be normal, but not half the screen.
> /dev/fb0:
> Miro
> PTLA150
> GM_ALL
> FL_MON_NORMAL
> 1024x768
> 300x225
> COLOR_LCD
Is that one correct ? Not that it matters - just out of curiosity ..
> SYNC_SEPARATE | SYNC_COMPOSITE | SYNC_MULTISYNC
> 0-200000000
> 31470-60240 // already tried 0-60240
> 56-75
This doesn't look quite consistent - 200 MHz input bandwidth against 60kHz
maximum horizontal resolution seems like quite some waste of a good input
citcuit (would allow for about 3000 Pixels resolution) but well ...
Tune down the horizontal minimum a little. I usually use 31000. Slower
frequencies are usually no problem for the monitor.
Also the vertical constraints seem to be quite tight you may want to loosen
them a little as well.
If you have set timings, you may want to calculate, if they fit within the
given limits. Standard VGA timing is
25175000
640, 640, 680, 776, 784, 800, 0
480, 488, 489, 491, 516, 524, 0
what yields:
hfreq= 25175000/800 = 31468 Hz
Ah - that might be your problem - that's out of range for the above monitor
description ... slightly differing clocks (like 25,00MHz) would worsen the
problem ...
vfreq= 31468/524 = 60 Hz
> > Just like with XFree. Copy the modelines over to the timelist format.
> > However usually a multisync definition is better.
> So I don't have to, right ?
Yes - they are only needed, if the default timing is not to your (or your
monitor's) liking.
> By the way: what pixelclock would be the appropriate for a given
> resolution ?
Rule of thumb:
Pixclock = Desired horizontal refresh-rate * 1.2 * horizontal resolution.
horiz-Refresh = Desired vertical refresh * 1.1 * vertical resolution.
Make sure to check all limits stay valid.
> > I suppose that worked before the change ? (i.e. when fbdev was in
> > 640x480 anyway) ?
> No it's because even fbset -g 640 480 640 480 8 doesn't work !
Though it came up with 640x480 after loading ??
> XGGI: Just wanted to know whether there is still active developement.
Well - it works nicely (as you can see - I'm using it right now) ...
> Andy: Thank's a lot for your help! Maybe I should write a section of
> (F)AQs after this is all done ?
If you'd like to - please do ! Improving docs is always a good thing.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
