Hi,
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.
<-- BEGIN -->
diff -Naur linux-2.5.54/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
<-- END -->
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).
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.
With the current approach, this "assistance" is gone. When a window size
change is requested, the fbdev driver is left on its own to find the
correct timing values for the video mode.
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.
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)
2. entered as a boot/module option
3. ?ioctl to upload monitor info to fbdev.
(As a side note, should we also add pixclock_min and pixclock_max to
info->monspecs?).
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?
Tony
diff -Naur linux-2.5.54/drivers/video/modedb.c linux/drivers/video/modedb.c
From: James Simmons <hidden> Date: 2003-01-06 22:18:52
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.
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.
That's true. The VBEInfoBlock struct contains a far pointer to a list
of video modes supported, standard VESA DMT modes and OEM-specific
modes. This is function 0x4F00 of VBE which unfortunately is accessible
only in 16-bit mode. Maybe the EDID block also contains such
information?
Also, if the user wants to control the refresh rate, or use nonstandard
video modes, there's no choice but to have the timings generated even
for new hardware. That's where the GTF is useful.
quoted
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!!!!
quoted
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!!!
quoted
2. entered as a boot/module option
Yuck! But I don't see much of a choose for modular drivers.
We do need to have the monitor's operational limits uploaded whatever
way and as early as possible so the user can boot to a high resolution
immediately. Using VBE/DDC and parsing the EDID block may not work with
new, but cheap monitors. I have one such monitor that is supposed to
support DDC2 but spits out a useless EDID block. So passing it as a
boot option may be useful. This is similar to XFree86 falling back to
/etc/X11/XF86Config's 'HorizSync' and 'VertRefresh' when the EDID info
is not available.
quoted
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.
What's the ioctl by the way?
The GTF only requires xres, yres and one of the three:
horizontal scan rate
vertical refresh rate
pixelclock.
in order to generate timings. So adding minimum and maximum pixelclock
fields in info->monspecs will be useful. Otherwise the GTF may generate
a pixelclock that is outside the graphics card's/monitor's capability.
Secondly, the GTF function assumes the following:
hsync_len = 8% of htotal
left_margin = 1/2 of inactive frame length
right margin = remainder of htotal
vsync_len = 3
lower_margin = 1
upper margin = remainder of vtotal.
Anyway, the most critical part when computing timings information is the
inactive frame length (htotal - xres, vtotal - yres), which is hblank
and vblank in the fb_get_mode() function.
Finally, some of the fixed numbers I used in the GTF function is
supposedly for a monitor with US specifications:
#define FLYBACK 550
#define V_FRONTPORCH 1
#define H_OFFSET 40
#define H_SCALEFACTOR 20
#define H_BLANKSCALE 128
#define H_GRADIENT 600
I'm not even sure about the meaning of some of them :-). We can add them
in the future if the above assumptions need to be changed.
Tony
PS: The GTF patch is erroneous. hfmin and hfmax must be in Hz and the
boolean logic is incorrect.
diff -Naur linux-2.5.54/drivers/video/modedb.c linux/drivers/video/modedb.c
Hi James,
Here's an improved GTF implementation. I was a bit delayed because I
was trying to find a way to do square roots without using floating
point. The diff is against linux-2.5.54 + your latest fbdev.diff.
static int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo
*var, struct fb_info *info);
if flags == 0: maximize timings
1: vrefresh rate driven calculation
2. hscan rate driven calculation
3. pixelclock driven calculation.
The parameter 'val' depends on the parameter 'flags': ignored if flags
== 0, in Hz if 1 and 2, in picoseconds if 3.
The flags are useful for cases such as a fixed-frequency monitor (pass
flags = 2) or for hardware which only have several sets of dotclocks to
use. In this case, it will run the GTF first, get the resulting
pixelclock to select a dotclock from the driver's own set, then rerun
the GTF using flags=3, and val = selected dotclock.
Probably still has precision errors, like converting KHZ to picoseconds,
but is more or less usable. Tested with i810fb and rivafb. (For rivafb,
I have to use a hacked version. The latest one does not work for the
riva128).
BTW, I downloaded the source code of read-edid, and it seems that the
following monitor limits are parsable from the EDID block: HorizSync,
VertRefresh, DotClock, and GTF capability. We may change info->monspecs
to match that. Also, the EDID contains a list of supported modes, but
there's only 4 of them(?).
Tony
diff -Naur linux-2.5.54/drivers/video/fbmon.c linux/drivers/video/fbmon.c
From: James Simmons <hidden> Date: 2003-01-10 18:09:46
Here's an improved GTF implementation. I was a bit delayed because I
was trying to find a way to do square roots without using floating
point. The diff is against linux-2.5.54 + your latest fbdev.diff.
Applied.
but is more or less usable. Tested with i810fb and rivafb. (For rivafb,
I have to use a hacked version. The latest one does not work for the
riva128).
What hack did you do? That is based on the latest riva driver from 2.4.2X.
BTW, I downloaded the source code of read-edid, and it seems that the
following monitor limits are parsable from the EDID block: HorizSync,
VertRefresh, DotClock, and GTF capability. We may change info->monspecs
to match that. Also, the EDID contains a list of supported modes, but
there's only 4 of them(?).
I figured monspec would have to be improved. I'm looking into the EDID
info right now. I'm also looking at read-edid. Next I need to figure out
how to use i2c to get this info.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Here's an improved GTF implementation. I was a bit delayed because I
was trying to find a way to do square roots without using floating
point. The diff is against linux-2.5.54 + your latest fbdev.diff.
Applied.
quoted
but is more or less usable. Tested with i810fb and rivafb. (For rivafb,
I have to use a hacked version. The latest one does not work for the
riva128).
What hack did you do? That is based on the latest riva driver from 2.4.2X.
I just combined the old riva_hw.c in linux-2.5.52 with the new fbdev.c
code. Not too sure why, either the newest riva_hw.c has dropped support
for old hardware, or we are using it incorrectly. If I'm to guess, the
new riva_hw.c did not come from linux-2.4.20, but probably from Xfree86?
quoted
BTW, I downloaded the source code of read-edid, and it seems that the
following monitor limits are parsable from the EDID block: HorizSync,
VertRefresh, DotClock, and GTF capability. We may change info->monspecs
to match that. Also, the EDID contains a list of supported modes, but
there's only 4 of them(?).
I figured monspec would have to be improved. I'm looking into the EDID
info right now. I'm also looking at read-edid. Next I need to figure out
how to use i2c to get this info.
On Mon, 2003-01-06 at 22:54, Antonino Daplas wrote:
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.
James,
Attached is a diff against linux-2.5.54 + your latest fbdev.diff.
Hopefully it's the final installment for the GTF implementation.
The fb_get_mode() function checks for a bit in 'flags' (FB_IGNOREMON) so
it will generate GTF timings regardless of the validity of
info->monspecs. This way, drivers can still use GTF even if they don't
have the operational limits of the monitor. They'll just decide what is
a practical safe limit.
This particular code snippet can be inserted in xxxfb_check_var() after
rounding off var->xres and var->yres.
...
if (fb_validate_mode(var, info)) {
if (!info->monspecs.hfmax || !info->monspecs.vfmax ||
!info->monspecs.dclkmax ||
info->monspecs.hfmax < info->monspecs.hfmin ||
info->monspecs.vfmax < info->monspecs.vfmin ||
info->monspecs.dclkmax < info->monspecs.dclkmin)
fb_get_mode(FB_IGNOREMON | FB_VSYNCTIMINGS, 60, var, info);
else
if (fb_get_mode(FB_MAXTIMINGS, 0, var, info))
return -EINVAL;
}
...
With the above, the driver will switch to a 60Hz refresh rate timings
(safe even for low-end monitors up to 1024x768) if monspecs is invalid.
Other changes: added a few more fields to fb_info.monspecs.
Tony
diff -Naur linux-2.5.54/drivers/video/fbmon.c linux/drivers/video/fbmon.c
From: James Simmons <hidden> Date: 2003-01-10 23:51:31
Hopefully it's the final installment for the GTF implementation.
The fb_get_mode() function checks for a bit in 'flags' (FB_IGNOREMON) so
it will generate GTF timings regardless of the validity of
info->monspecs. This way, drivers can still use GTF even if they don't
have the operational limits of the monitor. They'll just decide what is
a practical safe limit.