Latest working kernel version: - Earliest failing kernel version: Distribution: Debian Release: lenny/sid Hardware Environment: Intel PIII / i815M Software Environment: Problem Description: While all other framebuffer modules use the option "mode=..." to specify a modedb-style video mode, i810fb uses the non-standard "mode_option=..." This breaks the use of "video=i810fb:<videomode>" boot parameter, such that for instance "video=i810fb:1024x768" doesn't work. The boot scripts parse the "<videomode>" parameter internally and pass it to the correct module as 'mode=<videomode>'. -Alain
Reply-To: akpm@linux-foundation.org On Tue, 29 Jan 2008 21:02:39 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9847 > > Summary: i810fb: module parameter 'mode_option' inconsistent with > other framebuffer modules > Product: Drivers > Version: 2.5 > KernelVersion: 2.6.22 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Console/Framebuffers > AssignedTo: jsimmons@infradead.org > ReportedBy: miki@dds.nl > > > Latest working kernel version: - > Earliest failing kernel version: > Distribution: Debian Release: lenny/sid > Hardware Environment: Intel PIII / i815M > Software Environment: > Problem Description: While all other framebuffer modules use the option > "mode=..." to specify a modedb-style video mode, i810fb uses the non-standard > "mode_option=..." This breaks the use of "video=i810fb:<videomode>" boot > parameter, such that for instance "video=i810fb:1024x768" doesn't work. > The boot scripts parse the "<videomode>" parameter internally and pass > it to the correct module as 'mode=<videomode>'. > > -Alain
> Problem Description: While all other framebuffer modules use the option > "mode=..." to specify a modedb-style video mode, i810fb uses the non-standard > "mode_option=..." This breaks the use of "video=i810fb:<videomode>" boot > parameter, such that for instance "video=i810fb:1024x768" doesn't work. > The boot scripts parse the "<videomode>" parameter internally and pass > it to the correct module as 'mode=<videomode>'. are you sure with this? which scripts? i don´t find such on suse. >While all other framebuffer modules use the option "mode=..." it seems this isn`t true: modules using "mode=" ./pm2fb.ko parm: mode:Preferred video mode e.g. '648x480-8@60' (charp) ./arkfb.ko parm: mode:Default video mode ('640x480-8@60', etc) (charp) ./geode/gx1fb.ko parm: mode:video mode (<x>x<y>[-<bpp>][@<refr>]) (string) ./sis/sisfb.ko parm: mode: ./uvesafb.ko parm: mode:Specify initial video mode as "<xres>x<yres>[-<bpp>][@<refresh>]" (charp) ./intelfb/intelfb.ko parm: mode:Initial video mode "<xres>x<yres>[-<depth>][@<refresh>]" (charp) ./s3fb.ko parm: mode:Default video mode ('640x480-8@60', etc) (charp) ./tridentfb.ko parm: mode:charp ./vt8623fb.ko parm: mode:Default video mode ('640x480-8@60', etc) (charp) ./cyblafb.ko parm: mode:charp ./aty/atyfb.ko parm: mode:Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]" (charp) modules using "mode_option=" ./geode/lxfb.ko parm: mode_option:video mode (<x>x<y>[-<bpp>][@<refr>]) (charp) ./geode/gxfb.ko parm: mode_option:video mode (<x>x<y>[-<bpp>][@<refr>]) (charp) ./savage/savagefb.ko parm: mode_option:Specify initial video mode (charp) ./neofb.ko parm: mode_option:Preferred video mode ('640x480-8@60', etc) (charp) ./sstfb.ko parm: mode_option:Initial video mode (default=640x480@60) (charp) ./i810/i810fb.ko parm: mode_option:Specify initial video mode (charp) ./nvidia/nvidiafb.ko parm: mode_option:Specify initial video mode (charp) ./aty/radeonfb.ko parm: mode_option:Specify resolution as "<xres>x<yres>[-<bpp>] [@<refresh>]" (charp) so it seems, there is no standard....
>so it seems, there is no standard.... apparently, this was wrong mode_option should be the way to go, see: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=commit;h=cc6c549c7a9808cc7a8a5afbfa54dbbd2262509d but it`s not trivial: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=commit;h=9e3f0ca812ab8fa3f4e65ade41bf6fb936f14e15 (thanks to adrian bunk for the hint, btw!) alain, as this is already work in progress, do you think we need to leave this open ?
closing due to no response and because this is not a bug. please reopen if you think there is something to add here - or bring this up on lkml.