linux/drivers/auxdisplay/Kconfig

520 lines
18 KiB
Plaintext
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
# SPDX-License-Identifier: GPL-2.0
#
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/kconfig-language.rst.
#
# Auxiliary display drivers configuration.
#
menuconfig AUXDISPLAY
bool "Auxiliary Display support"
help
Say Y here to get to see options for auxiliary display drivers.
This option alone does not add any kernel code.
If you say N, all options in this submenu will be skipped and disabled.
if AUXDISPLAY
config CHARLCD
tristate "Character LCD core support" if COMPILE_TEST
help
This is the base system for character-based LCD displays.
It makes no sense to have this alone, you select your display driver
and if it needs the charlcd core, it will select it automatically.
This is some character LCD core interface that multiple drivers can
use.
config LINEDISP
tristate "Character line display core support" if COMPILE_TEST
help
This is the core support for single-line character displays, to be
selected by drivers that use it.
config HD44780_COMMON
tristate "Common functions for HD44780 (and compatibles) LCD displays" if COMPILE_TEST
select CHARLCD
help
This is a module with the common symbols for HD44780 (and compatibles)
displays. This is the code that multiple other modules use. It is not
useful alone. If you have some sort of HD44780 compatible display,
you very likely use this. It is selected automatically by selecting
your concrete display.
config HD44780
tristate "HD44780 Character LCD support"
depends on GPIOLIB || COMPILE_TEST
select HD44780_COMMON
help
Enable support for Character LCDs using a HD44780 controller.
The LCD is accessible through the /dev/lcd char device (10, 156).
This code can either be compiled as a module, or linked into the
kernel and started at boot.
If you don't understand what all this is about, say N.
config KS0108
tristate "KS0108 LCD Controller"
depends on PARPORT_PC
default n
help
If you have a LCD controlled by one or more KS0108
controllers, say Y. You will need also another more specific
driver for your LCD.
Depends on Parallel Port support. If you say Y at
parport, you will be able to compile this as a module (M)
and built-in as well (Y).
To compile this as a module, choose M here:
the module will be called ks0108.
If unsure, say N.
config KS0108_PORT
hex "Parallel port where the LCD is connected"
depends on KS0108
default 0x378
help
The address of the parallel port where the LCD is connected.
The first standard parallel port address is 0x378.
The second standard parallel port address is 0x278.
The third standard parallel port address is 0x3BC.
You can specify a different address if you need.
If you don't know what I'm talking about, load the parport module,
and execute "dmesg" or "cat /proc/ioports". You can see there how
many parallel ports are present and which address each one has.
Usually you only need to use 0x378.
If you compile this as a module, you can still override this
using the module parameters.
config KS0108_DELAY
int "Delay between each control writing (microseconds)"
depends on KS0108
default "2"
help
Amount of time the ks0108 should wait between each control write
to the parallel port.
If your LCD seems to miss random writings, increment this.
If you don't know what I'm talking about, ignore it.
If you compile this as a module, you can still override this
value using the module parameters.
config CFAG12864B
tristate "CFAG12864B LCD"
depends on X86
depends on FB
depends on KS0108
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
default n
help
If you have a Crystalfontz 128x64 2-color LCD, cfag12864b Series,
say Y. You also need the ks0108 LCD Controller driver.
For help about how to wire your LCD to the parallel port,
check Documentation/admin-guide/auxdisplay/cfag12864b.rst
Depends on the x86 arch and the framebuffer support.
The LCD framebuffer driver can be attached to a console.
It will work fine. However, you can't attach it to the fbdev driver
of the xorg server.
To compile this as a module, choose M here:
the modules will be called cfag12864b and cfag12864bfb.
If unsure, say N.
config CFAG12864B_RATE
int "Refresh rate (hertz)"
depends on CFAG12864B
default "20"
help
Refresh rate of the LCD.
As the LCD is not memory mapped, the driver has to make the work by
software. This means you should be careful setting this value higher.
If your CPUs are really slow or you feel the system is slowed down,
decrease the value.
Be careful modifying this value to a very high value:
You can freeze the computer, or the LCD maybe can't draw as fast as you
are requesting.
If you don't know what I'm talking about, ignore it.
If you compile this as a module, you can still override this
value using the module parameters.
auxdisplay: img-ascii-lcd: driver for simple ASCII LCD displays Add a driver for simple ASCII LCD displays found on the MIPS Boston, Malta & SEAD3 development boards. The Boston display is an independent memory mapped device with a simple memory mapped 8 byte register space containing the 8 ASCII characters to display. The Malta display is exposed as part of the Malta board registers, and provides 8 registers each of which corresponds to one of the ASCII characters to display. The SEAD3 display is slightly more complex, exposing an interface to an S6A0069 LCD controller via registers provided by the boards CPLD. However although the displays differ in their register interface, we require similar functionality on each board so abstracting away the differences within a single driver allows us to share a significant amount of code & ensure consistent behaviour. The driver displays the Linux kernel version as the default message, but allows the message to be changed via a character device. Messages longer then the number of characters that the display can show will scroll. This provides different behaviour to the existing LCD display code for the MIPS Malta or MIPS SEAD3 platforms in the following ways: - The default string to display is not "LINUX ON MALTA" or "LINUX ON SEAD3" but "Linux" followed by the version number of the kernel (UTS_RELEASE). - Since that string tends to be significantly longer it scrolls twice as fast, moving every 500ms rather than every 1s. - The LCD won't be updated until the driver is probed, so it doesn't provide the early "LINUX" string. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: David S. Miller <davem@davemloft.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14062/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-08-26 17:17:49 +03:00
config IMG_ASCII_LCD
tristate "Imagination Technologies ASCII LCD Display"
depends on HAS_IOMEM
default y if MIPS_MALTA
select MFD_SYSCON
select LINEDISP
auxdisplay: img-ascii-lcd: driver for simple ASCII LCD displays Add a driver for simple ASCII LCD displays found on the MIPS Boston, Malta & SEAD3 development boards. The Boston display is an independent memory mapped device with a simple memory mapped 8 byte register space containing the 8 ASCII characters to display. The Malta display is exposed as part of the Malta board registers, and provides 8 registers each of which corresponds to one of the ASCII characters to display. The SEAD3 display is slightly more complex, exposing an interface to an S6A0069 LCD controller via registers provided by the boards CPLD. However although the displays differ in their register interface, we require similar functionality on each board so abstracting away the differences within a single driver allows us to share a significant amount of code & ensure consistent behaviour. The driver displays the Linux kernel version as the default message, but allows the message to be changed via a character device. Messages longer then the number of characters that the display can show will scroll. This provides different behaviour to the existing LCD display code for the MIPS Malta or MIPS SEAD3 platforms in the following ways: - The default string to display is not "LINUX ON MALTA" or "LINUX ON SEAD3" but "Linux" followed by the version number of the kernel (UTS_RELEASE). - Since that string tends to be significantly longer it scrolls twice as fast, moving every 500ms rather than every 1s. - The LCD won't be updated until the driver is probed, so it doesn't provide the early "LINUX" string. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: David S. Miller <davem@davemloft.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14062/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-08-26 17:17:49 +03:00
help
Enable this to support the simple ASCII LCD displays found on
development boards such as the MIPS Boston, MIPS Malta & MIPS SEAD3
from Imagination Technologies.
config HT16K33
tristate "Holtek Ht16K33 LED controller with keyscan"
depends on FB && I2C && INPUT
select FB_SYS_FOPS
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
select INPUT_MATRIXKMAP
select FB_BACKLIGHT
select NEW_LEDS
select LEDS_CLASS
select LINEDISP
help
Say yes here to add support for Holtek HT16K33, RAM mapping 16*8
LED controller driver with keyscan.
config LCD2S
tristate "lcd2s 20x4 character display over I2C console"
depends on I2C
select CHARLCD
help
This is a driver that lets you use the lcd2s 20x4 character display
from Modtronix engineering as a console output device. The display
is a simple single color character display. You have to connect it
to an I2C bus.
config ARM_CHARLCD
bool "ARM Ltd. Character LCD Driver"
depends on PLAT_VERSATILE
help
This is a driver for the character LCD found on the ARM Ltd.
Versatile and RealView Platform Baseboards. It doesn't do
very much more than display the text "ARM Linux" on the first
line and the Linux version on the second line, but that's
still useful.
menuconfig PARPORT_PANEL
tristate "Parallel port LCD/Keypad Panel support"
depends on PARPORT
select HD44780_COMMON
help
Say Y here if you have an HD44780 or KS-0074 LCD connected to your
parallel port. This driver also features 4 and 6-key keypads. The LCD
is accessible through the /dev/lcd char device (10, 156), and the
keypad through /dev/keypad (10, 185). This code can either be
compiled as a module, or linked into the kernel and started at boot.
If you don't understand what all this is about, say N.
if PARPORT_PANEL
config PANEL_PARPORT
int "Default parallel port number (0=LPT1)"
range 0 255
default "0"
help
This is the index of the parallel port the panel is connected to. One
driver instance only supports one parallel port, so if your keypad
and LCD are connected to two separate ports, you have to start two
modules with different arguments. Numbering starts with '0' for LPT1,
and so on.
config PANEL_PROFILE
int "Default panel profile (0-5, 0=custom)"
range 0 5
default "5"
help
To ease configuration, the driver supports different configuration
profiles for past and recent wirings. These profiles can also be
used to define an approximative configuration, completed by a few
other options. Here are the profiles :
0 = custom (see further)
1 = 2x16 parallel LCD, old keypad
2 = 2x16 serial LCD (KS-0074), new keypad
3 = 2x16 parallel LCD (Hantronix), no keypad
4 = 2x16 parallel LCD (Nexcom NSA1045) with Nexcom's keypad
5 = 2x40 parallel LCD (old one), with old keypad
Custom configurations allow you to define how your display is
wired to the parallel port, and how it works. This is only intended
for experts.
config PANEL_KEYPAD
depends on PANEL_PROFILE="0"
int "Keypad type (0=none, 1=old 6 keys, 2=new 6 keys, 3=Nexcom 4 keys)"
range 0 3
default 0
help
This enables and configures a keypad connected to the parallel port.
The keys will be read from character device 10,185. Valid values are :
0 : do not enable this driver
1 : old 6 keys keypad
2 : new 6 keys keypad, as used on the server at www.ant-computing.com
3 : Nexcom NSA1045's 4 keys keypad
New profiles can be described in the driver source. The driver also
supports simultaneous keys pressed when the keypad supports them.
config PANEL_LCD
depends on PANEL_PROFILE="0"
int "LCD type (0=none, 1=custom, 2=old //, 3=ks0074, 4=hantronix, 5=Nexcom)"
range 0 5
default 0
help
This enables and configures an LCD connected to the parallel port.
The driver includes an interpreter for escape codes starting with
'\e[L' which are specific to the LCD, and a few ANSI codes. The
driver will be registered as character device 10,156, usually
under the name '/dev/lcd'. There are a total of 6 supported types :
0 : do not enable the driver
1 : custom configuration and wiring (see further)
2 : 2x16 & 2x40 parallel LCD (old wiring)
3 : 2x16 serial LCD (KS-0074 based)
4 : 2x16 parallel LCD (Hantronix wiring)
5 : 2x16 parallel LCD (Nexcom wiring)
When type '1' is specified, other options will appear to configure
more precise aspects (wiring, dimensions, protocol, ...). Please note
that those values changed from the 2.4 driver for better consistency.
config PANEL_LCD_HEIGHT
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "Number of lines on the LCD (1-2)"
range 1 2
default 2
help
This is the number of visible character lines on the LCD in custom profile.
It can either be 1 or 2.
config PANEL_LCD_WIDTH
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "Number of characters per line on the LCD (1-40)"
range 1 40
default 40
help
This is the number of characters per line on the LCD in custom profile.
Common values are 16,20,24,40.
config PANEL_LCD_BWIDTH
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "Internal LCD line width (1-40, 40 by default)"
range 1 40
default 40
help
Most LCDs use a standard controller which supports hardware lines of 40
characters, although sometimes only 16, 20 or 24 of them are really wired
to the terminal. This results in some non-visible but addressable characters,
and is the case for most parallel LCDs. Other LCDs, and some serial ones,
however, use the same line width internally as what is visible. The KS0074
for example, uses 16 characters per line for 16 visible characters per line.
This option lets you configure the value used by your LCD in 'custom' profile.
If you don't know, put '40' here.
config PANEL_LCD_HWIDTH
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "Hardware LCD line width (1-64, 64 by default)"
range 1 64
default 64
help
Most LCDs use a single address bit to differentiate line 0 and line 1. Since
some of them need to be able to address 40 chars with the lower bits, they
often use the immediately superior power of 2, which is 64, to address the
next line.
If you don't know what your LCD uses, in doubt let 16 here for a 2x16, and
64 here for a 2x40.
config PANEL_LCD_CHARSET
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "LCD character set (0=normal, 1=KS0074)"
range 0 1
default 0
help
Some controllers such as the KS0074 use a somewhat strange character set
where many symbols are at unusual places. The driver knows how to map
'standard' ASCII characters to the character sets used by these controllers.
Valid values are :
0 : normal (untranslated) character set
1 : KS0074 character set
If you don't know, use the normal one (0).
config PANEL_LCD_PROTO
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "LCD communication mode (0=parallel 8 bits, 1=serial)"
range 0 1
default 0
help
This driver now supports any serial or parallel LCD wired to a parallel
port. But before assigning signals, the driver needs to know if it will
be driving a serial LCD or a parallel one. Serial LCDs only use 2 wires
(SDA/SCL), while parallel ones use 2 or 3 wires for the control signals
(E, RS, sometimes RW), and 4 or 8 for the data. Use 0 here for a 8 bits
parallel LCD, and 1 for a serial LCD.
config PANEL_LCD_PIN_E
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO="0"
int "Parallel port pin number & polarity connected to the LCD E signal (-17...17) "
range -17 17
default 14
help
This describes the number of the parallel port pin to which the LCD 'E'
signal has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'E' pin in custom profile is '14' (AUTOFEED).
config PANEL_LCD_PIN_RS
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO="0"
int "Parallel port pin number & polarity connected to the LCD RS signal (-17...17) "
range -17 17
default 17
help
This describes the number of the parallel port pin to which the LCD 'RS'
signal has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'RS' pin in custom profile is '17' (SELECT IN).
config PANEL_LCD_PIN_RW
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO="0"
int "Parallel port pin number & polarity connected to the LCD RW signal (-17...17) "
range -17 17
default 16
help
This describes the number of the parallel port pin to which the LCD 'RW'
signal has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'RW' pin in custom profile is '16' (INIT).
config PANEL_LCD_PIN_SCL
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO!="0"
int "Parallel port pin number & polarity connected to the LCD SCL signal (-17...17) "
range -17 17
default 1
help
This describes the number of the parallel port pin to which the serial
LCD 'SCL' signal has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'SCL' pin in custom profile is '1' (STROBE).
config PANEL_LCD_PIN_SDA
depends on PANEL_PROFILE="0" && PANEL_LCD="1" && PANEL_LCD_PROTO!="0"
int "Parallel port pin number & polarity connected to the LCD SDA signal (-17...17) "
range -17 17
default 2
help
This describes the number of the parallel port pin to which the serial
LCD 'SDA' signal has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'SDA' pin in custom profile is '2' (D0).
config PANEL_LCD_PIN_BL
depends on PANEL_PROFILE="0" && PANEL_LCD="1"
int "Parallel port pin number & polarity connected to the LCD backlight signal (-17...17) "
range -17 17
default 0
help
This describes the number of the parallel port pin to which the LCD 'BL' signal
has been connected. It can be :
0 : no connection (eg: connected to ground)
1..17 : directly connected to any of these pins on the DB25 plug
-1..-17 : connected to the same pin through an inverter (eg: transistor).
Default for the 'BL' pin in custom profile is '0' (uncontrolled).
endif # PARPORT_PANEL
config PANEL_CHANGE_MESSAGE
bool "Change LCD initialization message ?"
depends on CHARLCD
default "n"
help
This allows you to replace the boot message indicating the kernel version
and the driver version with a custom message. This is useful on appliances
where a simple 'Starting system' message can be enough to stop a customer
from worrying.
If you say 'Y' here, you'll be able to choose a message yourself. Otherwise,
say 'N' and keep the default message with the version.
config PANEL_BOOT_MESSAGE
depends on PANEL_CHANGE_MESSAGE="y"
string "New initialization message"
default ""
help
This allows you to replace the boot message indicating the kernel version
and the driver version with a custom message. This is useful on appliances
where a simple 'Starting system' message can be enough to stop a customer
from worrying.
An empty message will only clear the display at driver init time. Any other
printf()-formatted message is valid with newline and escape codes.
choice
prompt "Backlight initial state"
default CHARLCD_BL_FLASH
help
Select the initial backlight state on boot or module load.
Previously, there was no option for this: the backlight flashed
briefly on init. Now you can also turn it off/on.
config CHARLCD_BL_OFF
bool "Off"
help
Backlight is initially turned off
config CHARLCD_BL_ON
bool "On"
help
Backlight is initially turned on
config CHARLCD_BL_FLASH
bool "Flash"
help
Backlight is flashed briefly on init
endchoice
endif # AUXDISPLAY
config PANEL
tristate "Parallel port LCD/Keypad Panel support (OLD OPTION)"
depends on PARPORT
select AUXDISPLAY
select PARPORT_PANEL