LCDProc 0.5.4-dev

mdima

Well, tbh, I can't get the completely default package to work with the example menu if I rename "lcdexec.conf.sample" to "lcdexec.conf" - I checked perms, too. And yes, I had it working with that standalone firebox LCDProc package that was on here. All I did was execute "./lcdexec -c ./lcdd.conf" after LCDProc was up and running.
Am I missing something to enable LCDExec and for it to run from the lcdexec.conf?

well… I am updating LCDproc to version 0.5.5 (package 0.8, will be released soon), I hope that this will solve your problem. If not please send me the your file lcdd.conf that I try to look what is wrong. Consider that this file changes machine to machine and does not contain any sensitive information.

Thanks,
Michele

mdima

Hello,
I just pushed a new version for the package. The changes are:

Updates LCDProc to 0.5.5 (very experimental!)
Rename the sdelcd driver to "Watchguard Firebox w/ SDEC LCD"

All feedbacks are welcome!
Michele

stephenw10

Tested 0.8 on my X-peak box after upgrading it to 2.0.1. Seems to work OK. :)

A couple of small things I noticed, this may have been true of previous versions I'm not sure.

The screen does not appear to be scrolling. I have the uptime screen enabled and it displays "up 12mins, 1 us " where it should say 'user'. Though there are characters available to display that. Perhaps a driver problem?

The service does not start until I go to Status: Services: and click 'start' next to LCDproc. This seems odd to me as the service should be restarted every time the changes are made to the config by the call to 'LCDproc.sh restart'.

Edit: Reading through lcdproc.inc (for the hundredth time!) it will only call for a service restart if lcdproc is already running. If it is not running and changes are made, as is the situation immediately after installation, then there is no call to start it.

This is where I hit trouble trying to make the package firebox only. It's not obvious to me how the start and stop logic works. It looks like the only way to stop the service is to remove the settings rather than uncheck the 'enable LCDproc' tick box. :-\ As I said this is where my skills ran out so I could easily be missing something.

Also there appears to be no point calling for a service restart since start contains stop as it's first command. Calling service start would seem to be sufficient.

Steve

fmertz

@stephenw10:

The screen does not appear to be scrolling. I have the uptime screen enabled and it displays "up 12mins, 1 us " where it should say 'user'. Though there are characters available to display that. Perhaps a driver problem?

I compiled the driver code in the lcdproc-0.5.5 tree. The resulting file is
https://github.com/downloads/fmertz/sdeclcd/sdeclcd.so
Just in case there is an updated needed from lcdproc-0.5.4 …

Feel free to update the driver file itself and restart. If it works better, I'll be happy to open a request with pfSense to make it the default for everyone.

mdima

Hello Steve,
I try to quote you:

@stephenw10:

Tested 0.8 on my X-peak box after upgrading it to 2.0.1. Seems to work OK. :)

That's great, also on the "sureelect" driver seems to work OK!

@stephenw10:

A couple of small things I noticed, this may have been true of previous versions I'm not sure.
The screen does not appear to be scrolling. I have the uptime screen enabled and it displays "up 12mins, 1 us " where it should say 'user'. Though there are characters available to display that. Perhaps a driver problem?

and again, the same problem is with my driver, so it does not look like something driver related.
But the "widgets" are sent all as "scroller", so I don't know what this is related to… I need to investigate a bit, maybe it is something broken in the package, maybe it's something broken in the LCDproc binaries...

@stephenw10:

The service does not start until I go to Status: Services: and click 'start' next to LCDproc. This seems odd to me as the service should be restarted every time the changes are made to the config by the call to 'LCDproc.sh restart'.
Edit: Reading through lcdproc.inc (for the hundredth time!) it will only call for a service restart if lcdproc is already running. If it is not running and changes are made, as is the situation immediately after installation, then there is no call to start it.

