All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: root <thunder7@xs4all.nl>
Cc: linux-fb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org,
	Michal Januszewski <spock@gentoo.org>,
	Krzysztof Helt <krzysztof.h1@wp.pl>,
	akpm <akpm@linux-foundation.org>
Subject: [PATCH] docs: Re: uvesafb in 2.6.27-rc9 uses mode_option, in 2.6.27 mode, but the docs aren't updated
Date: Thu, 9 Oct 2008 10:56:34 -0700	[thread overview]
Message-ID: <20081009105634.ee300093.randy.dunlap@oracle.com> (raw)
In-Reply-To: <20081007185410.GA7872@onderneming10>

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 <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
Reported-by: root <thunder7@xs4all.nl>
cc: Krzysztof Helt <krzysztof.h1@wp.pl>
cc: Michal Januszewski <spock@gentoo.org>
---
 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 <spock@gentoo.org>
- Last updated: 2007-06-16
+ Last updated: 2008-10-09
 
  Documentation of the uvesafb options is loosely based on vesafb.txt.
 

      reply	other threads:[~2008-10-10  0:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 18:54 uvesafb in 2.6.27-rc9 uses mode_option, in 2.6.27 mode, but the docs aren't updated root
2008-10-09 17:56 ` Randy Dunlap [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081009105634.ee300093.randy.dunlap@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=krzysztof.h1@wp.pl \
    --cc=linux-fb-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spock@gentoo.org \
    --cc=thunder7@xs4all.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.