Firebox LCD Driver for LCDProc
-
when i try to install the tar package and give ./ command it say's permission denied . logged in via ssh as root
-
You mean when you try to run this?
./install-embed2.lcdd.sh
Seems odd. It usually untars with the correct permissions.
You can reset the permissions with:chmod 0755 install-embed2.lcddd.sh
What version of pfSense are you using?
Steve
-
Thanks for reply.
I'm runing 2.0 Rc3 its a full hd install on x700. when i try to do chmod it say's command not found?
-
Hmm, well that seems very weird.
I don't have a full install to test right now but I can't believe that there's no chmod in it. It's certainly present in the nanoBSD install of RC3.
Are you experiencing any other problems?
The script is intended for embedded installs and may cause a problem with mounting the filesystem RO on a full install. However as you haven't managed to run it yet it can't be that. ???Steve
-
Hey
just like to confirm that it work's with full HDD install aswell
this is what i did
$ chmod 0755 ./install-embed2.lcdd.sh
$ /usr/local/etc/rc.d/lcdd.shVOLA it works :)
Thanks again for your help …
-
Hello stephenw10,
thank you for lcdd4.tar, it work quit well on my Firebox X700.
It is possible to disable/enable/blink the "Arm/Disarm"-LED in the BIOS (permanent).
One think could be enhanced: to extend the lcd-driver to set the "Arm/Disarm"-LED to green on init and to red on exit.
I don't have the source code, but I think it should be simple and would be the icing on the cake.xleox
-
It wasn't at all simple! ::)
Read the entire thread to discover just how not simple or go straight to this post to get the resulting program to set the led.Steve
-
I'm currently in the proces of migrating to pfSense 2.0. I installed a full 2.0RC3 version on a HD and installed Steve's LCD and LED packages on a WG Firebox X700. Just like on 1.2.3 it looks like it is running fine. I once encounterd a problem with the LCD driver only displaying "LCDproc Server" but couldn't reproduce.
Today I booted my Firebox for configuring and directly after bootup the LCD is "locked up" (see picture).
Arrow up shows "next", down shows "prev", right does nothing, left enters the menu with: options, screens, test menu. There is no system data like uptime, mem usage etc.-
version: 2.0-RC3 (i386) built on Sun Jul 24 19:17:15 EDT 2011
-
did not install the package LCDproc via packages, only Steve's tarball
-
Serial console shows a normal startup of the lcdd script
Starting CRON... done. Starting /usr/local/etc/rc.d/WGXepc.sh...done. Starting /usr/local/etc/rc.d/lcdd.sh...done. Bootup complete
What is going on here? Strange thing is it doesn't happen every time I boot or reboot the firewall…
I have little knowledge of FreeBSD, but is it possible to restart the lcdd service via the terminal? How?Thanks for your info and help!
-
-
LCDproc is in two parts. lcdd is the server half that talks to the screen. lcdprocc is the client that tells lcdd what to put on the screen. If you only have the server half running you get what you are seeing.
Got to the console and run 'top' you should see both lcdd and lcdproc:[2.0-RC3][root@pfsense.fire.box]/root(1): top last pid: 8157; load averages: 0.01, 0.01, 0.00 up 35+01:07:41 15:50:32 44 processes: 1 running, 43 sleeping CPU: 4.8% user, 0.0% nice, 0.0% system, 0.0% interrupt, 95.2% idle Mem: 52M Active, 20M Inact, 62M Wired, 128K Cache, 59M Buf, 352M Free Swap: PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 18701 nobody 1 64 20 3364K 1424K nanslp 51:51 0.00% LCDd 19029 root 1 64 20 3352K 1216K nanslp 28:42 0.00% lcdproc
q to stop.
You can start lcdproc manually by running:
/usr/local/etc/rc.d/lcdd.sh
Though it will try to start both server and client. It's hard to say why it stopped working reliably, disk errors? :-\
Steve
-
I issued "/usr/local/etc/rc.d/lcdd.sh" earlier and indeed, now it is working.
Top shows LCDd and lcdproc.My /usr/local/etc/rc.d/lcdd.sh contains:
#!/bin/sh # /usr/bin/nice -20 /usr/local/share/lcdd/LCDd -r 0 -c /usr/local/share/lcdd/LCDd.conf > /dev/null 2>&1 & /usr/bin/nice -20 /usr/local/share/lcdd/lcdproc C T U &
Thanks for our explanation: now I understand the server (lcdd) and the client (lcdprocc) both need to be running.
What I don't understand is why the client part wasn't running after boot, even though the lcdd.sh script was executed.<edit>Didn't see your edit before posting. Hmm, diskerrors, don't know. Didn't see any other errors.
Is there a sort of "chkdsk" tool/command for freebsd?
I will keep an eye on this…<edit2>I booted in single user mode (i guess?) and issued fsck -y /dev/ad2s1a. It gave no errors.</edit2></edit>
-
As part of my effort to produce a package for the Watchguard lcd I recompiled the driver. Until I get a proper package out anyone installing fresh might as well use this new set of programs. This for 2.0 only, it won't work on 1.2.x. Installation is as before.
Download the attached file and remove the .png extension.
Upload lcdd5.tar via the web GUI, Diagnostics: Command Prompt: Upload, this puts it in /tmp.
Then open a command line via serial or SSH or whatever and:[2.0-RC3][root@pfSense.localdomain]/root/tmp(3): cd /tmp [2.0-RC3][root@pfSense.localdomain]/tmp(4): tar xvf lcdd5.tar x install3.sh x lcdd/ x lcdd/LCDd.conf x lcdd/lcdd.sh x lcdd/lcdproc x lcdd/LCDd x lcdd/drivers/ x lcdd/drivers/sdeclcd.so [2.0-RC3][root@pfSense.localdomain]/tmp(5): ./install3.sh [2.0-RC3][root@pfSense.localdomain]/tmp(6): /usr/local/etc/rc.d/lcdd.sh
And your display should be working. :)
Changelog:
Renamed the install script to make it easier to type!
The programs, lcdproc and LCDd, are now V0.53 compiled against FreeBSD 8.1-Release.
The driver, sdecldec, was giving a lot of warnings when I tried to compile it. These have been corrected.The new version seems to obey the LCDd.conf file better such that the option heartbeat=no now works removing the ugly error on the right hand side of the display.
The key mapping is still incorrect for X-e boxes. :(
I had no response to my question as to whether anyone uses the big clock or vertical histogram functions. Personally I would rather have the heartbeat functioning but it's a choice in the driver. Any opinions?
Steve
-
Hi Steve,
I am in the middle of setting up a X500 got it today :) and just used your script for the LCD and it worked flawless the instructions are bang on no problems at all!!
Many Thanks for all your hard work put into this I'm sure it wasn't a easy time and time consuming to say the least so thank you. -
Thanks for that! :)
Most of the hard work was done by others before me though.
Coding by ridnhard19 and jjgoessens.Steve
-
Since it's now a very long thread and the code is somewhat spread out here are the source files for the sdeclcd driver.
Producing a driver file from these is not simply a matter of invoking gcc! I hope I have noted all the steps I took to do it here.
Steve
-
Thanks to fmertz the driver now correctly supports the front panel buttons on the X-E boxes. ;D
Attached to this post is v1.05 sdeclcd driver with reworked keyboard code.
the sdeclcd.so file should be 13522 Bytes.
There is no advantage to X-Core or X-Peak box users so you can continue using the old version in the tarball. Of course if you want to test that this new version doesn't break your box that would be great. ;)
I have tested it on the X-E and X-Peak boxes.Please report any problems.
Steve
-
Thanks to fmertz the driver now correctly supports the front panel buttons on the X-E boxes. ;D
In the spirit of facilitating getting folks involved in contributing to this driver, I decided it was time to put all this code in one place. The long term plan would certainly be to merge this driver with the upstream lcdproc project. For now, I gathered everyone's contributions and put them in public version controlled project on github.
The setup is as follows: The master branch contains the code from upstream lcdproc. It is the 0.5dev version, the current development area. I created the sdec branch to capture all the changes necessary for the Watchguard Firebox LCD driver. There are various commits on that branch, one for each contribution, attributed by author as best as I could. The branch captures changes to the sources, makefiles and documentation. The idea is that someone wanting to build this driver from source would be a few commands away from doing so by using this repo.
The github repository for the sdeclcd is at https://github.com/fmertz/sdeclcd
To build this driver from source:
to be updated... git clone ... cd ... ./autogen.sh --enable-drivers=sdeclcd make
Feedback welcome.
-
I'm not sure you can do that in one step, I certainly didn't.
./autogen.sh ./configure --enable-drivers=sdeclcd make
The requirements for getting the code into lcdproc upstream seemed tough to meet to me.
Steve
-
I'm not sure you can do that in one step
Commands:
git clone -b sdec git://github.com/fmertz/sdeclcd.git cd sdeclcd/ ./autogen.sh ./configure --enable-drivers=sdeclcd make
In FreeBSD:
[fcm@BSDDev /usr/home/fcm]$ uname -a FreeBSD BSDDev.localdomain 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 UTC 2011 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [fcm@BSDDev /usr/home/fcm]$ git clone -b sdec git://github.com/fmertz/sdeclcd.git Cloning into sdeclcd... remote: Counting objects: 628, done. remote: Compressing objects: 100% (499/499), done. remote: Total 628 (delta 90), reused 627 (delta 89) Receiving objects: 100% (628/628), 992.04 KiB | 191 KiB/s, done. Resolving deltas: 100% (90/90), done. [fcm@BSDDev /usr/home/fcm]$ cd sdeclcd/ [fcm@BSDDev /usr/home/fcm/sdeclcd]$ ./autogen.sh Running aclocal ... Running autoheader... Running automake ... configure.in:75: installing `./compile' configure.in:10: installing `./config.guess' configure.in:10: installing `./config.sub' configure.in:6: installing `./install-sh' configure.in:6: installing `./missing' clients/lcdexec/Makefile.am: installing `./depcomp' Running autoconf ... [fcm@BSDDev /usr/home/fcm/sdeclcd]$ ./configure --enable-drivers=sdeclcd checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking build system type... i386-unknown-freebsd8.2 checking host system type... i386-unknown-freebsd8.2 checking whether to enable debugging... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking whether gcc and cc understand -c and -o together... yes checking for xmlto... no checking CFLAGS for gcc -Wno-unused-function... -Wno-unused-function checking CFLAGS for gcc -ftrampolines... no, unknown checking for gethostbyname... yes checking for connect... yes checking for inet_aton... yes checking for kstat_open in -lkstat... no checking for nanosleep in -lposix4... no checking for getloadavg... yes checking for swapctl... no checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking procfs.h usability... no checking procfs.h presence... no checking for procfs.h... no checking sys/procfs.h usability... yes checking sys/procfs.h presence... yes checking for sys/procfs.h... yes checking sys/loadavg.h usability... no checking sys/loadavg.h presence... no checking for sys/loadavg.h... no checking utmpx.h usability... no checking utmpx.h presence... no checking for utmpx.h... no checking for kvm_open in -lkvm... yes checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking for sys/types.h... (cached) yes checking machine/pio.h usability... no checking machine/pio.h presence... no checking for machine/pio.h... no checking machine/sysarch.h usability... yes checking machine/sysarch.h presence... yes checking for machine/sysarch.h... yes checking sys/cpuvar.h usability... no checking sys/cpuvar.h presence... no checking for sys/cpuvar.h... no checking machine/apm_bios.h usability... yes checking machine/apm_bios.h presence... yes checking for machine/apm_bios.h... yes checking for System V IPC headers... yes checking for union semun... yes checking for machine/cpufunc.h... yes checking for sched_setscheduler... yes checking for sched_setscheduler in -lposix4... no checking for sched_setscheduler in -lrt... yes checking for i386_get_ioperm in -li386... no checking for i386_get_ioperm in -lc... yes checking for iopl... no checking for ioperm... no checking sys/io.h usability... no checking sys/io.h presence... no checking for sys/io.h... no checking for a parallel port... yes checking linux/i2c-dev.h usability... no checking linux/i2c-dev.h presence... no checking for linux/i2c-dev.h... no checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for ANSI C header files... (cached) yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking for unistd.h... (cached) yes checking for sys/io.h... (cached) no checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking kvm.h usability... yes checking kvm.h presence... yes checking for kvm.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/dkstat.h usability... yes checking sys/dkstat.h presence... yes checking for sys/dkstat.h... yes checking for sys/sysctl.h... yes checking for sys/pcpu.h... yes checking for SA_RESTART... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for uid_t in sys/types.h... yes checking whether gcc needs -traditional... no checking return type of signal handlers... void checking for select... yes checking for socket... yes checking for strdup... yes checking for strerror... yes checking for strtol... yes checking for uname... yes checking for cfmakeraw... yes checking for snprintf... yes checking for getopt... yes checking for your mounted filesystem table... /etc/fstab checking for fcntl.h... (cached) yes checking sys/dustat.h usability... no checking sys/dustat.h presence... no checking for sys/dustat.h... no checking for sys/param.h... (cached) yes checking sys/statfs.h usability... no checking sys/statfs.h presence... no checking for sys/statfs.h... no checking sys/fstyp.h usability... no checking sys/fstyp.h presence... no checking for sys/fstyp.h... no checking mnttab.h usability... no checking mnttab.h presence... no checking for mnttab.h... no checking mntent.h usability... no checking mntent.h presence... no checking for mntent.h... no checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking sys/statvfs.h usability... yes checking sys/statvfs.h presence... yes checking for sys/statvfs.h... yes checking sys/vfs.h usability... no checking sys/vfs.h presence... no checking for sys/vfs.h... no checking sys/filsys.h usability... no checking sys/filsys.h presence... no checking for sys/filsys.h... no checking sys/fs_types.h usability... no checking sys/fs_types.h presence... no checking for sys/fs_types.h... no checking for sys/mount.h... yes checking for getmntinfo... yes configure: checking how to get filesystem space usage... checking for statvfs... yes checking module extension... .so checking for dlopen in -ldl... no checking for shl_load in -ldld... no checking if libusb support has been enabled... yes checking for pkg-config... /usr/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for LIBUSB... no checking if libftdi support has been enabled... yes checking for LIBFTDI... no checking if libhid support has been enabled... yes checking for LIBHID... no checking if PNG support has been enabled... yes checking for libpng-config... /usr/local/bin/libpng-config checking whether libpng is present and sane... yes checking if freetype support has been enabled... yes checking for freetype-config... /usr/local/bin/freetype-config checking for FreeType -- version >= 7.0.1... yes checking if ethlcd support has been enabled... yes checking for doxygen... no configure: checking which drivers to compile... --------------------------------------- LCDd will be compiled with the drivers: - sdeclcd --------------------------------------- configure: creating ./config.status config.status: creating Makefile config.status: creating shared/Makefile config.status: creating server/Makefile config.status: creating server/commands/Makefile config.status: creating server/drivers/Makefile config.status: creating clients/Makefile config.status: creating clients/lcdproc/Makefile config.status: creating clients/lcdexec/Makefile config.status: creating clients/lcdvc/Makefile config.status: creating clients/examples/Makefile config.status: creating clients/metar/Makefile config.status: creating docs/Makefile config.status: creating docs/Doxyfile config.status: creating docs/lcdproc-dev/Makefile config.status: creating docs/lcdproc-user/Makefile config.status: creating docs/lcdproc-user/drivers/Makefile config.status: creating scripts/Makefile config.status: creating scripts/init-LCDd.LSB config.status: creating scripts/init-lcdproc.LSB config.status: creating scripts/init-lcdexec.LSB config.status: creating scripts/init-lcdvc.LSB config.status: creating scripts/init-LCDd.debian config.status: creating scripts/init-lcdproc.debian config.status: creating scripts/init-lcdexec.debian config.status: creating scripts/init-lcdvc.debian config.status: creating scripts/init-LCDd.rpm config.status: creating scripts/init-lcdproc.rpm config.status: creating config.h config.status: executing depfiles commands [fcm@BSDDev /usr/home/fcm/sdeclcd]$ make make all-recursive Making all in shared ... [fcm@BSDDev /usr/home/fcm/sdeclcd]$ ls -l server/drivers/sdeclcd.so -rwxr-xr-x 1 fcm fcm 13522 Dec 6 21:51 server/drivers/sdeclcd.so
-
Does anyone have this in a package yet for pfsense? I would build it my self except I don't currently have a freebsd VM or test machine to test on.
-
The github repository for the sdeclcd is at https://github.com/fmertz/sdeclcd
The code was updated. Check the sdec branch of the project:
https://github.com/fmertz/sdeclcd/tree/sdec
The changes are:
- Rewrite of driver code
- Suppressed user parameter in configuration file to preserve back light
- Added support for more icon codes
- Restored heart beat
- Fixed initialization
- Updated documentation
This is based on the 0.5dev version of the lcdproc upstream project.
The primary purpose of this effort is to submit a working driver to the upstream project. This is why it is a branch off of the latest dev branch.
In parallel, mdima has packaged lcdproc-dev for pfSense. It is based off of lcdproc-0.5.4. This latest driver code is included in mdima's package (I compiled it separately). The discussion is here: http://forum.pfsense.org/index.php/topic,44034.0.html. Big thanks to Stephenw10 and Spy Alelo for live testing on actual hardware, and confirming that the driver works. Basically, if you install the lcdproc-dev package on your Firebox, you should have a working LCD. As simple as that. Feedback most welcome.
PS: The button mapping in the LCDd.conf file might need an adjustment, but should be fixed shortly.
-
The code was updated. Check the sdec branch of the project:
https://github.com/fmertz/sdeclcd/tree/sdec
The primary purpose of this effort is to submit a working driver to the upstream project.
The code was updated again: housekeeping and bug fix.
A little while back, I submitted this code for inclusion into the upstream lcdproc project. I am happy to report that the code was accepted. This means this SDEC driver for Fireboxes is now a part of the official lcdproc project!
-
The code was updated again for supporting LEDs. Details here:
http://forum.pfsense.org/index.php/topic,44034.msg276249.html#msg276249
-
So I installed with the new LCDproc-dev.. All I can get the lcd to do is say "Thanks for using pfSense".
I have different screens checked on the screens tab but can't get it to do anything… buttons don't work.I had this working at one time.. now I am frustrated with it...
Dyno
-
There is a problem with the start sequence. Once your box is up if you go to Status: Services: and restart the lcdproc service it will run correctly.
Steve
-
I rewrote the startup script that lcdproc.inc outputs and fixed the boot issue on Fireboxes and my own units.
You guys will need to check my work and make sure nothing is getting messed up by my changes, but it appears start/stop/restart are working as intended. Something was wrong with the "if X running then kill X" statements. Not sure why the bug was inconsitent with different hardware, but I got it working.
I'll post it when I get home, stuck at work. I've been so busy I haven't even been able to test the xCore-e changes. :-\
-
Steve,
Is there anyway to fix this other than having to do that each time it reboots? This is a firebox for my best friend that I am building to help conserve space in his office.
Dyno
** Nevermind on reboot it works properly now!
Now to find a better and quieter cpu cooler…
-
Here is the "fixed" lcdproc.inc
Not sure if this will work for everyone or if it isn't working right, but let me know how it could be improved.
-
Brak,
I stumbled upon your ebay listings again today looking for a X-E box ;D
you boxes look nice.
-
Brak,
I stumbled upon your ebay listings again today looking for a X-E box ;D
you boxes look nice.
Thanks bud!
I'd probably sell my X-E boxes with pfsense on them, but I'm waiting for 2.1 so the driver is supported properly. So sad that 4 gigabit NICs are basically useless atm! I have 3 fully maxed upgraded ones just looking pretty in a rack :(
-
Try the patched driver. I've put a few 10s of Gigs through mine and hasn't crashed yet. Though I still haven't found a reliable way to crash it with the standard driver. ::)
Steve
-
how can I disable the backlight timer?
I have the backlight set to on, the brightness to 100% and the off-brightness to 100%… tried adding
BackLight=yes
Backlight_Timer=0to the lcdd.conf and still turns off after 30 seconds or so ???
-
If you are using the most recent re-written driver there is a hard coded backlight timer which can't be disabled. Fmertz did it deliberately as the the backlight has a finite (and not that long) life and has already been run for many hours on most peoples boxes. We had a number of failure reports.
Steve
-
its an LED backlight… its lifetime would be about the same as the power LED?...
-
well anyway if anyone wants the backlight on all the time regardless of what the driver tells it to do all you have to do is put a bit of solder across J2 right next to the "K" (Cathode) land on the back of the LCD panel
it has a 100k hour MTBF (~11.5 years) so decide if you want to "risk" it
-
Which box do you have?
Some had a cold cathode style backlight with a far shorter life.Steve
-
I have a firebox X500
yes a CCFL backlight will have about 1/10th the MTBF as an LED backlight…. an EL backlight even worse
interesting (strange?) that they would use a CCFL backlight LCD that is so small, usually you see that on larger graphic displays not tiny text displays?
-
I may have mis-remebered and it was in fact EL. I do remeber being both surprised and alarmed when I read the spec sheet for the display at the expected backlight life. Most of these boxes have seen thousands of hours before they ever have pfSense loaded. This may not be a problem because the Watchguard OS has a backlight timer but without any display driver pfSense will leave it on permanently.
See: http://forum.pfsense.org/index.php/topic,44034.msg234998.html#msg234998
Steve
-
I have worked on quite a few fireboxes (this one was my first with pfSense) and never seen one with an EL or CCFL backlight (would require an extra PCB and/or onboard inverter)… not saying they don't exist, but if they do I have never run across one...
the LED backlight on a regular text display is usually quoted as 30k-100k hours, but realistically it should last pretty much forever... if you are worried you could drop the voltage going to it by soldering a resistor across J2 to dim the display... undervolting the LEDs should extend their life
also some fireboxes like the XTM 5 series (green LED backlight) leave the backlight on 24/7
since the fireboxes have the LCD attached to the parallel port you actually could just swap the module out with a regular 2x20 HD44780 LCD, should probably fit... not sure if they are pin-compatible, would have to look at the datasheets for that...
-
Interesting about the XTM5. I have one of those running pfSense which works with the same driver as the previous boxes. I had assumed the only reason Watchguard would have specified a custom display would be to use a common driver across platforms.
IMHO there should be an option to enable the backlight permanently. Have the timer enabled by default with a warning perhaps.
However long the backlight should last there are quite a few reports of X-core boxes with dead backlights! ;)
Steve
-
ya like I said, it definitely could happen… I work on a lot of equipment that uses common small character displays, mostly HD44780 but some more oddball chips now and then like these fireboxes... most LED backlit (some EL and CCFL backlit, avoid EL/CCFL backlights!!) and their failure rate is nothing too bad... also if you are handy with a soldering iron you can always replace the LED (much more difficult with EL sheets/CCFL lamps)
I think the XTM is the same controller(?) but the LCD is different, its got a green backlight and is physically much smaller (smaller characters)
in a home environment I would imagine leaving the backlight on 24/7 could be more annoying than useful, but I have these things in racks with smoked plexi doors so without the backlight I cant read anything on the display :)
it would be cool if you could have a check box to leave it on all the time... would also be cool to use it as an indicator... so if there is an error condition you could "flash" the backlight... on these older fireboxes with the giant LCD displays that would definitely get your attention when you walk by it in a rack!