well… when you start the box, the service is started (if it's enabled in the package configuration).
Then when you apply some changes to the service settings, the service is restarted. If the service is not running when the changes are applied to the package, the service is not started.
This was the behavour the package had before, and I find it reasonable (if I stopped the service for some reason, it just stay stopped).
Do you agree with that?

@stephenw10:

Also there appears to be no point calling for a service restart since start contains stop as it's first command. Calling service start would seem to be sufficient.

The point is that to apply the changes you make to the configuration, the service must be restarted. Some of the settings and all the "screens" are defined only when the service starts, so if for example you add a new screen, the service must be restarted to apply this change. But there's no need to stop or restart the service manually before applying any change.
I agree that this "stop-restart" is reduntand since in the function "start" there's already a "stop the service" command, this is a bit more "safe" and has been inherited by the previous developer… I think that the previous developer thought to make it safer since for this package there are more than one program running, and in this way he was really SURE that before a start the service was not running anymore. I could simplify it, but I would prefer to keep it "safer" as it is (anyway, if the service is not running when it's called a "start", no code is executed). Consider that the package can be run also from other parts, or from the interface, from a refresh, and so on, this "safe" code avoids to have more than one program running in the background!

Ciao,
Michele

mdima

Hi Steve,
about that:

@stephenw10:

The screen does not appear to be scrolling. I have the uptime screen enabled and it displays "up 12mins, 1 us " where it should say 'user'. Though there are characters available to display that. Perhaps a driver problem?

after some investigation I found out that is the "uptime screen" that has a little problem, not the scrolling. If you enable the "interface screen" you will see your panel scrolling… Anyway, I fix that!

Ciao,
Michele

stephenw10

@mdima:

This was the behaviour the package had before, and I find it reasonable (if I stopped the service for some reason, it just stay stopped).
Do you agree with that?

Yes that seems reasonable and expected behaviour.
However I think that most users would expect the service to start if you tick the 'enable LCDproc' check box and then click save.
This is especially true just after installation when you have first setup the variables.
I think either it should instruct users to start the service manually or the service should start automatically.
Perhaps relabel the check box 'Enable LCDproc at boot time'?

@mdima:

Consider that the package can be run also from other parts, or from the interface, from a refresh, and so on, this "safe" code avoids to have more than one program running in the background!

I agree. :)

Steve

mdima

Hi Steve,

@stephenw10:

Perhaps relabel the check box 'Enable LCDproc at boot time'?

yes, I agree… you will find it the next release!

Ciao,
Michele

stephenw10

For further reducing user confusion you can include instructions using the <after_install_info>tag in pkg_config.8.xml. E.g.


 <after_install_info>Now configure your display in Services: LCDProc: then start the daemon in Status: Services:</after_install_info>

or something like that! ;)

Steve</after_install_info>

mdima

@stephenw10:

For further reducing user confusion you can include instructions using the <after_install_info>tag in pkg_config.8.xml. E.g.
 <after_install_info>Now configure your display in Services: LCDProc: then start the daemon in Status: Services:</after_install_info> 
or something like that! ;)
Steve</after_install_info>

yes, that's totally a good idea… you'll find it in the next release...

just a question (to you and to all): when do you think that we could replace the lcdproc package with the new lcdproc-dev package? I mean, to release it for real?

Thanks,
Michele

stephenw10

I would suggest we run both in parallel at least until 2.1 is released. At that point the package system is changing so work would be required to the old package which seems pointless if the dev package is relatively bug free.

Perhaps ask Seth Mos(databeestje)?

Steve

mdima

@stephenw10:

I would suggest we run both in parallel at least until 2.1 is released. At that point the package system is changing so work would be required to the old package which seems pointless if the dev package is relatively bug free.
Perhaps ask Seth Mos(databeestje)?
Steve

ok… I know that we are adding a lot of new features, but the "basic" features of lcdproc seem to be quite stable (I am running the service since days and days, with 1 second as refresh and it never hangs, while lcdproc 0.5.3.1 was hanging only after few days with a 5 seconds refresh). Actually I have no need to release it, but it would be great if also the other users could take advantage of this version, even if I don't have any number about the people that are using the package and their feedbacks.

Btw, before starting to put some work on the package, I tried to contact Seth Mos but the email was returning... but of course I will contact again before releasing the package on the "main" version...

