Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 6 Jan 2003 17:18:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 6 Jan 2003 17:18:52 -0500 Received: from phoenix.infradead.org ([195.224.96.167]:45325 "EHLO phoenix.infradead.org") by vger.kernel.org with ESMTP id ; Mon, 6 Jan 2003 17:18:50 -0500 Date: Mon, 6 Jan 2003 22:27:25 +0000 (GMT) From: James Simmons To: Antonino Daplas cc: Linux Fbdev development list , Linux Kernel List Subject: Re: [Linux-fbdev-devel] [RFC][PATCH][FBDEV]: Setting fbcon's windows size In-Reply-To: <1041864838.955.68.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3786 Lines: 95 > 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/