LCDproc (dev) 0.5.6 and CrystalFontz 635 USB misery
Crypton last edited by
Been scavenging just about all forum threads and other resources, fiddling with LCDd.conf for the past few hours and I thought I'd just give some info on my progress in case anyone from the package maintainers or any other person stumbling finds this helpful.
Got a CrystalFontz 635 LCD with a USB interface. On Windows, it shows up as both a CrystalFontz device (their driver) and an additional serial port.
Decided to plug it into my pfsense box today. At first, neither the LCDproc (stable?) nor the LCDproc-dev packages appeared to do anything.
$ dmesg | grep fontz ugen0.2: <crystalfontz>at usbus0 uftdi0: <crystalfontz cfa-635="" usb="" lcd="">on usbus0</crystalfontz></crystalfontz>
So the device appears to be recognized by 2.2.2-RELEASE (amd64).
My initial configuration that never worked:
I tried all three combinations of CrystalFontz drivers. The "CrystalFontz Packet" driver seemed most to not blow up anything in the logs.
After some more pondering and beating my head against the keyboard, I decided to mod lcdproc.inc and lcdproc.xml (located in /usr/local/pkg for anyone wondering and doesn't know). I found some information that /dev/ttyU0 might work as well, but it's not possible to select it via the drop down (hence the mod).
After adding the option in the code (xml and validation functions in the .inc), it works!
Now, my first rant, why isn't this already included in the configuration? Seems misleading…
Anyway, the LCDd starts and LCD itself brings to life with a LCDProc banner, a heartbeat icon and two more strings:
Anything else I'm missing? I have screens setup in the Screens tab in pfsense package config, but that doesn't seem to do anything.
System Log excerpt:
Jun 15 23:14:09 LCDd: LCDd version 0.5.7 starting Jun 15 23:14:09 LCDd: Using Configuration File: /usr/pbi/lcdproc-amd64/local/etc/LCDd.conf Jun 15 23:14:09 LCDd: Listening for queries on 127.0.0.1:13666 Jun 15 23:14:12 php: lcdproc: Start client procedure. Error counter: (0) Jun 15 23:14:23 php: lcdproc: Failed to connect to LCDd process Operation timed out (60) Jun 15 23:14:23 php: lcdproc: Start client procedure. Error counter: (1) Jun 15 23:14:34 php: lcdproc: Failed to connect to LCDd process Operation timed out (60) Jun 15 23:14:34 php: lcdproc: Start client procedure. Error counter: (2) Jun 15 23:14:45 php: lcdproc: Failed to connect to LCDd process Operation timed out (60) Jun 15 23:14:45 php: lcdproc: Start client procedure. Error counter: (3) Jun 15 23:14:56 php: lcdproc: Failed to connect to LCDd process Operation timed out (60) Jun 15 23:14:56 php: lcdproc: Too many errors, the client ends.
Also, any info on whether the four LEDs on this particular LCD work? Net activity for example.
mer last edited by
Interesting. I've used this panel at work (Linux system, userland driver code to talk to it over Linux dev ttyACM*), never played around with it on BSD (no need to), but this has me curious. I'll have to see if I can borrow one for a bit. Your snippet from the syslog looks like they did something similar.
/dev/ugen**** may be a lower level than the TTY driver (ugen, USB Generic), if you do "ls -ltr /dev | grep ugen" you may see a TTY device symlinked to the ugen one, that's what I would use first. Which it looks like you have (/dev/ttyU0).
I'll have to look at the info I've got at work, LEDs should be able to work, just a matter of if the package has code to manipulate them.