LCDProc 0.5.4-dev

Brak

@Brak:

That 64bit driver appears to work well, awesome!

Just testing things right now, only issue I see is that it's still 16x4 screens instead of 20x2, but I know you didn't change any code

Good news!

When you say 16 instead of 20, do you mean that it uses the first 16 characters out of 20, or that each character is wider so that only 16 show on the whole width? If 16 out of 20, maybe lcdproc (the client) thinks this is only 16 wide, somehow. You can test with the binary lcdproc that comes with the project (even running on another machine) to be sure…

Code from Lanner (includes LED, LCM, the software reset button (a pin hole on the units), and the physical LAN bypass feature):

http://mc.zsnnet.org/hosted/LannerLCMsamples.zip

As for what I mean on the character stuff, the LCD is 20x2, but the lcdproc status screens only use it like it's a 16x2 LCD. Something is writing to the 8 extra characters tho, since I sometimes see "Next" or "Prev" pop up in the extra spaces when i press a key button. LCDexec with my menu system also seems to be limited to writing to a 16x2. The Lanner-LCM driver you compiled for me a while back does use the full 20x2. Maybe there is some left over hard-coded 16x2 left in SDECLCD?

fmertz

@Brak:

Code from Lanner (includes LED, LCM, the software reset button (a pin hole on the units), and the physical LAN bypass feature):

http://mc.zsnnet.org/hosted/LannerLCMsamples.zip

Does this work (as root)?

https://github.com/downloads/fmertz/sdeclcd/a.out

It should cycle the LEDs (Green, Yellow, then Dark as per the code). I ported the code to FreeBSD (seems to be DOS and Linux initially).

In short, it looks like the LEDs are interfaces off of the SuperIO. The code mentions the board number. Is it this?

http://www.scribd.com/doc/39794230/Spec-FW-7565

Looks like there is an ICH8 Southbridge, and a Winbond W83627THG SuperIO…

Brak

I'll have to try it when I get home from work, but yeah, that is the proper board/unit number I believe.

I had no clue they were board specific, what lanner sent me seemed generic. I guess there really won't be an easy way of getting the LEDs working for all models until we get the samples from everything - if it's even worth it.

Why can't these LEDs be easy and be part of the LCD/button stuff. :-\

fmertz

@Brak:

Why can't these LEDs be easy and be part of the LCD/button stuff. :-\

That is what I am working on. This way, at least, the interface to the LEDs is captured in code as part of the driver. Now, whether we will have a client to turn them on/off is another matter…

acro-ii

Nobody has an idea about my cfa633 and the alternate rs232 pinout issue???

stephenw10

It seems very odd that it isn't wired in a standard manner. But if that is the case it would be a hardware only solution. I don't believe you can change the serial port pins in software (like you can with a parallel connected display).
If it is working under windows then it should be possible to have it function under lcdproc - with the correct driver. ;)

Steve

robi

Is there any chance to have the glcdlib driver also included with the LCDproc package?

It would allow us to use this very good priced graphic LCD screen with pfSense. This is a small digital photo frame which has an open alternative firmware called dpf-ax, allowing it to be used as graphical USB display. LCDProc's glcdlib driver actually translates the textual info in graphical format for displays like this.

linkdelight1.jpg_thumb

Brak

@fmertz:

@Brak:

Code from Lanner (includes LED, LCM, the software reset button (a pin hole on the units), and the physical LAN bypass feature):

http://mc.zsnnet.org/hosted/LannerLCMsamples.zip

Does this work (as root)?

https://github.com/downloads/fmertz/sdeclcd/a.out

It should cycle the LEDs (Green, Yellow, then Dark as per the code). I ported the code to FreeBSD (seems to be DOS and Linux initially).

In short, it looks like the LEDs are interfaces off of the SuperIO. The code mentions the board number. Is it this?

http://www.scribd.com/doc/39794230/Spec-FW-7565

Looks like there is an ICH8 Southbridge, and a Winbond W83627THG SuperIO…

Tried the a.out file, I keep getting "/a.out: Exec format error. Binary file not executable." Am I doing something stupid here, or is it not working?

fmertz

@Brak:

Tried the a.out file, I keep getting "/a.out: Exec format error. Binary file not executable." Am I doing something stupid here, or is it not working?

Strange, this a.out file works for me (in the Virtualbox VM) both in 32 bit and 64 bit. I re-downloaded it from github to be sure, with wget, directly from within the VM. Are you using ASCII ftp with Windows? Also, this is compiled for FreeBSD 8.2 i386, not sure what version of FreeBSD your install of pfSense is based off of. Run "chmod 755 a.out" to be sure.

