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
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/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?
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.
]
> 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.
Signed-off-by: Randy Dunlap <[email protected]>
Reported-by: root <[email protected]>
cc: Krzysztof Helt <[email protected]>
cc: Michal Januszewski <[email protected]>
---
Documentation/fb/uvesafb.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.27-rc9-git2.orig/Documentation/fb/uvesafb.txt
+++ linux-2.6.27-rc9-git2/Documentation/fb/uvesafb.txt
@@ -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.