sdeclcd patch for Watchguard XTM 5 button mapping

[jjakob]

I had to do this to get the buttons mapped correctly on WG XTM 5 series boxes:

--- server/drivers/sdeclcd.c	2018-11-22 23:15:49.412481599 +0100
+++ b/lcdproc-0.5.6/server/drivers/sdeclcd.c	2017-06-11 00:09:44.766428480 +0200
@@ -694,16 +695,16 @@
 	switch (kbd) {
 	    case 0x70:
 	    case 0xC8:
-		return ("Up");
+		return ("Left");
 	    case 0xF8:
 	    case 0xE0:
-		return ("Right");
+		return ("Up");
 	    case 0x68:
 	    case 0xC0:
 		return ("Down");
 	    case 0x58:
 	    case 0xE8:
-		return ("Left");
+		return ("Right");
 	    case 0x78:		/* button Releases */
 	    case 0x88:
 	    case 0x80:

It appears that they're still connected to the same pins but labelled differently on the front panel.
If the box model could be detected at runtime the correct mapping could be chosen automatically, but so far this needs to be patched at compile time. If anyone has any idea how to do that I could assist with testing on my HW (I have a few of these).

Also, if you want the backlight to stay on all the time / disable the timeout:

@@ -645,11 +642,13 @@
 sdeclcd_backlight(Driver *drvthis, int level)
 {
 	PrivateData *p = (PrivateData *) drvthis->private_data;
-
+/*
 	if (time(NULL) - p->bklgt_lasttime >= p->bklgt_timer || 0 == level)
 		p->bklgt = BACKLIGHT_OFF;
 	else
 		p->bklgt = BACKLIGHT_ON;
+*/
+	p->bklgt = level;
 }
 
 /**
@@ -672,11 +671,12 @@
 	 * light off when there is no activity. With a half life of only
 	 * 3,000 hours, we need to preserve it.
 	 */
+/*
 	if (time(NULL) - p->bklgt_lasttime >= p->bklgt_timer)
 		p->bklgt = BACKLIGHT_OFF;
 	else
 		p->bklgt = BACKLIGHT_ON;
-
+*/
 	/* read keyboard status */
 	kbd = port_in(LPT_STATUS) & LPT_STUS_MASK;
 	/* check if keyboard changed */

The ~3K hr. half-life applies only to EL, the XTM uses LEDs which have a half-life of 50-70K hr. (source) so IMO it's more convenient to leave it on. It can always be disabled in the menu, of course.

[haraldg]

The sdeclcd driver implements the same protocol as HD44780 with lcm162 connection type. With that driver you don't have the backlight timeout and IIRC you can set the key mapping from the configuration file. Seems like using that is your simplest option.

I'm not too happy with having two drivers implementing the same protocol anyway.

[jjakob]

Thanks, will test. I agree, if the other driver works, there would be no need for two drivers, as long as there's nothing special being done.

It seems that others were here before me:
https://forum.netgate.com/topic/7467/firebox-lcd-driver-for-lcdproc/357

[jjakob]

I've tried hd44780 with lcm162, the LCD works but the backlight and buttons don't, the backlight is off (enabled in conf file) and the keys are dead (on startup "Up" is displayed so maybe the line that expects the key Up is connected to somewhere else). Tried with KeyMatrix_(1,2)(1,2) and KeyDirect(1-4).
The backlight not working is obviously because the lcm162 driver doesn't implement it...

[haraldg]

Ugh, I just noticed that KeyDirect at all was documented in 2002 but never implemented. No wonder we have so many different drivers for very similar hardware. Looks like I have been wrong with my suggestion. Some bigger cleanup would be necessary to fix this mess.

[fmertz]

Author of the SDEC driver here.

The key mapping was discovered long ago, when these XTM5 models started rolling off data centers at EOL. I wrote "detection" code a long time back to try and have this re-wiring handled at runtime but never submitted it for inclusion with lcdproc. The detection was OS-specific (code for Linux and other code for BSD). The code is probably still around on my github repo. As the various Watchguard boxes involve different chipsets, the detection of the southbridge was all that was required. I also had code to handle the Armed/Disarmed LEDs, but as there was nothing obvious in the lcdproc client protocol to control them, it did not seem like a natural fit for this driver.

For the backlight timeout, the original SDEC spec suggested a short half life, so this code made some sense. Several users reported actual burned out back lights as these older models aged. I did not want this code to contribute to those failures. As the backlight hardware improved, it made less sense, clearly.

As time went on, it is probably safe to say that not very many of these original older 32-bit models are still around (x-peak, x-core, etc.) in a meaningful capacity, but I am reluctant to just break backward compatibility. I see the path forward in 2 possible directions:

1. Put more work into this SDEC driver, and expand the features by either

• allowing configuration options in the config file to override default settings for old hardware. This seems easy, but would require changes to the distribution integration packages (think pfSense, or OPNSense). Right now, the driver just runs, there are no parameters to deal with, easy for integration packages.

• runtime identification of the hardware chipset. Runtime detection is "easy", but there are several models by Watchguard, and then a few others by Lanner (Lanner is reputedly the actual manufacturer of the Watchguard hardware). Plus, this detection will likely be OS-specific, and things can get very specific very quickly (compiling for FreeBSD does not mean compiling for OpenBSD or NetBSD). Other OSes may never be supported (Solaris, etc.).

• simple (dirty?) compile-time identification by "bit-ness", i.e. default to the old code for 32-bit builds, (old hardware definitely cannot run 64-bit code) and engage new behavior for all 64-bit builds.

2. Consider this SDEC driver as applying to the older Watchguard models only, and leave it untouched. Focus the effort instead on making the necessary code changes to the more comprehensive HD44780 parallel driver an make the improvements there. This would be a sort of consolidation into fewer drivers, desirable in its own way. The baseline for the changes would be a permanent back light and support for XTM5s forward. Maybe a new connection type would be required to keep backward compatibility as none of us are likely to have an lcm162 around. I contributed the EZIO connection type to this HD44780 driver a while ago, which is really a fairly minor flavor difference to existing serial code.

I have thought about this for a while, and I am leaning toward path 2, but input is welcome.

[jjakob]

Option 2 is better IMO. I'd prefer a configurable backlight that can be turned on/off and a timeout that can be disabled. I haven't looked if any backlight support is already in the driver or if it'd need to be added.
It would be nice to keep the keys configurable, I'd much rather have a extra conf file to ship than to recompile from source. I don't quite remember how the keypress detection works, if it could be done with the KeyDirect (which isn't implemented as @haraldg said so that would need to be done too) or if custom code would need to be done.
As for the Arm LED I'd keep it separate, it's easy enough to compile a little binary or even script to do it.

[haraldg]

Obviously I prefer option 2 too.

I wouldn't fork lcm162 into a new connection type just for testing. However since @jjakob reported incompatibilities in backlight wiring, it might make sense. If you think you can add everything to hd44780 and lcm162 without breaking other HW support, then I suggest to go for it even if it is untested. If you notice some serious incompatibilities, then of course a new connection type is in order.

As for controling extra LEDs, there actually is the "output" command for that in the client language. Though it seems nobody is using it at the moment and it isn't really specified well. I think the building blocks are there, so shouldn't be too difficult to work on that.

[fmertz]

I've tried hd44780 with lcm162

Have you tried the "8bit" connection type? Just browsing through the code, it seems closer to the SDEC.

[jjakob]

@fmertz I can't remember which connection type it was, but the display part worked fine, only the backlight and keys didn't.