Brak

@fmertz:

@Brak:

Tried the a.out file, I keep getting "/a.out: Exec format error. Binary file not executable." Am I doing something stupid here, or is it not working?

Strange, this a.out file works for me (in the Virtualbox VM) both in 32 bit and 64 bit. I re-downloaded it from github to be sure, with wget, directly from within the VM. Are you using ASCII ftp with Windows? Also, this is compiled for FreeBSD 8.2 i386, not sure what version of FreeBSD your install of pfSense is based off of. Run "chmod 755 a.out" to be sure.

Okay, tried fetching it, no change on the 64bit pfsense install… But then I tried it on my 32bit install on the same hardware and the program works in the sense that it ran, but the LED does not do anything at all. That's probably not much help tho. :/

stephenw10

But it prints to the console: "Status LED: Green" etc?

Steve

Brak

Yep, then Yellow, then Dark. Doesn't actually flip the LEDs tho. :-\

fmertz

@Brak:

Okay, tried fetching it, no change on the 64bit pfsense install… But then I tried it on my 32bit install on the same hardware and the program works in the sense that it ran, but the LED does not do anything at all. That's probably not much help tho. :/

That is what I figured. That code doesn't reconcile with any of the SuperIO documentation I have seen, or even the code's own comments. Hopefully, the code comments will be enough to be able to come up with something…

stephenw10

I think we should take this to a separate thread. This one is already massive and LED control on a particular Lanner box is not helpful for most people reading it.

Steve

Brak

@stephenw10:

I think we should take this to a separate thread. This one is already massive and LED control on a particular Lanner box is not helpful for most people reading it.

Steve

Agreed, but honestly, it's probably not worth worrying about the LED in it at all.

Only thing I think we can keep from this side-tracking is that the 64-bit SDECLCD works, but it is hard-coded as 16x2 status screens still.

fmertz

@Brak:

Only thing I think we can keep from this side-tracking is that the 64-bit SDECLCD works, but it is hard-coded as 16x2 status screens still.

You can ask LCDd what it thinks the width is:


telnet <pfsense host="" ip="" or="" name="">13666
hello
connect LCDproc 0.5.4 protocol 0.3 lcd wid 20 hgt 2 cellwid 5 cellhgt 8</pfsense>

Brak

@fmertz:

@Brak:

Only thing I think we can keep from this side-tracking is that the 64-bit SDECLCD works, but it is hard-coded as 16x2 status screens still.

You can ask LCDd what it thinks the width is:
telnet <pfsense host="" ip="" or="" name="">13666
hello
connect LCDproc 0.5.4 protocol 0.3 lcd wid 20 hgt 2 cellwid 5 cellhgt 8</pfsense> 

Output:


[2.0.1-RELEASE][root@fringebox.blizzard]/root(4): telnet 127.0.0.1 13666
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hello
connect LCDproc 0.5.5 protocol 0.3 lcd wid 20 hgt 2 cellwid 5 cellhgt 8

Examples: (Kinda bad example, but it at least shows the screens are shortened. I know things are getting cut off since I can't change the "pfsense shutting down" to be any bigger without losing the extra 8 characters on the end. The Lanner-LCM hacked driver can write the shutdown line on all the 20x2 characters just fine)

Off center, not showing screens to be big enough:

Clearly addresses the extra characters with other displays:

stephenw10

Not a driver problem then.
Are you sure it ever shows more characters than that? The screens are always drawn from the left side.
E.g.

Steve

fmertz

Brak,

If you want to point me to the hacked Lanner code again, I can have a quick look. Without hardware available to me though, this is quickly becoming unproductive. I am in the mid-atlantic US, maybe you should look up shipping rates and mail me a stripped down box for development. I could probably get the full LCD and LED control coded in the driver for 32 and 64 bit. Up to you.

Brak

I think the issue was just with my implementation. No use you guys wasting time on my hardware.

I did notice the issue with lcdproc crashing on the initial boot, then later restarting into just the LCDd server/client menu. Once I start the service once, it's seemingly good forever (at least until an unlucky interface up/down!)

Is there anything I should try and look at to see why it's failing at the initial boot?

Also, is there any way we could get LCDExec to be included in the package (both 32bit/64bit, 32bit does NOT work on 64bit in my experience - makes no sense?), and have it check for an lcdexec.conf (and if it exists, start the process running that config right after lcdproc starts?) My menu system would be more easily implemented if we could get everyone already have a working lcdexec install. 80% of my installation scripts are just hacking in the lcdexec install.