Re: [Linux-fbdev-devel] [RFC][PATCH][FBDEV]: Setting fbcon's windows size

In 2.5, in contrast with the 2.4 fbdev framework, any changes in the
fbdev layer will not reflect in the upper console layer, except during
initialization of fbcon.  So using fbset to change the resolution will
produce unexpected results. If my understanding is correct, the
relationship between console and fbdev is now master (console) and slave
(fbdev).  If this is true, then console changes must become visible to
fbcon/fbdev.  This is easily accomplished by adding a csw->con_resize()
hook to fbcon.

Correct to the above. I applied your patch.

The tty/console layer has several ioctl's that will allow changing of
the console window size (VT_RESIZE, VT_RESIZEX, TIOCSWINSZ, etc). So
using:

stty cols 128 rows 48

will change the fb resolution to 1024x768 if using an 8x16 font.

One advantage of this approach is that the changes are preserved per
console (in contrast to using fbset which sets all consoles).

Yeap. TIOCSWINSZ is per VC. VT_RESIZE and VT_RESIZEX affect all VCs. 
They should work as well.

This approach has one major problem though.  In the 2.4 interface, we
have fbset that basically "assists" fbdev with the changes.  The fbset
utility will fill up fb_var_screeninfo with correct information such as
video timings from /etc/fb.modes.  

I neved like the idea of fb.modes. We should be asking the hardware are 
selves instead.Yes there are cases of really old hardware that lack this. 
I think the below code will be usefull for these cases.
 

So, what's needed is a function that calculates timing parameters which
is generic enough to work with the most common monitors.  One solution
is to use VESA's GTF (Generalized Timing Formula).  Attached is a patch
that implements the formula.

Great!!!!

The timings generated by GTF are different from the standard VESA
timings (DMT).  However, it should work for GTF compliant monitors and
is also specifically formulated to work with older monitors as well. 
Another advantage is that it can calculate the timings for any video
mode. It may not work for proprietary displays or TV displays.

One requirement of the GTF is that the monitor specs must be known, ie
info->monspecs must be valid.  This can be filled up several ways:

1. VBE/DDC and EDID parsing (I see the beginnings of it already in
fbmon.c)

Yeap. We can parse the EDID block for data about the limits of your 
monitor!!! 

2. entered as a boot/module option

Yuck! But I don't see much of a choose for modular drivers.
 

3. ?ioctl to upload monitor info to fbdev.

(As a side note, should we also add pixclock_min and pixclock_max to
info->monspecs?).

ioctl already exist for this. The only issue is fb_monspec good enough for 
our needs.

User-entered timings are always preferred, so these are validated
first.  If the timings are not valid, then they will be computed. So,
here are 2 new functions:

1. fb_validate_mode(fb_var_screeninfo *var, fb_info *info)

2. fb_get_mode(u32 refresh, fb_var_screeninfo *var, fb_info *info)

It's in fb_get_mode() where the GTF is implemented.  The 'refresh'
parameter is optional, and if == 0, the vertical refresh rate will be
maximized.

Anyway, using fb_get_mode(), I was able to generate working video modes from as low as
300x300@60 to as high as 1600x1200@85.  I've also experimented with
unusual modes, such as 1600x480.

Comments?

Nice. The only thing is i like to see monitor stuff end up in fbmon.c. I 
will apply your patch.