- 07 11月, 2005 2 次提交
-
-
由 Antonino A. Daplas 提交于
Add new helper, fb_find_best_display(), which will search the modelist for the best mode for the attached display. This requires an EDID block that is converted to struct fb_monspecs and a private modelist. The search will be done in this manner: - if 1st detailed timing is preferred, use that - else if dimensions of the display are known, use that to estimate xres and - else if modelist has detailed timings, use the first detailed timing - else, use the very first entry from the modelist Signed-off-by: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Michal Januszewski 提交于
Currently the fb_find_nearest_mode() function finds a mode with screen resolution closest to that described by the 'var' argument and with some arbitrary refresh rate (eg. in the following sequence of refresh rates: 70 60 53 85 75, 53 is selected). This patch fixes the function so that it looks for the closest mode as far as both resolution and refresh rate are concerned. The function's first argument is changed to fb_videomode so that the refresh rate can be specified by the caller, as fb_var_screeninfo doesn't have any fields that could directly hold this data. Signed-off-by: NMichal Januszewski <spock@gentoo.org> Signed-off-by: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 10 9月, 2005 1 次提交
-
-
由 Antonino A. Daplas 提交于
The Coordinated Video Timings (CVT) is the latest standard approved by VESA concerning video timings generation. It addresses the limitation of GTF which is designed mainly for CRT displays. CRT's have a high blanking requirement (as much as 25% of the horizontal frame length) which artificially increases the pixelclock. Digital displays, on the other hand, needs to conserve the pixelclock as much as possible. The GTF also does not take into account the different aspect ratios in its calculation. The new function added is fb_find_mode_cvt(). It is called by fb_find_mode() if it recognizes a mode option string formatted for CVT. The format is: <xres>x<yres>[M][R][-<bpp>][<at-sign><refresh>][i][m] The 'M' tells the function to calculate using CVT. On it's own, it will compute a timing for CRT displays at 60Hz. If the 'R' is specified, 'reduced blanking' computation will be used, best for flatpanels. The 'i' and the 'm' is for 'interlaced mode' and 'with margins' respectively. To determine if CVT was used, check for dmesg for something like this: CVT Mode - <pix>M<n>[-R], ie: .480M3-R (800x600 reduced blanking) where: pix - product of xres and yres, in MB M - is a CVT mode n - the aspect ratio (3 - 4:3; 4 - 5:4; 9 - 16:9, 15:9; A - 16:10) -R - reduced blanking Signed-off-by: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 09 8月, 2005 1 次提交
-
-
由 Antonino Daplas 提交于
Reported by:Vincent Fortier (Bugzilla Bug 4768) "At boot time the screen appears moved to the mid right portion of the actual video pannel making the end of the line appears at the left edge... It simply looks like moved half way to the right" His particular hardware has a display with an unusual dimension (1920x1200) but unfortunately has no EDID block. None of the entries in the global mode database is correct for this particular display, and it particularly has difficulty scaling up 640x480 (the default startup mode of nvidiafb) to 1920x1200 which causes the above described problem. 1, Add 1920x1200 to the global mode database. 2. Let nvidiafb base the startup mode from the flatpanel dimensions only if the EDID block is absent, no boot mode parameter is specified by the user, and a flatpanel/LCD display is attached. Signed-off-by: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-