diff --git a/Makefile.am b/Makefile.am index e1d7d1e..17687f8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -7,7 +7,7 @@ SUBDIRS = shared clients server docs scripts sysconf_DATA = LCDd.conf -EXTRA_DIST = $(sysconf_DATA) CREDITS README.IRman contrib +EXTRA_DIST = $(sysconf_DATA) CREDITS contrib dist-hook: diff --git a/README.IRman b/README.IRman deleted file mode 100644 index 355ee3a..0000000 --- a/README.IRman +++ /dev/null @@ -1,65 +0,0 @@ -Hello, - -I made a IRman input driver for lcdproc-0.4 wich is now include in -"lcdproc-0.4-pre6". This input driver require "libirman-0.4.1b" the -library with function support for IRman. - -I want to help you use this new driver (if anybody other than me use -it... please tell me!!!). - -In order to help you compile your own version of LCDd with support for -IRman, I recorded every step I took in order to compile my own copy -based on two file downloaded directly from the internet. - -The first file is " lcdproc-0.4-pre6.tar.gz " the current version of -lcdproc. You can download this file from -"http://lcdproc.omnipotent.net/download.php3" The second file is -"libirman-0.4.1b.tar.gz" the current version of libirman. You can -download this file from http://www.evation.com/libirman/ DO NOT USE -THE COPY OF LIBIRMAN FROM LCDPROC HOME PAGE... I don't know what is -wrong with that one but I can't decompress it??? - -How to compile lcdproc for use with support for IRman: - --Untar lcdproc and libirman: - tar -xzvf lcdproc-0.4-pre6.tgz - tar -xzvf libirman$$$ --Go, configure and compile libirman: - cd libirman-0.4.1b/ - ./configure - make - cd .. --Go in lcdproc directory: - cd lcdproc-0.4-pre6 --Here is the modification you need to include IRman driver in lcdproc: - edit Makefile.config - # Irman input... handy! - DRIVERS += -DIRMANIN_DRV - DOBJ += irmanin.o ../../../libirman-0.4.1b/libirman.a - IRMAN=1 --Compile lcdproc - make --Make sure you have a network interface up and working: - ifup lo --Go and install your IRman configuration file: - cd server - cd drivers - cp DOTirmanrc ~/.irmanrc --Modify if needed (if you use another remote control) the .irmanrc file. --Run LCDd with two driver, irmanin and an output driver: - ./LCDd -d irmanin "-d /dev/ttyS0" -d curses --Try to access the menu by pressing the remote control. - -Now if it does not work: -· Try your IRMAN on ttyS0 alone (with other software). -· Try LCDd without the IrmanIN driver. -· ... - -David GLAUDE - -PS: If you really have successfuly made LCDd working without IRman AND -You have successfuly made IRman device working AND you don't succeed -to make it work together ussing my driver... then maybe I can help and -give you some support (as time permit and if it does not eat up too -much bandwidth). - diff --git a/docs/Makefile.am b/docs/Makefile.am index 24f167c..d45c36e 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -4,12 +4,7 @@ man_MANS = lcdproc.1 lcdexec.1 LCDd.8 lcdproc-config.5 SUBDIRS = lcdproc-user lcdproc-dev doxygen_input = header.html footer.html -EXTRA_DIST = README.dg \ - README.dg2 \ - README.glcdlib \ - menustuff.txt \ - netstuff.txt \ - lcdproc.1.in \ +EXTRA_DIST = lcdproc.1.in \ lcdexec.1 \ LCDd.8.in \ lcdproc-config.5.in \ diff --git a/docs/README.dg b/docs/README.dg deleted file mode 100644 index 7b08f54..0000000 --- a/docs/README.dg +++ /dev/null @@ -1,68 +0,0 @@ -William W. Ferrell (choadster@earthlink.net) -Scott Scriven (scriven@cs.colostate.edu). - -Hello, -I am the happy new owner of a matrix-orbital LK-204-25 V. -I also made computer science studies (but currently I only program for fun). -The reason why I wanted this LCD screen was to build a MAME/MPEG3/DVD player. -Currently the IR receaver is missing, but I already started to work on my -project by checking LCDPROC capability and trying to make it work the way I -want. - -I don't know yet if my developpement will be a client of LCDPROC or if I will -make a stand-alone program (more likely reussing some of your code). -Currently, feature in LCDPROC don't cover yet my need yet. -So, my best option is to support you or your team in building the perfect -server in order for me to build only a client. - -So, I downloaded v0.4-pre5 and started to hack. ;-) -I was a little bit confuse with your documentation, sometime talking about -version 0.3.x or about comming feature, but reading the source code (and -the sgml description that I only founded later) was the best. - -I made some "minor" change to a few source file (this is what I remember): - * Cleaning the help screen from LCDd. - * Adding a speed option to MtxOrb driver. - * Updated MtxOrb help screen to indicate those change. - * Added some error checking to parameter sended to MtxOrb driver. - * Added fake support for big number into curses driver. - * Some modification to the debug_driver in order to compile. - * Added bignum widget in order to use that feature from the driver. - * Added big cloc[K] (24H) to lcdproc to test the new widget. (ugly/blinking) - * Added a General Purpose Output function to the MtxOrb driver. - -Here is some kind of todo-list one liner only: - * Implement a debug/error to a syslog server rather than printf(stderr,... - * General Purpose Output support. - * Make "LCDproc Server" and "End Screen" (build-in screen) optionnal. - * Make HeartBeat working with General Purpose Output (led blinking). - * KeyPad support. - * Make KeyPad local feedback using General Purpose Output (led blinking). - * Make the server port number (listen) a param/config option. - * Accept incoming 'telnet' (specific port) as a new i/o device (vt100/ansi). - * MtxOrb driver across an outgoing 'telnet' session (access server). - -My major todo: - * Well, I would like to (one way or another) interconnect IrMan(?) and - LCDProc. I will use LCDProc for the ouput of the name of the song, ... - and maybe for keyboard input. I will also use IrMan or some infrared - library in order to receave remote controle input. Now, I would be nice - to be able to connect to LCDProc and 'register' a new input and/or output - device. - What I am thinking about is to have LCDd be a server with local device - to manage, but also have remote device that could attach themself to - LCDd. I think, by reading your documentation, that you have somethink like - that already in mind. This will allow dynamic addition of new driver without - having to recompile LCDd... - -Change you should make yourself: - * Update the network protocol description with heartbeat function. - * Remove reference/out of date description related to 0.3.x - -I made many change to a lot of different file... (sorry) -I don't have the tool/knowledge available to give you a patch with only my -modification. So, I send you a taz.gz with everything after my change. -I won't have much time to spend on LCDPROC for about two week (and the -week-end in between). This give you time to check my change and incorporate -anything you find interesting. - diff --git a/docs/README.dg2 b/docs/README.dg2 deleted file mode 100644 index 7fb7346..0000000 --- a/docs/README.dg2 +++ /dev/null @@ -1,79 +0,0 @@ -Hello, - -In order to compile LCDd (the lcdproc server) with support for IRman, -you need to put libirman in a neighbor directory. -Currently I use version 0.4.1b and this is hard coded into makefile and -#include string. (could do better). - -Now for libirman to "work" you need a .irmanrc file with description of -you infrared "code" and mapping to command in my driver. -A template of such a file is given in the driver directory. This template -will only work with my JVC remote control, but you already have configured -IRman, you should be able to modify it for yours. - -David GLAUDE - -FINDING THE COMPONENT: - -lcdproc: deamon to display information on a lcd screen. - version: 0.4-pre5 - need libirman and my driver to support input from IrMan. - -libirman: library in use to read input from IrMan on a serial port. - version used: 0.4.1b - currently used untouch and just needed to use my driver for lcdproc. - ------------Here stop the currently usefull information------------ - -The following text describe a project I never finished: LCDCD. -If anybody wish to do such an LCDd client, have a look at cdtools. - -David GLAUDE - -lirc: standardize interface to control IR receaver and emetteur. - version: 0.5.4 - currently not used but might be usefull have support for other IR. - -cdtools: command line program to control the cdrom and play audio cd. - might need some patch to have a better output of cd song information. - -Hello, - -This file describe the personnal developpement I have made and wich sources -you need to bring together in order to integrate everything the same way -I did. - -Basicaly, we are talking about a yet another CD player 'yaCDplayer' but -because the name might already have been in use, it was decided to call it -'lcdcd'. - -This CD player take as input (control) and output (display of the status) the -lcdproc server. It as thus no user interface on it's own. -Lcdproc is a server that allow the control of LCD screen over TCP connection. -Some LCD screen also have support to connect a keypad, it also offer -input user interface for this program. -Because lcdproc is a very flexible input/output server, it also support for -input comming from a joystic, the keyboard (curses output) or even irman. -It also support multiple driver simultaniously and multiple driver like curses -and joystic for those without an LCD screen and an irman. - -Now irman is an infrared receaver with a build in chip to hash the input -signal into a unique key that can be readed throught a serial interface. - -An other important think about lcdcd it is that in order to communicate with -lcdproc we use a TCP/IP connection. Lcdproc need to run in background on the -server where the input/output device are connected. Lcdcd must run on the -client where the cdrom is located. In between, we need to have a TCP/IP -network. Now, if you have a firewall, you will let traffic from the client to -the server on port 13666 wich is the default for lcdproc, be carefull there -is not security build in lcdproc and anybody can connect to it. If you don't -have an IP network and the client and the server are located on a single -computer (with the CDROM, the LCD screen and the IrMan connected) then you -need to enable IP on this computer. This can be done by putting an IP address -on a loopback interface (like 127.0.0.1 on lo, try 'ifup lo' it might work -also on your distribution of Linux). - -Currently, this ... ---to be continued--- - - - diff --git a/docs/README.glcdlib b/docs/README.glcdlib deleted file mode 100644 index 9765498..0000000 --- a/docs/README.glcdlib +++ /dev/null @@ -1,8 +0,0 @@ -The so-called "meta-driver" glcdlib extends LCDproc's supported drivers by -all the drivers supported by graphlcd-base, which you can get from -http://graphlcd.berlios.de. -In order to be able to use it, you have to get and install the glcdprocdriver -from http://www.muresan.de/graphlcd/lcdproc before configuring the LCDproc -build process --enable-drivers=glcdlib. - -Lucian Muresan diff --git a/docs/hd44780_howto.txt b/docs/hd44780_howto.txt deleted file mode 100644 index 90ed82c..0000000 --- a/docs/hd44780_howto.txt +++ /dev/null @@ -1,696 +0,0 @@ -HD44780 HOWTO -------------- - -There are several ways of wiring up the HD44780 devices. Your choice -will probably be governed largely by your ability to wire up each one -and/or a desire to use the device with other programs. - -The LCDproc HD44780 driver supports the following connections on a -parallel port: - - 4-bit - - 8-bit (winamp style) - - extended 8-bit (LCD + LED bargraph) - - serial LPT -And supports a PIC-an-LCD connected to a serial port. - -The driver also lets you use multiple displays as a single virtual -display. For example, a 4, 2 and 1 line display can be used to form a -7 line display. The number of displays is limited by the individual -HD44780 driver. - - -1. Connections --------------- - -1.1 Common connections for all connectiontypes ------------------------------------------------ - -No matter what connectiontype you choose, you will always need some -connections. They are explaned here. - - -1.1.1 Power ------------- - -All variants use the same method of obtaining power. i.e., for each LCD: - - LCD pin signal - 1 GND (connect to any of pins 18 - 25 of you parallel port) - 2 +5V - 3 Vadj (contrast) - -WARNING: Always double check your power connection, your display probably - wont survive a reversely connected supply ! - -There are several ways to get 5V: - -- Connect to a 5V line intented for disk drives (the red wire is 5V, black - is GND). -- Get it from a joystick port (pin 1 and 9 are 5V, 4, 5 and 12 are GND). - It seems that some soundcards can use these lines for communication, so - if you want to use this first check wether it really gives a 'clean' 5V. -- If you don't have a backlight, you can sometimes get the needed mA's from - the LPT port itself. Connect a few diodes from the data pins to a - capacitor and you have the 5V. If it's strong enough is another question... -- Get it from the keyboard connector. I do not recommend to use this with a - backlight, as the keyboard connector is often protected with a fuse of - 100mA or 200mA. - -Connecting the contrast adjusting pin (Vadj.): - - (variable resistor) - .------. - Vcc ---| 10k |--- GND - `---^--' - /|\ - | - Vadj. - - -1.1.2 Keypad -------------- - -You can connect a keypad with all connection types. The maximum supported -number of keys differs per type. There are several ways to connect the keys -to the input pins. - - -1.1.2.1 Direct keys --------------------- - -If you connect a key like sketched below, then you can only connect one key -per input pin. It is a simple solution if you need only few keys. - - O 5V - | - | - - - | | 10k - | | - - - | - +-----------o input (X) - | - | - o - \ - o - | - | - === GND - -By default, the following keystrokes are generated by the different keys: - -X0 A -X1 B -X2 C -X3 D -X4 E - -You should modify and recompile the driver to get other keystrokes. - - -1.1.2.2 Matrix keys --------------------- - -Using a matrix, we can connect much more keys. To simplify the drawing here, -we replace all switches with an @ symbol: - - - X line - | - | - Y line ---+--------- - | | | - o | = --@-- - \ | | - o | - | | - +---+ - | - | - -We connect the matrix of keys like this: - -Y0 o---|<---@--@--@ - | | | -Y1 o---|<---@--@--@ - | | | -Y2 o---|<---@--@--@ - | | | -Y3 o---|<---@--@--@ O 5V - | | | | - diodes | | | ___ | - 1N4148 +----------|___|---+ - | | | ___ | - | +-------|___|---+ - | | | ___ | - | | +----|___|---+ resistors 22k - | | | - o o o - X0 X1 X2 - -As you can see, you need 1 resistor per X line, and 1 diode per Y line. -Lcdproc will presume that you have a keypad with a layout like a telephone -connected, with X and Y lines connected as show. To be more precise, it -assumes this: - - X0 X1 X2 X3 - -Y0 1 2 3 A -Y1 4 5 6 B -Y2 7 8 9 C -Y3 * 0 # D - -If you only need 10 keys, leave the rest away. However, the lcdproc menu is -controlled by the keystrokes A to D. You should modify and recompile the -driver to get an other keypad layout. - -You can buy arrays of keys that are connected like this in the electronics -shop. They usually call it a matrix keypad. To hook it to lcdproc, you -would only need to add the resistors and diodes. - -If you want to use just one return line, for example with the serialLpt -wiring, it looks (completely drawn) like this: - - O 5V - | - .-. - | | 4k7 or 22k - diodes | | - 1N4148 '-' - ___ | -Y0 o---|<---o o---+ - ___ | -Y1 o---|<---o o---+ - ___ | -Y2 o---|<---o o---+ - ___ | -Y3 o---|<---o o---+----o return line - - -If the driver generates keypresses without you actually pressing a key, -it might be that the unconnected input lines are picking up -electromagnetic waves from the air. In that case connect the unconnected -input lines (pin 10, 11, 12, 13 and 15 of the LPT) to VCC = 5V. - - -1.1.3 Backlight ---------------- - -A small extension allows you to switch the backlight of the display on -and off. At the moment only the 4bit and winamp connection types support -this. The extension uses one output pin, you cannot use that pin for other -functions anymore. The wiring looks like this: - - O 5V - ___ | - +---|___|---+ -LPT Sub-D connector | 4k7 | - | |e - ___ | b |/ - BL pin o------------|___|---+---------| - 1k |\ - bc327 |c - | LCD connector - | - +--------o 15 backlight - - +--------o 16 GND backlight - | - === GND - -Note: 4k7 means 4,7 kohm. -The BC327 transistor has the following connections: - - _____ - | | - |bc327| - |_____| - | | | - | | | - | | | - c b e - -Sometimes the backlight connections are not on the 'main' connector, but on -the side. If that is the case, there is usually NO RESISTOR present to limit -the current through the LEDs. Therefor you should then add a resistor after -the transistor of about 10 ohm (see display documentation). - -If you want the backlight to light a bit while it's switched 'off', you can -add a resistor bypassing the transistor from e to c, with a value of, say -47ohm or 22ohm. (My 4x20 has an internal resistor of 6ohm, so with 47 ohm -extra it lights at only 1/9th. I like this. Joris.) - - -1.2 4-bit ----------- - -This is originally based on "lcdtext" (by Matthias Prinke). - -The pinouts are: - - printer port LCD - - D0 (2) D4 (11) - D1 (3) D5 (12) - D2 (4) D6 (13) - D3 (5) D7 (14) - D4 (6) RS (4) - D5 (7) RW (5) (LCD3 - 6) (optional - pull all LCD RW low) - D6 (8) EN (6) - D7 (9) EN2 (LCD2 - 6) (optional) - -If you want to connect more than two displays to the parallel port then -wire D5 (pin 7) to the enable line (pin 6) of the third LCD. Then for -displays four to seven use: - - printer port LCD - - STR (1) EN4 - LF (14) EN5 - INIT (16) EN6 - SEL (17) EN7 - -The optional keypad can be connected as follows: - - printer port keypad - - D0 (2) Y0 - D1 (3) Y1 - D2 (4) Y2 - D3 (5) Y3 - D4 (6) Y4 - D5 (7) Y5 - nSTRB (1) Y6 - nLF (14) Y7 - INIT (16) Y8 - nSEL (17) Y9 - - nACK (10) X0 - BUSY (11) X1 - PAPEREND (12) X2 - SELIN (13) X3 - nFAULT (15) X4 - -The optional backlight wiring should be connected to D5, pin 7. - - -1.3 8-bit "Winamp" -------------------- - -This type of connection should work with winamp. - - printer port LCD - - D0 (2) D0 (7) - D1 (3) D1 (8) - D2 (4) D2 (9) - D3 (5) D3 (10) - D4 (6) D4 (11) - D5 (7) D5 (12) - D6 (8) D6 (13) - D7 (9) D7 (14) - nSTRB (1) EN (6) - nLF (14) nRW (5) (EN3 6 - LCD 3) (optional) - INIT (16) RS (4) - nSEL (17) EN2 (6 - LCD 2) (optional) - -If you want the display to work with the Winamp plugin, wire nLF (pin 14) -to nRW of your LCD. You can then use the plugin in bidirectional mode (wich -is much faster). With 3 connected LCDs this is not possible. -Note from Benjamin: I haven't tried using winamp while having the third LCD -connected to this line. - -The optional keypad can be connected as follows: - - printer port keypad - - D0 (2) Y0 - D1 (3) Y1 - D2 (4) Y2 - D3 (5) Y3 - D4 (6) Y4 - D5 (7) Y5 - D6 (8) Y6 - D7 (9) Y7 - nLF (14) Y8 - INIT (16) Y9 - - nACK (10) X0 - BUSY (11) X1 - PAPEREND (12) X2 - SELIN (13) X3 - nFAULT (15) X4 - -The optional backlight wiring should be connected to nSEL, pin 17. - - -1.4 Extended 8-bit "lcdtime" ------------------------------ - -This is originally based on "lcdtime" (by Benjamin Tse -) and allows you to combine the LCD with a LED -bargraph. The LCD is driven by LCDproc and the LEDs by another program -such as portato. Further details can be obtained from: - -http://metalab.unc.edu/pub/linux/system/status/lcdtime-0.2.tar.gz -http://metalab.unc.edu/pub/linux/system/status/meter-0.2.tar.gz -http://metalab.unc.edu/pub/linux/system/status/portato-1.2.tar.gz - -Theoretically this wiring sends the data over twice as slow as the -winamp or ext8bit wirings, because it only sends 4 bits at a time. - -The LCD connections are: - - printer port LCD - - D0 (2) D0 (7) - D1 (3) D1 (8) - D2 (4) D2 (9) - D3 (5) D3 (10) - D4 (6) D4 (11) - D5 (7) D5 (12) - D6 (8) D6 (13) - D7 (9) D7 (14) - nSEL (17) - - nSTRB (1) RS (4) - nLF (14) RW (5) (LCD2 - 6) (optional - pull all LCD RW low) - INIT (16) EN (6) - -See the lcdtime tar-ball (above) for full details of the bargraph -connections. - -The optional keypad can be connected as follows: - - printer port keypad - - D0 (2) Y0 - D1 (3) Y1 - D2 (4) Y2 - D3 (5) Y3 - D4 (6) Y4 - D5 (7) Y5 - D6 (8) Y6 - D7 (9) Y7 - nSTRB (1) Y8 - nSEL (17) Y9 - - nACK (10) X0 - BUSY (11) X1 - PAPEREND (12) X2 - SELIN (13) X3 - nFAULT (15) X4 - -The backlight wiring should be attached to nSEL, pin 17. Because the portato -program (mentioned above) also uses this pin to control the bargraph, you -cannot use the backlight control together with the bargraph. - - -1.5 Serial LPT ---------------- - -This interface uses a handful of wires to interface to the -HD44780. Suitable for high noise, long connections. Designed by -Andrew McMeikan . The original wiring and -driver can be found at: -http://members.xoom.com/andrewmuck - -I (Joris) have extended this driver and the wiring a bit. It now supports -keys again (it had earlier supported keys, but some time did not). - -Further I have extended the driver and the wiring to be able to run -using 2 instead of 3 output pins. That's even one less pin ! :) - -Of course the use of fewer lines than the other wirings can not stay -without drawbacks. In this case the simplicity of the long feeding wires -is compensated by some intelligence in the decoding of the data. If you -have no experience with the soldering iron, I do not recommend to build -this wiring. - -OK, so here is the wiring. First of the 'simple' 3 wires version. IC1 is -the shift register, a 4094. Do not forget to connect the 5V to pin 16 and -GND to pin 8 of the IC. - - IC1 - ----------- - | 4094 | - 5V | shift reg | display - O | | /keys - | 1| |3 - +----|STR Q0|---------------------o 7 D0 - | | |4 /Y0 - Data | 2| Q1|---------------------o 8 D1 - D3 5 o---------------------------|D |5 /Y1 - | | Q2|---------------------o 9 D2 - | 3|CK |6 /Y2 - D4 6 o---------------------------| Q3|---------------------o 10 D3 - | | |10 /Y3 - | 15| Q4|---------------------o Y4 - +----|OE |11 - | Q5|---------------------o 4 RS - | |12 /Y5 - | Q6|---------------------o Y6 - | |13 - | Q7|---------------------o Y7 - | |9 - | QS|-- +--o 5 RW - | __|10 | - | QS|-- === - | | - ----------- - - - D2 4 o-------------------------------------------------------------o 6 EN - - D7 9 o-------------------------------------------------------------o 6 EN2 - (2nd LCD) - - - 5V O-----+--------+----------------------------------+-----o 2 VCC - | | | - | | | - |100n O 16 .-. - --- IC1 | |<---o 3 Vlcd - --- O 8 | |10k - | | '-' - GND | | | - 18..25 o-----------+--------+--------------------------+-------+-----o 1 GND - | - === GND - - - -The second possible wiring is with 2 output lines. This one is a bit more -complex. If you do not understand the schematic, do not build it. - - IC2 - ----------- - | 74HCT164 | - | shift reg | display - | | /keys - Data 1| |3 - D3 5 o-----------------------+---|D Q0|---------------------o 7 D0 - | | |4 /Y0 - | 2| Q1|---------------------o 8 D1 - +---|D |5 /Y1 - | Q2|---------------------o 9 D2 - | |6 /Y2 - | Q3|---------------------o 10 D3 - | |10 /Y3 - Clock 8| Q4|---------------------o Y4 - D4 6 o---------------------------|CK |11 - | Q5|---------------------o 4 RS - ___ 9|\ 8 9|_ |12 /Y5 - +--|___|--+----| >o----|R Q6|---------------------o Y6 - | 22k | |/ | |13 - | --- IC1 | Q7|---+ +--o 5 RW - | --- | | | 5V | - | |100p ----------- | O === - | | | | - | === | .-. - | | | |22k - +--------------------------------------+ | | - | '-' - | ___ 11|\ 10 | 5|\ 6 - +--|___|--+----| >o-------------------||----+-----| >o---o 6 EN - 22k | |/ 22p |/ - --- IC1 IC1 - --- - |22p - | IC1=74HCT14 (6x Schmitt trigger inverter) - === - - - 5V O--+-------+------+------+------------------------+-----o 2 VCC - | | | | 13|\ 12 | - | | | +---| >o- | - |100n O 14 O 14 |/ .-. - --- IC1 IC2 | |<---o 3 Vlcd - --- O 7 O 7 1|\ 2 3|\ 4 | |10k - | | | +--| >o- +--| >o- '-' - GND | | | | |/ | |/ | - 18..25 o--------+-------+------+-------+----------+-----+------+-----o 1 GND - | - === GND - - -1.6 PIC-an-LCD serial device "picanlcd" ----------------------------------------- - -The PIC-an-LCD module is also supported. It is not connected to the LPT port -but to a serial port, which saves you from a lot of potential problems. -To use it, specify the device to which you have connected the module in the -config file with the Device= setting. The default is /dev/lcd. -It does not support a keypad nor backlight switching. - -1.7 LIS2 Usb device -=================== - -LIS2 from VLSystem (http://www.vlsys.co.kr) is a full featured usb vfd module -with four channel fan controls. This device can be access as a serial device with -help of the kernel modules ftdi_sio wich map the usb port to a serial port (/dev/ttyUSBx). - -To use LIS2 with LCDproc, you will need a few settings in the config file : - -[server] - Driver=hd44780 - -[hd44780] - size=20x2 - ConnectionType=lis2 - #Device=/dev/ttyUSB0 - extendedmode=false - -Size of the display (size=20x2), driver to use in ConnectionType: lis2, the serial Usb -device as device settings (default is /dev/ttyUSB0), and extendedmode should be left to false, -as this device don't seems to support hd44780 extended mode. - -The device support only a subset of the hd44780 specification. For now, I find this function: - -Function #1 : Clear Screen - -Send char(0) -Send char(160) -Send char(0) -Send char(167) - -Function #2 : Cursors move: (x,y) - -Send char(0) -Send char(160 + y) -Send char(x) -Send char(167) - -Function #3 : Write a char - -Send char(asciiCode) : asciiCode 0 to 7 can be redefine to user charset (see below). - -Function #4 : Redefine a char - -Send char(0) -Send char(171) -Send char(matriceNum) : Ascii code of char to refine, from 0 to 7 -Send char(line) : the line to change -Send char(pixel) : define wich pixel of the line is on or off. -There's 5 pixels by line, adresse by power of 2, from right to left (16, 8, 4, 2, 1). - -Function #5 : Fan Control - -Send char(0) -Send char(174) -Send char(0) -Send char(0) -Send char(fan1) -Send char(0) -Send char(fan2) -Send char(0) -Send char(fan3) -Send char(0) -Send char(fan4) -Send char(0) -Send char(0) - -fanX is a value from 0 to 255, 0 is fan off, 255 is fan full speed. - - - - -1.5.1 Keypad ------------- - -To understand this part of the serialLpt documentation, you also need to -read the keypad section in this document. - -serialLpt wiring supports a keypad. The 3 wires version supports -8 keys, or if you use multiple return lines up to 8 x 5 = 40 lines. The -2 wires version supports 7 keys, or with multiple return lines -7 x 5 = 35 keys. - -The return lines are the following: - - nACK (10) X0 - BUSY (11) X1 - PAPEREND (12) X2 - SELIN (13) X3 - nFAULT (15) X4 - -On lines longer than, say a meter, you should buffer the return line(s). -If you only have 1 return line, you can buffer it with two remaining -buffers from the 74HCT14: - - 1|\ 2 13|\ 12 ___ - keypad o-----| >o------| >o---|___|---+---o input pin on LPT port - return |/ |/ 220E | - IC1 IC1 --- - --- 1nF - | - === - -Also a backlight is suported. You will also need a port from the 74HCT14 for -that. The BL output below should be connected to the BL input in paragraph -1.1.3. - - ___ 3|\ 4 - Data o-----|___|--+----| >o----o BL output - LPT-D3 470k | |/ - --- IC1 - --- - |100nF - | - === - - -2. Compiling ------------- - -Make sure that the HD44780 files are built when you run configure. This -can be done by specifying "--enable-drivers=all" or by -"--enable-drivers=hd44780". - - -3. Running ----------- - -Modify the LCDd.conf file before you run LCDd. In this config file are -detailed instructions on how to configure the HD44780 driver. - -Then as usual, start LCDd with the correct config file: - LCDd -c ./LCDd.conf -for example. - -If you want to override the driver selection in LCDd.conf then use: - LCDd -c ./LCDd.conf -d HD44780 -If you use this, the HD44780 driver will read the options from the config -file. - - -4. Miscellania ---------------- - -This text originally taken from a message by Bill Farrow -. - -Updated February 2000, Benjamin Tse (blt@ComPorts.com) - -Updated October 2001, Joris Robijn (joris at robijn.net) diff --git a/docs/menustuff.txt b/docs/menustuff.txt deleted file mode 100644 index c2ab663..0000000 --- a/docs/menustuff.txt +++ /dev/null @@ -1,144 +0,0 @@ -CAUTION: -This file may contain outdated information. -In order to find current information about the LCDproc client-server -protocol see the LCDproc Administrator's Guide in docs/lcdproc-dev/ - - -======================================================================== - - -Menus - -This file originally described how the menus should become implemented. -Now that they are implemented, the description is also in the source: -server/menu.h. The current menu contents can be found in server/menus.c. -Reading these files it becomes easy to understand the menus. - -I (Joris) have given the file you are reading a new purpose: -client-supplied menus. - -fixme: some of this stuff is described better in - ./docs/lcdproc-dev/language.docbook so this file should - probably be removed after extracting the information that is - not anywhere else; see also ./docs/netstuff.txt (Volker) - - -INTERNAL SERVER DATA - -In the server dir there is a file named client_menus.h from 3 april 2000 -which describes the data structures that we should probably need. - -typedef struct client_menu { - char id[]; - LL *items; -} client_menu; - -(LL is a list) - -typedef struct client_menu_item { - char id[]; - int type; // Title, function, submenu, slider, checkbox, etc... - int value; // Holds stuff like "true", 43, etc... - char text[]; // Text to display here... - char child[]; // For the "submenu" type -} client_menu; - - - -DEFINING BY CLIENTS - -To define a menuitem using the widget language the following functions have -been defined in the file client_functions.c: -(In my opinion the menu_add functions can be left away, because a submenu -is an item as well.) - -menu_add_item -menu_del_item -menu_set_item - -The functions are not implemented yet, but looking at what we need, the -parameters could look like this: - -menu_add_item itemname itemstring itemtype [-m menu] -v initvalue -menu_del_item itemname -menu_set_item itemname [-v value] [-s itemstring] - -You should not need to define the first menu of a client. The name of the -client is known and will be used to give the menu a name. The first level -menu will simply be created automatically when a client defines an item in -it's menu. -(Or is there any reason why the client should create its own menu ? A client -should not be able to create two main menus anyway) - -The following item types exist: -title A title to be used on the top of the menu. -menu A submenu. Refer to this new menu using the -m option. -action An action. The client is notified that the user wants the - action to be executed. -checkbox A checkbox. The client is notified whenever the state is - changed. -slider A checkbox. The client is notified whenever the slider is - moved. - -fixme: missing description of numeric, alpha, ip, ..., see - ./docs/lcdproc-dev/language.docbook (Volker) - -Note that I have changed the 'function' menu type to 'action' here. The name -'function' was only appropriate internally, because a function was called. -For clients we only know an action will be performed. - -fixme: missing reference to lcdexec (Volker) - - -RETURNED DATA - -The server should inform the client on events. It should be able to return -strings like: - -action itemname -checkbox itemname newvalue -slider itemname newvalue - - -EXAMPLE SESSION - -We have an M3 player here. - -menu_add_item action play "Play" -menu_add_item action stop "Stop" -menu_add_item menu tracks "Select Track" -menu_add_item action track1 "1: Leg" -menu_add_item action track2 "2: Palomine" -menu_add_item action track3 "3: Kid's allright" -menu_add_item action track4 "4: brain-Tag" -menu_add_item menu CDs "Select CD" -menu_add_item action cd1 "1: Bettie Serveert - Palomine" -menu_add_item action cd2 "2: Rammstein - Herzeleid" -menu_add_item slider volume "Volume" - -When you should switch CD using the second submenu, the client will be -informed with: - -action cd2 - -Then the client knows the user has selected the second CD, and the items of -the Track menu should be changed according to the contents of the CD: - -menu_set_item track1 -s "1: Wollt ihr das bett in flammen sehen" -menu_set_item track2 -s "2: Der meister" -menu_set_item track3 -s "3: Weisses fleish" - -When the user changes the volume slider, the client will be informed with: - -slider volume 40 - -When it is set at 40%. - - - -fixme: missing description of menu_goto for session control (Volker) - - --- -Complete rewrite, Joris Robijn, 20011015 - diff --git a/docs/netstuff.txt b/docs/netstuff.txt deleted file mode 100644 index afa6ac6..0000000 --- a/docs/netstuff.txt +++ /dev/null @@ -1,313 +0,0 @@ -CAUTION: -This file may contain outdated information. -In order to find current information about the LCDproc client-server -protocol see the LCDproc Administrator's Guide in docs/lcdproc-dev/ - - - -======================================================================== - - -LCDproc client/server protocol, V0.2 ---------------------------------------------- - -fixme: most of this stuff is described better in - ./docs/lcdproc-dev/language.docbook so this file should - probably be removed after extracting the information that is - not anywhere else; see also ./docs/menustuff.txt (Volker) - -QUICKSTART ----------- - - Open a socket to the LCDproc port (usually 13666). - - say "hello" - - the server will notify you of a good connection, and some info - on the type of display available. - - Identify yourself. "client_set name some_sort_of_name" - - Add a new screen. "screen_add my_screen" - - Put a widget on the screen. - "widget_add my_screen my_widget string" - - Now, update the widget whenever your status info changes... - "widget_set my_screen my_widget 1 1 Booger!" - - - When you're done, just close the socket. - - You probably want to read on for more information, once you've - gotten the LCDproc server to display something. :) - - - -DETAILS -------- - -There are two parts to the spec: - A language for client/server to interact with. - A protocol guiding interactions. - -=================== The protocol ================================== - -The protocol is context-free. So, no commands require responses; and -responses are simply commands. - -The client may send updated info at any time, and the server decides -whether to display it. An ideal communication may flow like this: - client->server server->client - ------------------ ------------------- - (idle) (nothing) - (idle) "I'm listening" - new stats... (nothing; displays updated stats) - new stats... (nothing...) - new stats... (nothing...) - new stats... "Okay, be quiet" - (idle) (nothing; displays new screen) - ... ... - (idle) "Your slider moved up" - Set slider value: 43 (nothing; displays updated slider) - (idle) (nothing) - ... ... -But the client could safely continue to send new stats, knowing that -the server isn't listening and won't display it. Also, the client could -ignore the slider change, and the slider onscreen simply wouldn't move. - - -=================== The syntax ================================== - -The language is ascii-based, so a human can telnet to a port and talk -to the server. This helps with development and debugging. - -With that in mind, a commandline-like syntax seems good: - - function arg1 arg2 arg3 ... - -The syntax dictates that the first word is a function name, and the -rest of the line is passed to that function as an argument. -String-type arguments should always come last. So, for example: - - set_label 23 3 2 Hey, booger. What's up? - -The first argument is a label id number, the 2nd and 3rd are x,y -coordinates onscreen, and the rest of the line is a string. - - -=================== The command set ================================== - -The naming convention dictates that function names are lower-case, -with underscores ("_"'s) between words. - -The naming convention also requires that function-name words go in -descending order. So, "screen_set_priority" would be okay, but -"set_screen_priority" would not. - -Id's are strings. (the "#id" things) - -In general, we're trying to keep the command set small. Especially the -server->client functions, so that clients won't have to handle a lot of -different types of input. - -Now, the function list: - -client->server functions -------------------------- -hello - Client init. You must send this before the server will pay - any attention to you. You'll get some info about the server - in return... (a "connect" string) - - -client_set [-name #id] - Set client's name and other info - - -screen_add #id - Add a new screen - -screen_del #id - Remove a screen - -screen_set #id [-priority integer] [-name "my_name"] [-duration integer] - [-wid width] [-hgt height] [-heartbeat type] - Initialize a screen, or reset its data. - Heartbeat types can be: - on, heart "Heart" icon - normal, default User's choice - off, none None - slash Rotating slash - Priority values are as follows: - 0 You feel like getting kicked off the server, don't you? - 1 The world is about to explode - 16 Emergency priority - 32 Very high priority (important) - 64 High priority (normal) - 128 Normal (recommended) - 192 Low priority (normal) - 224 Very low priority (very unimportant) - 240 Boring as hell - 255 This screen won't show up very much even if there are - no other screens queued... - An example of using priorities is as follows. - - Imagine you're making an mp3 player for LCDproc. When the - song changes, it's nice to display the new name immediately. - So, you could set your screen's priority to 64, wait for - the server to display (or ignore) your screen, then set the - screen back to 128. This would cause the mp3 screen to - show up as soon as the one onscreen was finished, then - return to normal priority afterward. - - Or, let's say your client monitors the health of hospital - patients. If one of the patients has a heart attack, you - could set the screen priority to 16 (emergency), and it - would be displayed immediately. It wouldn't even wait for - the previous screen to finish. ... And it would stay there - most of the time until the user did something about it. - - A priority of 1 would stay onscreen permanently, with - flashing lights and other visual cues if possible. - ... Please *don't* use this priority. :) - - The duration can be either a positive number, or -1. A - positive number indicates how many display frames the screen - should last for. A 0 or -1 means that the server should use - "auto" duration, which is probably a good idea. This will be - whatever the user wants. It defaults to 4 seconds (32 - frames), or will be calculated for things such as scrollers. - -widget_add #screen #id type [-in #id] - Add something onscreen - Widget types can be any of the following: "string", "hbar", - "vbar", "title", "icon", "num" "scroller", "frame", ... more - later? Widgets are drawn in the order you create them. - - You can put a widget inside a frame by adding "-in #id", where - #id is the name of a frame. - -widget_del #screen #id - Kill something onscreen - -widget_set #screen #id data - Set (reset) widget's data - Note that the "string" type should be used for frame buffers. - Strings should not be bigger than the screen. - The widgets take these arguments for data: - - string x y text - - hbar x y length_in_pixels - - vbar x y length_in_pixels - - icon x y binary_data - - num x number_between_0_and_9 - - title text - - scroller left top right bottom direction speed text - - A scroller is a string which scrolls. - This is useful for things such as the disk - usage screen, which may be very tall. - The speed is how many display frames to delay - between scrolling. Each display frame is - 1/8th of a second, by default. - Direction must be "h" for horizontal, "m" for - marquee style horizontal or "v" for vertical - scrolling.. - Positive speeds indicate frames per movement. - Negative speeds indicate movements per frame. - - frame left top right bottom wid hgt dir speed - - Frames occupy the area (left, top)-(right,bottom) - onscreen, and the inside area is wid x hgt. - The inside may be bigger than the actual size, - so that the frame will scroll. - - -server->client functions -------------------------- -connect args - Verifies connection; gives info about the LCD, etc... - -bye - Notifies the client of a server shutdown. - -huh? [info] - Notifies the client of a request error. - -listen [#screen [#widget [#widgets...]]] - Notifies client that "server is listening for data". - -ignore [#screen [#widget [#widgets...]]] - Tells the client "shut up". - -key #id - Sends a keypress to the client. - - -client->server functions -------------------------- -client_add_key #id - Tells the server the client can handle keypresses of type #id. - #id is just "Up", "Down", "Left", "Right", "Enter", "Escape", ... - All keypresses are disabled by default, so you'll have to tell - the server which ones you want to accept... - -client_del_key #id - Tells the server to never send that keypress. - All keypresses are disabled by default. - - -menu_add #id - Add a new menu. - -menu_del #id - Get rid of a menu. - -menu_set [top] [name my_menu_name] - if (top) Gets added to "Client Menus". - else Client must insert it into its own menu heirarchy. - -menu_item_add #menu #id - Add a new, blank menu item. - -menu_item_del #menu #id - Delete a menu item. - -menu_item_set #menu #id type [value] text - (re)Set the menu item's data. - If type is "checkbox" or "slider" or "menu", [value] should - contain appropriate info. (like true, 43, or #menuid) - - -backlight [on] [off] [blink] [flash] [toggle] - Requests that the backlight be toggled... The backlight - command will likely be ignored, but users can enable it if - desired. - - The LCDproc server has [will have] several backlight modes: - On Stays on all the time - Off Stays off all the time - Load? Turns off when the load average is low - Shell? Controlled by a user-supplied shell script - Open Can be controlled by all clients - Vis Controlled by the currently visible client - - -driver_add #id? type args - Start up a new output driver. - Nice if you want to check on your machine remotely with the - curses driver. - -driver_del #id? (or type) - Stop a running output driver. - Good for reclaiming your joystick when you want to play games... - - - - -server->client functions -------------------------- -menuevent #menu #item #action - Tells the client that a menu item was selected/used/etc... - The client should handle this according to what type of menu - item has been activated, and should probably send the server a - new item definition if the item was a checkbox or slider. diff --git a/server/drivers/README b/server/drivers/README index 94a9788..0317790 100644 --- a/server/drivers/README +++ b/server/drivers/README @@ -3,98 +3,5 @@ UNDERSTANDING LCDPROC DRIVERS LCDproc drivers are compiled as modules that will be loaded by the LCDd daemon's core on request. -To understand how to write a driver see docs/API-0.5.txt and the -section about the driver API in the Admin Guide. - - --------- 8< snip >8 ------------------ -The remainder of this file may be horribly outdated. -Treat the information contained herein with caution. -You have been warned. - - ------------------------------- lcd_logical_driver ------------------------------ - -The first thing that is done is that lcd_init (lcd.c) is called. This function -first sets up basic housekeeping details. Then it calls lcd_drv_init, which -initializes the basic functions for the lcd structure. - -Each function loops through the list of currently loaded and active drivers. -The framebuffer is set to point to the appropriate framebuffer. Then -the function determines what function to call (for each driver) - which -is one of three possibilities: - -1. driver->function() > 0 - - Call the driver function contained in driver->function(); - -2. driver->function() == NULL - - Ignore (no function); - -3. driver->function() == -1 - - Call the generic driver. - -The generic driver functions are drv_base_* and are contained in drv_base.c - -Note that these drv_base_* functions are also installed as part of the "base" -driver, and thus could be called not only once, but many times. - -So... to clear the screen (after initializing the drivers) one might do -this - and it leads to the sequence of activities shown... - -lcd.clear; - --> lcd_drv_clear; - --> driver->clear; - --> drv_base_clear; - --> driver->clear; - --> MtxOrb_clear; - --> driver->clear; - --> drv_base_clear; - --> driver->clear; - -In the first case, the "base" driver is called. In the second, the "MtxOrb" -driver is called, and it has a function to use. In the third, an unnamed -driver is called, but it delegates back to the base function. In the fourth, -the driver has no function; so it is ignored. - -SUGGESTED SIMPLIFICATIONS - -1. Remove the base driver entirely. - -The base driver does not provide any substantial advantage, and significantly -complicates code. - -2. Separate the input driver data from the output driver data. - -This promotes easier comprehension and allows more specialization of each. -Some drivers may only have input or output components; some may have both. -This also permits coding such that only one output device is allowed -while multiple input devices are allowed. - -3. Use only ONE output driver for each invocation of the server. - -This simplifies coding - since there is then only one size, one width, one -height. It also removes the need for scanning a big loop for functions to -execute. - -Given these enhancements, all of drv_base.c could be eliminated, and -probably most or all of lcd.c. It would dramatically reduce all of the -processing overhead necessary to handle screen output. - -MORE SUGGESTIONS AND ENHANCEMENTS - -1. Make input keys driver-specific. - -This permits the use of each and every key without overlap. For example, -it would keep a joystick button press from conflicting with a LCD display -button. - -2. Specify the standard (configurable) set of keys for server actions - in each driver. - -This permits not only a unique standard configuration for each device, -it also hides what that is from the program itself. If this is configurable, -it also makes it possible to adjust this set of keys during operation. - +To understand how to write a driver see docs/API-0.5.txt or the +section about the driver API in the Developer's Guide. diff --git a/server/drivers/ideas.txt b/server/drivers/ideas.txt deleted file mode 100644 index d778e4b..0000000 --- a/server/drivers/ideas.txt +++ /dev/null @@ -1,21 +0,0 @@ -Hmm... - -How to do multiple drivers... - - -lcd_sample_func(parameters) -{ - D'oh.. -} - -lcd_driver_caller() -{ - foreach driver (@drivers) - { - if(driver supports function) - call driver's function - else if(driver uses defaults) - call default function - else don't do anything - } -}