Files
lcdproc/docs/lcdproc-user/drivers/picolcd.docbook
T

314 lines
12 KiB
Plaintext

<sect1 id="picolcd">
<title>The Mini-Box USB LCD (picoLCD 20x2) Driver (picolcd)</title>
<para>
This section covers the installation and use of the Mini-Box USB LCD (picoLCD
20x2) display.
</para>
<para>
The picoLCD page indicates that the device can be connected via I<superscript>2</superscript>C
or USART.
This LCDproc driver, however, is limited to the USB connected model.
</para>
<sect2 id="picolcd-setup">
<title>Setting up the picoLCD</title>
<para>
The picoLCD device as used by this driver is USB connected and may be purchased
with an internal USB header connector (5-pin to 5-pin) or an external cable
(Type-A to 5-pin). See: <ulink url="http://www.mini-box.com/picoLCD-20x2-OEM"/>.
It may also come pre-installed on systems like the Mini-Box M300:
<ulink url="http://www.mini-box.com/Mini-Box-M300-LCD"/>.
</para>
<para>
Building and using the USB LCD with this driver requires the
<filename>libusb</filename> library.
Most distributions do provide this library.
The only kernel module required is the USB host controller driver
(<filename>uhci_hcd</filename> on the M300) to fire up the USB bus
to which the LCD is attached.
</para>
<para>
Lastly, the <filename>usbfs</filename> file system must be mounted on
<filename>/proc/bus/usb</filename>, e.g. using the command
<code>mount -t usbfs usbfs /proc/bus/usb</code> or by your disptributions
default configuration.
</para>
<para>
You can also change the USB LCD's initial display (what it shows when you
initialize the device) by using the <command>usblcd</command> binary's
<command>splash</command> command.
</para>
<para>
To use the picoLCD with LCDproc, add <literal>picolcd</literal>
to the LCDproc <code>./configure</code> <code>--drivers</code> option
(or use <literal>all</literal>), set the <code>Driver=</code> to
<literal>picolcd</literal> in the <filename>LCDd.conf</filename> config
file, and then start <application>LCDd</application> either directly or using startup scripts.
The driver has sane default options and the options that are user configurable
are limited to mostly simple items, like contrast and which keys to light up.
</para>
</sect2>
<sect2 id="picolcd-config">
<title>Configuration in LCDd.conf</title>
<sect3 id="picolcd-config-section">
<title>[picolcd]</title>
<variablelist>
<varlistentry>
<term>
<command>Contrast</command> =
<arg choice="plain"><replaceable>CONTRAST</replaceable></arg>
</term>
<listitem><para>
Contrast: <literal>0</literal>-<literal>1000</literal>.
<literal>0</literal> is visible, and <literal>1000</literal> is not on my M300.
Default is <literal>0</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term>
<command>KeyLights</command> =
<arg choice="plain">
<group choice="req">
<arg choice="plain"><literal><emphasis>yes</emphasis></literal></arg>
<arg choice="plain"><literal>no</literal></arg>
</group>
</arg>
</term>
<listitem><para>
Allow key LEDs to be turned on or off. Default is <literal>yes</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term>
<command>Key0Light</command> =
<arg choice="plain">
<group choice="req">
<arg choice="plain"><literal><emphasis>yes</emphasis></literal></arg>
<arg choice="plain"><literal>no</literal></arg>
</group>
</arg>
</term>
<listitem><para>
If <command>Keylights</command> is set, you can disable the directional pad LED by
setting this value to <literal>no</literal>. Default is <literal>yes</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term>
<command>Key1Light</command> =
<arg choice="plain">
<group choice="req">
<arg choice="plain"><literal><emphasis>yes</emphasis></literal></arg>
<arg choice="plain"><literal>no</literal></arg>
</group>
</arg>
</term>
<listitem><para>
If <command>Keylights</command> is set, you can disable the F1 LED by setting this value
to <literal>no</literal>. Default is <literal>yes</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term>
<command>Key2Light</command> =
<arg choice="plain">
<group choice="req">
<arg choice="plain"><literal><emphasis>yes</emphasis></literal></arg>
<arg choice="plain"><literal>no</literal></arg>
</group>
</arg>
</term>
<listitem><para>
If <command>Keylights</command> is set, you can disable the F2 LED by setting this value
to <literal>no</literal>. Default is <literal>yes</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term>
<command>Key3Light</command> =
<arg choice="plain">
<group choice="req">
<arg choice="plain"><literal><emphasis>yes</emphasis></literal></arg>
<arg choice="plain"><literal>no</literal></arg>
</group>
</arg>
</term>
<listitem><para>
If <command>Keylights</command> is set, you can disable the F3 LED by setting this value
to <literal>no</literal>. Default is <literal>yes</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term>
<command>Key4Light</command> =
<arg choice="plain">
<group choice="req">
<arg choice="plain"><literal><emphasis>yes</emphasis></literal></arg>
<arg choice="plain"><literal>no</literal></arg>
</group>
</arg>
</term>
<listitem><para>
If <command>Keylights</command> is set, you can disable the F4 LED by setting this value
to <literal>no</literal>. Default is <literal>yes</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term>
<command>Key5Light</command> =
<arg choice="plain">
<group choice="req">
<arg choice="plain"><literal><emphasis>yes</emphasis></literal></arg>
<arg choice="plain"><literal>no</literal></arg>
</group>
</arg>
</term>
<listitem><para>
If <command>Keylights</command> is set, you can disable the F5 LED by setting this value
to <literal>no</literal>. Default is <literal>yes</literal>.
</para></listitem>
</varlistentry>
<varlistentry>
<term>
<command>KeyTimeout</command> =
<arg choice="plain"><replaceable>DURATION</replaceable></arg>
</term>
<listitem><para>
(Advanced) This value controls how long <application>LCDd</application> waits for a key press when
get_key() is called. The value represents microseconds and the default is <literal>500</literal>
or .5 seconds. Lowering this value will make LCDd more responsive but also causes LCDd to use
more CPU time and, as the timeout grows shorter, key presses become harder to detect.
Larger values make key presses more reliable if somewhat slow to take effect.
</para></listitem>
</varlistentry>
<varlistentry>
<term>
<command>LircHost=</command>
<arg choice="plain"><replaceable>HOSTNAME_OR_IP-ADDRESS</replaceable></arg>
</term>
<listitem>
<para>
Set the hostname or IP address to which the driver will send IR data from the sensor.
If not set or set to an empty value, IR support for LIRC will be disabled.
</para>
<para>
LIRC should be configured to use the driver "udp", which will cause it to listen on some
UDP port for packets containing a series of integers, representing pulse and mark
intervals from the sensor. It doesn't matter whether LCDd or LIRC is started first; if LIRC
isn't listening, the packets from LCDd will be discarded. When LIRC comes back, it will
start picking up the packets. Similarly, LCDd can be stopped and restarted without affecting
anything, because UDP is a connectionless protocol.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>LircPort=</command>
<arg choice="plain"><replaceable>PORTNUM</replaceable></arg>
</term>
<listitem>
<para>
This value determines the UDP port to which the driver will send IR data from the sensor. It
defaults to <literal>8765</literal>, which is also the default port on which LIRC will listen.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>LircSync=</command>
<arg choice="plain"><replaceable>DURATION</replaceable></arg>
</term>
<listitem>
<para>
This value determines the length in jiffies (1/16384 seconds) of the synthesized sync pulse added
to the beginning of the UDP packet sent to LIRC. Values up to 255 are permitted. Setting a length
of zero will suppress the synthesized pulse (I can't make it work without it, though). The default is
<literal>64</literal> jiffies (3.9ms).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>LircLength=</command>
<arg choice="plain"><replaceable>DURATION</replaceable></arg>
</term>
<listitem>
<para>
This value determines the length in jiffies (1/16384 seconds) of the entire LIRC code for a single remote
command. It depends on the notion that all commands are of the same duration, and are padded with a trailing
gap (space) to make up the time. No such gap is emitted by the picolcd hardware. Values up to MAXINT are permitted.
Setting a length of zero will suppress the synthesized gap. The default is 2048 jiffies (125ms).
</para>
</listitem>
</varlistentry>
</variablelist>
</sect3>
</sect2>
<sect2 id="picolcd-status">
<title>picolcd driver status</title>
<para>
The lcdproc picolcd driver relies upon Mini-Box's usblcd library to setup the USB/HID
interface. Unfortunately the usblcd library is very thin and tends to put function
results on stdout/stderr instead of in return values. They (Mini-Box) really had
scripting interfaces in mind.
</para>
<para>
The primary example of this is that I had to write a replacement (get_key_events) for
usblcd's read_events so that I could get the key presses back to the calling function
instead of on stdout. usblcd also has a large number of function shells for which no
code exists yet. I am not an expert on HID and USB coding, but if and as time permits
and hardware is available I will try and improve this drivers access to the hardware in
order to get back data (get_contrast for example) and to potentially drive multiple
pcioLCDs at once (or pick the one we want out of many).
</para>
<para>
To sum up, this driver right now stabs and hopes since response data is lacking.
</para>
<para>
The hardware also reports key-up events. Normally this would be of no issue (they are
usually a 0 or 'no key') except that when keys are used in combonation, the key-up
event may actually come back as multiple events depending on how the user released the
keys. If the key-up event for a multiple key press comes back as two events, the first
up event will actually look like a new key press. The algorithm in get_key tries to
deal with this in a sane way and toss out all key-up events for now. The hardware is
touchy and both combo key-down and key-up actions may be reported as mutiple events if
the user is more than a tenth of a second (maybe less?) off in motions.
</para>
<sect3 id="picolcd-ir-status">
<title>Infrared sensor status</title>
<para>
LIRC expects sensor data that starts with a longish 'sync' space, denoting the start of
a command; followed by the code data, a sequence of mark/space pairs; sometimes followed by
a 'gap', which should be a space long enough to make the entire command up to a preset
duration in milliseconds. The 'sync' and the 'gap' are absent from the data
emitted by the picolcd hardware. I found that LIRC configuration files for remotes similar to the
ones I tested all used such a fixed-duration encoding, and as that was the only way I could get it
working, this driver by default adds the gap as well as the sync. However I have
<emphasis>still</emphasis> had trouble getting <code>irrecord</code> to work; you need at least
to feed it a template configuration containing sync and gap data.
</para>
<para>
This code could therefore use more testing, more research, and more work.
</para>
</sect3>
</sect2>
<sect2 id="picolcd-copy">
<title>Copyright</title>
<para>
The lcdproc picolcd driver originally was written by Gatewood Green (woody@nitrosecurity.com)
or (woody@linif.org) and paid for by NitroSecurity, Inc (nitrosecurity.com),
but has been extended with code from various contributors since then.
</para>
</sect2>
</sect1>