Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[krzysztof.h1]

Alain Kalker napisa³:

> >From Documentation/fb/modedb.txt:
> ---
> 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):
> ...
> 
> >From this I believe that "mode_option" is the standard way, It also
> indicates that the parameter name itself is optional, but I am not sure
> if there is an overall Linux standard for indicating optional parameter
> names.
> 

If the mode_option is the correct one please email Andrew Morton to remove the patch I made for i810fb.
I will fix drivers which use the "mode" option.

> 
> P.S.: Krzysztof, maybe it would be a good idea to update fbmode.txt
> too, as there are now many more framebuffer drivers which support video
> mode naming.
> 
> 

I'll update it with every driver I reworked.

Regards,
Krzysztof


Pogoda na najblizsze dni.
Sprawdz >>> http://link.interia.pl/f1ce1


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[Alain Kalker]

On Tue, 2008-02-05 at 13:40 +0100, krzysztof.h1@poczta.fm wrote:
> Alain Kalker napisał:
> 
> > >From Documentation/fb/modedb.txt:
> > ---
> > 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):
> > ...
> > 
> > >From this I believe that "mode_option" is the standard way, It also
> > indicates that the parameter name itself is optional, but I am not sure
> > if there is an overall Linux standard for indicating optional parameter
> > names.
> > 
> 
> If the mode_option is the correct one please email Andrew Morton to remove the patch I made for i810fb.
> I will fix drivers which use the "mode" option.

Done.

> 
> > 
> > P.S.: Krzysztof, maybe it would be a good idea to update fbmode.txt
> > too, as there are now many more framebuffer drivers which support video
> > mode naming.
> > 
> > 
> 
> I'll update it with every driver I reworked.

Thanks!

Regards,

Alain

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[krzysztof.h1]

Alain Kalker napisa³(a):
>
> I would like to propose instead to make the "mode& / mode_option"
> parameter name optional for all drivers where possible. This will
> greatly simplify framebuffer driver loading by the boot scripts, which
> currently cannot easily identify drivers needing either parameter name.
>

Just for conirmation:

so the current solution should be to add "mode_option" for drivers using
ModeDB and for all drivers to be able to accept resolution without any
parameter name?

Regards,
Krzysztof



----------------------------------------------------------------------
Wyjatkowe pioro Andrzeja Mleczki! 
Licytuj! >>> http://link.interia.pl/f1cf2


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[krzysztof.h1]

Randy Dunlap napisa³(a):
> On 05 Feb 2008 08:08:10 +0100 krzysztof.h1@poczta.fm wrote:
> 
> > Hi,
> > 
> > Few days ago, a bug was reported that the i810fb uses "mode_option"
> parameters while other framebuffers uses the "mode" parameter to set
> initial mode. It was spotted later that some drivers uses "mode_option",
> some uses "mode" and some does use none.
> > 
> > I want to ask what is a correct way. I can rework at least some of the
> drivers to a standard way, but I don't know what the standard is.
> 
> Hi,
> Hopefully one of the fbdev driver developers will know for sure.
> 
> 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.
> 

I and Alain Kalker (who originally filled the bug report) decided to proceed
with mode_option parameter because it is stated in documentation, fb driver
skeleton and more drivers then the mode option. It seems that the mode
option is used in newer drivers (drivers added later).

We want to preserve what older fbdev developers decided some time ago. 
Personaly, I am not sure one way is much better then the other one. 
The problem is that it is not one way.

The first step is to fix the mess with different option names, so to add
the mode_option parameter to drivers which do not support it or support the
mode parameter.

> Please keep Documentation/fb/modedb.txt updated if you make any
> relevant changes.
> 

Yes, of course.

Regards,
Krzysztof


----------------------------------------------------------------------
Wyjatkowe pioro Andrzeja Mleczki! 
Licytuj! >>> http://link.interia.pl/f1cf2


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[Alain Kalker]

On Wed, 2008-02-06 at 08:15 +0100, krzysztof.h1@poczta.fm wrote:
> I and Alain Kalker (who originally filled the bug report) decided to proceed
> with mode_option parameter because it is stated in documentation, fb driver
> skeleton and more drivers then the mode option. It seems that the mode
> option is used in newer drivers (drivers added later).
> 
> We want to preserve what older fbdev developers decided some time ago. 
> Personaly, I am not sure one way is much better then the other one. 
> The problem is that it is not one way.
> 
> The first step is to fix the mess with different option names, so to add
> the mode_option parameter to drivers which do not support it or support the
> mode parameter.

