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

[James Simmons]

> 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.