Hi, I get the "hd44780: unknown ConnectionType: gpio" when I try to start LCDproc by this config file:

...
[hd44780]
ConnectionType=gpio
Backlight=no
Size=16x2
...

I configured my source folder by this command:

./configure
--enable-debug
--enable-drivers=hd44780,curses
--disable-libusb
--disable-libusb-1-0
--disable-libftdi
--disable-libX11
--disable-libhid
--disable-libpng
--disable-freetype
--disable-ethlcd

Why I get the above error!? :(

Thank you so much!
Antonio

Some of the shared code does a lot of logging. This is a problem for moving this code into a proper shared library, that can be linked in by any lcdproc clients: Not every client will like to have lcdproc style logging... Generally library functions should have as little side effects as possible.

Some of the shared code will be dropped anyway, but especially the socket code should get cleaned up and made available to the external world.

Currently some drivers use libusb-1.0 and some use libusb-0.1 which isn't supported anymore. If drivers aren't ported to the new API, they can't be enabled by distributions like debian and OpenWRT soon. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810428

Any idea what I'm missing? This error isn't present in previous version.

hd44780-bwct-usb.c: In function 'hd_init_bwct_usb':
hd44780-bwct-usb.c:68:3: warning: implicit declaration of function 'usb_init' [-Wimplicit-function-declaration]
usb_init();
^
hd44780-bwct-usb.c:69:3: warning: implicit declaration of function 'usb_find_busses' [-Wimplicit-function-declaration]
usb_find_busses();
^
hd44780-bwct-usb.c:70:3: warning: implicit declaration of function 'usb_find_devices' [-Wimplicit-function-declaration]
usb_find_devices();
^
hd44780-bwct-usb.c:72:4: error: 'PrivateData' has no member named 'usbHandle'
p->usbHandle = NULL;
^
hd44780-bwct-usb.c:73:4: error: 'PrivateData' has no member named 'usbIndex'
p->usbIndex = 0;
^
hd44780-bwct-usb.c:74:3: warning: implicit declaration of function 'usb_get_busses' [-Wimplicit-function-declaration]
for (bus = usb_get_busses(); bus != NULL; bus = bus->next) {
^
hd44780-bwct-usb.c:74:12: warning: assignment makes pointer from integer without a cast
for (bus = usb_get_busses(); bus != NULL; bus = bus->next) {
^
hd44780-bwct-usb.c:74:54: error: dereferencing pointer to incomplete type
for (bus = usb_get_busses(); bus != NULL; bus = bus->next) {
^
hd44780-bwct-usb.c:77:19: error: dereferencing pointer to incomplete type
for (dev = bus->devices; dev != NULL; dev = dev->next) {
^
hd44780-bwct-usb.c:77:52: error: dereferencing pointer to incomplete type
for (dev = bus->devices; dev != NULL; dev = dev->next) {
^
hd44780-bwct-usb.c:81:14: error: dereferencing pointer to incomplete type
if (dev->descriptor.idVendor != BWCT_USB_VENDORID) {
^
hd44780-bwct-usb.c:85:26: error: dereferencing pointer to incomplete type
for (c = 0; c < dev->descriptor.bNumConfigurations; c++) {
^
hd44780-bwct-usb.c:87:15: error: 'PrivateData' has no member named 'usbIndex'
for (p->usbIndex = 0; p->usbIndex < dev->config[c].bNumInterfaces; p->usbIndex++) {
^
hd44780-bwct-usb.c:87:32: error: 'PrivateData' has no member named 'usbIndex'
for (p->usbIndex = 0; p->usbIndex < dev->config[c].bNumInterfaces; p->usbIndex++) {
^
hd44780-bwct-usb.c:87:48: error: dereferencing pointer to incomplete type
for (p->usbIndex = 0; p->usbIndex < dev->config[c].bNumInterfaces; p->usbIndex++) {
^
hd44780-bwct-usb.c:87:77: error: 'PrivateData' has no member named 'usbIndex'
for (p->usbIndex = 0; p->usbIndex < dev->config[c].bNumInterfaces; p->usbIndex++) {
^
hd44780-bwct-usb.c:91:30: error: dereferencing pointer to incomplete type
for (a = 0; a < dev->config[c].interface[p->usbIndex].num_altsetting; a++) {
^
hd44780-bwct-usb.c:91:53: error: 'PrivateData' has no member named 'usbIndex'
for (a = 0; a < dev->config[c].interface[p->usbIndex].num_altsetting; a++) {
^
hd44780-bwct-usb.c:93:22: error: dereferencing pointer to incomplete type
if (((dev->config[c].interface[p->usbIndex].altsetting[a].bInterfaceClass == 0xFF) &&
^
hd44780-bwct-usb.c:93:45: error: 'PrivateData' has no member named 'usbIndex'
if (((dev->config[c].interface[p->usbIndex].altsetting[a].bInterfaceClass == 0xFF) &&
^
hd44780-bwct-usb.c:94:22: error: dereferencing pointer to incomplete type
(dev->config[c].interface[p->usbIndex].altsetting[a].bInterfaceSubClass == 0x01)) ||
^
hd44780-bwct-usb.c:94:45: error: 'PrivateData' has no member named 'usbIndex'
(dev->config[c].interface[p->usbIndex].altsetting[a].bInterfaceSubClass == 0x01)) ||
^
hd44780-bwct-usb.c:95:21: error: dereferencing pointer to incomplete type
(dev->descriptor.idProduct == BWCT_USB_PRODUCTID)) {
^
hd44780-bwct-usb.c:98:16: error: 'PrivateData' has no member named 'usbHandle'
p->usbHandle = usb_open(dev);
^
hd44780-bwct-usb.c:98:15: warning: implicit declaration of function 'usb_open' [-Wimplicit-function-declaration]
p->usbHandle = usb_open(dev);
^
hd44780-bwct-usb.c:99:20: error: 'PrivateData' has no member named 'usbHandle'
if (p->usbHandle == NULL) {
^
hd44780-bwct-usb.c:115:17: warning: implicit declaration of function 'usb_get_string_simple' [-Wimplicit-function-declaration]
if (usb_get_string_simple(p->usbHandle, dev->descriptor.iSerialNumber,
^
hd44780-bwct-usb.c:115:44: error: 'PrivateData' has no member named 'usbHandle'
if (usb_get_string_simple(p->usbHandle, dev->descriptor.iSerialNumber,
^
hd44780-bwct-usb.c:115:60: error: dereferencing pointer to incomplete type
if (usb_get_string_simple(p->usbHandle, dev->descriptor.iSerialNumber,
^
hd44780-bwct-usb.c:121:19: warning: implicit declaration of function 'usb_close' [-Wimplicit-function-declaration]
usb_close(p->usbHandle);
^
hd44780-bwct-usb.c:121:30: error: 'PrivateData' has no member named 'usbHandle'
usb_close(p->usbHandle);
^
hd44780-bwct-usb.c:129:28: error: 'PrivateData' has no member named 'usbHandle'
usb_close(p->usbHandle);
^
hd44780-bwct-usb.c:130:18: error: 'PrivateData' has no member named 'usbHandle'
p->usbHandle = NULL;
^
hd44780-bwct-usb.c:140:8: error: 'PrivateData' has no member named 'usbHandle'
if (p->usbHandle != NULL) {
^
hd44780-bwct-usb.c:144:5: warning: implicit declaration of function 'usb_set_configuration' [-Wimplicit-function-declaration]
if (usb_set_configuration(p->usbHandle, p->usbIndex) < 0) {
^
hd44780-bwct-usb.c:144:32: error: 'PrivateData' has no member named 'usbHandle'
if (usb_set_configuration(p->usbHandle, p->usbIndex) < 0) {
^
hd44780-bwct-usb.c:144:46: error: 'PrivateData' has no member named 'usbIndex'
if (usb_set_configuration(p->usbHandle, p->usbIndex) < 0) {
^
hd44780-bwct-usb.c:150:5: warning: implicit declaration of function 'usb_claim_interface' [-Wimplicit-function-declaration]
if (usb_claim_interface(p->usbHandle, p->usbIndex) < 0) {
^
hd44780-bwct-usb.c:150:30: error: 'PrivateData' has no member named 'usbHandle'
if (usb_claim_interface(p->usbHandle, p->usbIndex) < 0) {
^
hd44780-bwct-usb.c:150:44: error: 'PrivateData' has no member named 'usbIndex'
if (usb_claim_interface(p->usbHandle, p->usbIndex) < 0) {
^
hd44780-bwct-usb.c:166:18: error: 'PrivateData' has no member named 'usbHandle'
usb_close(p->usbHandle);
^
hd44780-bwct-usb.c: In function 'bwct_usb_HD44780_senddata':
hd44780-bwct-usb.c:194:3: warning: implicit declaration of function 'usb_control_msg' [-Wimplicit-function-declaration]
usb_control_msg(p->usbHandle, USB_TYPE_VENDOR, type, ch, p->usbIndex, NULL, 0, 1000);
^
hd44780-bwct-usb.c:194:20: error: 'PrivateData' has no member named 'usbHandle'
usb_control_msg(p->usbHandle, USB_TYPE_VENDOR, type, ch, p->usbIndex, NULL, 0, 1000);
^
hd44780-bwct-usb.c:194:33: error: 'USB_TYPE_VENDOR' undeclared (first use in this function)
usb_control_msg(p->usbHandle, USB_TYPE_VENDOR, type, ch, p->usbIndex, NULL, 0, 1000);
^
hd44780-bwct-usb.c:194:33: note: each undeclared identifier is reported only once for each function it appears in
hd44780-bwct-usb.c:194:61: error: 'PrivateData' has no member named 'usbIndex'
usb_control_msg(p->usbHandle, USB_TYPE_VENDOR, type, ch, p->usbIndex, NULL, 0, 1000);
^
hd44780-bwct-usb.c: In function 'bwct_usb_HD44780_close':
hd44780-bwct-usb.c:201:8: error: 'PrivateData' has no member named 'usbHandle'
if (p->usbHandle != NULL) {
^
hd44780-bwct-usb.c:202:16: error: 'PrivateData' has no member named 'usbHandle'
usb_close(p->usbHandle);
^
hd44780-bwct-usb.c:203:6: error: 'PrivateData' has no member named 'usbHandle'
p->usbHandle = NULL;
^
hd44780-bwct-usb.c: In function 'bwct_usb_HD44780_set_contrast':
hd44780-bwct-usb.c:216:24: error: 'PrivateData' has no member named 'usbHandle'
if (usb_control_msg(p->usbHandle, USB_TYPE_VENDOR, BWCT_LCD_SET_CONTRAST,
^
hd44780-bwct-usb.c:216:37: error: 'USB_TYPE_VENDOR' undeclared (first use in this function)
if (usb_control_msg(p->usbHandle, USB_TYPE_VENDOR, BWCT_LCD_SET_CONTRAST,
^
hd44780-bwct-usb.c:217:31: error: 'PrivateData' has no member named 'usbIndex'
value, p->usbIndex, NULL, 0, 1000) < 0)
^
Makefile:1334: recipe for target 'hd44780-hd44780-bwct-usb.o' failed
make[3]: *** [hd44780-hd44780-bwct-usb.o] Error 1
make[3]: Leaving directory '/usr/src/lcdproc/server/drivers'
Makefile:472: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/usr/src/lcdproc/server'
Makefile:451: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/src/lcdproc'
Makefile:370: recipe for target 'all' failed
make: *** [all] Error 2

In the comment of the hd44780-i2c.c there is an example of the alternative wirings:

  alternative wiring example:
   PCF8574AP: P0 P1 P2 P3 P4 P5 P6 P7
              |  |  |  |  |  |  |  |
   HD44780:   RS RW EN BL D4 D5 D6 D7
   
   in LCDd.conf we then need to define
    i2c_line_RS=0x01
    i2c_line_RW=0x02
    i2c_line_EN=0x04
    i2c_line_BL=0x80
    i2c_line_D4=0x10
    i2c_line_D5=0x20
    i2c_line_D6=0x40
    i2c_line_D7=0x80
    Backlight=yes
    BacklightInvert=yes

but there is an error in the i2c_line_BL=0x80 because it must be i2c_line_BL=0x08.
Someone can fix this?
Thankyou

We got a bug report on the mailing list quite some time ago:

Hi all, I have a picolcdgfx running lcdproc 0.5.7. The initial contrast
value in LCDd.conf is not applied to my LCD correctly. When I tried to
adjust contrast value from glcd menu, it works.

Looks like the init function of the glcd driver actually does read the
contrast value from the config file and store it in the drivers private
data. Probably the init function of either glcd_drv.c or glcd-picolcdgfx.c
should do the function call to set the contrast ...

I just wanted to ask when a new release was planned? I noticed there has been a lot of activity since the last release and some things seem more vital.

Also, if there is anything I can do to help with QA, I am open to it.

• it is not documented
• it may read the wrong configuration file (ignores -c)
• it doesn't notify the clients that screen size might have changed
• it didn't actually work when I tried it

I'm mentioning this mostly to warn @markus2330 and @tom-wa who consider using that feature.

I'm looking to use a graphical LCD (with a T6963 driver) on a raspberry pi, however it seems that the only driver for this is written to use the parallel port. i know that the HD44780 type displays have had the driver adapted to use the GPIO pins of the pi with the correct connection type set in the driver config.
Given that a lot of the drivers are written to use either USB or a parallel port i'm wondering if it would be possible to write a compatibility wrapper to translate parallel port calls to GPIO in a common way to prevent having to rewrite each driver to use the GPIO?

I would attempt to adapt the driver i need but i'm a novice with C/C++ and having had a look at the driver files i'm not even sure where to begin...

the new 0.5.8 release lists some connection types as being obsolete due to the new addition of the gpio connection type, however the raspberrypi connection type supports dual controller displays such as needed to 40x4 format displays by including a second enable pin for the second driver IC, this is missing from the gpio connection type.

as such when i connect my 40x4 driver and use the gpio connection type only the top half of the display is driven.
switching to the raspberrypi connection type fixes this and drives the whole display, i would say that it's wrong to mark it as obsolete when its replacement does not do everything that its predecessor can do.

Hello. lcdd demon works, but there is some problem with the server driver, I guess:

...
[13728.771949] imon:send_packet: packet tx failed (-32)
[13728.781381] imon:lcd_write: send packet failed!
[13753.715177] imon:send_packet: packet tx failed (-32)
[13753.724782] imon:lcd_write: send packet failed!
[13817.052136] imon:send_packet: packet tx failed (-32)
[13817.061700] imon:lcd_write: send packet failed!
[13825.242160] imon:send_packet: packet tx failed (-32)
[13825.251699] imon:lcd_write: send packet failed!
[13877.515668] imon:send_packet: packet tx failed (-32)
[13877.525140] imon:lcd_write: send packet failed!
[13883.522322] imon:send_packet: packet tx failed (-32)
[13883.531890] imon:lcd_write: send packet failed!
[13922.119242] imon:send_packet: packet tx failed (-32)
[13922.128599] imon:lcd_write: send packet failed!
[13999.685908] imon:send_packet: packet tx failed (-32)
[13999.695564] imon:lcd_write: send packet failed!
[14018.399307] imon:send_packet: packet tx failed (-32)
[14018.412253] imon:lcd_write: send packet failed!
...

I'm using imonlcd.so driver with protocol version 1.
Protocol version 0 is not working for me at all.
I tried to add "usleep(100000)" at the end of "send_packet" function, display becomes very "slow", but errors remain.

OS archlinux x64, cpu core i3 6100

Get this when starting LCDPROC services, but there is a MainMenu in the right config and all seems ok and LCD is working, I am guessing the critical error is due to me needing to build LCDPROC on the newer OS version my LCD runs on, but not sure why I am getting the other two errors.

No matching processes were found - this is OK, have a script to check for rogue processes
no main menu found in configuration - unsure why I am getting this
Critical error, abort - ignoring for now until I rebuild

@YARD2 can you look into this:

yard2LCD.c:226:1: warning: return type defaults to 'int' [-Wimplicit-int]
 yard_hwSetBrightness(Driver *drvthis, unsigned char brightVal)
 ^
yard2LCD.c: In function 'yard_init':
yard2LCD.c:308:20: warning: embedded '\0' in format [-Wformat-contains-nul]
  sprintf(Recbuffer,"LCDPROC\0");
                    ^
yard2LCD.c:349:14: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
  p->framebuf = (unsigned char *) malloc((p->width * p->height)*2);
              ^
yard2LCD.c: At top level:
yard2LCD.c:79:12: warning: 'yard_hwEnterGmode' declared 'static' but never defined [-Wunused-function]
 static int yard_hwEnterGmode(Driver *drvthis);
            ^
yard2LCD.c:187:1: warning: 'yard_hwPrintChar' defined but not used [-Wunused-function]
 yard_hwPrintChar(Driver *drvthis, char c)
 ^

I guess nobody ever compiled this driver with -Wall ...

I'm always removing the code in the hd44780 driver which displays the basic parameters and waits 2 secs at startup. It would be more easier for me if it would be a configuration setting. I do this:

diff --git a/server/drivers/hd44780.c b/server/drivers/hd44780.c
index a53639e..920a47a 100644
--- a/server/drivers/hd44780.c
+++ b/server/drivers/hd44780.c
@@ -391,55 +391,6 @@ HD44780_init(Driver *drvthis)
 
 	/* Display startup parameters on the LCD */
 	HD44780_clear(drvthis);
-	sprintf(buf, "HD44780 %dx%d", p->width, p->height);
-	HD44780_string(drvthis, 1, 1, buf);
- 	switch(if_type) {
- 	  case IF_TYPE_USB:
-  		sprintf(buf, "USB %s%s%s",
- 			 (p->have_backlight?" bl":""),
- 			 (p->have_keypad?" key":""),
- 			 (p->have_output?" out":"")
- 			);
- 		break;
- 	  case IF_TYPE_SERIAL:
- 		sprintf(buf, "SERIAL %s%s%s",
- 			 (p->have_backlight?" bl":""),
- 			 (p->have_keypad?" key":""),
- 			 (p->have_output?" out":"")
- 			);
- 		break;
- 	  case IF_TYPE_I2C:
- 		sprintf(buf, "I2C %s%s%s",
- 			 (p->have_backlight?" bl":""),
- 			 (p->have_keypad?" key":""),
- 			 (p->have_output?" out":"")
- 			);
- 		break;
- 	  case IF_TYPE_SPI:
- 		sprintf(buf, "SPI %s%s%s",
- 			 (p->have_backlight?" bl":""),
- 			 (p->have_keypad?" key":""),
- 			 (p->have_output?" out":"")
- 			);
- 		break;
- 	  case IF_TYPE_TCP:
- 		sprintf(buf, "TCP %s%s%s",
- 			 (p->have_backlight?" bl":""),
- 			 (p->have_keypad?" key":""),
- 			 (p->have_output?" out":"")
- 			);
- 		break;
-	  case IF_TYPE_PARPORT:
- 	  default:
- 		sprintf(buf, "LPT 0x%x%s%s%s", p->port,
- 			 (p->have_backlight?" bl":""),
- 			 (p->have_keypad?" key":""),
- 			 (p->have_output?" out":"")
-  			);
-  	}
-	HD44780_string(drvthis, 1, 2, buf);
-	HD44780_flush(drvthis);
-	sleep(2);
 
 	return 0;
 }

In bug 806800, a Debian user reports:

LCDd seems to send critical syslog messages on some weird
situations. I don't know why. Here's an example of a tail on a
logfile:

Message from syslogd@marcos at Dec  1 10:16:06 ...
 sten L

Message from syslogd@marcos at Dec  1 10:16:06 ...
 nore L
déc 01 10:16:05 marcos LCDd[11778]: ignore I
déc 01 10:16:05 marcos LCDd[11778]: listen NT
déc 01 10:16:05 marcos LCDd[11778]: ignore NT
déc 01 10:16:05 marcos LCDd[11778]: listen M
déc 01 10:16:05 marcos LCDd[11778]: ignore M
déc 01 10:16:05 marcos LCDd[11778]: listen L
déc 01 10:16:05 marcos LCDd[11778]: ignore L

Notice how you got `Message` lines above? Those flood *all* terminals
I am connected to - not just the one where i was tailing the
logfile. oddly enough, part of that message is stripped as well
("listen" becomes "sten" and "ignore" becomes "nore", not sure why).

The main issue is that critical messages are issued by LCDd. Anarcat mentions also:

I wonder if this isn't connected to the vsyslog call:

  vsyslog(LOG_USER | (level + 2), format, ap);

This seems to bump up the level, which could distort the levels...

He may be on to something.

All the best

Hello,
Can you display version of lcdproc on startup on the device ?

In the spirit of moving this project forward and keeping changes incremental, how about combining all (or most) existing drivers into just one "universal" driver (yes, one more driver, for now).

Let's get this out of the way first: https://xkcd.com/927/

This new driver would implement a matrix, by de-coupling the "language" from the "hardware interface", meaning this driver could be told what command set to use on the one hand (the few drivers I have seen seem to have similar command sets), and then separately what particular hardware interface to issue those commands over. This new driver could have all the interface code compiled-in or use some new ABI to dynamically load one interface at a time to minimize memory footprint on embedded platforms.

Remember, there is no computer problem that can't be simplified by adding a level of indirection!

If we were to implement something like this, I believe the majority of the needed code would be already there in the existing implementation of each driver. There would be a need for a (massive) refactoring. The HD driver(s) seem like a great place to start.

Also, it would not be disruptive as it would not require changes to LCDd, or ABI (unless we wanted to). It could also be a phased implementation, with more and more LCDs supported over time. This would allow us to retire the corresponding discrete drivers over time, too.

The main idea is that it could fill in the matrix of combinations "for free" and avoid silly situations where we have a driver with the right commands here, and another driver for the hardware interface there, but no implementation combining the two.

Also, we could add "high level" configurations entries that would describe popular combinations of LCDs and interface for pre-made hardware, like commercial firewalls, e.g. an entry for "Watchguard/Lanner" would know to engage the SDEC "language" and the parallel port "interface", making it EASY for end users to get their hardware going, and be the next best thing to an automatic detection. The idea here is to make it easy for individual distributions to create glue code to integrate LCDproc. An example is pfSense, which needs PHP code to integrate packages into the GUI of the distribution. A complicated set of drivers and parameters makes it hard for users to get things to work. If there were fewer options, and pre-configured known-good combinations, this glue-code would be easier to write and maintain, and eventually serve the users better.

Thanks for any thought.

This ticket is to collect ideas for future changes to the driver API, so that we don't forget something when it is time and also to give everybody a fair warning ahead.

Generally speaking, the existing API disallows to reference any symbols in the server from the drivers. This is actually an artificial requirement - dlopen() resolves such symbols just fine. I broke that rule already when changed the access to report() as it was easy to do and solved a number of issues. Maybe there are more symbols, where (read or call) access would make sense for the drivers?

Configuration access will change with the switch to libelektra. We will see what API changes elekra folks will propose.

To improve support for multibyte characters in string rendering, I think an optional length() function,m returning the number of display cells neccessary to display a string, would be important. The fallback would be the usual byte count. I'm not sure whether the function should take a screen coordinate (on some displays not all cells have the same properties) and wether it should return an int (length) or a pointer (to the tail, that won't fit on the screen).

The old sysfs gpio interface of the linux kernel is deprecated in favor of a new ioctl based API. Thus libugpio is discontinued. There is a new library libgpiod that makes interfacing the new API easier. Thus we should switch from one library to the other.

Since the addressing scheme of GPIOs is entirely different now, also driver configuration well need changes, but since the libugpio based connection type never saw much use (likely my bad for pushing libugpio shortly before it was deprecated) this shouldn't be much of a problem.

I kind of feel responsible for this situation and will look into it during the cold season. But if somebody wants to work on it sooner, just leave a note here an feel free to take it over. Should be fairly easy and beginner friendly topic to work on!

All sockets are opened nonblocking, but then we are doing evil things like tight loops in case of EAGAIN and reading one byte at a time. The only code using select() is the server. I haven't looked into this in much detail yet, but this probably requires some fundamental changes, so let's have a discussion and collect our collective wisdom.

This probably isn't much of an issue with LCDd running on a loop-back interface, but with lcdproc sessions running across remote networks we should expect anything.

So far I had the following ideas:

• Switch to blocking IO and use the C stream API (at least for output)
• Use send/recv instead or write/read as these allow to select blocking/nonblocking behaviour on a per call basis (not sure if this is supported by all our supported platforms though)
• Implement our own buffering - there are already a few attempts to do that in the code. Not sure how useful they are
• Change the API to something suitable for event loop integration and move all programms to something like libev

Just need to know what code to look at to see why the LCD mem used % is about twice as much as top, the webgui, and a memory stats pearl script shows.

Looks like we got the linking wrong when the gpio connection type is not built.
https://bbs.nextthing.co/t/lcdproc-with-20-character-by-4-line-lcd/8789/11

I wonder why we don't get an error at build time?

I will look into this in a couple of days.

This ticket is to collect all the ideas for changes to the network protocol (backwards compatible or not). Also maybe to collect current and future real world use cases.

Character encoding (character set?)

Currently LCDd just shuffles bytes between clients and drivers and it is the responsibility of the user to set up everything, so that things fit together. This means we are mostly using 7bit ascii, but exceptions exist. There should be a way to at least negotiate what's supported. Even better if LCDd could be told to do some conversions.

Frames

are specified in the current version of the protocol, but most parts never got implemented (for more then a decade). Maybe it is time to acknoledge that we target small displays where these are not very useful and nobody really needs them. We should figure out which parts are actually implemented (and work!) and drop the rest from the ABI and also remove any code that never actually worked as intended.

Way to edit times (or strings)

This could be a new menu widget or a general input widget (lcdproc currently doesn't have general input widgets though). Either it would be special for editing time strings like we already have for IPv4 addresses or it would take a specification of allowed characters in the string to be edited. The latter would allow to not only edit times, but also cron lines, etc.

Example for simple specification syntax: [012][0-9]:[0-5][0-9]
This example has the problem that "29:00" is not a valid time. The purpose of the specification would be more to make the editing process easier with only Up/Down keys easier, than to ensure that only legal values can be entered. A more complex specification language would be necessary for the latter. Not sure if it is worth the effort, though.

This is an old bug report, I just dug up from the mailinglist archive:

On 11.02.2014 15:11, Jörg Hohwieler wrote:

On 13.01.2014 21:20, Markus Dolze wrote:

On 09.01.2014 12:52, Jörg Hohwieler wrote:

It's a long time since I started this thread, but finally I found a
solution.

--- pylcd.c.orig        2013-11-19 13:02:20.733699143 +0100
+++ pylcd.c     2013-11-19 13:02:28.629900897 +0100
@@ -208,7 +208,7 @@ real_send_tele(PrivateData *p, char *buf
     write(p->FD, buffer2, len);

     /* Take a little nap. This works as a pacemaker */
-    usleep(50);
+    usleep(30000);

     return 0;
 }

Before introduction of high resolution timers I think the timer
granularity was not fine enough for usleep(50). So I guess usleep(50)
took always much more time than intended.

With introduction of highres timers the granularity became much finer,
resulting in the intended sleep time of usleep(50).

Running with usleep(50) the displays processor becomes overloaded as too
much commands are coming in.

Running the kernel now with highres=off and usleep(30000) behaves the
same as with highres=on.

Btw, I've determined the value empirically but it seems to be fine.

Please include my patch above.

thank you.

Best regards
Joerg

Hi Jörg,

I will be happy to commit this. Before that I'd like to test with some
'non Linux' OS. Just for curiosity.

Regards,
Markus

Hi Markus,

were you able to run some tests on "non linux" systems?

Best regards
Joerg

Hello Jörg,

sorry - I almost forgot about this.

Yes, I tested with the longer delay and was not really happy with it.
Updating the LCD slows down a lot. Title scrolling and fast changing bar
graphs like the CPU screen slow down noticeable.

If we need this longer delay, I suggest to make it a configuration
option (e.g. delay in ms) so users can adjust as necessary.

Regards,
Markus

For the next major release, look into moving the project C code base to C99. Everything moves forward, including the language itself. Maybe it is time this project formally adopts C99. As folks are making proposals for important code changes, choosing the language version early would help.

https://en.wikipedia.org/wiki/C99

The title says it all. The CD5220 driver seems to redraw the whole screen every frame, so the display is very stuttery. Possibly it's needed to calculate the difference between frames and upload just that.

I have written a Mac driver for my CD7220 display back in the day which doesn't have the issue: https://bitbucket.org/vladkorotnev/vfd-osx/src/master/

However, I'm not sure if it's possible to backport that into lcdproc?

Not sure how critical the issue is, but it is at least pretty confusing that there seems to be two different 0.5.7 releases. On sourceforge, we have the one from 2014 with the following sha1 (provided by sourceforge themselves) eacc65c5f16237beb18b3cdb4835ba0a57f5f811, and by browsing the releases (well, tags) here on that github page, there is another one dated July 2016.

Unfortunately, even the content of the tarballs is slightly different ...
Just renaming the tag would lift-off the ambiguity ...

I can't get LCDproc to work with a HD44780 display on a Pi zero W.
Hardware is OK as I can drive the display by a python script.

LCDd reports
Server running in foreground
Listening for queries on 127.0.0.1:13666
HD44780: using ConnectionType: raspberrypi
hd44780: Using hd44780_default charmap
check_board_rev: Raspberry Pi 2 or higher detected

I suspect the hardware detection and corresponding determination of GPIO base adress may be a problem here. Pi zero runs on the same SoC as a Pi 1, but is apprently treated as a "Pi2 or higher"

I was trying to port lcdproc 0.5.8 to a new distro and had some issues getting timing.h to do the right thing in the hd44780 driver (which as luck would have it, was the only display hardware I had available to test on).

Distilling the issue:

1. configure.ac expects nanosleep to be in an ancillary library, not in libc (not the case on linux for instance);

this is fixed with:

--- a/lcdproc-0.5.8/configure.ac     2017-02-07 16:28:00.894415517 -0700
+++ b/lcdproc-0.5.8/configure.ac  2017-02-07 16:40:08.906990034 -0700
@@ -86,7 +86,11 @@
 AC_CHECK_FUNC(connect,,[AC_CHECK_LIB(socket,connect)])
 AC_CHECK_FUNC(inet_aton,,[AC_CHECK_LIB(resolv,inet_aton)])
 AC_CHECK_LIB(kstat, kstat_open)
-AC_CHECK_LIB(posix4, nanosleep)
+dnl nanosleep should be in libc if not, try in a POSIX compatibility library
+AC_CHECK_FUNCS(nanosleep)
+AC_CHECK_LIB(posix4, nanosleep,
+       AC_DEFINE([HAVE_NANOSLEEP], [1],
+                       [Define if you have the nanosleep function.]))
 AC_CHECK_FUNCS(getloadavg swapctl)
 AC_CHECK_HEADERS(procfs.h sys/procfs.h sys/loadavg.h utmpx.h)
 

i.e. checking against the default libraries first before checking against libposix4.

2. testing for HAVE_NANOSLEEP and nothing else, such as:

--- a/lcdproc-0.5.8/server/drivers/timing.h  2015-03-27 10:10:45.000000000 -0600
+++ b/lcdproc-0.5.8/server/drivers/timing.h       2017-02-07 16:44:00.944497415 -0700
@@ -46,7 +46,7 @@
 
 /* Autoselect...  Does this always work well ? */
 #ifdef DELAY_AUTOSELECT
-# if defined HAVE_SCHED_H && defined HAVE_SCHED_SETSCHEDULER
+# if defined HAVE_NANOSLEEP
 #  define DELAY_NANOSLEEP
 # else
 #  define DELAY_GETTIMEOFDAY
@@ -76,7 +76,6 @@
 #else /* assume DELAY_NANOSLEEP */
 # undef DELAY_GETTIMEOFDAY
 # undef DELAY_IOCALLS
-# include <sched.h>
 #endif
 
 /*
@@ -130,17 +129,7 @@
 static inline int
 timing_init()
 {
-#if defined DELAY_NANOSLEEP
-       /* Change to Round-Robin scheduling for nanosleep */
-       {
-               /* Set priority to 1 */
-               struct sched_param param;
-               param.sched_priority=1;
-               if (( sched_setscheduler(0, SCHED_RR, &param)) == -1) {
-                       return -1;
-               }
-       }
-#elif defined DELAY_IOCALLS
+#if defined DELAY_IOCALLS
        if (port_access(0x3BD) == -1) {
                return -1;
        }

most OSes today don't require changing out the scheduler for nanosleep() to work so we can drop that check.

3. The comment says it all.

--- a/lcdproc-0.5.8/server/drivers/hd44780.c 2015-03-27 10:10:45.000000000 -0600
+++ b/lcdproc-0.5.8/server/drivers/hd44780.c      2017-02-07 16:00:21.435216682 -0700
@@ -51,16 +51,6 @@
 */ 

 
-/*
- * Uncomment one of the lines below to select your desired delay generation
- * mechanism. Using DELAY_NANOSLEEP  seems to provide the best performance.
- *
- * Setting this here, overrides the set or selected algorithm in timing.h.
- * FIXME: Is this on purpose?
- */
-//#define DELAY_GETTIMEOFDAY
-#define DELAY_NANOSLEEP
-//#define DELAY_IOCALLS
 
 /* Default parallel port address */
 #define LPTPORT         0x378

All that said, I've not managed to bring up the hd44780 display I have (it's actually an ST7063) so perhaps someone else can confirm my changes?

Thanks

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.

I built from the latest source (d6119a9) with ./configure --enable-drivers=hd44780, and I get this error when trying to run LCDd:

pi@frambuesa:~/lcdproc $ sudo /etc/init.d/LCDd start
Starting LCDproc display server daemon: hd_init_gpio: unable to initialize GPIO pins
Driver [hd44780] init failed, return code -1
Could not load driver hd44780
There is no output driver
Critical error while initializing, abort.

@dod38fr writes on the mailing list:

I'm using rc1 to build a new Debian package for lcdproc.

Unfortunately, compilation fails:

gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall -g -O2 -fdebug-prefix-map=/home/domi/debian-dev/build-area/lcdproc-0.5.8~rc1=. -fstack-protector-strong -Wformat -Werror=format-security -Wno-unused-function -c -o futaba-futaba.o test -f 'futaba.c' || echo './'futaba.c
futaba.c: In function ‘futaba_start_driver’:
futaba.c:435:26: error: ‘my_driver’ undeclared (first use in this function)
if (usb_claim_interface(my_driver->my_handle, 0) < 0) {
^~~~~~~~~
futaba.c:435:26: note: each undeclared identifier is reported only once for each function it appears in

@ajw107 Can you look into this?

It would be great to add to the build process so that all of the docbook files are converted to .md so that the documentation could be ready directly on github.

For each pull request - Should a line be added to refer to the pull request?

https://github.com/lcdproc/lcdproc/blob/master/ChangeLog#L8

v0.5dev (ongoing development)

• Update hd44780-i2c driver, pins defined via config file, rather than hardcoded #1

v0.5.7

The issue tracker on sourceforge is still used by some people and has some interessting material. Adding links here to make this easier to find for everybody working on cleaning up and merging patches.

https://sourceforge.net/p/lcdproc/patches/

https://sourceforge.net/p/lcdproc/bugs/

Not sure if the mailing list is still functional so I'm cross-posting the message I sent three days ago here:

I have recently taken over maintainership of LCDjava, a Java client library for LCDproc originally created by boncey / Darren Greaves. It is listed under Clients on lcdproc.org. I have fixed some bugs and improved its documentation and packaging. I feel that the project is soon ready for its first stable release and publication to the central Maven repository.

The Maven repository is used by many Java build systems such as Maven itself, Apache Ivy and Scala SBT. It identifies packages globally by a groupId and an artifactId. As you may know, there is a long-standing tradition in Java of using the reverse fully qualified domain name in the groupId 2. Typically, the product/technology name is appended to the reverse FQDN and may also be used in the artifactId.

I would like to use LCDproc's name in LCDjava's packaging, to make it the "official" LCDproc Java client library. The groupId would for example be "org.lcdproc.lcdjava" and the artifactId "lcdjava". The Java classes would be filed under org.lcdproc.lcdjava.* . I think this is more suitable for a long-lived OSS project than using a personal domain in the packaging info.

I see that LCDproc is in the process of migrating to Git and has a Github organization 3. I would also be happy to move LCDjava over to this organization, along with the example projects (see the two repositories linked from LCDjava's README).

What do the LCDproc developers think about this idea? I have also opened a ticket to see what boncey thinks. 4

Hello

The Debian files and information given in scripts directory are outdated. I suggest to remove them to avoid confusion.

All the best

There are some patches from around 2006 below contrib/patches that for whatever reason didn't get merged. Of course nobody keeps them up to date with the code. We should figure out what to do with them.

I've compiled and am running version 0.5.8 on my raspberry pi 2 with a 40x4 display, as part of some testing I had the lcdproc client running and one of the screens (the first one after boot with default config) was reporting an idle time of 455%....

This is for a ./configure &&make && sudo make install when trying to run with hd44780 on CHIP. This works fine for previous version.

It looks like mx5000tools upstream is dead / inactive. The closest thing to an upstream I could find is an old github mirror and a pull-req there has so far gone unanswered:
coolacid/mx5000tools-revo#1

I've been working on packaging mx5000tools for Fedora, so that the Fedora lcdproc package can be built with mx5000 support, but I think it is probably a better idea to just include the bits of libmx5000 which lcdproc needs directly into the lcdproc mx5000 driver and forget about libmx5000 as a standalone project.

It looks like the code which we need is about 600 lines if copied 1:1, probably less when modified ro better fit in lcdproc (e.g. directly embed necessary data into the driver struct, rather then malloc-ing it separately).

I'm willing to do the work for this and submit a pull-req with the necessary changes. The reason for filing this RFE issue is because I first wanted to know what you think about this, before spending time on it only to have the pull-req denied because you think it is a bad idea...

So what do you think about integrating the few bits of libmx5000 which we need directly into lcdproc?

AFAIK this isn't specified anywhere explicitely, but given that the lcdproc protocol is stream based, I'd expect that I can write to the socket chunks of any size (even bytes) as I see fit. However the current combination of non-blocking IO and buffering doesn't cope with that and discards incomplete lines.

It seems this is not a problem for the existing clients, but can hit you when writing new or custom clients.

Yet an other thing to keep in mind when reworking the socket IO code.

I am having trouble making my own alterations to the LCDd menu that has "options" "screens" on the menu even when the lcdproc server is off but LCDd is on. I only want to add menus there and use "menu_goto" on this level. Also "backlight" method does not work on menu or lcdproc screens. i want to use the lcdproc server and be able to modify it.

Thanks

Hi,
first time to use github (no coder myself yet) so I'm sorry I don't know how to fork and bugfix and submit a pull request for it, so I'm just telling you via an issue that there's a small error in the hd44780-rpi.c:
When I installed lcdproc it told me via syslog that:

"LCDd: check_pin: Use of GPIO pin 2 not allowed"

which is simply not true for rev 2 boards (see http://elinux.org/Rpi_Low-level_peripherals#GPIO_hardware_hacking")

so a small change in hd44780-rpi.c line 91 is necessary:
from: -1, -1, -1, 3, 4, -1, -1, 7,
to: -1, -1, 2, 3, 4, -1, -1, 7,

after which it worked perfectly fine.

This is probably low priority for everybody, but I guess we shouldn't forget to clean this up as well, when we rework the socket stuff.

Currently all widgets on the active screen are redrawn 8 times per second, even if the screen is entirely static and widget data hasn't changed. LCDd doesn't contribute to the system load significantly, so this is low priority to clean up. (Actually on my system it seems to consume more memory the CPU.)

Still I was surprised to find this, given that lot's of driver try hard to implement delta-updates to the frame buffer.

It would be awesome if the Drivers set_char and maybe get_free_char would be exposed over the socket connection so clients could use custom characters.

I realize that this defeats the abstraction layer purpose of LCDproc a bit but IMHO it is better to have this feature only work for supporting devices instead of not having it at all.
Alternative to exposing get_free_char the server could add this information to the hello response.

Is there any chance a PR containing this change will be accepted ?
Otherwise i'll do it quick an dirty only for myself.

Hello,

I currently am running lcdproc with the LIS driver and lcdproc seems to crash on me when loading the disk plugin. I determined this from the debug output.

[root@daniel-desktop ~]# lcdproc -v
LCDproc 0.5.9

[root@daniel-desktop ~]# gdb lcdproc
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) run -f
Starting program: /usr/local/bin/lcdproc -f

Program received signal SIGFPE, Arithmetic exception.
0x00000000004051e2 in disk_screen (rep=<value optimized out>, display=<value optimized out>, flags_ptr=<value optimized out>)
Current language:  auto; currently minimal
(gdb) bt
#0  0x00000000004051e2 in disk_screen (rep=<value optimized out>, display=<value optimized out>, flags_ptr=<value optimized out>)
#1  0x0000000000402d69 in update_screen (m=<value optimized out>, display=<value optimized out>) at mode.c:74
#2  0x0000000000402cb9 in main_loop () at _ctype.h:141
#3  0x0000000000402859 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:356

This is currently on FreeBSD 11.2 AMD64.

I can disable the disk plugin and the problem goes away, so I believe its isolated to that.

lcdproc compiles fine when on my laptop where both old and new libusb are installed,

However, the packaging fails in a chroot where only libusb-1.0-0-dev and libftdi1-dev are installed:

$ grep -E 'lib(usb|ftdi)' /tmp/lcdproc.log |tail -25
Selecting previously unselected package libusb-1.0-0:amd64.
Preparing to unpack .../079-libusb-1.0-0_2%3a1.0.21-1_amd64.deb ...
Unpacking libusb-1.0-0:amd64 (2:1.0.21-1) ...
Selecting previously unselected package libftdi1-2:amd64.
Preparing to unpack .../080-libftdi1-2_1.3-2_amd64.deb ...
Unpacking libftdi1-2:amd64 (1.3-2) ...
Selecting previously unselected package libusb-1.0-0-dev:amd64.
Preparing to unpack .../081-libusb-1.0-0-dev_2%3a1.0.21-1_amd64.deb ...
Unpacking libusb-1.0-0-dev:amd64 (2:1.0.21-1) ...
Selecting previously unselected package libftdi1-dev.
Preparing to unpack .../082-libftdi1-dev_1.3-2_amd64.deb ...
Unpacking libftdi1-dev (1.3-2) ...
Setting up libusb-1.0-0:amd64 (2:1.0.21-1) ...
Setting up libusb-1.0-0-dev:amd64 (2:1.0.21-1) ...
Setting up libftdi1-2:amd64 (1.3-2) ...
Setting up libftdi1-dev (1.3-2) ...
        --enable-libusb \
        ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --enable-stat-nfs --enable-stat-smbfs --enable-drivers=all,\!irman,\!svga --enable-libusb --enable-seamless-hbars --enable-testmenus --enable-permissive-menu-goto --enable-lcdproc-menus
checking if libusb support has been enabled... yes
checking if libusb-1-0 support has been enabled... yes
checking if libftdi support has been enabled... yes
configure: WARNING: The futaba driver needs the libusb library.
configure: WARNING: The IOWarrior driver needs the libusb library.
configure: WARNING: The picolcd driver needs the libusb library.
configure: WARNING: The shuttleVFD driver needs the libusb library.

packaging fails with:

$ grep missing /tmp/lcdproc.log 
dh_install: lcdproc-extra-drivers missing files: usr/lib/*/lcdproc/IOWarrior.so
dh_install: lcdproc-extra-drivers missing files: usr/lib/*/lcdproc/i2500vfd.so
dh_install: lcdproc-extra-drivers missing files: usr/lib/*/lcdproc/lis.so
dh_install: lcdproc-extra-drivers missing files: usr/lib/*/lcdproc/picolcd.so
dh_install: lcdproc-extra-drivers missing files: usr/lib/*/lcdproc/shuttleVFD.so
dh_install: lcdproc-extra-drivers missing files: usr/lib/*/lcdproc/ula200.so
dh_install: missing files, aborting

All the best

Hello

With Debian bug 849659, Benoît Allard report a segfault of hd44780 driver:

Using the hd44780 driver with connectiontype=8bit consistently triggers
a segmentation fault.

The drivers of lcdproc define their own sem_get, sem_wait,
sem_signal, ... (See server/drivers/lcd_sem.h).

Unfortunately, the linux's version of sem_wait (3) is being used,
leading to a segmentation fault.

Program received signal SIGSEGV, Segmentation fault.
sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:44
44	../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S: No such
file or directory. (gdb) bt
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:44
#1  0x00007ffff74049d7 in lcdtime_HD44780_senddata (p=p@entry=0x631d00,
displayID=displayID@entry=0 '\000', flags=flags@entry=1 '\001',
ch=ch@entry=48 '0') at hd44780-ext8bit.c:153 #2  0x00007ffff7404c7f in
hd_init_ext8bit (drvthis=0x630810) at hd44780-ext8bit.c:112 #3
0x00007ffff74022a1 in HD44780_init (drvthis=0x630810) at hd44780.c:373
#4  0x00000000004109a0 in driver_load (name=name@entry=0x6220d0
"hd44780", filename=filename@entry=0x6307d0
"/usr/lib/x86_64-linux-gnu/lcdproc/hd44780.so") at driver.c:153 #5
0x000000000040fddf in drivers_load_driver (name=0x6220d0 "hd44780") at
drivers.c:85 #6  0x0000000000407df5 in init_drivers () at main.c:670
#7  0x000000000040635b in main (argc=<optimized out>, argv=<optimized
out>) at main.c:2

I'm not sure whether this problem comes from lcdproc ot the way this package is built with Debian.
For reference, here's Debian build log on i386.

Do you have an idea on how to solve this problem ? (the frist that come to mind is to rename lcdproc's sem_wait function to avoid this collision, but a simpler solution may exist).

All the best