Firebox LCD Driver for LCDProc

stephenw10 · Feb 1, 2014, 1:57 AM

Yes it should do. That's part of the standard lcdproc configuration independent of the driver so it'd not hard coded or anything.

Steve

Feb 15, 2014, 1:49 PM

Hello,

i've just installed the lcdproc-dev package. I works so far, but after 30sek the backlight turned off.
In the webgui Services > LCDproc > Backlight > On
In the LCDd.conf is a line "Backlight=on" So it should work, but it doesn't.

Any ideas?

Thanks.

stephenw10 · Feb 15, 2014, 1:59 PM

That's the normal behaviour.
The backlight is hardcoded to turn off. The decision to do that was based on datasheets for the LCD module in the orginal X-Core box which stated the backlight life as limited number of hours (a few years) and that many of those boxes alreday had a dead backlight. Several people have requested it be allowed to stay on, which seems reasonable given the more recent modules have led backlights with a very long life, but that hasn't made it into the code.

Steve

Feb 15, 2014, 2:12 PM

Hello Steve,

thanks for your fast answer.

Too bad. I hoped, to let the backlight always on.
If i didn't use the LCDproc the backlight is always on, but it shows this annoying "Booting OS…"

pyro

ps. runnung pfsense on a X1250e

stephenw10 · Feb 15, 2014, 2:28 PM

You could try something horrible like adding a cronjob to set the backlight on every 20s. No idea how it might interfer with the LCD driver though. :-
Or you could fork the driver and remove the code that turns it off. ;)

Steve

ridnhard19 · Mar 21, 2014, 8:42 PM

Wow… This is crazy to see how my original proof of concept driver has taken off to a regular package and driver. I guess I lost track of all of this after mine died. It's nice to see people still using this hardware and the neat enhancements made. It's great for us as these devices are useless to many once they don't renew the licenses.

stephenw10 · Mar 22, 2014, 10:31 AM

Hey, great to hear from you. Thank you so much for your original work. :)

Steve

cii · Apr 9, 2014, 9:18 PM

@pyroblast:

Hello Steve,

thanks for your fast answer.

Too bad. I hoped, to let the backlight always on.
If i didn't use the LCDproc the backlight is always on, but it shows this annoying "Booting OS…"

pyro

ps. runnung pfsense on a X1250e

I've rebuilt the code from github to force the backlight always on.

You can grab the file from https://www.dropbox.com/s/6ilykwt1p6zn4rm/sdeclcd.so, sadly Dropbox doesn't work nicely with fetch…

You'll need to drop this in /usr/pbi/lcdproc-i386/lib/lcdproc/ and chmod 555 the file. Don't forget to back up your original! Once you reboot the backlight should be on.

stephenw10 · Apr 10, 2014, 12:19 PM

Nice. Good to have options. :)

Steve

g.jauch · Apr 11, 2014, 5:49 PM

@cii:

I've rebuilt the code from github to force the backlight always on.

You can grab the file from https://www.dropbox.com/s/6ilykwt1p6zn4rm/sdeclcd.so, sadly Dropbox doesn't work nicely with fetch…

You'll need to drop this in /usr/pbi/lcdproc-i386/lib/lcdproc/ and chmod 555 the file. Don't forget to back up your original! Once you reboot the backlight should be on.

Hi cii,

thx for your work… but dropbox send your sdeclcd.so as HTML-Text, not as a binary file... could you please zip your file and upload it again ?

@cii:

I've rebuilt the code from github

Can someone give me a direct link to the github sources… i searched myself but didn't find the sources :'(

cu gunther

cii · Apr 11, 2014, 6:54 PM

You can try this URL for a zipped version:
https://dl.dropboxusercontent.com/u/6133016/bsd/sdeclcd.so.zip

It was built from this repo (under FreeBSD 8.3)
https://github.com/fmertz/sdeclcd

g.jauch · Apr 11, 2014, 8:12 PM

works fine, the display stays on… big THX cii ;)

btw the first dropbox-link is also working now... very strange :o

cu gunther

g.jauch · Apr 13, 2014, 7:39 AM

Hi,

under pfsense 2.1 with the latest LCDproc-Dev driver you can configure the displayed entries via the webconfigurator inside the LCDproc Service Menu:

1. Simply navigate to the LCD-Proc Service Menu: 'Services -> LCDproc'

Click on "Enable LCDproc at startup" and change the settings as shown on the picture, like stephenw10 mentioned in this posting

2. Then click on the "Screens" Tab to see the following menu

and choose what the display should display, then click the "SAVE" button at the bottom of the page!

And your LCD become alive ;)

3. If your LCD shows only the following picture

