Commit graph

8 commits

Author SHA1 Message Date
Ulf Magnusson eddd98f811 kconfig: Replace some single-symbol 'if's with 'depends on'
I think people might be reading differences into 'if' and 'depends on'
that aren't there, like maybe 'if' being needed to "hide" a symbol,
while 'depends on' just adds a dependency.

There are no differences between 'if' and 'depends on'. 'if' is just a
shorthand for 'depends on'. They work the same when it comes to creating
implicit menus too.

The way symbols get "hidden" is through their dependencies not being
satisfied ('if'/'depends on' get copied up as a dependency on the
prompt).

Since 'if' and 'depends on' are the same, an 'if' with just a single
symbol in it can be replaced with a 'depends on'. IMO, it's best to
avoid 'if' there as a style choice too, because it confuses people into
thinking there's deep Kconfig magic going on that requires 'if'.

Going for 'depends on' can also remove some nested 'if's, which
generates nicer symbol information and docs, because nested 'if's really
are so simple/dumb that they just add the dependencies from both 'if's
to all symbols within.

Replace a bunch of single-symbol 'if's with 'depends on' to despam the
Kconfig files a bit and make it clearer how things work. Also do some
other minor related dependency refactoring.

The replacement isn't complete. Will fix up the rest later. Splitting it
a bit to make it more manageable.

(Everything above is true for choices, menus, and comments as well.)

Detected by tweaking the Kconfiglib parsing code. It's impossible to
detect after parsing, because 'if' turns into 'depends on'.

Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-08 08:32:42 -05:00
Ulf Magnusson bd6e04411e kconfig: Clean up header comments and make them consistent
Use this short header style in all Kconfig files:

    # <description>

    # <copyright>
    # <license>

    ...

Also change all <description>s from

    # Kconfig[.extension] - Foo-related options

to just

    # Foo-related options

It's clear enough that it's about Kconfig.

The <description> cleanup was done with this command, along with some
manual cleanup (big letter at the start, etc.)

    git ls-files '*Kconfig*' | \
        xargs sed -i -E '1 s/#\s*Kconfig[\w.-]*\s*-\s*/# /'

Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-11-04 17:31:27 -05:00
Johann Fischer fc57ea8d3c drivers: ssd1673: rename driver to ssd16xx
ssd1673 driver supports different controllers,
rename it to more generic ssd16xx.

Signed-off-by: Johann Fischer <j.fischer@phytec.de>
2019-07-04 07:27:09 -04:00
Sebastian Bøe 0438657193 kconfig: Have the 'framebuffer' menu depend on it being enabled
As this was written before, a 'Framebuffer' menu entry was present,
and to see what kind of features or configuration it had, one had to
navigate into the menu to determine if anything related to
'Framebuffer' was enabled at all.

Now there is an unchecked box on the 'framebuffer' menu when it is
disabled, which clearly expresses that it is disabled without the need
to enter the menu entry.

This change only changes the menu layout, and not the dependencies of
any options.

Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-12-30 16:24:50 -05:00
Diego Sueiro 20e4567bab shell: Add initial code for Character Framebuffer shell module
This adds the config option and files of the Character Framebuffer
shell module

Signed-off-by: Diego Sueiro <diego.sueiro@gmail.com>
2018-12-07 10:21:02 -05:00
Anas Nashif 4e2c9d1491 Revert "shell: Add initial code for Character Framebuffer shell module"
This reverts commit 2e27113eec.

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-12-06 11:39:44 -05:00
Diego Sueiro 2e27113eec shell: Add initial code for Character Framebuffer shell module
This adds the config option and files of the Character Framebuffer
shell module

Signed-off-by: Diego Sueiro <diego.sueiro@gmail.com>
2018-12-06 09:55:15 -05:00
Johann Fischer f531e0d62e subsys: add monochrome character framebuffer
Add monochrome character framebuffer for monochrome
graphic dot matrix displays and electrophoretic displays.

These displays are mostly monochrome and can only display
black and some other color, for example white. Typically,
a byte controls 8 pixels, arranged vertically or horizontally
depending on the controller or settings.
The API is not suitable to display graphics, the purpose is
to display text or symbols. It is possible to use several fonts.
A font can also consist of graphic symbols only and thus,
for example, enable the realization of a menu.

Signed-off-by: Johann Fischer <j.fischer@phytec.de>
2018-10-16 14:54:47 -04:00