uvesafb in 2.6.27-rc9 uses mode_option, in 2.6.27 mode, but the docs aren't updated
Subsystems (2)
I just tested 2.6.27-rc9 on my laptop, which uses uvesafb. I notice that I need to update
/sbin/modprobe uvesafb mode=1400x1050
to
/sbin/modprobe uvesafb mode_option=1400x1050
but the documentation in Documentation/fb/uvesafb.txt happily talks about the mode option. It would be nice to have the documentation updated at least, but might I also question this move at all? Why call something 'mode_option' when 'mode' is shorter and the fact that it's an option really is clear from the fact you mention it on the commandline, like, how-do-I-call-it, yes-I-remember, an option?
Or are we moving toward 'mtrr_option', 'scroll_option', 'vram_remap_option' etc? I don't think that really a good idea, so the easiest thing to do would be to revert the patch that did this rename, since that resyncs the Documentation to the actual module and removes the needless description of the 'mode' option.
Kind regards,
Jurriaan
PATCH 1/1 docs: Re: uvesafb in 2.6.27-rc9 uses mode_option, in 2.6.27 mode, but the docs aren't updated
Quoted 7 lines · On Tue, 7 Oct 2008 18:54:10 +0000 root wrote:
I just tested 2.6.27-rc9 on my laptop, which uses uvesafb. I notice that I need to update
/sbin/modprobeuvesafb mode=1400x1050to
Quoted 8 lines
/sbin/modprobeuvesafb mode_option=1400x1050but the documentation in
Documentation/fb/uvesafb.txthappily talks about the mode option. It would be nice to have the documentation updated at least, but might I also question this move at all? Why call something 'mode_option' when 'mode' is shorter and the fact that it's an option really is clear from the fact you mention it on the commandline, like, how-do-I-call-it, yes-I-remember, an option?
True, but most framebuffer drivers use 'mode_option', so this one was converted to be more normal. And I was outvoted. :(
[I wrote on 2008-FEB-05:
I would (do) say that "mode_option" is being redundant. Yes, it's an option, but we don't usually name options (in other parts of the kernel) with an _option suffix. Sure, the variable could be called <mode_option>, but the userspace name should just be "mode". IMHO.
Please keep Documentation/fb/modedb.txt updated if you make any relevant changes.
]
Quoted 5 lines
Or are we moving toward '
mtrr_option', 'scroll_option', 'vram_remap_option' etc? I don't think that really a good idea, so the easiest thing to do would be to revert the patch that did this rename, since that resyncs the Documentation to the actual module and removes the needless description of the 'mode' option.
From: Randy Dunlap <[email protected]>
uvesafb was switched from the 'mode' parameter to the more common (in fb-land) 'mode_option' parameter, so update the documentation for that.
--- Documentation/fb/uvesafb.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Documentation/fb/uvesafb.txt +3 -3
@@ -52,7 +52,7 @@ are either given on the kernel command l video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel) - # modprobe uvesafb mode=1024x768-32 mtrr=3 scroll=ywrap (module) + # modprobe uvesafb mode_option=1024x768-32 mtrr=3 scroll=ywrap (module) Accepted options:
@@ -105,7 +105,7 @@ vtotal:n <mode> The mode you want to set, in the standard modedb format. Refer to modedb.txt for a detailed description. When uvesafb is compiled as a module, the mode string should be provided as a value of the - 'mode' option. + 'mode_option' parameter. vbemode:x Force the use of VBE mode x. The mode will only be set if it's
@@ -182,7 +182,7 @@ from the Video BIOS if you set pixclock -- Michal Januszewski <[email protected]> - Last updated: 2007-06-16 + Last updated: 2008-10-09 Documentation of the uvesafb options is loosely based on vesafb.txt.