mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-22 20:23:57 +08:00
b24413180f
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>
450 lines
16 KiB
Plaintext
450 lines
16 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0
|
|
#
|
|
# For a description of the syntax of this configuration file,
|
|
# see Documentation/kbuild/kconfig-language.txt.
|
|
#
|
|
# 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.
|
|
|
|
config CHARLCD
|
|
tristate "Character LCD core support" if COMPILE_TEST
|
|
|
|
if AUXDISPLAY
|
|
|
|
config HD44780
|
|
tristate "HD44780 Character LCD support"
|
|
depends on GPIOLIB || COMPILE_TEST
|
|
select CHARLCD
|
|
---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/auxdisplay/cfag12864b
|
|
|
|
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.
|
|
|
|
config IMG_ASCII_LCD
|
|
tristate "Imagination Technologies ASCII LCD Display"
|
|
default y if MIPS_MALTA || MIPS_SEAD3
|
|
select SYSCON
|
|
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 && OF && I2C && INPUT
|
|
select FB_SYS_FOPS
|
|
select FB_SYS_FILLRECT
|
|
select FB_SYS_COPYAREA
|
|
select FB_SYS_IMAGEBLIT
|
|
select INPUT_MATRIXKMAP
|
|
select FB_BACKLIGHT
|
|
help
|
|
Say yes here to add support for Holtek HT16K33, RAM mapping 16*8
|
|
LED controller driver with keyscan.
|
|
|
|
endif # AUXDISPLAY
|
|
|
|
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.
|
|
|
|
config PANEL
|
|
tristate "Parallel port LCD/Keypad Panel support"
|
|
depends on PARPORT
|
|
select CHARLCD
|
|
---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 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).
|
|
|
|
config PANEL_CHANGE_MESSAGE
|
|
bool "Change LCD initialization message ?"
|
|
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.
|
|
|
|
endif # PANEL
|