This was indeed the intention of my bug report, but I have come to
realize that the 'mode_option' name currently makes it very easy to
distinguish between drivers which already use the ModeDB mechanism and
those that don't. One can usie a tool like 'modinfo' to list module
parameters instead of having to grep the kernel source for a function
like 'fb_find_mode'. Maybe in future when all drivers have been
harmonized, the 'mode_option' name can be changed once and for all.

I would like to propose instead to make the 'mode' / 'mode_option'
parameter name optional for all drivers where possible. This will
greatly simplify framebuffer driver loading by the boot scripts, which
currently cannot easily identify drivers needing either parameter name.

Regards,

Alain

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[Alain Kalker]

On Wed, 2008-02-06 at 17:47 +0100, Alain Kalker wrote:
> I would like to propose instead to make the 'mode' / 'mode_option'
> parameter name optional for all drivers where possible. This will
> greatly simplify framebuffer driver loading by the boot scripts, which
> currently cannot easily identify drivers needing either parameter name.

so one would be able to use

# modprobe <xxxfb> 1024x768 <other options>

instead of 

# modprobe <xxxfb> mode_option=1024x768 <other options>

Regards,

Alain

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[krzysztof.h1]

Hi,

Few days ago, a bug was reported that the i810fb uses "mode_option" parameters while other framebuffers uses the "mode" parameter to set initial mode. It was spotted later that some drivers uses "mode_option", some uses "mode" and some does use none.

I want to ask what is a correct way. I can rework at least some of the drivers to a standard way, but I don't know what the standard is.

Kind regards,
Krzysztof


Pogoda na najblizsze dni.
Sprawdz >>> http://link.interia.pl/f1ce1


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[Alain Kalker]

On Tue, 2008-02-05 at 08:08 +0100, krzysztof.h1@poczta.fm wrote:
> Hi,
> 
> Few days ago, a bug was reported that the i810fb uses "mode_option" parameters while other framebuffers uses the "mode" parameter to set initial mode. It was spotted later that some drivers uses "mode_option", some uses "mode" and some does use none.
> 
> I want to ask what is a correct way. I can rework at least some of the drivers to a standard way, but I don't know what the standard is.

With your permission, I have cc:'ed your question to my original Debian
bug report,

From Documentation/fb/modedb.txt:
---
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):
...

From this I believe that 'mode_option' is the standard way, It also
indicates that the parameter name itself is optional, but I am not sure
if there is an overall Linux standard for indicating optional parameter
names.

Kind regards,

Alain

P.S.: Krzysztof, maybe it would be a good idea to update fbmode.txt
too, as there are now many more framebuffer drivers which support video
mode naming.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[Alain Kalker]

On Tue, 2008-02-05 at 12:42 +0100, Alain Kalker wrote:
> P.S.: Krzysztof, maybe it would be a good idea to update fbmode.txt
> too, as there are now many more framebuffer drivers which support video
> mode naming.

I have to rephrase that, the situation is much more complicated (sigh).
The only pattern I see is that drivers which support ModeDB (e.g.
i810fb) use the parameter name 'video_mode' which can then be optional,
while others (e.g. cirrusfb) use hardcoded video modes and _require_ the
parameter name to be present, which must then be called 'mode'.

Kind regards,

Alain

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[Alain Kalker]

On Tue, 2008-02-05 at 13:09 +0100, Alain Kalker wrote:
> parameter name 'video_mode'

That should be 'mode_option'.
Need More Coffee ASAP

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: mode_option or mode parameter (was: i810fb module parameter 'mode_option' inconsistent with other framebuffer modules)

[Randy Dunlap]

On 05 Feb 2008 08:08:10 +0100 krzysztof.h1@poczta.fm wrote:

> Hi,
> 
> Few days ago, a bug was reported that the i810fb uses "mode_option" parameters while other framebuffers uses the "mode" parameter to set initial mode. It was spotted later that some drivers uses "mode_option", some uses "mode" and some does use none.
> 
> I want to ask what is a correct way. I can rework at least some of the drivers to a standard way, but I don't know what the standard is.

Hi,
Hopefully one of the fbdev driver developers will know for sure.

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.

Thanks.
---
~Randy

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/