Michele

fmertz

@mdima:

just a question (to you and to all): when do you think that we could replace the lcdproc package with the new lcdproc-dev package?

What is this package released against? A production pfSense release, or a development pfSense release? If it is development, I would say release it soon. This way, you can catch problems from users of other drivers before the package becomes production…

stephenw10

It would be very interesting to know how many people are using it.
I don't think we can ever hope to test everything before declaring it 'ready'.

I'm not sure really. :-\

Steve

mdima

@fmertz:

@mdima:

just a question (to you and to all): when do you think that we could replace the lcdproc package with the new lcdproc-dev package?

What is this package released against? A production pfSense release, or a development pfSense release? If it is development, I would say release it soon. This way, you can catch problems from users of other drivers before the package becomes production…

Hi fmertz,
I ment to release in production (replace the "lcdproc" package with the "lcdproc-dev" package)…

opinions opinions! ;)

Thanks,
Michele

mdima

@stephenw10:

It would be very interesting to know how many people are using it.
I don't think we can ever hope to test everything before declaring it 'ready'.
I'm not sure really. :-
Steve

me too… but also on the previous package, I think that there were a lot of "it works for me" parts of the code, and people has been using it for years (working)...
I would prefer that with a fresh install most people would use the "-dev" package in order to test it on as many systems as possible, but I really don't know how stable it is out of my environment...

stephenw10

I have found the strange behaviour from my box running v0.8 on pfSense 2.0.1.
Twice now I have found myself unable to log into the box either via http or ssh (ssh can login but then I get no console menu or command prompt).
Both times the problem has resolved itself when my WAN connection cycled causing packages to be reloaded.
It's hard to say at this point what is causing it, whether LCDproc is a cause or a symptom of something else.

What is certainly true is that I believe the php lcdproc client needs some better timeout code because when I look at the logs to try to determine what's happening all I see is:

Jan 13 08:37:43 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:42 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:32 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:30 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:20 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:19 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:09 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:37:08 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:36:57 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:36:56 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)
Jan 13 08:36:46 php: lcdproc: Failed to connect to LCDd process Operation timed out (60)

The standard lcdproc client will timeout after 3 or 4 attempts and quit.
What do you think?

Steve

power_matz

Hi,

first I want to thank you for the great effort you made on this project.
It was very annoying installing the LCDproc manually every time after an update.

I am using a FireBox. I am wondering why the backlight isn't staying on. I configured that in the control panel and also with the buttons on the hardware.

Can you tell me what the correct way is?
I was using the SDEC driver some time ago. There you had to set this in the conf file.
But I think you write this with the control panel, right?

Matthias

stephenw10

The newest driver for the sdeclcd no longer gives you that option. This is because the lamp in the display has a half life of just 3000 hours! You do not want it on all the time.
However if enough people want it it could be reinstated I guess.

Steve

fmertz

@power_matz:

I am using a FireBox. I am wondering why the backlight isn't staying on. I configured that in the control panel and also with the buttons on the hardware.

The initial driver had the option of setting the backlight timer to zero to leave the light always on. I read the spec of the SDEC LCD and it mentions a "Half Lift" (not my typo) of "3,000 HR.". I am not a component engineer, but I read this to mean that if a sufficiently large number of these LCDs are turned on at a given time, half of them will be off (and dead) after 3,000 Hours, or 17 weeks. It seemed like a good enough reason to keep the light off as much as possible, unless someone was "there" to look at it. Barring the availability of a proximity sensor, I coded it so it stays on for 30 sec after a key is pressed. If another key is pressed, the light stays on for another 30 seconds. From memory, someone posted on this forum that his backlight was dead. I figured these boxes have seen some use before we get them, so who knows how much life is left in that light. Also, with the high fan noise level these boxes make, I figured most of them will be stashed somewhere where the LCD would not be directly visible. This is my reasoning, and why I am reluctant to give folks an option to kill that light prematurely.

The original thread for the code is here: http://forum.pfsense.org/index.php/topic,7920.0.html