Summary: | 2.5/2.6 framebuffer system no longer uses fbset | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Travis Tilley (RETIRED) <lv> |
Component: | [OLD] Core system | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | hramrach, jforman, johnm, spock |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Travis Tilley (RETIRED)
2003-07-16 03:21:48 UTC
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.. |