This means that your lcdproc-client "died", happens for me on every reboot… don't know why... i will have a look inside the php-script ( lcdproc-client is really a php-shell-script )

Simple workaround... is to restart the lcdproc by hand ( 1. via command line, 2. via shellcmd )

/usr/local/etc/rc.d/lcdproc.sh restart

and all is fine... and running!

cu gunther

stephenw10 · Apr 12, 2014, 10:40 PM

If you find a solution to that problem please tell us. :)
I have personally tried many, many modifications to the lcdproc client and start/stop scripts. None of them were very successful. That's the reason I have ended starting the client and server outside of the package system as detailed in that post.
There is a lot of discussion about it in the lcdproc-dev thread in the packages subforum.

Steve

g.jauch · Apr 16, 2014, 2:05 PM

@stephenw10:

If you find a solution to that problem please tell us. :)

It took me a while to find the "real" problem.

As I mentioned my problem occured only after a startup ( reboot, power on ), the LCD-Daemon is running but obviously no Client.

If you simply restart the LCDproc via /usr/local/etc/rc.d/lcdproc.sh after the boot everything is fine and stays fine!

Q: So whats wrong during the startup/system boot ???
A: Both scripts ( /usr/local/etc/rc.d/lcdproc.sh and /usr/local/pkg/lcdproc_client.php ) itself are fine!

The "real problem" is the OS… pfSense since version 2.1 has a "startup" bug!

I must take a deeper look into the the system rc-scripts/configuration.

The only thing i can tell right now is... that since pfSense 2.1 every script under /usr/local/etc/rc.d gets called twice ( with a pause of ~3 seconds ) during the system startup/boot

You can easily modify the lcdproc.sh to prevent a double start, actually there is already some code inside the "rc_start section", but this code seems not to work well!

>>> Here's a video showing the "problem/bug" <<<

stay tuned… i'll be back 8)

cu gunther

stephenw10 · Apr 16, 2014, 1:59 PM

You'll find it gets started at least twice and that depending on what else you're loading and what speed your CPU is the resulting number of clients and servers can vary.
There is much in the lcdproc-dev thread, for example here: https://forum.pfsense.org/index.php?topic=44034.msg260465#msg260465

Steve

g.jauch · Apr 16, 2014, 2:26 PM

@stephenw10:

You'll find it gets started at least twice and that depending on what else you're loading and what speed your CPU is the resulting number of clients and servers can vary.
There is much in the lcdproc-dev thread, for example here: https://forum.pfsense.org/index.php?topic=44034.msg260465#msg260465

Steve

Hi steve,

I updated my previous posting… I forgot the video link!

This problem/bug has nothing to do with LCDproc !!!

I made a simple test script t.sh... and put it under /usr/local/etc/rc.d/
The script simply redirect it's output to a file under /tmp/debug_log.txt

Inside the script i only call the 'date' command and echo the $1 value !!!

Both VM's are fresh installed from the LiveCD... Quick Install, Standard Kernel, no changes!

Under 2.03 the script is processed/called 1 time ( which is correct ) under 2.1 ( and above ) it's processed/called 2 times during the startup !

Why is my script called twice... this doesn't make any sense to me ???

cu gunther

stephenw10 · Apr 16, 2014, 4:12 PM

