a new warning should be added to the linux kernel merge for 2.5/2.6 that fbset will corrupt your framebuffer and is no longer supported in 2.5/2.6. stty is currently intended to change the console resolution, but the desired display mode is not, as we are all used to, given by x resolution, y resolution, depth and refresh rate, but by rows and cols in the unit of text characters. For instance, if you are using the default console font (8x16), stty rows 128 cols 48 selects 1024x768. If you call fbset to change the display mode under 2.5/2.6, the console dimension (ie the amount of columns and rows) will not change - resulting in display corruption. Use fbset only to change the refresh rate and/or the depth. also, it is important to note that framebuffer drivers are now seperate from the framebuffer console driver. This changes the system behavior when it comes to whether or not the framebuffer driver decides it should be used. framebuffer driver and framebuffer console support in-kernel: you will boot in framebuffer console mode and there is nothing you can do to stop this. framebuffer driver in kernel and framebuffer console support as module: you will boot in normal text mode and switching to framebuffer console mode happens as soon as you load fbcon framebuffer console support in kernel and framebuffer driver as module: you will boot in text mode, and even after you load your framebuffer driver you will STILL BE IN TEXT MODE. in this situation you need the con2fb utility to tell the framebuffer driver to kick in. framebuffer console and driver as modules: you will boot in text mode. when you load your framebuffer driver you might lose your text console. only after loading the framebuffer console driver will you have a usable console again. confused yet? in summary, in 2.4 you use fbset. in 2.5, you use stty to change res, fbset to change refresh, and con2fb to activate the framebuffer driver. CRAPTASTIC. There is a hack to get fbset to behave like it used to by forcing it to accept this craptastical interface, but I have yet to get it to work properly. If/when I do I'll submit a patch but untill then I would definately be made happy with just a simple warning to let everyone know that this isnt a bug in the kernel (well at least not technically). Reproducible: Always Steps to Reproduce: 1. boot 2.5.x or 2.6.x 2. use fbset 3. power off your machine cuz there is usually no damned way that video card is going to reset itself even after rebooting. Sometimes I can just reboot, depending on kernel used. usually, you need to actually power off the machine at the supply. no freaking clue why.
There is no hope for fbset. That is unless you fix the craptastical kernel api. also, if you have a matrox like me, you're screwed. The maintainer of the matrox driver is understandably pissed at the new framebuffer layer: I'll still update my own version of fbdev layer and matroxfb, as this stripped down driver is quite unusable for me. Petr Vandrovec Hi Linus, as it appears that current fbdev layer is not going to disappear, there is update of matroxfb. I'm sorry that it is quite large, but due to completely changed underlying API there is no reasonable way how to split it into smaller pieces. (Mis) Features: Removed support for text mode. No way for it with current API. Removed support for hardware cursor. Generic cursor code has enough troubles as is, in software mode. No reasonable fbset support... It is especially annoying on multihead system, as 'stty cols XXX rows YYY' does not change pixclock... Removed fastfont support. No way for it with current API. (Mis) Features inherited from generic fbdev API: Cursor on other framebuffers than primary one does not blink. Contents of visible, but not foreground, display is not updated. Thanks, Petr Vandrovec so, perhaps the warning during the kernel merge should be "if you use a framebuffer driver you've just been seriously boned".
So then how does one control the framebuffer resolution a la vga=### used in grub and lilo configurations? I've got an nvidia geforce4 based card and have had no luck either in using their rivafb module.
You dont. vga= will no longer work. vga= is vesafb specific. something like "video=rivafb,xres:1024,yres:768,bpp:8" -should- work. but at this point it probably wont. If you get anything more than lines and dancing dots, consider yourself lucky. ;p To quote the modedb documentation: Currently all frame buffer device drivers have their own video mode databases, which is a mess and a waste of resources. The main idea of modedb is to have - one routine to probe for video modes, which can be used by all frame buffer devices - one generic video mode database with a fair amount of standard videomodes (taken from XFree86) - the possibility to supply your own mode database for graphics hardware that needs non-standard modes, like amifb and Mac frame buffer drivers (which use macmodes.c) When a frame buffer device receives a video= option it doesn't know, it should consider that to be a video mode option. If no frame buffer device is specified in a video= option, fbmem considers that to be a global video mode option. Valid mode specifiers (mode_option argument): <xres>x<yres>[-<bpp>][@<refresh>] <name>[-<bpp>][@<refresh>] with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string. Things between square brackets are optional. To find a suitable video mode, you just call int __init fb_find_mode(struct fb_var_screeninfo *var, struct fb_info *info, const char *mode_option, const struct fb_videomode *db, unsigned int dbsize, const struct fb_videomode *default_mode, unsigned int default_bpp) with db/dbsize your non-standard video mode database, or NULL to use the standard video mode database. fb_find_mode() first tries the specified video mode (or any mode that matches, e.g. there can be multiple 640x480 modes, each of them is tried). If that fails, the default mode is tried. If that fails, it walks over all modes. To specify a video mode at bootup, use the following boot options: video=<driver>:<xres>x<yres>[-<bpp>][@refresh] where <driver> is a name from the table below. Valid default modes can be found in linux/drivers/video/modedb.c. Check your driver's documentation. There may be more modes. Drivers that support modedb boot options Boot Name Cards Supported ami - Amiga chipset frame buffer aty128fb - ATI Rage128 / Pro frame buffer atyfb - ATI Mach64 frame buffer tdfx - 3D Fx frame buffer BTW, only a few drivers use this at the moment. Others are to follow (feel free to send patches).
I'm sorry, I forgot to mention that in 2.6 the only thing that uses the framebuffer right now is the framebuffer console. you shouldnt be able to use xdirectfb or mplayer on console or any of that. they'll need to be updated to work at all. if you actually make use of a framebuffer, do not upgrade. if anyone has a matrox, the matrox driver can be patched to use the old api. the matrox guy also has a patch for allowing fbset to work but it required the kernel itself to be patched. The latest matroxfb driver which includes the fbset kernel changes and fixes pretty much every issue there is as long as you have a matrox: http://platan.vc.cvut.cz/ftp/pub/linux/matrox-latest/matroxfb-2.5.72.gz This patch applies cleanly against 2.6.0-test1. The fbset patch which i believe should work for all drivers is here: http://platan.vc.cvut.cz/ftp/pub/linux/matrox-latest/fbset-through-vt-2.5.24.gz do NOT apply this if you use the updated matroxfb driver, as it is included. Also note, this wont fix much more than the framebuffer console mode switching. and it isnt actively maintained, as you can see by the version number. Petr Vandrovec 0wnz me =D
Im going to resolve this bug currently as gentoo-dev-sources and the linux tree in general are getting quite a lot of attention in relation to fbdev and other vc/vt work. as almost of all of the issue is upstream i shall resolve as upstream, although i see this being work in progress for quite some time. Rest assured this wont be forgotten.
hmm, interesting. With a Matrox card I have been able to switch modes on the framebuffer console just fine. Kernel and fbset without any special patches (as far as I know). The only glitch I noticed is that gpm is not always aware of the current console size.
Well, the problem has been fixed in the vanilla kernels for a long time now..
