LCDProc 0.5.4-dev
-
-
Well, it works in that it doesn't crash - but there is no change to anything with the LCM.
How should I go about making sure the driver is even compatible? Check the wiring diagram with the h44780-lanner.c file?
The connector is very similar to the Firebox connector. It's like a small parallel port.
-
I'm not even sure what device this thing works as… /dev/parport0, /dev/lpt0 or /dev/ttyS0? They all don't work... Ugh...
I can't even get the FreeBSD LCD sample that shipped with my unit to work... :-\
-
Looks like it should be on lpt0 from the patch code. Assuming it's on 0x378 on your box.
Steve
-
Hmm… I checked the BIOS, looks like the LCM port might have been disabled. I set the parallel port to 0x378.
This is the output of "cd /dev/":
acpi ata cuau0.init fd md0 pf stdin ttyu1.lock ugen3.1 ad0 bpf cuau0.lock fido md1 ppi0 stdout ufs urandom ad0s1 bpf0 cuau1 geom.ctl mdctl ptmx ttyu0 ufsid usb ad0s1a console cuau1.init io mem pts ttyu0.init ugen0.1 usbctl ad0s2 crypto cuau1.lock klog nfslock random ttyu0.lock ugen0.2 xpt0 ad0s2a ctty devctl kmem null speaker ttyu1 ugen1.1 zero ad0s3 cuau0 devstat led pci stderr ttyu1.init ugen2.1Not sure what "led" is, but I don't see anything in here interesting…
...breaking news: The backlight shuts off now when LCDd is started... Not sure why everything else doesn't work.
-
Holy #$&$ it works.
I love you guys. :D
I guess if we can move this to 0.5.4, it can be put into lcdproc-dev
-
Good to hear. Try the sdeclcd driver again now that the parallel port is enabled in the BIOS.
-
Good to hear. Try the sdeclcd driver again now that the parallel port is enabled in the BIOS.
Doesn't look like the sdeclcd works. I think the Lanner version specifying "connectiontype=lanner" means there is something funky with the implementation.
Only issue I see about the lanner driver is that the backlight doesn't timeout (maybe I'm stupid and that's an LCDProc config) and enabling the heartbeat on LCDProc limits the screen updates and actually closes the window the key presses can be detected (I think.)
-
Years ago i had lcdproc working with pfsense on my IPC2U/Lanner FW 7550. DSH made a path to support the special hd44780 wiring on this box. But in the actual lcdproc package this patch seem to be missing. You can find the path here : http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/pfPorts/lcdproc/files/
Can someone include this into the current lcdproc package ?
-
Hi Marcom,
if you can let me have the .so driver compiled for version 0.5.4 (x86 and/or x64) I'll be glad to add it to the package!If you need any other configuration for that driver (heartbeat, blacklight, and so on) please tell me so I can include them in the driver's configuration.
Ciao,
Michele -
Hm, i dont know how to do that. I have the .so driver compiled for lcdproc version 0.5.1. See :
http://www.mfc-nordhorn.de/hd44780.so
Does this help ?
Can you compile the .so with the information given at : http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/pfPorts/lcdproc/files/ ?
-
mmhhh… if you already have the .so file, instead of publishing a new version of the package without knowing if it works or not, we could manage a 20 minutes skype + remote assistance session to test the driver on your box, and if it works I can include it in the package...
what do you think about it?
Ciao,
Michele -
Great idea. I am currently unavailable, but be on later this evening. I already tried to use my .so file. Than i get the error message that this file is missing :
libusb-0.1.so.8
-
mmhhh… if it does not find that library means the driver should be recompiled (I am almost sure that library is already included in 0.5.5). If you were able to get to this point, I think a remote-connection is not needed... ;)
Probably we could work on the "connection type" in the configuration. Look here:
[hd44780] ConnectionType=lcd2usband here:
http://lcdproc.sourceforge.net/docs/lcdproc-0-5-5-user.html#hd44780-howtoThe driver should be hd44780, if you find the correct combination of ConnectionType and port, probably we can skip the compile step. If we are lucky and find it, I can add a new "driver" that uses the same hd44780 driver and the connectiontype you discover.
Ciao,
Michele -
Marcom, according to this post:
http://comments.gmane.org/gmane.comp.sysutils.lcdproc/10937it should work on a parallel port (0x378).
-
Brak, Fmertz,
let me summaryze:
I should add a new driver from https://github.com/downloads/fmertz/sdeclcd/hd44780.so that I will rename "lcm-162 (x86)", then add a new port "lcd" (change: "led" port), is it correct?If this is correct I will do it asap…
Ciao,
Michele -
Truthfully, I'm not sure. The driver is for 0.5.2, and that's what I've used it with. I didn't seem to be able to get 0.5.4-dev working with it, but I don't know enough about the package to be able to get it working.
I would assume tho it would be better to call it the "Lanner LCM" driver/port since it's neither the HD44780 spec nor the LCM-162 spec (at least the comments on the patch make it seem that way.)
-
Truthfully, I'm not sure. The driver is for 0.5.2, and that's what I've used it with. I didn't seem to be able to get 0.5.4-dev working with it, but I don't know enough about the package to be able to get it working.
I would assume tho it would be better to call it the "Lanner LCM" driver/port since it's neither the HD44780 spec nor the LCM-162 spec (at least the comments on the patch make it seem that way.)
well, if the driver is for 0.5.2 I don't think it will work for 0.5.4. But if someone could compile it for 0.5.4 I could integrate with the name you just told…
Ciao,
Michele -
Brak,
If you can make the Lanner hardware available to me, I can come up with proper driver code for it. This thread is labeled 0.5.4, but I think the lcdproc-dev package is actually on the current production release 0.5.5 (New development is done against 0.5dev). We probably have enough of the base functionality to take it from here and get it working completely. I would hope we could get the big clock, vbars, hbars, maybe even special characters and menus. If there are enough differences with an existing driver (HD or sdeclcd), then I can submit a patch upstream so this would become supported going forward. I would make the driver against 0.5dev, and backport it to 0.5.5. I could test Linux and FreeBSD, and compile with OpenBSD and NetBSD to be sure. Let me know.
-
I have it working with the 0x378 port. My problem is, that on every reboot my LCDd.conf file is overwritten. Esp. the line ConnectionType=winamp is reverted ti ConnectionType=lcd2usb. How can i make my changes permanent ?