Yes, interesting. I think in fact most of the investigative work done in the lcdproc-dev thread was before 2.1 was even in beta.
One thing to note is that the package system will restart all the packages if an interface goes down or up which can be a problem during boot. It should not do that IMHO. Another thing is that the lcdproc rc script issues a killall for the server and client so even if three clients have been started (which I've seen) they are all killed. Another thing is that the first instance of LCDd is 'un-killable' such that it doesn't get killed by the script and a new instance is started but fails because it can't attch to the parallel port.
Also of note is that we removed the loop script that continually restarted the server and client if it wasn't running. This seemed completely superfluous in 2.0 but since then a time limit on php processes has been introduced (I think) so that the php client will eventually die.

Perhaps the most interesting thing is that this is only a problem with the sdeclcd driver. Users with other LCD types run lcdproc-dev without any issues.

Steve

g.jauch · Apr 18, 2014, 7:37 PM

@stephenw10:

One thing to note is that the package system will restart all the packages if an interface goes down or up which can be a problem during boot.

Yes that causes the problem… I wonder how I've overlooked this error messages in system.log all the time :o

Apr 18 22:04:38 pfSense php: rc.newwanip: rc.newwanip: Informational is starting em0.
Apr 18 22:04:38 pfSense php: rc.newwanip: rc.newwanip: on (IP address: 192.168.211.130) (interface: wan) (real interface: em0).
Apr 18 22:04:41 pfSense check_reload_status: Updating all dyndns
Apr 18 22:04:45 pfSense php: rc.bootup: Creating rrd update script
Apr 18 22:04:45 pfSense syslogd: exiting on signal 15
Apr 18 22:04:45 pfSense syslogd: kernel boot file is /boot/kernel/kernel

>>> Apr 18 22:04:45 pfSense php: rc.start_packages: Restarting/Starting all packages.

Apr 18 22:04:46 pfSense login: login on ttyv0 as root
Apr 18 22:04:46 pfSense sshlockout[58995]: sshlockout/webConfigurator v3.0 starting up
Apr 18 22:04:46 pfSense php: rc.newwanip: Resyncing OpenVPN instances for interface WAN.
Apr 18 22:04:46 pfSense php: rc.newwanip: Creating rrd update script
Apr 18 22:04:48 pfSense php: rc.newwanip: pfSense package system has detected an ip change 192.168.1.10 ->  192.168.211.130 ... Restarting packages.
Apr 18 22:04:48 pfSense check_reload_status: Starting packages
Apr 18 22:04:48 pfSense check_reload_status: Reloading filter

>>> Apr 18 22:04:51 pfSense php: rc.start_packages: Restarting/Starting all packages.

But if you use static IP's for WAN & LAN the restarts aren't triggered ! All is fine then.
The default is DHCP for WAN…

@stephenw10:

It should not do that IMHO.

Fully agree with that!

@stephenw10:

Another thing is that the lcdproc rc script issues a killall for the server and client so even if three clients have been started (which I've seen) they are all killed. Another thing is that the first instance of LCDd is 'un-killable' such that it doesn't get killed by the script and a new instance is started but fails because it can't attch to the parallel port.

Indeed… after the system is up there are 2 LCD's and one "unfinished/waiting/hanging" 'lcdproc.sh start' process running!


[2.1.2-RELEASE][root@pfSense.localdomain]/root(1): ps -auxww | grep -i lcd
root    6656  0.0  0.1  3644  1496  ??  IN    0:00.00 /bin/sh /usr/local/etc/rc.d/lcdproc.sh start
root    7886  0.0  0.1  3300  1136  ??  IN      0:00.00 /usr/pbi/lcdproc-i386/sbin/LCDd -c /usr/local/etc/LCDd.conf -u nobody
nobody  8224  0.0  0.1  3316  1360  ??  SNs     0:00.26 /usr/pbi/lcdproc-i386/sbin/LCDd -c /usr/local/etc/LCDd.conf -u nobody

If you kill the LCDd process running as root / PID 7886 in this case… the lcdproc.sh script proceeds and finaly connect to the "real" LCDd and all is good, display gets alive!

@stephenw10:

Also of note is that we removed the loop script that continually restarted the server and client if it wasn't running. This seemed completely superfluous in 2.0 but since then a time limit on php processes has been introduced (I think) so that the php client will eventually die.

I disliked the used rc_start code/logic inside the lcdproc.sh script since I've looked the first time into that file.
IMHO there shouldn't be a kill/termination of the "services" you are trying to start inside that procedure, if something went wrong with that kills you end up ( as you allready mentioned ) with multiple instances of running LCDd and lcdproc_client.php scripts.

Why not simply check inside the rc_start if there is already a LCDd & lcdproc_client.php running and react on that in a proper way.

If no LCDd is running: Start it, if it's already running then ignore that 2.nd start request completely
Same thing for the lcdproc_client.php, further… only start the lcdproc_client.php if there is a LCDd running, because without a LCDd the start of the php script is useless

Something like that should be used inside the rc_start segment of lcdproc.sh to be "save":


rc_start() {
if  [ ! `pgrep -anx LCDd` ]; then
	/usr/bin/nice -20 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf -u nobody
fi

if [ ! `pgrep -f lcdproc_client.php` ] -a [ `pgrep -anx LCDd` ];then
	/usr/bin/nice -20 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php &
fi
}

@stephenw10:

Perhaps the most interesting thing is that this is only a problem with the sdeclcd driver. Users with other LCD types run lcdproc-dev without any issues.

Maybe they use static IP addresses! It should not be a driver problem.

cu gunther

stephenw10 · Apr 18, 2014, 7:54 PM

@g.jauch:

It should not be a driver problem.

Indeed it should not yet it seems to be.
My only thoughts on that were that the sdeclcd driver somehow had a delay in initialising the hardware such that it is unable to start/stop in the required time when multiple restarts are called at boot. That might also explain why the driver seems to work better on the X-Core box which has a slower CPU. However no amount of adding or removing delays from the start script seemed to really solve the problem.

Interestingly using the Shellcmd package to start the client and server outside of the package system the commands only get run once. It might be worth looking at how shellcmd is arranged to run only once.

Steve