> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jan 07 2003 - 22:00:33 EST