From avdongen at xs4all.nl Thu Jan 1 16:40:34 2009 From: avdongen at xs4all.nl (Arthur van Dongen) Date: Thu, 01 Jan 2009 17:40:34 +0100 Subject: [Lcdproc] [PATCH] redesigned icon support Message-ID: <1230828034.5209.26.camel@TangoLinux.lan> Hi all, First I'd like to wish you all a happy and fruitful new year, with lots of backlight and fluorescence ;-) In other words: Enjoy! Having said that, I would like to present my second patch for the support of icons on my MD8800 display. I implemented some remarks on my first patch: - I now use the term global_icon. I think it matches the purpose better, and emphasises that it is not screen- or widget related. - Parsing is now done in the core, not in the driver. This makes it easier to add support in other drivers. In addition to static texts, the parser also handles numbers, for using strings like "VOLUME.80". - Drivers should export functions global_icon_set and global_icon_clear to set and clear icons. The functions get an icon id, and should return 0 when the id is handled. - Clients can use the get and set functions to test if a certain icon is supported by the core and the loaded drivers. - There is (currently) no interface available to test the status of the icons. The reason is that this makes driver implementation easier. The diff contains modifications to existing files and there are a few new files: drivers/globalicons.h, commands/globalicon_commands.[ch]. As always, any feedback is appreciated. Arthur -------------- next part -------------- ? .cdtproject ? .project ? .settings ? LCDd_test.conf ? cvsdiff.out ? clients/.cdtproject ? clients/.project ? clients/.settings ? docs/LCDd.8 ? docs/lcdproc-config.5 ? docs/lcdproc.1 ? docs/lcdproc-dev/README.tex ? docs/lcdproc-dev/a1960.html ? docs/lcdproc-dev/add-your-driver.tex ? docs/lcdproc-dev/bookinfo.tex ? docs/lcdproc-dev/c1245.html ? docs/lcdproc-dev/c150.html ? docs/lcdproc-dev/c1608.html ? docs/lcdproc-dev/c1707.html ? docs/lcdproc-dev/c35.html ? docs/lcdproc-dev/c47.html ? docs/lcdproc-dev/driver-api.tex ? docs/lcdproc-dev/introduction.tex ? docs/lcdproc-dev/language.tex ? docs/lcdproc-dev/lcdproc-dev.tex ? docs/lcdproc-dev/license.tex ? docs/lcdproc-dev/make-driver.tex ? docs/lcdproc-dev/shared-files.tex ? docs/lcdproc-dev/x11.html ? docs/lcdproc-dev/x114.html ? docs/lcdproc-dev/x1158.html ? docs/lcdproc-dev/x12.html ? docs/lcdproc-dev/x1255.html ? docs/lcdproc-dev/x1266.html ? docs/lcdproc-dev/x155.html ? docs/lcdproc-dev/x161.html ? docs/lcdproc-dev/x1614.html ? docs/lcdproc-dev/x1669.html ? docs/lcdproc-dev/x1713.html ? docs/lcdproc-dev/x1970.html ? docs/lcdproc-dev/x1980.html ? docs/lcdproc-dev/x1984.html ? docs/lcdproc-dev/x1990.html ? docs/lcdproc-dev/x2026.html ? docs/lcdproc-dev/x2031.html ? docs/lcdproc-dev/x2035.html ? docs/lcdproc-dev/x2039.html ? docs/lcdproc-dev/x2042.html ? docs/lcdproc-dev/x2045.html ? docs/lcdproc-dev/x2050.html ? docs/lcdproc-dev/x21.html ? docs/lcdproc-dev/x22.html ? docs/lcdproc-dev/x25.html ? docs/lcdproc-dev/x31.html ? docs/lcdproc-dev/x52.html ? docs/lcdproc-dev/x6.html ? docs/lcdproc-dev/x62.html ? docs/lcdproc-dev/x67.html ? docs/lcdproc-dev/x68.html ? docs/lcdproc-dev/x7.html ? docs/lcdproc-dev/x72.html ? docs/lcdproc-dev/x76.html ? docs/lcdproc-dev/x80.html ? docs/lcdproc-dev/x83.html ? docs/lcdproc-dev/x86.html ? docs/lcdproc-dev/x91.html ? docs/lcdproc-dev/x962.html ? scripts/init-LCDd.LSB ? scripts/init-lcdexec.LSB ? scripts/init-lcdexec.debian ? scripts/init-lcdproc.LSB ? scripts/init-lcdvc.LSB ? scripts/init-lcdvc.debian ? server/.cdtproject ? server/.project ? server/.settings ? server/commands/globalicon_commands.c ? server/commands/globalicon_commands.h ? server/drivers/globalicons.c ? server/drivers/globalicons.h Index: server/driver.c =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/driver.c,v retrieving revision 1.21 diff -u -r1.21 driver.c --- server/driver.c 14 Dec 2008 23:38:42 -0000 1.21 +++ server/driver.c 1 Jan 2009 16:29:34 -0000 @@ -76,6 +76,8 @@ { "output", offsetof(Driver, output), 0 }, { "get_key", offsetof(Driver, get_key), 0 }, { "get_info", offsetof(Driver, get_info), 0 }, + { "globalicon_set", offsetof(Driver, globalicon_set), 0 }, + { "globalicon_clear", offsetof(Driver, globalicon_clear), 0 }, { NULL, 0, 0 } }; @@ -654,7 +656,6 @@ drv->chr(drv, x+1, y, ch2); } - /** Set cursor position and state. * Fallback for the driver's \c cursor method if the driver does not provide one. * \param drv Pointer to driver structure. Index: server/drivers.c =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/drivers.c,v retrieving revision 1.23 diff -u -r1.23 drivers.c --- server/drivers.c 30 Nov 2008 22:31:20 -0000 1.23 +++ server/drivers.c 1 Jan 2009 16:29:34 -0000 @@ -27,6 +27,7 @@ #include "drivers.h" #include "driver.h" #include "drivers/lcd.h" +#include "drivers/globalicons.h" #include "widget.h" /* lcd.h is used for the driver API definition */ @@ -388,6 +389,60 @@ } } +/** + * Write global icon to all drivers. + * For drivers that define a globalicon_set() function, call it; + * \param icon symbolic value representing the icon. See globalicons.h + * \return 0 if any driver supports this icon. + * -1 if no driver reported OK in its globalicon_set function call. + */ +int +drivers_globalicon_set(global_icon_ids global_icon_id) +{ + Driver *drv; + int retval = -1; + int r = 0; + debug(RPT_DEBUG, "%s(icon=%x)", __FUNCTION__, global_icon_id); + + ForAllDrivers(drv) { + /* Does the driver have the icon function ? */ + if (drv->globalicon_set) { + /* Try driver call */ + r = drv->globalicon_set(drv, global_icon_id); + if (r == 0) + retval = r; + } + } + return retval; // 0 if OK returned from any driver +} + +/** + * Write global icon to all drivers. + * For drivers that define a globalicon_clear() function, call it; + * \param icon symbolic value representing the icon. See globalicons.h + * \return 0 if any driver supports this icon. + * -1 if no driver reported OK in its globalicon_clear function call. + */ +int +drivers_globalicon_clear(global_icon_ids global_icon_id) +{ + Driver *drv; + int retval = -1; + int r = 0; + debug(RPT_DEBUG, "%s(icon=%x)", __FUNCTION__, global_icon_id); + + ForAllDrivers(drv) { + /* Does the driver have the icon function ? */ + if (drv->globalicon_clear) { + /* Try driver call */ + r = drv->globalicon_clear(drv, global_icon_id); + if (r == 0) + retval = r; + } + } + return retval; // 0 if OK returned from any driver +} + /** * Set cursor on all loaded drivers. Index: server/drivers.h =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/drivers.h,v retrieving revision 1.13 diff -u -r1.13 drivers.h --- server/drivers.h 30 Nov 2008 22:31:20 -0000 1.13 +++ server/drivers.h 1 Jan 2009 16:29:34 -0000 @@ -80,6 +80,12 @@ void drivers_backlight(int brightness); +int +drivers_globalicon_set(global_icon_ids global_icon_id); + +int +drivers_globalicon_clear(global_icon_ids global_icon_id); + void drivers_output(int state); Index: server/widget.h =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/widget.h,v retrieving revision 1.16 diff -u -r1.16 widget.h --- server/widget.h 14 Dec 2008 09:33:01 -0000 1.16 +++ server/widget.h 1 Jan 2009 16:29:34 -0000 @@ -34,15 +34,15 @@ /** Widget structure */ typedef struct Widget { - char *id; /**< the widget's name */ - WidgetType type; /**< the widget's type */ - Screen *screen; /**< What screen is this widget in ? */ - int x, y; /**< Position */ - int width, height; /**< Visible size */ + char *id; /**< the widget's name */ + WidgetType type; /**< the widget's type */ + Screen *screen; /**< What screen is this widget in ? */ + int x, y; /**< Position */ + int width, height; /**< Visible size */ int left, top, right, bottom; /**< bounding rectangle */ - int length; /**< size or direction */ - int speed; /**< For scroller... */ - char *text; /**< text or binary data */ + int length; /**< size or direction */ + int speed; /**< For scroller... */ + char *text; /**< text or binary data */ struct Screen *frame_screen; /**< frame widget get an associated screen */ //LinkedList *kids; /* Frames can contain more widgets...*/ } Widget; Index: server/commands/Makefile.am =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/commands/Makefile.am,v retrieving revision 1.3 diff -u -r1.3 Makefile.am --- server/commands/Makefile.am 16 Jan 2006 19:36:59 -0000 1.3 +++ server/commands/Makefile.am 1 Jan 2009 16:29:34 -0000 @@ -2,7 +2,7 @@ noinst_LIBRARIES = libLCDcommands.a -libLCDcommands_a_SOURCES = command_list.c command_list.h client_commands.c client_commands.h menu_commands.c menu_commands.h screen_commands.c screen_commands.h server_commands.c server_commands.h widget_commands.c widget_commands.h +libLCDcommands_a_SOURCES = command_list.c command_list.h client_commands.c client_commands.h globalicon_commands.c globalicon_commands.h menu_commands.c menu_commands.h screen_commands.c screen_commands.h server_commands.c server_commands.h widget_commands.c widget_commands.h AM_CPPFLAGS = -I$(top_srcdir) -I$(srcdir)/.. Index: server/commands/client_commands.h =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/commands/client_commands.h,v retrieving revision 1.5 diff -u -r1.5 client_commands.h --- server/commands/client_commands.h 30 Nov 2008 22:42:34 -0000 1.5 +++ server/commands/client_commands.h 1 Jan 2009 16:29:34 -0000 @@ -20,6 +20,5 @@ int client_add_key_func(Client *c, int argc, char **argv); int client_del_key_func(Client *c, int argc, char **argv); int backlight_func(Client *c, int argc, char **argv); - #endif Index: server/commands/command_list.c =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/commands/command_list.c,v retrieving revision 1.8 diff -u -r1.8 command_list.c --- server/commands/command_list.c 30 Nov 2008 22:42:34 -0000 1.8 +++ server/commands/command_list.c 1 Jan 2009 16:29:34 -0000 @@ -23,37 +23,40 @@ #include "screen_commands.h" #include "widget_commands.h" #include "menu_commands.h" +#include "globalicon_commands.h" #include #include static client_function commands[] = { - { "test_func", test_func_func }, - { "hello", hello_func }, - { "client_set", client_set_func }, - { "client_add_key", client_add_key_func }, - { "client_del_key", client_del_key_func }, -/* { "screen_add_key", screen_add_key_func }, */ -/* { "screen_del_key", screen_del_key_func }, */ - { "screen_add", screen_add_func }, - { "screen_del", screen_del_func }, - { "screen_set", screen_set_func }, - { "widget_add", widget_add_func }, - { "widget_del", widget_del_func }, - { "widget_set", widget_set_func }, - { "menu_add_item", menu_add_item_func }, - { "menu_del_item", menu_del_item_func }, - { "menu_set_item", menu_set_item_func }, - { "menu_goto", menu_goto_func }, - { "menu_set_main", menu_set_main_func }, + { "test_func", test_func_func }, + { "hello", hello_func }, + { "client_set", client_set_func }, + { "client_add_key", client_add_key_func }, + { "client_del_key", client_del_key_func }, +/* { "screen_add_key", screen_add_key_func }, */ +/* { "screen_del_key", screen_del_key_func }, */ + { "screen_add", screen_add_func }, + { "screen_del", screen_del_func }, + { "screen_set", screen_set_func }, + { "widget_add", widget_add_func }, + { "widget_del", widget_del_func }, + { "widget_set", widget_set_func }, + { "menu_add_item", menu_add_item_func }, + { "menu_del_item", menu_del_item_func }, + { "menu_set_item", menu_set_item_func }, + { "menu_goto", menu_goto_func }, + { "menu_set_main", menu_set_main_func }, /* Misc stuff...*/ - { "backlight", backlight_func }, - { "output", output_func }, - { "noop", noop_func }, - { "info", info_func }, - { "sleep", sleep_func }, - { "bye", bye_func }, - { NULL, NULL}, + { "backlight", backlight_func }, + { "output", output_func }, + { "globalicon_set", globalicon_set_func }, + { "globalicon_clear",globalicon_clear_func }, + { "noop", noop_func }, + { "info", info_func }, + { "sleep", sleep_func }, + { "bye", bye_func }, + { NULL, NULL}, }; Index: server/commands/screen_commands.c =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/commands/screen_commands.c,v retrieving revision 1.13 diff -u -r1.13 screen_commands.c --- server/commands/screen_commands.c 30 Nov 2008 22:42:34 -0000 1.13 +++ server/commands/screen_commands.c 1 Jan 2009 16:29:34 -0000 @@ -193,9 +193,13 @@ /* first try to interpret it as a number */ number = atoi(argv[i]); if (number > 0) { - if (number <= 64) + if (number <= 32) + number = PRI_INPUT; + else if (number <= 64) + number = PRI_ALERT; + else if (number <= 128) number = PRI_FOREGROUND; - else if (number < 192) + else if (number <= 192) number = PRI_INFO; else number = PRI_BACKGROUND; Index: server/drivers/MD8800.c =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/drivers/MD8800.c,v retrieving revision 1.6 diff -u -r1.6 MD8800.c --- server/drivers/MD8800.c 21 Dec 2008 10:04:37 -0000 1.6 +++ server/drivers/MD8800.c 1 Jan 2009 16:29:35 -0000 @@ -3,7 +3,7 @@ */ /* - Copyright (C) 2006 Stefan Herdler in collaboration with Martin M?. + Copyright (C) 2006 Stefan Herdler in collaboration with Martin M?ller. This source Code is based on the NoritakeVFD, the serialVFD and the CFontzPacket Driver of this package. @@ -28,7 +28,7 @@ ============================================================================== Known hardware-commands of the MD8800 display - discovered by Martin M? (listed in octal notation): + discovered by Martin M?ller (listed in octal notation): \33\0abcdef (abcdef can be anything, it seems) - set clock, I think. The mapping is: bb:aa dd.cc.eeff @@ -179,6 +179,7 @@ #include #include #include +#include #ifdef HAVE_CONFIG_H # include "config.h" @@ -189,12 +190,14 @@ #include "report.h" #include "lcd_lib.h" +#include "globalicons.h" /* Constants for userdefchar_mode */ #define NUM_CCs 0 /* max. number of custom characters */ #define DEFAULT_OFF_BRIGHTNESS 300 #define DEFAULT_ON_BRIGHTNESS 1000 + /** private data for the \c MD8800 driver */ typedef struct MD8800_private_data { char device[200]; @@ -212,6 +215,12 @@ int hw_brightness; int last_command; int wifi_scan; + int playmode; + int recording; + int mediasrc; + int mediatype; + int volume; + int mail; char info[255]; } PrivateData; @@ -602,6 +611,510 @@ // Controls the custom icons. // // + +MODULE_EXPORT int +MD8800_globalicon_set (Driver *drvthis, global_icon_ids global_icon_id) +{ + PrivateData *p = drvthis->private_data; + + switch(global_icon_id) + { + case ALL_ALL: + p->playmode = PLAYMODE_ALL; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F", 11); + write(p->fd, "\x1B\x30\x08", 3); // Turn on REC icon + write(p->fd, &p->hw_brightness, 1); // .. using right brightness level + write(p->fd, "\x1B\x30\x1C\x01", 4); // bounding box + write(p->fd, "\x1B\x30\x13\x01", 4); // turn on speaker icon + write(p->fd, "\x1B\x30\x14\x01", 4); // turn on muted speaker icon + write(p->fd, "\x1B\x30\x0B\x01", 4); // turn on all volume levels + write(p->fd, "\x1B\x30\x0C\x01", 4); + write(p->fd, "\x1B\x30\x0D\x01", 4); + write(p->fd, "\x1B\x30\x0E\x01", 4); + write(p->fd, "\x1B\x30\x0F\x01", 4); + write(p->fd, "\x1B\x30\x10\x01", 4); + write(p->fd, "\x1B\x30\x11\x01", 4); + write(p->fd, "\x1B\x30\x12\x01", 4); + + write(p->fd, "\x1B\x30\x09\x01", 4); // mail envelope + write(p->fd, "\x1B\x30\x0A\x01", 4); // mail envelope fill + write(p->fd, "\x1B\x30\x1B\x01", 4); // turn on email boundinbox + + p->mediasrc = MEDIASOURCE_ALL; + write(p->fd, "\x1B\x30\x00", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x01", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x02", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x03", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x18\x01", 4); + + p->mediatype = MEDIATYPE_ALL; + write(p->fd, "\x1B\x30\x04", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x05", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x06", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x07", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x19\x01", 4); + + write(p->fd, "\x1B\x30\x15\x01", 4); // red wifi icon + write(p->fd, "\x1B\x30\x16\x01", 4); + write(p->fd, "\x1B\x30\x17\x01", 4); + break; + case PLAYMODE_ALL: + p->playmode = PLAYMODE_ALL; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F\x7F", 11); + break; + case PLAYMODE_PLAY: + p->playmode = PLAYMODE_PLAY; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x00\x08\x1C\x3E\x7F\x00\x00\x00", 11); + break; + case PLAYMODE_STOP: + p->playmode = PLAYMODE_STOP; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x3E\x3E\x3E\x3E\x3E\x00\x00\x00", 11); + break; + case PLAYMODE_PAUSE: + p->playmode = PLAYMODE_PAUSE; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x3E\x3E\x00\x3E\x3E\x00\x00\x00", 11); + break; + case PLAYMODE_FF: + p->playmode = PLAYMODE_FF; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x08\x1C\x3E\x08\x1C\x3E\x00\x00", 11); + break; + case PLAYMODE_REW: + p->playmode = PLAYMODE_REW; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x3E\x1C\x08\x3E\x1C\x08\x00\x00", 11); + break; + case RECORDING_REC: + case RECORDING_ALL: + p->recording = RECORDING_REC; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x30\x08", 3); // Turn on REC icon + write(p->fd, &p->hw_brightness, 1); // .. using right brightness level + break; + case VOLUME_ALL: + write(p->fd, "\x1B\x30\x1C\x01", 4); // bounding box + write(p->fd, "\x1B\x30\x13\x01", 4); // turn on speaker icon + write(p->fd, "\x1B\x30\x14\x01", 4); // turn on muted speaker icon + write(p->fd, "\x1B\x30\x0B\x01", 4); // turn on all volume levels + write(p->fd, "\x1B\x30\x0C\x01", 4); + write(p->fd, "\x1B\x30\x0D\x01", 4); + write(p->fd, "\x1B\x30\x0E\x01", 4); + write(p->fd, "\x1B\x30\x0F\x01", 4); + write(p->fd, "\x1B\x30\x10\x01", 4); + write(p->fd, "\x1B\x30\x11\x01", 4); + write(p->fd, "\x1B\x30\x12\x01", 4); + break; + case VOLUME_MUTE: + write(p->fd, "\x1B\x30\x1C\x01", 4); // bounding box + write(p->fd, "\x1B\x30\x13\x00", 4); // turn off speaker icon + write(p->fd, "\x1B\x30\x14\x01", 4); // turn on muted speaker icon + break; + case VOLUME_UNMUTE: + write(p->fd, "\x1B\x30\x1C\x01", 4); // bounding box + write(p->fd, "\x1B\x30\x13\x01", 4); // turn on speaker icon + write(p->fd, "\x1B\x30\x14\x00", 4); // turn off muted speaker icon + break; + case MAIL_ALL: + write(p->fd, "\x1B\x30\x09\x01", 4); + write(p->fd, "\x1B\x30\x0A\x01", 4); + write(p->fd, "\x1B\x30\x1B\x01", 4); // turn on email boundinbox + break; + case MAIL_OUTLINE: + p->mail = MAIL_OUTLINE; + write(p->fd, "\x1B\x30\x09\x01", 4); + write(p->fd, "\x1B\x30\x1B\x01", 4); // turn on email boundingbox + break; + case MAIL_NEWMAIL: + p->mail = MAIL_NEWMAIL; + write(p->fd, "\x1B\x30\x09\x01", 4); + write(p->fd, "\x1B\x30\x0A\x01", 4); + write(p->fd, "\x1B\x30\x1B\x01", 4); // turn on email boundinbox + break; + case MEDIASOURCE_ALL: + p->mediasrc = MEDIASOURCE_ALL; + write(p->fd, "\x1B\x30\x00", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x01", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x02", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x03", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x18\x01", 4); + break; + case MEDIASOURCE_HDD: + p->mediasrc = MEDIASOURCE_HDD; + write(p->fd, "\x1B\x30\x00", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x18\x01", 4); + break; + case MEDIASOURCE_IEEE1394: + p->mediasrc = MEDIASOURCE_IEEE1394; + write(p->fd, "\x1B\x30\x01", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x18\x01", 4); + break; + case MEDIASOURCE_CD: + p->mediasrc = MEDIASOURCE_CD; + write(p->fd, "\x1B\x30\x02", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x18\x01", 4); + break; + case MEDIASOURCE_USB: + p->mediasrc = MEDIASOURCE_USB; + write(p->fd, "\x1B\x30\x03", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x18\x01", 4); + break; + case MEDIATYPE_ALL: + p->mediatype = MEDIATYPE_ALL; + write(p->fd, "\x1B\x30\x04", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x05", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x06", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x07", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x19\x01", 4); + break; + case MEDIATYPE_MOVIE: + p->mediatype = MEDIATYPE_MOVIE; + write(p->fd, "\x1B\x30\x04", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x19\x01", 4); + break; + case MEDIATYPE_TV: + p->mediatype = MEDIATYPE_TV; + write(p->fd, "\x1B\x30\x05", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x19\x01", 4); + break; + case MEDIATYPE_MUSIC: + p->mediatype = MEDIATYPE_MUSIC; + write(p->fd, "\x1B\x30\x06", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x19\x01", 4); + break; + case MEDIATYPE_PHOTO: + p->mediatype = MEDIATYPE_PHOTO; + write(p->fd, "\x1B\x30\x07", 3); + write(p->fd, &p->hw_brightness, 1); + write(p->fd, "\x1B\x30\x19\x01", 4); + break; + case WIFI_ALL: + write(p->fd, "\x1B\x30\x1C\x01", 4); // bounding box + write(p->fd, "\x1B\x30\x15\x01", 4); + write(p->fd, "\x1B\x30\x16\x01", 4); + write(p->fd, "\x1B\x30\x17\x01", 4); + break; + case WIFI_ANTENNA: + write(p->fd, "\x1B\x30\x15\x01", 4); + break; + default: + if ((global_icon_id >= VOLUME_LEVEL_MIN) && (global_icon_id <= VOLUME_LEVEL_MAX)) + { + int volumeLevel = global_icon_id - VOLUME_LEVEL_MIN; + p->volume = volumeLevel; + if (volumeLevel > 100) + { + volumeLevel = -1; + } + if (volumeLevel >= 12) + write(p->fd, "\x1B\x30\x0B\x01", 4); + else + write(p->fd, "\x1B\x30\x0B\x00", 4); + if (volumeLevel >= 25) + write(p->fd, "\x1B\x30\x0C\x01", 4); + else + write(p->fd, "\x1B\x30\x0C\x00", 4); + if (volumeLevel >= 37) + write(p->fd, "\x1B\x30\x0D\x01", 4); + else + write(p->fd, "\x1B\x30\x0D\x00", 4); + if (volumeLevel >= 50) + write(p->fd, "\x1B\x30\x0E\x01", 4); + else + write(p->fd, "\x1B\x30\x0E\x00", 4); + if (volumeLevel >= 62) + write(p->fd, "\x1B\x30\x0F\x01", 4); + else + write(p->fd, "\x1B\x30\x0F\x00", 4); + if (volumeLevel >= 75) + write(p->fd, "\x1B\x30\x10\x01", 4); + else + write(p->fd, "\x1B\x30\x10\x00", 4); + if (volumeLevel >= 87) + write(p->fd, "\x1B\x30\x11\x01", 4); + else + write(p->fd, "\x1B\x30\x11\x00", 4); + if (volumeLevel >= 100) + write(p->fd, "\x1B\x30\x12\x01", 4); + else + write(p->fd, "\x1B\x30\x12\x00", 4); + break; + } + else if ((global_icon_id >= WIFI_LEVEL_MIN) && (global_icon_id <= WIFI_LEVEL_MAX)) + { + int wifilevel = global_icon_id - WIFI_LEVEL_MIN; + if (wifilevel > 33) + write(p->fd, "\x1B\x30\x16\x01", 4); + else + write(p->fd, "\x1B\x30\x16\x00", 4); + if (wifilevel > 66) + write(p->fd, "\x1B\x30\x17\x01", 4); + else + write(p->fd, "\x1B\x30\x17\x00", 4); + break; + } + return -1; + } + return 0; +} + +MODULE_EXPORT int +MD8800_globalicon_clear (Driver *drvthis, global_icon_ids global_icon_id) +{ + PrivateData *p = drvthis->private_data; + + switch(global_icon_id) + { + case ALL_ALL: + // clear playmode section + p->playmode = 0; + write(p->fd, "\x1B\x30\x1A\x00", 4); // turn off bounding box + write(p->fd, "\x1B\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00", 11); + + p->recording = 0; + write(p->fd, "\x1B\x30\x08\x00", 4); // Turn off REC icon + write(p->fd, "\x1B\x30\x1C\x00", 4); // bounding box + + write(p->fd, "\x1B\x30\x13\x00", 4); // turn off speaker icon + write(p->fd, "\x1B\x30\x14\x00", 4); // turn off muted speaker icon + write(p->fd, "\x1B\x30\x0B\x00", 4); // turn off all volume levels + write(p->fd, "\x1B\x30\x0C\x00", 4); + write(p->fd, "\x1B\x30\x0D\x00", 4); + write(p->fd, "\x1B\x30\x0E\x00", 4); + write(p->fd, "\x1B\x30\x0F\x00", 4); + write(p->fd, "\x1B\x30\x10\x00", 4); + write(p->fd, "\x1B\x30\x11\x00", 4); + write(p->fd, "\x1B\x30\x12\x00", 4); + + write(p->fd, "\x1B\x30\x09\x00", 4); + write(p->fd, "\x1B\x30\x0A\x00", 4); + write(p->fd, "\x1B\x30\x1B\x00", 4); // turn off email boundinbox + + write(p->fd, "\x1B\x30\x00\x00", 4); // media source + write(p->fd, "\x1B\x30\x01\x00", 4); + write(p->fd, "\x1B\x30\x02\x00", 4); + write(p->fd, "\x1B\x30\x03\x00", 4); + write(p->fd, "\x1B\x30\x18\x00", 4); + + write(p->fd, "\x1B\x30\x04\x00", 4); // media type + write(p->fd, "\x1B\x30\x05\x00", 4); + write(p->fd, "\x1B\x30\x06\x00", 4); + write(p->fd, "\x1B\x30\x07\x00", 4); + write(p->fd, "\x1B\x30\x19\x00", 4); + + write(p->fd, "\x1B\x30\x15\x00", 4); // red wifi icon + write(p->fd, "\x1B\x30\x16\x00", 4); + write(p->fd, "\x1B\x30\x17\x00", 4); + break; + case PLAYMODE_ALL: + p->playmode = 0; + write(p->fd, "\x1B\x30\x1A\x00", 4); // turn off bounding box + write(p->fd, "\x1B\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00", 11); + break; + case PLAYMODE_PLAY: + if (p->playmode == PLAYMODE_PLAY) + { + p->playmode = 0; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00", 11); + } + break; + case PLAYMODE_STOP: + if (p->playmode == PLAYMODE_STOP) + { + p->playmode = 0; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00", 11); + } + break; + case PLAYMODE_PAUSE: + if (p->playmode == PLAYMODE_PAUSE) + { + p->playmode = 0; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00", 11); + } + break; + case PLAYMODE_FF: + if (p->playmode == PLAYMODE_FF) + { + p->playmode = 0; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00", 11); + } + break; + case PLAYMODE_REW: + if (p->playmode == PLAYMODE_REW) + { + p->playmode = 0; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x31\x00\x00\x00\x00\x00\x00\x00\x00\x00", 11); + } + break; + case RECORDING_REC: + p->recording = 0; + write(p->fd, "\x1B\x30\x08\x00", 4); // Turn off REC icon + break; + case RECORDING_ALL: + p->recording = 0; + write(p->fd, "\x1B\x30\x1A\x01", 4); // turn on bounding box + write(p->fd, "\x1B\x30\x08\x00", 4); // Turn off REC icon + break; + case VOLUME_ALL: + write(p->fd, "\x1B\x30\x1C\x00", 4); // bounding box + write(p->fd, "\x1B\x30\x13\x00", 4); // turn off speaker icon + write(p->fd, "\x1B\x30\x14\x00", 4); // turn off muted speaker icon + write(p->fd, "\x1B\x30\x0B\x00", 4); // turn off all volume levels + write(p->fd, "\x1B\x30\x0C\x00", 4); + write(p->fd, "\x1B\x30\x0D\x00", 4); + write(p->fd, "\x1B\x30\x0E\x00", 4); + write(p->fd, "\x1B\x30\x0F\x00", 4); + write(p->fd, "\x1B\x30\x10\x00", 4); + write(p->fd, "\x1B\x30\x11\x00", 4); + write(p->fd, "\x1B\x30\x12\x00", 4); + break; + case VOLUME_MUTE: + write(p->fd, "\x1B\x30\x14\x00", 4); // turn off muted speaker icon + break; + case VOLUME_UNMUTE: + write(p->fd, "\x1B\x30\x13\x00", 4); // turn off speaker icon + break; + case MAIL_ALL: + write(p->fd, "\x1B\x30\x09\x00", 4); + write(p->fd, "\x1B\x30\x0A\x00", 4); + write(p->fd, "\x1B\x30\x1B\x00", 4); // turn off email boundinbox + break; + case MAIL_OUTLINE: + write(p->fd, "\x1B\x30\x09\x00", 4); + break; + case MAIL_NEWMAIL: + p->mail = MAIL_NEWMAIL; + write(p->fd, "\x1B\x30\x09\x00", 4); + write(p->fd, "\x1B\x30\x0A\x00", 4); + break; + case MEDIASOURCE_ALL: + write(p->fd, "\x1B\x30\x00\x00", 4); + write(p->fd, "\x1B\x30\x01\x00", 4); + write(p->fd, "\x1B\x30\x02\x00", 4); + write(p->fd, "\x1B\x30\x03\x00", 4); + write(p->fd, "\x1B\x30\x18\x00", 4); + break; + case MEDIASOURCE_HDD: + write(p->fd, "\x1B\x30\x00\x00", 4); + break; + case MEDIASOURCE_IEEE1394: + write(p->fd, "\x1B\x30\x01\x00", 4); + break; + case MEDIASOURCE_CD: + write(p->fd, "\x1B\x30\x02\x00", 4); + break; + case MEDIASOURCE_USB: + write(p->fd, "\x1B\x30\x03\x00", 4); + break; + case MEDIATYPE_ALL: + write(p->fd, "\x1B\x30\x04\x00", 4); + write(p->fd, "\x1B\x30\x05\x00", 4); + write(p->fd, "\x1B\x30\x06\x00", 4); + write(p->fd, "\x1B\x30\x07\x00", 4); + write(p->fd, "\x1B\x30\x19\x00", 4); + break; + case MEDIATYPE_MOVIE: + write(p->fd, "\x1B\x30\x04\x00", 4); + break; + case MEDIATYPE_TV: + write(p->fd, "\x1B\x30\x05\x00", 4); + break; + case MEDIATYPE_MUSIC: + write(p->fd, "\x1B\x30\x06\x00", 4); + break; + case MEDIATYPE_PHOTO: + write(p->fd, "\x1B\x30\x07\x00", 4); + break; + case WIFI_ALL: + write(p->fd, "\x1B\x30\x1C\x00", 4); // bounding box + write(p->fd, "\x1B\x30\x15\x00", 4); + write(p->fd, "\x1B\x30\x16\x00", 4); + write(p->fd, "\x1B\x30\x17\x00", 4); + break; + case WIFI_ANTENNA: + write(p->fd, "\x1B\x30\x15\x00", 4); + break; + default: + if ((global_icon_id >= VOLUME_LEVEL_MIN) && (global_icon_id <= VOLUME_LEVEL_MAX)) + { + int volumeLevel = global_icon_id - VOLUME_LEVEL_MIN; + p->volume = volumeLevel; + if (volumeLevel > 100) + { + volumeLevel = -1; + } + if (volumeLevel >= 12) + write(p->fd, "\x1B\x30\x0B\x01", 4); + else + write(p->fd, "\x1B\x30\x0B\x00", 4); + if (volumeLevel >= 25) + write(p->fd, "\x1B\x30\x0C\x01", 4); + else + write(p->fd, "\x1B\x30\x0C\x00", 4); + if (volumeLevel >= 37) + write(p->fd, "\x1B\x30\x0D\x01", 4); + else + write(p->fd, "\x1B\x30\x0D\x00", 4); + if (volumeLevel >= 50) + write(p->fd, "\x1B\x30\x0E\x01", 4); + else + write(p->fd, "\x1B\x30\x0E\x00", 4); + if (volumeLevel >= 62) + write(p->fd, "\x1B\x30\x0F\x01", 4); + else + write(p->fd, "\x1B\x30\x0F\x00", 4); + if (volumeLevel >= 75) + write(p->fd, "\x1B\x30\x10\x01", 4); + else + write(p->fd, "\x1B\x30\x10\x00", 4); + if (volumeLevel >= 87) + write(p->fd, "\x1B\x30\x11\x01", 4); + else + write(p->fd, "\x1B\x30\x11\x00", 4); + if (volumeLevel >= 100) + write(p->fd, "\x1B\x30\x12\x01", 4); + else + write(p->fd, "\x1B\x30\x12\x00", 4); + break; + } + return -1; + } + return 0; +} + + MODULE_EXPORT void MD8800_output (Driver *drvthis, int on) { Index: server/drivers/MD8800.h =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/drivers/MD8800.h,v retrieving revision 1.3 diff -u -r1.3 MD8800.h --- server/drivers/MD8800.h 2 Apr 2007 21:29:54 -0000 1.3 +++ server/drivers/MD8800.h 1 Jan 2009 16:29:35 -0000 @@ -1,6 +1,6 @@ /* This is the LCDproc driver for the VFD of the Medion MD8800 PC - Copyright (C) 2006 Stefan Herdler in collaboration with Martin M?. + Copyright (C) 2006 Stefan Herdler in collaboration with Martin M?ller. This source Code is based on the NoritakeVFD, the serialVFD and the CFontzPacket Driver of this package. @@ -46,6 +46,6 @@ MODULE_EXPORT void MD8800_set_brightness(Driver *drvthis, int state, int promille); MODULE_EXPORT int MD8800_get_brightness(Driver *drvthis, int state); MODULE_EXPORT int MD8800_icon (Driver *drvthis, int x, int y, int icon); - - +MODULE_EXPORT int MD8800_globalicon_set (Driver *drvthis, global_icon_ids global_icon_id); +MODULE_EXPORT int MD8800_globalicon_clear (Driver *drvthis, global_icon_ids global_icon_id); #endif Index: server/drivers/lcd.h =================================================================== RCS file: /cvsroot/lcdproc/lcdproc/server/drivers/lcd.h,v retrieving revision 1.25 diff -u -r1.25 lcd.h --- server/drivers/lcd.h 2 Apr 2007 21:29:54 -0000 1.25 +++ server/drivers/lcd.h 1 Jan 2009 16:29:35 -0000 @@ -79,6 +79,11 @@ * lot of things in that area might need to be changed. */ +#define ICONGROUP_LEN 16 +#define ICONGROUPMEMBER_LEN 16 +#define ICONGROUP_MEMBER_SEPARATOR '.' +#include "globalicons.h" + /* Heartbeat data */ #define HEARTBEAT_OFF 0 #define HEARTBEAT_ON 1 @@ -147,6 +152,8 @@ void (*num) (struct lcd_logical_driver *drvthis, int x, int num); void (*heartbeat) (struct lcd_logical_driver *drvthis, int state); int (*icon) (struct lcd_logical_driver *drvthis, int x, int y, int icon); + int (*globalicon_set) (struct lcd_logical_driver *drvthis, global_icon_ids global_icon_id); + int (*globalicon_clear) (struct lcd_logical_driver *drvthis, global_icon_ids global_icon_id); void (*cursor) (struct lcd_logical_driver *drvthis, int x, int y, int type); /* user-defined character functions, are those still supported ? */ -------------- next part -------------- A non-text attachment was scrubbed... Name: globalicons.h Type: text/x-chdr Size: 2101 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: globalicon_commands.c Type: text/x-csrc Size: 8813 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: globalicon_commands.h Type: text/x-chdr Size: 956 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From qxc at gmx.de Sun Jan 4 17:11:58 2009 From: qxc at gmx.de (qxc at gmx.de) Date: Sun, 04 Jan 2009 18:11:58 +0100 Subject: [Lcdproc] Custom characters / LCDd protocol description Message-ID: <20090104171158.163100@gmx.net> Hi, I'm using the hd77840 driver, an own client and want to set some custom characters (as far as I know that controller supports the possibility to replace characters by ones with an own design). Unfortunately I could not find a description of the LCDd protocol anywhere so I don't know how to submit the related information. So my questions are: is there a specification of the protocol available somewhere? Or what is the procedure of sending own character designs to lcdproc? Kind regards Michael Btw: there is a Java implementation of a lcdproc client available that continues the abadoned jLCD project. The online documentation is available at http://www.realsimulation3d.com/doc/com/vwp/jLCD/package-summary.html , a new version of the Java XTools that incorporate these classes will be available soon. -- Sensationsangebot verl?ngert: GMX FreeDSL - Telefonanschluss + DSL f?r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a From qxc at gmx.de Mon Jan 5 09:48:45 2009 From: qxc at gmx.de (qxc at gmx.de) Date: Mon, 05 Jan 2009 10:48:45 +0100 Subject: [Lcdproc] jLCD: Java Client API continued Message-ID: <20090105094845.207440@gmx.net> Just for your information: the well-known Java client library "jLCD" that was not further developed for some years and that is a nice possibility to access a lcdproc server out of an Java application is now re-animated: jLCD is now part of the new Java XTools Library version 1.7 that can be found at http://www.realsimulation3d.com/dev.php There is a JavaDoc online documentation available at http://www.realsimulation3d.com/doc/com/vwp/jLCD/package-summary.html The Java XTools library itself is open source and can be downloaded from http://www.realsimulation3d.com/download.php?anchor=dev&refid= , alternatively the latest sources can be retrieved from CVS as described here http://www.realsimulation3d.com/dev.php#xtoolssrc Comments, suggestions, ideas are of course welcome! -- Sensationsangebot verl?ngert: GMX FreeDSL - Telefonanschluss + DSL f?r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a From zicronsoft at yahoo.com Mon Jan 5 18:06:39 2009 From: zicronsoft at yahoo.com (Peter Schmidt) Date: Mon, 5 Jan 2009 10:06:39 -0800 (PST) Subject: [Lcdproc] Starter program Message-ID: <953903.53932.qm@web63707.mail.re1.yahoo.com> Now I understand how many people may find using the LCDd.conf is easy to use, but if you plan to port this program to Windows (and the fact that it does work on Mac) there should be some sort of setup. I'm NOT saying make the entire program a GUI, I'm saying I would like it if there was some sort of starter app that helps set you up. For example, this program would be able to search for all possible LCDs/VFDs in /dev/ and would test the bit rates and drivers. There aren't that many bit rates or drivers, so I would assume it could take maybe a full minute to test all of them (probably less if it finds the correct driver at the beginning of its process) and would be fairly minimal to code. Obviously the program only does this once. After this the program should ask the user about really basic configuration settings you would only make once such as refresh rate. Then at the end it should create 3 default screens/pages so the user gets an idea of what can be edited, and will make a comment specifying that the screens or pages can be edited. Before it quits, it will ask where the configuration file should be stored and then create a launcher code to be copied. This is just my idea of how the program would work. It would save people a lot of time and stress (stress for those who don't know exactly what they are doing or what they have). Keep in mind that although your program is well made, it isn't user friendly for beginners like myself and I do not see it practical for Windows and especially Mac use for the simple fact that there is nothing that prepares you. Thank you for your time, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.dicks at gmail.com Mon Jan 5 19:26:55 2009 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 5 Jan 2009 14:26:55 -0500 Subject: [Lcdproc] Starter program In-Reply-To: <953903.53932.qm@web63707.mail.re1.yahoo.com> References: <953903.53932.qm@web63707.mail.re1.yahoo.com> Message-ID: On Mon, Jan 5, 2009 at 1:06 PM, Peter Schmidt wrote: > Now I understand how many people may find using the LCDd.conf is easy to > use, but if you plan to port this program to Windows (and the fact that it > does work on Mac) there should be some sort of setup. I'm NOT saying make > the entire program a GUI, I'm saying I would like it if there was some sort > of starter app that helps set you up. > > For example, this program would be able to search for all possible LCDs/VFDs > in /dev/ and would test the bit rates and drivers. There aren't that many > bit rates or drivers, so I would assume it could take maybe a full minute to > test all of them (probably less if it finds the correct driver at the > beginning of its process) and would be fairly minimal to code. >From you saing "there aren't that many", perhaps you haven't dug into how many drivers and modules are supported by LCDd. For Matrix Orbital products alone, there are dozens of compatible LCD and VFD modules. In the case of USB-attached devices, it is at least easy to determine what "odd" vendor/product codes are on the bus and attack that angle with a list of known products. There's no "speed" to worry about, etc. It would probably not be _too_ bad to come up with a probe routine to determine what's on the bus, but at least in case of USB MtxOrb modules, it might not be possible to reliably determine geometry since they have been known to reuse ident codes in the past. For parallel-attached modules, there are several attachment techniques - 4-bit, 8-bit, with shift register, without... it's not insurmountable, but neither is it simple. Serial is the big unknown - baud rates, vendor codes, what state will modules be in after receiving much garbage data. I would think that testing wouldn't be reasonably complete without having a stack of serially attached modules on hand (I have 3-4 myself). Since there is often zero feedback from modules as to their specific geometry (some "backpack" interfaces can be told what they have, most USB modules know one way or another, but many parallel modules just don't have the first idea), I doubt it is possible to cover more than a small fraction of the devices that LCDproc supports without feedback from the human looking at the module. One could imagine a scenario where LCDd tries the easiest ones first and asks for confirmation that there is *some* legible message on the display, but after the trivial ones are exhausted, I foresee a cycle of "how about now?" *click* "how about now?" for literally dozens of choices. A tool to build a LCDd.conf and to leave a launch script lying around is a fine idea, but having worked with a dozen different types of modules myself, with most interface types represented, I am skeptical as to how to get a program to guess what you have hanging on your system beyond a small fraction of cases. Have you looked at other LCD projects to see how they have done things? I haven't in enough depth to give a reasonable answer. One "easy" way to do it is to list in some HCL list the ones that can be autodetected, then provide for an "advanced" screen if you don't happen to have one of the 20-or-so modules that are on the autodetect list. Right now, I couldn't even tell you how many specific modules and interfaces and geometries are supported, but it wouldn't surprise me to hear that it's well over 100. Just MtxOrb alone, one I know well, is several dozen, and there are subtle differences from product to product just for that one vendor alone. This is, essentially, as complex an issue as attaching a random printer to your system. Saying "for those who don't know exactly what they are doing or what they have" is incredibly complex when you are dealing with parallel vs serial vs network vs USB, and some combinations are much more complex than others. Look at how long it's taken to get printers *mostly* sorted out - and most of that is by focusing on USB vs other attachment methods. For anything that doesn't report details, the user *must* know vendor and model to direct the install process. LCDs and VFDs aren't magical compared to printers - they in fact have many of the same issues and problems (except being out of paper ;-) for much the same reason - there isn't one or two or three ways to do it - there are many, many combinations of interfaces, widths, feature sets, etc. Can things be improved? Almost certainly. Can you take a random newbie and a random module and a random OS and get a zero (or even, say, three) question install program? Almost certainly not. Redefining the scope of the effort will go a long way to increasing the chances of success. Now comes the hard part... who's going to write it? It's not me - I have been programming professionally for over 25 years. In all that time, paying all my bills by working in IT, I have not written a single Windows GUI program. Not one. I don't care how many Windows machines or users are out there; it's just not a direction I've had to go to further my career. LCDproc, like most open source projects, is volunteer driven. Saying "hey, wouldn't this be nice?" is usually followed up with "hey, here's my attempt at it". Perhaps there are members of this list with lots of relevant experience and, more importantly, lots of time, but I think that pool is much smaller for GUI anything than system-level command-line projects. -ethan From bsdfan at nurfuerspam.de Mon Jan 5 21:35:37 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 05 Jan 2009 22:35:37 +0100 Subject: [Lcdproc] Starter program In-Reply-To: <953903.53932.qm@web63707.mail.re1.yahoo.com> References: <953903.53932.qm@web63707.mail.re1.yahoo.com> Message-ID: <49627D29.6070002@nurfuerspam.de> Peter Schmidt wrote: > Now I understand how many people may find using the LCDd.conf is easy > to use, but if you plan to port this program to Windows (and the fact > that it does work on Mac) there should be some sort of setup. I'm NOT > saying make the entire program a GUI, I'm saying I would like it if > there was some sort of starter app that helps set you up. I don't know if we plan to support Windows in the near future again. I do know that it once did work on Windows, and there is still some Windows specific code in it. But I doubt that someone has tried to get it run on Win32 recently, did anybody? Additionally some advanced programs for Windows interfacing to different displays already exist and I think LCDproc's strength are Linux / Unix type OS. It will be a lot of work to come up to the level of Windows support those programs already offer. > > ... > This is just my idea of how the program would work. It would save > people a lot of time and stress (stress for those who don't know > exactly what they are doing or what they have). Keep in mind that > although your program is well made, it isn't user friendly for > beginners like myself and I do not see it practical for Windows and > especially Mac use for the simple fact that there is nothing that > prepares you. I think that we have to cope with two type of users: Those who select, buy and integrate a LCD module on their own (system builders, companies, geeks) and those who get a case with a device built-in and want to use it with something else than Windows. The former group does know which module they built in and given the difficulties Ethan described in his mail those will perhaps not need a setup program. But for the latter group such a setup might be helpful. > > > Thank you for your time, > Peter > From herdler at gmx.de Wed Jan 7 00:17:26 2009 From: herdler at gmx.de (Stefan Herdler) Date: Wed, 07 Jan 2009 01:17:26 +0100 Subject: [Lcdproc] [Fwd: Re: How to handle separate icon area on LCD/VFD glass] In-Reply-To: <1230551528.5196.44.camel@TangoLinux.lan> References: <1230551528.5196.44.camel@TangoLinux.lan> Message-ID: <4963F496.60209@gmx.de> Arthur van Dongen wrote: > [...] >> >>> * Queryable. A client can request whether an "Envelope" icon is >>> supported by the device, and decide to display a "New mail" text based >>> on the result of this request. >>> >> Here I concur in principle. >> But to make the interface generic you need to standardize on names >> and properties for these new icons/widgets. >> >> Only with a standardized set of these widgets and their properties clients >> can be written that support more than one specific display. >> >> I don't see a problem if the names of the icons are not 100% standardized. The standard icons like "play" are common on these displays. And defining different names for the same icon in different drivers doesn't make much sense to me. For the display specific icons you have to write a extra client anyway. Or make some icons configurable in the client, which isn't a big deal, I think. >>> * Separate control of the icons. One client can control the "Play" icon, >>> and another can control the "Envelope" icon. >>> * Combined control of icons. Switching from "FF" to "Play" icon should >>> be possible in a single command. There is no sense in controlling these >>> from different clients. >>> * Efficiency. The list of all icon names can only grow, and searching >>> for an icon in the list should not take too long. Grouping? >>> * Flexibility in defining combined icons. For example an icon set for >>> the video source can contain "TV" and "Film" on one device and "DVB-T", >>> "Sat", "MPEG", "DivX", "unknown-codec-of-the-future" icons on another. >>> >>> Design outline >>> ============== >>> Client-Server interface >>> ----------------------- >>> Example: >>> screen_add scrn0 >>> widget_add scrn0 iconWidget icon >>> widget_set scrn0 iconWidget 0 0 PLAYMODE.FF >>> widget_set scrn0 iconWidget 0 0 MAIL.OFF >>> widget_set scrn0 iconWidget 0 0 VIDSRC.TV >>> widget_set scrn0 iconWidget 0 0 VIDSRC.TV_Sat >>> >>> Server-Device API >>> ----------------- >>> _icon(Driver *drvthis, const char iconDef[]); >>> >> Please don't force the individual drivers to interpret text. >> This is up to the server core so that it can be done once (and correctly). >> > You've got a point here. But the alternative is using a set of > predefined constants, and that is much less expandable. For now I vote > for using strings. This can be reasonable efficient by doing a two-step > comparison of the group ("PLAYMODE") and member ("FF") parts. > What do you think about defining the names of the icons in a header file of the driver? So the driver gets a number (64 or more?) of commands for icons (or whatever) which can be named individual. Only the command types had to be standardized and the interpretation could be done in the server core. (I'm thinking about something like "boolean", "int", "icon"(on, off and blinking) , "bargraph" and the "play indicator".) > [...] >> I can understand your pain, but from a "harmonization" point of >> view, I consider the extended icons on the different displays >> too different to be able to get a common system. >> >> So, for the short term I suggest using the output command >> >> > to get the icons.I have considered that, of course. But there are a few cons to this > approach: > - the current output() commands provides 32 bits, and my displays have > 29 and 33 segments. Only 20 of them are common. Extending to 64 bits > would only give some room for now but we would hit this limit sooner or > later. > - The clients can call the output functions, but only if they have > knowledge about which bit means what. This is something only the driver > can know, and sometimes not even at compile time. Consider the case if > the GPIOs of a LCD display are connected to LEDs by an integrator, then > this is something that could be specified in the driver config section. > - I was looking for some mechanism that is future-proof and can be used > by any client and any driver that supports this in any way. > - The client programmer has to dive into the documentation of every display he wants to support. Having different icon names would be much easier to handle. Changing icon names in a configfile could even be done by any experienced a user. Regards Stefan >> Regards >> Peter >> >> > Thanks, > Arthur > > ------------------------------------------------------------------------ > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > From junk_inbox at verizon.net Wed Jan 7 17:19:52 2009 From: junk_inbox at verizon.net (Jeff Artz) Date: Wed, 07 Jan 2009 12:19:52 -0500 Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD Message-ID: Any suggestions, please? Thanks, Jeff ----- Original Message ----- From: Jeff Artz To: lcdproc Sent: Sunday, December 28, 2008 11:07 PM Subject: LCDd daemon hangs with USB Crystalfontz 634 LCD Ok, I've googled and found some references to this hang, and my new CF 634 display does the same, exactly as described in this thread from last year: http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS LCDproc v0.5.2 Here's what happens: [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start Starting up LCDd: ps ax of above hang scenerio: [root at mythbackend mythtv]# ps ax | grep LCDd 16361 pts/1 S+ 0:00 /bin/sh /sbin/service LCDd start 16368 pts/1 S+ 0:00 /bin/sh /etc/init.d/LCDd start 16373 pts/1 S+ 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf 16374 pts/1 S+ 0:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf 16375 ? Ss 0:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf 16381 pts/3 R+ 0:00 grep LCDd [root at mythbackend mythtv]# If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the prompt will come back and everything works fine. So, to help troubleshoot, I changed the ReportLevel to 5, and here's what I get to stdout: [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start Starting up LCDd: LCDd version 0.5.2 starting Built on Dec 22 2008, protocol version 0.3, API version 0.5 Using Configuration File: /home/mythtv/lcd/LCDd.conf Set report level to 5, output to stderr Server forking to background Listening for queries on 127.0.0.1:13666 screenlist_init() driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so") CFontz: using Device /dev/lcd CFontz: init() done Key "Escape" is now reserved in exclusive mode by client [-1] Key "Enter" is now reserved in shared mode by client [-1] Key "Up" is now reserved in shared mode by client [-1] Key "Down" is now reserved in shared mode by client [-1] screenlist_process() screenlist_switch(s=[_server_screen]) screenlist_switch: switched to screen [_server_screen] screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() (Which doesn't seem very helpful to me - perhaps it will to the developers) So for the moment I can't setup LCDd to start at boot time, or it will hang my system. I manually start it after booting. (Thankfully that's not very often, as it's my MythTV backend system) How can I help troubleshoot this further? (Suggestions of a debugger and/or the process, not quite step-by-step, but the more explict the better - ie please don't reply with simply "just debug the process"... I don't know how to do that [yet]!) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From umberto.bernardi at gmail.com Thu Jan 8 18:04:11 2009 From: umberto.bernardi at gmail.com (Umberto Bernardi) Date: Thu, 8 Jan 2009 19:04:11 +0100 Subject: [Lcdproc] Ks0108 serdisplib In-Reply-To: <99984a220812100316w418c628fx157f37bdf73cee27@mail.gmail.com> References: <99984a220812091509p45823a03n459a73b3e55e1e37@mail.gmail.com> <493F72A4.1090308@on-luebeck.de> <99984a220812100316w418c628fx157f37bdf73cee27@mail.gmail.com> Message-ID: <99984a220901081004od0b2d32g293bde708a251478@mail.gmail.com> 2008/12/10 Umberto Bernardi > > > 2008/12/10 Stefan Hu?feldt > >> Here i'm running a gLCD (t6963c, 240x128) via graphlcd under Ubuntu >> intrepid 64bit. I had to patch graphlcd-base-0.1.5.tgz? and >> glcdprocdriver-0.0.4.tar.bz2 to work with gcc 4.3. >> ?http://bugs.gentoo.org/show_bug.cgi?id=227125 >> >> -- >> Und Tsch?ss. >> Stefan >> >> ### Kilroy was here ### 2.6.20.2 up 82 days >> > Hello! It's working! but I have a problem: mine is a 128x64 display and lcd proc start to write in the middle of display like in this (ugly :-) ) ascii picture -------------------------------------------------------- -******************************************** - * -or using * thanks f - linux * lcdproc & - * - * -******************************************** --------------------------------------------------------- I've tryed with X offset an Y ossfet but only Y have an effect. Can someone help me? -- Umberto "crash_override" Bernardi Linux Registered User #353811 --------------------------------------------------- Impossibilia nemo tenetur.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From NSUTTON at bes.gloucs.sch.uk Fri Jan 9 10:37:10 2009 From: NSUTTON at bes.gloucs.sch.uk (N.Sutton) Date: Fri, 9 Jan 2009 10:37:10 +0000 Subject: [Lcdproc] FIC Spectra VFD Support [Scanned] Message-ID: Hi all, I am currently looking at moving my XBMC install from Windows to Linux and have been researching getting the VFD in my FIC Spectra case working. I found some conflicting info at the MythTV website saying the FIC Spectra uses a DM-140GINK (I managed to find an LCDProc driver for this one) but that isn't the VFD fitted.. The FIC Spectra uses a 7x1 Futaba TOSD-5711BB USB display and features icons for music,video,tv guide, record etc (handy for things like Myth, VDR etc..) I have the following info for the display - PID(0x7000) and VID(0x0547) Hex codes to drive the display; 00 8B 04 01 07 xx xx xx xx xx xx xx -> where xx are the ASCII codes of the seven characters to display - the display only supports Capital Letters 00 85 02 01 aa ss -> where aa is the code of the icon and ss is the state (00=off, 01=on) 00 85 02 02 a1 s1 a2 s2 -> a1 s1 = code and state of the first icon, a2 s2 = code and state of the second icon 00 85 02 nn a1 s1 a2 s2 .... an sn -> where nn is the number of icon values present in the buffer and then a couple of bytes for every icon to set with icon number in the first byte and state in the second one so here's the icon numbers list: 01 = VOLUME icon 02 to 0C = volume bars 0E = SHUFFLE icon 0F = MUTE 10 = PHONE 11 = REC 12 = RADIO 13 = DVD 14 = VCD 15 = CD 16 = MUSIC 17 = PHOTO 18 = TV 19 = cd/dvd disk icon 1A = 5.1 icon 1B = 7.1 icon 1E = REPEAT icon 1F = ALL icon 20 = REW 21 = PAUSE 22 = PLAY 23 = TIMER 24 and 25 = GUIDE (double led) 26 = HOME 28 = eject icon 29 = FWD 2A = KHz 2B = MHz so this will be the buffer to light the REC icon 00 85 02 01 11 01 and this to turn off rec icon 00 85 02 01 11 00 every sent buffer has to be filled with 00 after the command to reach 65 bytes. All the numbers are in HEX notation Image of the display here; http://forum.team-mediaportal.com/attachments/improvement-suggestions-121/10399d1189231915-support-futaba-display-fic-spectra-htpc-100_0769.jpg Info is courtesy of AndreaVB at the Mediaportal forums.. Is there any way this display could be supported under LCDProc ? I have checkedout the CVS and looked at the source for some of the drivers but can't make head or tail of it as I only know VB.net! Thanks! Neil ________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. If you have received this email in error please notify the sender and delete the message. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of Brockworth Enterprise School. Sent by Microsoft Exchange Server 2007 -------------- next part -------------- An HTML attachment was scrubbed... URL: From herdler at gmx.de Sat Jan 10 00:27:58 2009 From: herdler at gmx.de (Stefan Herdler) Date: Sat, 10 Jan 2009 01:27:58 +0100 Subject: [Lcdproc] Custom characters / LCDd protocol description In-Reply-To: <20090104171158.163100@gmx.net> References: <20090104171158.163100@gmx.net> Message-ID: <4967EB8E.8010702@gmx.de> Hi, qxc at gmx.de wrote: > Hi, > > I'm using the hd77840 driver, an own client and want to set some custom characters (as far as I know that controller supports the possibility to replace characters by ones with an own design). > > Unfortunately I could not find a description of the LCDd protocol anywhere so I don't know how to submit the related information. > > So my questions are: is there a specification of the protocol available somewhere? Or what is the procedure of sending own character designs to lcdproc? > It isn't possible to control the custom characters by a client, sorry. At the Moment only the server core can do that. Regards Stefan > Kind regards > > Michael > > Btw: there is a Java implementation of a lcdproc client available that continues the abadoned jLCD project. The online documentation is available at http://www.realsimulation3d.com/doc/com/vwp/jLCD/package-summary.html , a new version of the Java XTools that incorporate these classes will be available soon. > > > From christian.leuschen at gmx.de Sat Jan 10 14:28:02 2009 From: christian.leuschen at gmx.de (Christian Leuschen) Date: Sat, 10 Jan 2009 15:28:02 +0100 Subject: [Lcdproc] How to handle separate icon area on LCD/VFD glass: iMon-LCD Message-ID: <4968B072.2080809@gmx.de> Hello everybody, I wrote some code of the driver for the iMon-LCD (http://www.soundgraph.com/Eng_/Products/oem3.aspx?topMenu=2&subMenu=1&leftMenu=43), based upon the work of Dean Harding (http://codeka.com/blogs/index.php/c29/c30/?blog=5). Especially the part of the "output"-command was a pain. 32 bit are not enough to manage all icons independently. So I had to build groups and assign values to them. This way, e.g. in the lower row of formats (MPG, DIVX, ..., WMA, WAV), there can be only one icon of a group of four switched on. However, a DVB channel may provide AC3 and MPG sound simultaneously. At the moment it is not possible to show this information to the user. As I also adjusted an output plugin (vdr-lcdproc) to use these special icons, I know both worlds - the driver and the lcdproc-client view. I fully support and appreciate the request for handling the special icons in LCDd by corresponding function-calls. As can be seen in the images of the display, there are plenty of icons and 2 (actually 4) progressbars which can be used. At the moment I do not have any time to think about the details of a solution, but with this mail and the screenshots in the links I intend to call everybody's attention to yet another display and to get an impression of the versatility of the display - in the future there may be even more complex displays. Greets, Christian From umberto.bernardi at gmail.com Sun Jan 11 00:45:38 2009 From: umberto.bernardi at gmail.com (Umberto Bernardi) Date: Sun, 11 Jan 2009 01:45:38 +0100 Subject: [Lcdproc] X-Y center problem Message-ID: <99984a220901101645rfe01413qcf7741c4dbf31350@mail.gmail.com> Hello, I have a problem on my samsung ks0108 : mine is a 128x64 display and lcd proc start to write in the middle of display like in this (ugly :-) ) ascii picture --------------------------------------------------------- -********************************************- - * - -or using * thanks f - - linux * lcdproc &- - * - - * - -********************************************- --------------------------------------------------------- I've tried with X offset an Y osffet but only Y have an effect. Can someone help me? -- Umberto "crash_override" Bernardi Linux Registered User #353811 --------------------------------------------------- Impossibilia nemo tenetur.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From hitman at gmail.com Sun Jan 11 08:28:26 2009 From: hitman at gmail.com (Hiten Mistry) Date: Sun, 11 Jan 2009 08:28:26 +0000 Subject: [Lcdproc] FIC Spectra VFD Support [Scanned] In-Reply-To: References: Message-ID: <254fe180901110028o13518d4buccc893fe10cc746b@mail.gmail.com> Just want to add another token of interest to this as I have a Media PC case that uses this display also, and it also happens to run XBMC on Linux (Kubuntu). 2009/1/9 N.Sutton : > Hi all, > > I am currently looking at moving my XBMC install from Windows to Linux and > have been researching getting the VFD in my FIC Spectra case working. > > I found some conflicting info at the MythTV website saying the FIC Spectra > uses a DM-140GINK (I managed to find an LCDProc driver for this one) but > that isn't the VFD fitted.. > > The FIC Spectra uses a 7x1 Futaba TOSD-5711BB USB display and features icons > for music,video,tv guide, record etc (handy for things like Myth, VDR etc..) > > I have the following info for the display - PID(0x7000) and VID(0x0547) > > Hex codes to drive the display; > > > > 00 8B 04 01 07 xx xx xx xx xx xx xx -> where xx are the ASCII codes of the > seven characters to display ? the display only supports Capital Letters > > 00 85 02 01 aa ss -> where aa is the code of the icon and ss is the state > (00=off, 01=on) > > 00 85 02 02 a1 s1 a2 s2 -> a1 s1 = code and state of the first icon, a2 s2 = > code and state of the second icon > > 00 85 02 nn a1 s1 a2 s2 .... an sn -> where nn is the number of icon values > present in the buffer and then a couple of bytes for every icon to set with > icon number in the first byte and state in the second one > > so here's the icon numbers list: > 01 = VOLUME icon > 02 to 0C = volume bars > 0E = SHUFFLE icon > 0F = MUTE > 10 = PHONE > 11 = REC > 12 = RADIO > 13 = DVD > 14 = VCD > 15 = CD > 16 = MUSIC > 17 = PHOTO > 18 = TV > 19 = cd/dvd disk icon > 1A = 5.1 icon > 1B = 7.1 icon > 1E = REPEAT icon > 1F = ALL icon > 20 = REW > 21 = PAUSE > 22 = PLAY > 23 = TIMER > 24 and 25 = GUIDE (double led) > 26 = HOME > 28 = eject icon > 29 = FWD > 2A = KHz > 2B = MHz > > so this will be the buffer to light the REC icon > 00 85 02 01 11 01 > and this to turn off rec icon > 00 85 02 01 11 00 > > every sent buffer has to be filled with 00 after the command to reach 65 > bytes. > All the numbers are in HEX notation > > Image of the display here; > http://forum.team-mediaportal.com/attachments/improvement-suggestions-121/10399d1189231915-support-futaba-display-fic-spectra-htpc-100_0769.jpg > > Info is courtesy of AndreaVB at the Mediaportal forums.. > > > > Is there any way this display could be supported under LCDProc ? > > I have checkedout the CVS and looked at the source for some of the drivers > but can't make head or tail of it as I only know VB.net! > > > > Thanks! > > Neil > > ________________________________ > This email and any files transmitted with it are confidential and intended > solely for the use of the individual to whom they are addressed. If you have > received this email in error please notify the sender and delete the > message. > Any views or opinions expressed in this email are solely those of the author > and do not necessarily represent those of Brockworth Enterprise School. > > Sent by Microsoft Exchange Server 2007 > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > From erik.haggstrom at gmail.com Sun Jan 11 09:33:50 2009 From: erik.haggstrom at gmail.com (=?ISO-8859-1?Q?Erik_H=E4ggstr=F6m?=) Date: Sun, 11 Jan 2009 09:33:50 +0000 Subject: [Lcdproc] New driver for LCDproc (Acer Idea 500/501 built in VFD display) Message-ID: <261dc0680901110133x41d1dd1dr5c48e46b509778cd@mail.gmail.com> Hello All, I have written a kernel module and a driver module for LCDproc to control the Acer VFD display. What is the procedure for getting this into LCDproc and does the kernel module go in a different package? The kernel module works standalone with 'echo > "Something" /dev/lcd0' Regards, Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From aeriksson2 at fastmail.fm Sun Jan 11 14:24:55 2009 From: aeriksson2 at fastmail.fm (aeriksson2 at fastmail.fm) Date: Sun, 11 Jan 2009 15:24:55 +0100 Subject: [Lcdproc] improved imon hbars Message-ID: <20090111142455.2A49E940566@tippex.mynet.homeunix.org> I've created this patch to the imon driver. Effectively, it uses the vbar characters to paint the non-full cell. Apart from a different look, it actually gets more info onto the display. Any interest in integrating it? --- lcdproc-0.5.2/server/drivers/imon.c 2007-04-14 16:38:14.000000000 +0200 +++ lcdproc-0.5.2_new/server/drivers/imon.c 2009-01-11 15:11:48.000000000 +0100 @@ -393,18 +393,13 @@ if (x + pos > p->width) return; - if (pixels >= p->cellwidth * 3/4) { + if (pixels >= p->cellwidth ) { /* write a "full" block to the screen... */ imon_chr(drvthis, x+pos, y, IMON_CHAR_BLOCK_FILLED); } - else if (pixels >= p->cellwidth * 2/4) { - /* write a partial block... */ - imon_chr(drvthis, x+pos, y, IMON_CHAR_PLAY); - break; - } - else if (pixels >= p->cellwidth * 1/4) { - /* write a partial block... */ - imon_chr(drvthis, x+pos, y, '>'); + else if (pixels >= 1) { + /* write a partial block, albeit vertically... */ + imon_chr(drvthis, x+pos, y, pixels * p->cellheight / p->cellwidth); break; } else { From junk_inbox at verizon.net Mon Jan 12 16:42:08 2009 From: junk_inbox at verizon.net (Jeff Artz) Date: Mon, 12 Jan 2009 11:42:08 -0500 Subject: [Lcdproc] X-Y center problem References: <99984a220901101645rfe01413qcf7741c4dbf31350@mail.gmail.com> Message-ID: <145780C4B6FC43ABB90AAA9C8917F6DC@jartzhome> Hi Umberto, That LCDs has two controller chips on-board. It sounds like the "chip select" lines for the graphics chips are connected backwards, thus the symptoms you are seeing. Based on what I found at: http://serdisplib.sourceforge.net/ser/ks0108.html - your display is probably attached via parallel port. You just need to switch the CS1 and CS2 lines (Pins 16 and 17 per that pinout) to fix your issue. According to their "Customisable Wiring" page, you can also pass a string to the driver to specify the non-standard pinout as well. (There is a link on the above referenced page that details that configuration.) Now if I can just get a reply to my post... ;-) Jeff ----- Original Message ----- From: Umberto Bernardi To: lcdproc at lists.omnipotent.net Sent: Saturday, January 10, 2009 7:45 PM Subject: [Lcdproc] X-Y center problem Hello, I have a problem on my samsung ks0108 : mine is a 128x64 display and lcd proc start to write in the middle of display like in this (ugly :-) ) ascii picture --------------------------------------------------------- -********************************************- - * - -or using * thanks f - - linux * lcdproc &- - * - - * - -********************************************- --------------------------------------------------------- I've tried with X offset an Y osffet but only Y have an effect. Can someone help me? -- Umberto "crash_override" Bernardi Linux Registered User #353811 --------------------------------------------------- Impossibilia nemo tenetur.... ------------------------------------------------------------------------------ _______________________________________________ LCDproc mailing list LCDproc at lists.omnipotent.net http://lists.omnipotent.net/mailman/listinfo/lcdproc -------------- next part -------------- An HTML attachment was scrubbed... URL: From umberto.bernardi at gmail.com Mon Jan 12 22:39:20 2009 From: umberto.bernardi at gmail.com (Umberto Bernardi) Date: Mon, 12 Jan 2009 23:39:20 +0100 Subject: [Lcdproc] X-Y center problem In-Reply-To: <145780C4B6FC43ABB90AAA9C8917F6DC@jartzhome> References: <99984a220901101645rfe01413qcf7741c4dbf31350@mail.gmail.com> <145780C4B6FC43ABB90AAA9C8917F6DC@jartzhome> Message-ID: <99984a220901121439o55911ba0w446b459607019c39@mail.gmail.com> 2009/1/12 Jeff Artz > Hi Umberto, > > That LCDs has two controller chips on-board. It sounds like the "chip > select" lines for the graphics chips are connected backwards, thus the > symptoms you are seeing. > > Based on what I found at: > http://serdisplib.sourceforge.net/ser/ks0108.html - your display is > probably attached via parallel port. You just need to switch the CS1 and > CS2 lines (Pins 16 and 17 per that pinout) to fix your issue. > > According to their "Customisable Wiring" page, you can also pass a string > to the driver to specify the non-standard pinout as well. (There is a > link on the above referenced page that details that configuration.) > > Now if I can just get a reply to my post... ;-) > > Jeff > Great Jeff!!! last night I dreamed something about CS1 / CS2... you've confirmed my idea... I've just switched two pins and now my display works perfectly. Thanks a lot; good night -- Umberto "crash_override" Bernardi Linux Registered User #353811 --------------------------------------------------- Impossibilia nemo tenetur.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.dicks at gmail.com Tue Jan 13 03:36:22 2009 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 12 Jan 2009 22:36:22 -0500 Subject: [Lcdproc] What's the state of the picolcd driver? Message-ID: Hi, All, I've been catching up on development stuff and have the 20x4 "sideshow" picoLCD working with the "driver" tarball from on my SUSE laptop. I checked the latest LCDproc nightly tarball and _that_ picoLCD driver (i.e., the one from the CVS tree) is the older picolcd.c that only supports the "mini-box" 20x2 display. I have fixed the 19-vs-20-char issue in picolcd.c from picolcd.com as I described a few weeks ago on the list. I'd love to submit a patch, but I don't know what to submit against. Has someone already submitted the "new" picoLCD driver that supports both displays? Are we just waiting for the submission queue to catch up? I'm happy to continue to test and submit patches, but I think the base driver needs to catch up first. In the meantime, I'll probably submit another debugging/diagnostic client or two, the ones I've written to help me find bugs in my own work - one for bargraphs, one for bignums. Thanks, -ethan From npavel at ituner.com Tue Jan 13 08:30:49 2009 From: npavel at ituner.com (Nicu Pavel) Date: Tue, 13 Jan 2009 10:30:49 +0200 Subject: [Lcdproc] What's the state of the picolcd driver? In-Reply-To: References: Message-ID: <496C5139.80004@ituner.com> Hi Ethan, I think the new picoLCD driver is in CVS, the "nightly" tarball is a little outdated. I will have to do some modifications on current picoLCD drivers from Peter suggestions, and I will also add another display that should come up (a graphical 256x64 LCD) Nicu > Hi, All, > > I've been catching up on development stuff and have the 20x4 > "sideshow" picoLCD working with the "driver" tarball from > on my SUSE laptop. I checked the > latest LCDproc nightly tarball and _that_ picoLCD driver (i.e., the > one from the CVS tree) is the older picolcd.c that only supports the > "mini-box" 20x2 display. > > I have fixed the 19-vs-20-char issue in picolcd.c from picolcd.com as > I described a few weeks ago on the list. I'd love to submit a patch, > but I don't know what to submit against. Has someone already > submitted the "new" picoLCD driver that supports both displays? Are > we just waiting for the submission queue to catch up? I'm happy to > continue to test and submit patches, but I think the base driver needs > to catch up first. > > In the meantime, I'll probably submit another debugging/diagnostic > client or two, the ones I've written to help me find bugs in my own > work - one for bargraphs, one for bignums. > > Thanks, > > -ethan > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From NSUTTON at bes.gloucs.sch.uk Tue Jan 13 08:44:06 2009 From: NSUTTON at bes.gloucs.sch.uk (N.Sutton) Date: Tue, 13 Jan 2009 08:44:06 +0000 Subject: [Lcdproc] FIC Spectra VFD Support [Scanned] [Spam score:8%] In-Reply-To: <254fe180901110028o13518d4buccc893fe10cc746b@mail.gmail.com> References: <254fe180901110028o13518d4buccc893fe10cc746b@mail.gmail.com> Message-ID: Good to know I'm not the only one after support for this display ;) Hopefully we can find someone with the skills to put together a basic driver to support it! -----Original Message----- From: Hiten Mistry [mailto:hitman at gmail.com] Sent: 11 January 2009 08:28 To: N.Sutton Cc: lcdproc at lists.omnipotent.net Subject: Re: [Lcdproc] FIC Spectra VFD Support [Scanned] [Spam score:8%] Just want to add another token of interest to this as I have a Media PC case that uses this display also, and it also happens to run XBMC on Linux (Kubuntu). 2009/1/9 N.Sutton : > Hi all, > > I am currently looking at moving my XBMC install from Windows to Linux and > have been researching getting the VFD in my FIC Spectra case working. > > I found some conflicting info at the MythTV website saying the FIC Spectra > uses a DM-140GINK (I managed to find an LCDProc driver for this one) but > that isn't the VFD fitted.. > > The FIC Spectra uses a 7x1 Futaba TOSD-5711BB USB display and features icons > for music,video,tv guide, record etc (handy for things like Myth, VDR etc..) > > I have the following info for the display - PID(0x7000) and VID(0x0547) > > Hex codes to drive the display; > > > > 00 8B 04 01 07 xx xx xx xx xx xx xx -> where xx are the ASCII codes of the > seven characters to display - the display only supports Capital Letters > > 00 85 02 01 aa ss -> where aa is the code of the icon and ss is the state > (00=off, 01=on) > > 00 85 02 02 a1 s1 a2 s2 -> a1 s1 = code and state of the first icon, a2 s2 = > code and state of the second icon > > 00 85 02 nn a1 s1 a2 s2 .... an sn -> where nn is the number of icon values > present in the buffer and then a couple of bytes for every icon to set with > icon number in the first byte and state in the second one > > so here's the icon numbers list: > 01 = VOLUME icon > 02 to 0C = volume bars > 0E = SHUFFLE icon > 0F = MUTE > 10 = PHONE > 11 = REC > 12 = RADIO > 13 = DVD > 14 = VCD > 15 = CD > 16 = MUSIC > 17 = PHOTO > 18 = TV > 19 = cd/dvd disk icon > 1A = 5.1 icon > 1B = 7.1 icon > 1E = REPEAT icon > 1F = ALL icon > 20 = REW > 21 = PAUSE > 22 = PLAY > 23 = TIMER > 24 and 25 = GUIDE (double led) > 26 = HOME > 28 = eject icon > 29 = FWD > 2A = KHz > 2B = MHz > > so this will be the buffer to light the REC icon > 00 85 02 01 11 01 > and this to turn off rec icon > 00 85 02 01 11 00 > > every sent buffer has to be filled with 00 after the command to reach 65 > bytes. > All the numbers are in HEX notation > > Image of the display here; > http://forum.team-mediaportal.com/attachments/improvement-suggestions-121/10399d1189231915-support-futaba-display-fic-spectra-htpc-100_0769.jpg > > Info is courtesy of AndreaVB at the Mediaportal forums.. > > > > Is there any way this display could be supported under LCDProc ? > > I have checkedout the CVS and looked at the source for some of the drivers > but can't make head or tail of it as I only know VB.net! > > > > Thanks! > > Neil > > ________________________________ > This email and any files transmitted with it are confidential and intended > solely for the use of the individual to whom they are addressed. If you have > received this email in error please notify the sender and delete the > message. > Any views or opinions expressed in this email are solely those of the author > and do not necessarily represent those of Brockworth Enterprise School. > > Sent by Microsoft Exchange Server 2007 > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > This email and any files transmitted with it are confidential and intended solely for the use of the individual to whom they are addressed. If you have received this email in error please notify the sender and delete the message. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of Brockworth Enterprise School. Sent by Microsoft Exchange Server 2007 From qxc at gmx.de Tue Jan 13 09:50:42 2009 From: qxc at gmx.de (qxc at gmx.de) Date: Tue, 13 Jan 2009 10:50:42 +0100 Subject: [Lcdproc] Define what is displayed after LCDd start In-Reply-To: <99984a220901121439o55911ba0w446b459607019c39@mail.gmail.com> References: <99984a220901101645rfe01413qcf7741c4dbf31350@mail.gmail.com> <145780C4B6FC43ABB90AAA9C8917F6DC@jartzhome> <99984a220901121439o55911ba0w446b459607019c39@mail.gmail.com> Message-ID: <20090113095042.310500@gmx.net> Hi, on my system there is a relatively long time between the moment when LCDd was started and the time, when the first client connects to display something useful. During that time the informative but for an end-user useles and ugly client/screen/heartbeat default information are displayed. So my question is: is there a possibility to define a default text that is displayed directly after LCDd is started to display something more fancy like "Booting system..."? Thx! -- Sensationsangebot verl?ngert: GMX FreeDSL - Telefonanschluss + DSL f?r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a From support at ocg.ca Tue Jan 13 14:18:20 2009 From: support at ocg.ca (OCG Technical Support) Date: Tue, 13 Jan 2009 09:18:20 -0500 Subject: [Lcdproc] Support for Matrix Orbital GLK19264 Message-ID: <007901c97589$c9870c10$5c952430$@ca> I'm looking at the new MO GLK19264 and wondering if anyone has it working properly with LCDproc? Is anyone doing anything cool with the graphics - or just using the ascii text output? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From nombrandue at tsukinokage.net Tue Jan 13 15:01:32 2009 From: nombrandue at tsukinokage.net (Seann Clark) Date: Tue, 13 Jan 2009 09:01:32 -0600 Subject: [Lcdproc] Support for Matrix Orbital GLK19264 In-Reply-To: <007901c97589$c9870c10$5c952430$@ca> References: <007901c97589$c9870c10$5c952430$@ca> Message-ID: <496CACCC.2070107@tsukinokage.net> OCG Technical Support wrote: > > I?m looking at the new MO GLK19264 and wondering if anyone has it > working properly with LCDproc? > > Is anyone doing anything cool with the graphics ? or just using the > ascii text output? > > Thanks > > ------------------------------------------------------------------------ > > As far as I know right now, the glk timing nodes have changed on the newer MO LCD's. I have a GLK19264-7T-1U-GW-E, and the driver doesn't work on this LCD. I haven't had time to work on a new driver, since coding in C isn't my forte, and I haven't had much luck shaking the tree here for help on this, and I can't find the blasted information from the guy at MO that happened to respond to me when I first got this LCD about 7 months ago. Under Doze, you can do a lot of Graphics and fun stuff, though I don't know under *nix* since I haven't played with raw commands and custom scripts to the board in a while. In theory yes, there is a lot of fun stuff to do, but I know of no LCDProc graphics items off the top of my head, but scripting them is cake if LCDproc can talk to the driver. Otherwise homespun's until the driver is fixed for this LCD series from MO is the best bet. I have made some changed where LCDproc can discover the display but it requires adding line to the source and recompiling it, which isn't hard, I just would have to dig through the driver. Regards, Seann -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5614 bytes Desc: S/MIME Cryptographic Signature URL: From rmolenkamp at matrixorbital.ca Tue Jan 13 15:15:03 2009 From: rmolenkamp at matrixorbital.ca (Ray Molenkamp) Date: Tue, 13 Jan 2009 08:15:03 -0700 Subject: [Lcdproc] Support for Matrix Orbital GLK19264 In-Reply-To: <496CACCC.2070107@tsukinokage.net> References: <007901c97589$c9870c10$5c952430$@ca> <496CACCC.2070107@tsukinokage.net> Message-ID: <496CAFF7.5030903@matrixorbital.ca> You could have looked me up in the list archives :) --Ray Seann Clark wrote: > and I can't find the blasted information from the guy at MO that > happened to respond to me when I first got this LCD about 7 months ago. From nombrandue at tsukinokage.net Tue Jan 13 15:34:05 2009 From: nombrandue at tsukinokage.net (Seann Clark) Date: Tue, 13 Jan 2009 09:34:05 -0600 Subject: [Lcdproc] Support for Matrix Orbital GLK19264 In-Reply-To: <496CAFF7.5030903@matrixorbital.ca> References: <007901c97589$c9870c10$5c952430$@ca> <496CACCC.2070107@tsukinokage.net> <496CAFF7.5030903@matrixorbital.ca> Message-ID: <496CB46D.50905@tsukinokage.net> Ray Molenkamp wrote: > You could have looked me up in the list archives :) > > --Ray > > Seann Clark wrote: > >> and I can't find the blasted information from the guy at MO that >> happened to respond to me when I first got this LCD about 7 months ago. >> > _______________________________________________ > Yeah, I tried, but some of the communications about this ended up being off list, and I have yet to locate just where they dropped off (I think the Windows system that now is home for my other MO LCD) but I have yet to find out the best way/place to start to re-write the driver, since I haven't much exp with C. Fun to learn though. I just don't know where to starter looking, otherwise, since I have the LCD, and have some free time to code and test I think it could work after a bit. ~Seann -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5614 bytes Desc: S/MIME Cryptographic Signature URL: From support at ocg.ca Tue Jan 13 15:48:27 2009 From: support at ocg.ca (OCG Technical Support) Date: Tue, 13 Jan 2009 10:48:27 -0500 Subject: [Lcdproc] Support for Matrix Orbital GLK19264 In-Reply-To: <496CAFF7.5030903@matrixorbital.ca> References: <007901c97589$c9870c10$5c952430$@ca> <496CACCC.2070107@tsukinokage.net> <496CAFF7.5030903@matrixorbital.ca> Message-ID: <00a801c97596$603ec380$20bc4a80$@ca> Hi Ray - can you provide an update for LCDproc support of this device? I found the source code change to enable discovery of the device...but I want to make sure LCDproc works with the unit before buying.. Thanks -----Original Message----- From: lcdproc-bounces at lists.omnipotent.net [mailto:lcdproc-bounces at lists.omnipotent.net] On Behalf Of Ray Molenkamp Sent: January 13, 2009 10:15 AM To: Seann Clark Cc: LCDPROC Users List Subject: Re: [Lcdproc] Support for Matrix Orbital GLK19264 You could have looked me up in the list archives :) --Ray Seann Clark wrote: > and I can't find the blasted information from the guy at MO that > happened to respond to me when I first got this LCD about 7 months ago. _______________________________________________ LCDproc mailing list LCDproc at lists.omnipotent.net http://lists.omnipotent.net/mailman/listinfo/lcdproc From qxc at gmx.de Wed Jan 14 07:13:47 2009 From: qxc at gmx.de (qxc at gmx.de) Date: Wed, 14 Jan 2009 08:13:47 +0100 Subject: [Lcdproc] HD44780: problems with 8 bit characters In-Reply-To: References: <254fe180901110028o13518d4buccc893fe10cc746b@mail.gmail.com> Message-ID: <20090114071347.225750@gmx.net> Hi, I'm using a HD44780 display with the driver in "winamp" mode. That works well for all ASCII-characters smaller or equal than 0x7F. But when I try to display a character that is located in range 0x80..0xFF or when I try to display an icon something goes completely wrong: Instead of the correct character two different ones are displayed, mainly starting with a "A". So all special characters the HD44780 supports and all custom icons can't be displayed. What could be the reason for this? Kind regards Michael -- Sensationsangebot verl?ngert: GMX FreeDSL - Telefonanschluss + DSL f?r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a From stefanh at on-luebeck.de Wed Jan 14 08:32:37 2009 From: stefanh at on-luebeck.de (=?ISO-8859-1?Q?Stefan_Hu=DFfeldt?=) Date: Wed, 14 Jan 2009 09:32:37 +0100 Subject: [Lcdproc] HD44780: problems with 8 bit characters In-Reply-To: <20090114071347.225750@gmx.net> References: <254fe180901110028o13518d4buccc893fe10cc746b@mail.gmail.com> <20090114071347.225750@gmx.net> Message-ID: <496DA325.1000409@on-luebeck.de> qxc at gmx.de schrieb: > Instead of the correct character two different ones are displayed, mainly starting with a "A". So all special characters the HD44780 supports and all custom icons can't be displayed. > What could be the reason for this? Try to start your client in an none UTF-8 environment. From ernie.cline at gmail.com Wed Jan 14 23:18:55 2009 From: ernie.cline at gmail.com (Ernie Cline) Date: Wed, 14 Jan 2009 15:18:55 -0800 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD Message-ID: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> Hello all,I recently purchased one of these little guys for eventual use on my alix/pfsense based firewall: http://www.mini-box.com/PicoLCD-4X20-Sideshow I cannot seem to get it to work! I have tried the mini-box provided version of LCDProc, version .5.2 and the latest CVS version, all seem to give the same output: Server running in foreground Listening for queries on 127.0.0.1:13666 screenlist_init() driver_load(name="picolcd", filename="/usr/local/lib/lcdproc/picolcd.so") picolcd: looking for device picoLCD20x2 picolcd: looking for device picoLCD20x4 picolcd: no device found Driver [picolcd] init failed, return code -1 Module /usr/local/lib/lcdproc/picolcd.so could not be loaded Could not load driver picolcd There is no output driver Critical error while initializing, abort. if I run a truss against that, the relevant errors seem to be along the lines of: ioctl(4,USB_DEVICEINFO,0xbfbfe960) ERR#6 'Device not configured' I have read a few other errors some involving libusblcd, some saying this is seen as an HID device when it shouldn't be, but nothing seems to work for me. I'm trying this on FreeBSD 7.1 in emulation (vmware fusion) and FreeBSD 7.0 directly on hardware, although both report the device just fine in usbdevs: addr 1: UHCI root hub, Intel addr 2: USB-LCD-4x20, ITUNER INC Any help or a point in the right direction would be helpful! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.dicks at gmail.com Thu Jan 15 00:48:54 2009 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Wed, 14 Jan 2009 19:48:54 -0500 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> Message-ID: On Wed, Jan 14, 2009 at 6:18 PM, Ernie Cline wrote: > Hello all, > I recently purchased one of these little guys for eventual use on my > alix/pfsense based firewall: http://www.mini-box.com/PicoLCD-4X20-Sideshow > I cannot seem to get it to work! I have tried the mini-box provided version > of LCDProc, version .5.2 and the latest CVS version, all seem to give the > same output: > Server running in foreground . . . > picolcd: looking for device picoLCD20x2 > picolcd: looking for device picoLCD20x4 > picolcd: no device found > Driver [picolcd] init failed, return code -1 > Module /usr/local/lib/lcdproc/picolcd.so could not be loaded . . . > ioctl(4,USB_DEVICEINFO,0xbfbfe960) ERR#6 'Device not configured' . . . > I'm trying this on FreeBSD 7.1 in emulation (vmware fusion) and FreeBSD 7.0 > directly on hardware, although both report the device just fine in usbdevs: > addr 1: UHCI root hub, Intel > addr 2: USB-LCD-4x20, ITUNER INC > Any help or a point in the right direction would be helpful! Hi Ernie, I have both a "Minibox" 20x2 and a "Sideshow" 20x4 display and have gotten them both working with Linux, but I have no experience with libusb and FreeBSD. Checking my logs for the Sideshow the last time I plugged it into a Linux (SUSE) machine, I see... usb 1-1: new full speed USB device using uhci_hcd and address 3 usb 1-1: configuration #1 chosen from 1 choice input: ITUNER INC USB-LCD-4x20 as /devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1:1.0/input/input7 input,hiddev96,hidraw0: USB HID v1.01 Device [ITUNER INC USB-LCD-4x20] on usb-0000:00:1d.0-1 usb 1-1: New USB device found, idVendor=04d8, idProduct=c001 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: USB-LCD-4x20 usb 1-1: Manufacturer: ITUNER INC usb 1-1: SerialNumber: Ver.01.11 I am using the complete tarball from picolcd.com of 0.5.2 that includes the newer picolcd.c and it worked right out of the box on my system (details below)... Having fiddled with the older version of the picoLCD code and my minibox display w/RedHat WS4, I can say that the code for requesting the system give back HID devices is probably somewhat Linux-specific. I did try to get things working on my OS 10.4 MacBook Pro, but I ran into some issues with what version of libusb I had on the system and calls from picolcd.c not matching up, and I never did resolve it. So my experience is with two distros of Linux, I had no problem with libusb on Linux and getting both types of picoLCD working, but I had no success after a bit of fiddling under BSD (OS X). I _did_ have my usb4lcd working a year ago on that MacBook, so I know that my usblib install isn't there entirely defective. If you are a coder, look into the chain of calls that picolcd.c and see how it stages its requests to free up a system HID-driver-encumbered display. I wouldn't be shocked to learn that there are Linux/BSD differences. -ethan From bsdfan at nurfuerspam.de Thu Jan 15 07:12:25 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 15 Jan 2009 08:12:25 +0100 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> Message-ID: <496EE1D9.7090309@nurfuerspam.de> Ernie Cline wrote: > Hello all, > I recently purchased one of these little guys for eventual use on my > alix/pfsense based firewall: http://www.mini-box.com/PicoLCD-4X20-Sideshow > > I cannot seem to get it to work! I have tried the mini-box provided > version of LCDProc, version .5.2 and the latest CVS version, all seem > to give the same output: > > Hello, I am sorry, but the picolcd driver is currently not supported under FreeBSD. So without any additional programming there is no way to get it to work with FreeBSD. In the FreeBSD's port it is therefore disabled and not built by default. On your system the driver loads and tries to identify the device. What packages have you installed to get the dependicies satisfied? Please send me the "config.log" output from a configure run. Additionally, please post the output of: usbdevs -v -d Regards Markus From bsdfan at nurfuerspam.de Thu Jan 15 07:58:58 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 15 Jan 2009 08:58:58 +0100 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: <496EE1D9.7090309@nurfuerspam.de> References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> <496EE1D9.7090309@nurfuerspam.de> Message-ID: <496EECC2.6010707@nurfuerspam.de> A short follow-up to myself: The "device not configured" messages in truss you see arise from libusb scanning the busses for usb devices. You will see a lot of them. If you save the truss output to a file and send it to me, it might be helpful. Markus Dolze wrote: > Ernie Cline wrote: >> Hello all, >> I recently purchased one of these little guys for eventual use on my >> alix/pfsense based firewall: >> http://www.mini-box.com/PicoLCD-4X20-Sideshow >> >> I cannot seem to get it to work! I have tried the mini-box provided >> version of LCDProc, version .5.2 and the latest CVS version, all seem >> to give the same output: >> >> > > Hello, > > I am sorry, but the picolcd driver is currently not supported under > FreeBSD. So without any additional programming there is no way to get > it to work with FreeBSD. In the FreeBSD's port it is therefore > disabled and not built by default. > > On your system the driver loads and tries to identify the device. What > packages have you installed to get the dependencies satisfied? You can ignore the above. The dependency problem was valid for 0.5.2 (the version the port is based on). The cvs version does not need additional packages beside libusb. It will be build by default in the next version of lcdproc as well (I just checked this). > > Please send me the "config.log" output from a configure run. > > Additionally, please post the output of: usbdevs -v -d > > Regards > Markus > From andy at siliconlandmark.com Thu Jan 15 15:46:28 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Thu, 15 Jan 2009 10:46:28 -0500 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: <496EE1D9.7090309@nurfuerspam.de> References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> <496EE1D9.7090309@nurfuerspam.de> Message-ID: On Jan 15, 2009, at 2:12 AM, Markus Dolze wrote: > Ernie Cline wrote: >> Hello all, >> I recently purchased one of these little guys for eventual use on >> my alix/pfsense based firewall: http://www.mini-box.com/PicoLCD-4X20-Sideshow >> >> I cannot seem to get it to work! I have tried the mini-box >> provided version of LCDProc, version .5.2 and the latest CVS >> version, all seem to give the same output: >> > I am sorry, but the picolcd driver is currently not supported under > FreeBSD. So without any additional programming there is no way to > get it to work with FreeBSD. In the FreeBSD's port it is therefore > disabled and not built by default. > > On your system the driver loads and tries to identify the device. > What packages have you installed to get the dependicies satisfied? Unfortunately the PicoLCD 2X20 and 4X20 devices present themselves as HID devices. I filed PR usb/128803 and attached a patch which quirks the device, so that it doesn't get attached to by the HID driver (Thus making it available to libusb). It can be found at http://www.freebsd.org/cgi/query-pr.cgi?pr=128803 . It would be awesome if this would get committed on CURRENT and possibly MFC'ed... :) Cheers, Andy PS: I have the magic to get the 4X20 working on OSX too, if anyone is interested. /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From ernie.cline at gmail.com Thu Jan 15 17:10:24 2009 From: ernie.cline at gmail.com (Ernie Cline) Date: Thu, 15 Jan 2009 09:10:24 -0800 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> <496EE1D9.7090309@nurfuerspam.de> Message-ID: <1b9f9a570901150910q3261755dh284463351c60928d@mail.gmail.com> I'm going to give Andre's suggestions a shot and recompile and see how it goes. I'll report back to the list my findings. On Thu, Jan 15, 2009 at 7:46 AM, Andre Guibert de Bruet < andy at siliconlandmark.com> wrote: > On Jan 15, 2009, at 2:12 AM, Markus Dolze wrote: > > Ernie Cline wrote: >> >>> Hello all, >>> I recently purchased one of these little guys for eventual use on my >>> alix/pfsense based firewall: >>> http://www.mini-box.com/PicoLCD-4X20-Sideshow >>> >>> I cannot seem to get it to work! I have tried the mini-box provided >>> version of LCDProc, version .5.2 and the latest CVS version, all seem to >>> give the same output: >>> >>> I am sorry, but the picolcd driver is currently not supported under >> FreeBSD. So without any additional programming there is no way to get it to >> work with FreeBSD. In the FreeBSD's port it is therefore disabled and not >> built by default. >> >> On your system the driver loads and tries to identify the device. What >> packages have you installed to get the dependicies satisfied? >> > > Unfortunately the PicoLCD 2X20 and 4X20 devices present themselves as HID > devices. I filed PR usb/128803 and attached a patch which quirks the device, > so that it doesn't get attached to by the HID driver (Thus making it > available to libusb). It can be found at > http://www.freebsd.org/cgi/query-pr.cgi?pr=128803 . It would be awesome if > this would get committed on CURRENT and possibly MFC'ed... :) > > Cheers, > Andy > > PS: I have the magic to get the 4X20 working on OSX too, if anyone is > interested. > > /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ > /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ > /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ > /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.dicks at gmail.com Thu Jan 15 17:23:46 2009 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Thu, 15 Jan 2009 12:23:46 -0500 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> <496EE1D9.7090309@nurfuerspam.de> Message-ID: On Thu, Jan 15, 2009 at 10:46 AM, Andre Guibert de Bruet wrote: > PS: I have the magic to get the 4X20 working on OSX too, if anyone is > interested. I would love the magic - I am splitting my time between OSX laptop and a SUSE laptop, but I only have my 20x4 working on the SUSE laptop. I'm big on not reinventing the wheel. Thanks! -ethan From andy at siliconlandmark.com Thu Jan 15 19:59:50 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Thu, 15 Jan 2009 14:59:50 -0500 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> <496EE1D9.7090309@nurfuerspam.de> Message-ID: On Jan 15, 2009, at 12:23 PM, Ethan Dicks wrote: > On Thu, Jan 15, 2009 at 10:46 AM, Andre Guibert de Bruet > wrote: >> PS: I have the magic to get the 4X20 working on OSX too, if anyone is >> interested. > > I would love the magic - I am splitting my time between OSX laptop and > a SUSE laptop, but I only have my 20x4 working on the SUSE laptop. > I'm big on not reinventing the wheel. I have the instructions as well as the kext required up at: http://bling.properkernel.com/picolcd/ > Thanks! You are most welcome! I am glad someone can benefit from my work... :) Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From ethan.dicks at gmail.com Thu Jan 15 20:28:10 2009 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Thu, 15 Jan 2009 15:28:10 -0500 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> <496EE1D9.7090309@nurfuerspam.de> Message-ID: On Thu, Jan 15, 2009 at 2:59 PM, Andre Guibert de Bruet wrote: > On Jan 15, 2009, at 12:23 PM, Ethan Dicks wrote: >> I would love the magic... > > I have the instructions as well as the kext required up at: > http://bling.properkernel.com/picolcd/ Nice. Thanks! (I'll test it on my 10.4 laptop when I have an opportunity to reboot) -ethan From andy at siliconlandmark.com Thu Jan 15 20:48:10 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Thu, 15 Jan 2009 15:48:10 -0500 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> <496EE1D9.7090309@nurfuerspam.de> Message-ID: <61EC496E-D0D4-4FF5-8616-B165F5ABA6AB@siliconlandmark.com> On Jan 15, 2009, at 3:28 PM, Ethan Dicks wrote: > On Thu, Jan 15, 2009 at 2:59 PM, Andre Guibert de Bruet > wrote: >> On Jan 15, 2009, at 12:23 PM, Ethan Dicks wrote: >>> I would love the magic... >> >> I have the instructions as well as the kext required up at: >> http://bling.properkernel.com/picolcd/ > > Nice. Thanks! > > (I'll test it on my 10.4 laptop when I have an opportunity to reboot) > > -ethan The kext was developed on 10.5. It uses IOKit in a rather generic way and should be compatible with 10.4. Please let me know how it goes so that I can update my documentation. Thanks, Andy /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From bsdfan at nurfuerspam.de Thu Jan 15 21:20:19 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 15 Jan 2009 22:20:19 +0100 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> <496EE1D9.7090309@nurfuerspam.de> Message-ID: <496FA893.6000002@nurfuerspam.de> Andre Guibert de Bruet wrote: ... > > Unfortunately the PicoLCD 2X20 and 4X20 devices present themselves as > HID devices. I filed PR usb/128803 and attached a patch which quirks the > device, so that it doesn't get attached to by the HID driver (Thus > making it available to libusb). It can be found at > http://www.freebsd.org/cgi/query-pr.cgi?pr=128803 . It would be awesome > if this would get committed on CURRENT and possibly MFC'ed... :) > > Cheers, > Andy > We discovered this problem nearly 1.5 years ago, but didn't submit the HID patch then. I am glad that you did it now. At that time I rewrote the libusb detection and fixed the non-portable code. I was thinking that the detection routine would report a device was found and then fails to actually open the device. But from Ernie's report it does not seem to like that. Regards Markus From bsdfan at nurfuerspam.de Thu Jan 15 21:31:37 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 15 Jan 2009 22:31:37 +0100 Subject: [Lcdproc] New driver for LCDproc (Acer Idea 500/501 built in VFD display) In-Reply-To: <261dc0680901110133x41d1dd1dr5c48e46b509778cd@mail.gmail.com> References: <261dc0680901110133x41d1dd1dr5c48e46b509778cd@mail.gmail.com> Message-ID: <496FAB39.3090907@nurfuerspam.de> Erik H?ggstr?m wrote: > Hello All, > > I have written a kernel module and a driver module for LCDproc to > control the Acer VFD display. > What is the procedure for getting this into LCDproc and does the > kernel module go in a different package? > > The kernel module works standalone with 'echo > "Something" /dev/lcd0' > > Regards, > > Erik Hello Erik, you found the right place. Please send a diff against the current CVS version to this mailing list. It will have to be discussed what to do with the kernel driver. But please submit it as well. Regards Markus From andy at siliconlandmark.com Thu Jan 15 21:46:34 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Thu, 15 Jan 2009 16:46:34 -0500 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: <496FA893.6000002@nurfuerspam.de> References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> <496EE1D9.7090309@nurfuerspam.de> <496FA893.6000002@nurfuerspam.de> Message-ID: On Jan 15, 2009, at 4:20 PM, Markus Dolze wrote: > Andre Guibert de Bruet wrote: > ... >> Unfortunately the PicoLCD 2X20 and 4X20 devices present themselves >> as HID devices. I filed PR usb/128803 and attached a patch which >> quirks the device, so that it doesn't get attached to by the HID >> driver (Thus making it available to libusb). It can be found at http://www.freebsd.org/cgi/query-pr.cgi?pr=128803 >> . It would be awesome if this would get committed on CURRENT and >> possibly MFC'ed... :) >> Cheers, >> Andy > > We discovered this problem nearly 1.5 years ago, but didn't submit > the HID patch then. I am glad that you did it now. FreeBSD is in the process of merging in a much improved USB stack from perforce to CURRENT svn. It's been roughly a month since I submitted the patch, and it appears that it got lost in the noise... At least it's in a PR and the link is available on both the LCDproc and CURRENT mailing lists. > At that time I rewrote the libusb detection and fixed the non- > portable code. I was thinking that the detection routine would > report a device was found and then fails to actually open the > device. But from Ernie's report it does not seem to like that. The FreeBSD HID patch seems to have resolved Ernie's issue (This was resolved off-list). Cheers, Andy /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From ernie.cline at gmail.com Thu Jan 15 21:48:16 2009 From: ernie.cline at gmail.com (Ernie Cline) Date: Thu, 15 Jan 2009 13:48:16 -0800 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: <496FA893.6000002@nurfuerspam.de> References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com> <496EE1D9.7090309@nurfuerspam.de> <496FA893.6000002@nurfuerspam.de> Message-ID: <1b9f9a570901151348u410f3aadh2bc6081306187eab@mail.gmail.com> I would like to report that with Andre's FreeBSD kernel patch, this now works fine! Instead of attaching to the HID driver, it now shows up as a generic device, and with the most recent LCDproc code it works fine and I can finally start LCDd without an error. Thanks to everyone involved and I hope this makes it into FreeBSD soon. On Thu, Jan 15, 2009 at 1:20 PM, Markus Dolze wrote: > Andre Guibert de Bruet wrote: > ... > >> >> Unfortunately the PicoLCD 2X20 and 4X20 devices present themselves as HID >> devices. I filed PR usb/128803 and attached a patch which quirks the device, >> so that it doesn't get attached to by the HID driver (Thus making it >> available to libusb). It can be found at >> http://www.freebsd.org/cgi/query-pr.cgi?pr=128803 . It would be awesome >> if this would get committed on CURRENT and possibly MFC'ed... :) >> >> Cheers, >> Andy >> >> > We discovered this problem nearly 1.5 years ago, but didn't submit the HID > patch then. I am glad that you did it now. > > At that time I rewrote the libusb detection and fixed the non-portable > code. I was thinking that the detection routine would report a device was > found and then fails to actually open the device. But from Ernie's report it > does not seem to like that. > > Regards > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at siliconlandmark.com Fri Jan 16 20:32:30 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Fri, 16 Jan 2009 15:32:30 -0500 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: <17C934E643C24C478EAA0C15A2D898EB@DFW5RB41> References: <1b9f9a570901141518q1ba70c73ibc58a4f32811e254@mail.gmail.com><496EE1D9.7090309@nurfuerspam.de> <17C934E643C24C478EAA0C15A2D898EB@DFW5RB41> Message-ID: On Jan 16, 2009, at 5:09 AM, Gary R. Van Sickle wrote: >> From: Andre Guibert de Bruet >> >> Unfortunately the PicoLCD 2X20 and 4X20 devices present >> themselves as HID devices. > > ...but... they *are* HID devices. Why is this "unfortunate"? The PicoLCD 4X20 devices offer a bunch of different bits of functionality: - A 4x20 character display. - 8 physical buttons. - An IR receiver. It is "unfortunate" because the FreeBSD HID implementation (Along with OSX, Linux and Windows') has no clue what to do why any of these. It is way more useful for a program to be able to attach to the device and interact with it in a user-configurable way. You may want to have the display print out the output of a program (Such as lcdproc or lcdexec), have the buttons map to commonly-used scripts and have the IR controller hooked up to lirc, for example. >> I filed PR usb/128803 and attached >> a patch which quirks the device, so that it doesn't get >> attached to by the HID driver (Thus making it available to >> libusb). It can be found at >> http://www.freebsd.org/cgi/query-pr.cgi?pr=128803 >> . It would be awesome if this would get committed on >> CURRENT and possibly MFC'ed... :) > > Perhaps I'm missing something, but how would that be awesome? > Wouldn't it > be significantly more awesome if these HID devices were communicated > with in > the same manner as any other HID device? Or is FreeBSD's HID > support really > that broken? It has nothing to do with FreeBSD being broken. As stated above, this quirk allows third-party programs to connect to the device and interact with it. Note that this device's smaller brother, the PicoLCD 2X20 is already being quirked in the USB stack. Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From andy at siliconlandmark.com Fri Jan 16 20:39:00 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Fri, 16 Jan 2009 15:39:00 -0500 Subject: [Lcdproc] Define what is displayed after LCDd start In-Reply-To: <20090113095042.310500@gmx.net> References: <99984a220901101645rfe01413qcf7741c4dbf31350@mail.gmail.com> <145780C4B6FC43ABB90AAA9C8917F6DC@jartzhome> <99984a220901121439o55911ba0w446b459607019c39@mail.gmail.com> <20090113095042.310500@gmx.net> Message-ID: <20FE3D9A-1A8F-40F6-AFD8-C52779391299@siliconlandmark.com> On Jan 13, 2009, at 4:50 AM, qxc at gmx.de wrote: > Hi, > > on my system there is a relatively long time between the moment when > LCDd was started and the time, when the first client connects to > display something useful. During that time the informative but for > an end-user useles and ugly client/screen/heartbeat default > information are displayed. > > So my question is: is there a possibility to define a default text > that is displayed directly after LCDd is started to display > something more fancy like "Booting system..."? You are looking for the "Hello" configuration parameter in the "server" section of LCDd.conf. You may also be interested in the "GoodBye" parameter, for when your last client disconnects. Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From qxc at gmx.de Sun Jan 18 11:31:19 2009 From: qxc at gmx.de (qxc at gmx.de) Date: Sun, 18 Jan 2009 12:31:19 +0100 Subject: [Lcdproc] Define what is displayed after LCDd start In-Reply-To: <20FE3D9A-1A8F-40F6-AFD8-C52779391299@siliconlandmark.com> References: <99984a220901101645rfe01413qcf7741c4dbf31350@mail.gmail.com> <145780C4B6FC43ABB90AAA9C8917F6DC@jartzhome> <99984a220901121439o55911ba0w446b459607019c39@mail.gmail.com> <20090113095042.310500@gmx.net> <20FE3D9A-1A8F-40F6-AFD8-C52779391299@siliconlandmark.com> Message-ID: <20090118113119.34430@gmx.net> > > on my system there is a relatively long time between the moment when > > LCDd was started and the time, when the first client connects to > > display something useful. During that time the informative but for > > an end-user useles and ugly client/screen/heartbeat default > > information are displayed. > > > > So my question is: is there a possibility to define a default text > > that is displayed directly after LCDd is started to display > > something more fancy like "Booting system..."? > > > You are looking for the "Hello" configuration parameter in the > "server" section of LCDd.conf. You may also be interested in the > "GoodBye" parameter, for when your last client disconnects. My config file does not contain such a section and does not uses it when I add it. Is there a minimum version of lcdproc to support that? I'm using version 0.5.2 here. Kind regards Michael -- Sensationsangebot verl?ngert: GMX FreeDSL - Telefonanschluss + DSL f?r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a From andy at siliconlandmark.com Mon Jan 19 17:06:27 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Mon, 19 Jan 2009 12:06:27 -0500 Subject: [Lcdproc] Define what is displayed after LCDd start In-Reply-To: <20090118113119.34430@gmx.net> References: <99984a220901101645rfe01413qcf7741c4dbf31350@mail.gmail.com> <145780C4B6FC43ABB90AAA9C8917F6DC@jartzhome> <99984a220901121439o55911ba0w446b459607019c39@mail.gmail.com> <20090113095042.310500@gmx.net> <20FE3D9A-1A8F-40F6-AFD8-C52779391299@siliconlandmark.com> <20090118113119.34430@gmx.net> Message-ID: <625C87B0-4B09-4BED-8EDE-1B73219EA47F@siliconlandmark.com> On Jan 18, 2009, at 6:31 AM, qxc at gmx.de wrote: >>> So my question is: is there a possibility to define a default text >>> that is displayed directly after LCDd is started to display >>> something more fancy like "Booting system..."? >> >> You are looking for the "Hello" configuration parameter in the >> "server" section of LCDd.conf. You may also be interested in the >> "GoodBye" parameter, for when your last client disconnects. > > My config file does not contain such a section and does not uses it > when I add it. Is there a minimum version of lcdproc to support > that? I'm using version 0.5.2 here. I am not sure when the feature was added. You may want to give CVS HEAD a spin. Cheers, /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From andrea at dottout.com Mon Jan 19 17:38:20 2009 From: andrea at dottout.com (Andrea Rizzolo) Date: Mon, 19 Jan 2009 18:38:20 +0100 Subject: [Lcdproc] set brightness onthefly Message-ID: <4974BA8C.6020409@dottout.com> hi, is there any way to change brightness onthefly? Id like to play with brightness level eg during night (I dont want to shutdown my mediacenter, but I need to sleep ;) ) From andy at siliconlandmark.com Mon Jan 19 19:19:26 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Mon, 19 Jan 2009 14:19:26 -0500 Subject: [Lcdproc] LCDProc CVS + PicoLCD on FreeBSD In-Reply-To: <550B7A950EEE45359972D2A54F44EA5C@DFW5RB41> References: Your message of "Fri, 16 Jan 2009 15:32:30 EST." <23243.1232140762@critter.freebsd.dk> <550B7A950EEE45359972D2A54F44EA5C@DFW5RB41> Message-ID: <0CDC7501-0C01-4458-9FF9-DA523BE4DC70@siliconlandmark.com> On Jan 16, 2009, at 8:17 PM, Gary R. Van Sickle wrote: >> From: Poul-Henning Kamp >> >> In message >> , >> Andre Guibert de Bruet writes: >>> On Jan 16, 2009, at 5:09 AM, Gary R. Van Sickle wrote: >>>>> Unfortunately the PicoLCD 2X20 and 4X20 devices present themselves >>>>> as HID devices. >>>> >>>> ...but... they *are* HID devices. Why is this "unfortunate"? >> >> It's unfortunate, because they are HID devices only because >> that is what microchip.com supplies as a USB programming example. >> >> The actual protocol they talk has nothing to do with the HID >> specification. > > Ah. That's not "unfortunate", that's just sheer laziness on > iTuner's part. > Great, and I just bought one too. Welp, here's hoping whatever > nonstandard > protocol they do use works reasonably, and that the mfg gets their act > together on the next one. The iTuner parts are firmware upgradable, so there is hope. The Picolcd.com SDK has code that does the flashing on Windows so it would be a matter of porting it, if firmware that addresses the issue becomes available. I have purchased a couple of these and they've worked with LCDproc CVS HEAD with the quirk. I just upgraded my testbed to CURRENT and will be producing the appropriate patch for the USB2 stack, later tonight. Cheers, Andy /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From erik.haggstrom at gmail.com Mon Jan 19 19:26:47 2009 From: erik.haggstrom at gmail.com (=?ISO-8859-1?Q?Erik_H=E4ggstr=F6m?=) Date: Mon, 19 Jan 2009 19:26:47 +0000 Subject: [Lcdproc] New driver for LCDproc (Acer Idea 500/501 built in VFD display) In-Reply-To: <496FAB39.3090907@nurfuerspam.de> References: <261dc0680901110133x41d1dd1dr5c48e46b509778cd@mail.gmail.com> <496FAB39.3090907@nurfuerspam.de> Message-ID: <261dc0680901191126l1bad8cc1o28315bd407a8da00@mail.gmail.com> Right, here it is. The kernel driver is not included yet, needs some tidying. On Thu, Jan 15, 2009 at 9:31 PM, Markus Dolze wrote: > Erik H?ggstr?m wrote: > >> Hello All, >> >> I have written a kernel module and a driver module for LCDproc to control >> the Acer VFD display. >> What is the procedure for getting this into LCDproc and does the kernel >> module go in a different package? >> >> The kernel module works standalone with 'echo > "Something" /dev/lcd0' >> >> Regards, >> >> Erik >> > Hello Erik, > > you found the right place. Please send a diff against the current CVS > version to this mailing list. > > It will have to be discussed what to do with the kernel driver. But please > submit it as well. > > Regards > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: acer_idea_vfd_diff.zip Type: application/zip Size: 4574 bytes Desc: not available URL: From kripton at kripserver.net Mon Jan 19 22:02:40 2009 From: kripton at kripserver.net (Jannis Achstetter) Date: Mon, 19 Jan 2009 23:02:40 +0100 Subject: [Lcdproc] set brightness onthefly In-Reply-To: <4974BA8C.6020409@dottout.com> References: <4974BA8C.6020409@dottout.com> Message-ID: <4974F880.6040200@kripserver.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrea Rizzolo schrieb: > hi, is there any way to change brightness onthefly? Id like to play with > brightness level eg during night (I dont want to shutdown my > mediacenter, but I need to sleep ;) ) I think that depends on the LCD-driver used. With my CrystalFontz CF-635 (USB), I can change the brightness via lcdproc's menu and the screen keys so I think it can be changed by software. Wether this is implemented or not I don't know. Jannis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl0+IAACgkQeYlewm37lbh2FwCeMHdZSonRaaevFNTKgKw++Sez 2AUAn0zkKC9XYeasGH092E8vzo9pSR/N =w5JX -----END PGP SIGNATURE----- From andrea at dottout.com Mon Jan 19 22:13:08 2009 From: andrea at dottout.com (Andrea Rizzolo) Date: Mon, 19 Jan 2009 23:13:08 +0100 Subject: [Lcdproc] set brightness onthefly In-Reply-To: <4974F880.6040200@kripserver.net> References: <4974BA8C.6020409@dottout.com> <4974F880.6040200@kripserver.net> Message-ID: <4974FAF4.4090005@dottout.com> On 19/01/2009 23:02, Jannis Achstetter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrea Rizzolo schrieb: > >> hi, is there any way to change brightness onthefly? Id like to play with >> brightness level eg during night (I dont want to shutdown my >> mediacenter, but I need to sleep ;) ) >> > > I think that depends on the LCD-driver used. With my CrystalFontz CF-635 > (USB), I can change the brightness via lcdproc's menu and the screen > keys so I think it can be changed by software. Wether this is > implemented or not I don't know. > > Jannis > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkl0+IAACgkQeYlewm37lbh2FwCeMHdZSonRaaevFNTKgKw++Sez > 2AUAn0zkKC9XYeasGH092E8vzo9pSR/N > =w5JX > -----END PGP SIGNATURE----- > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > > Im using cfontz driver with a 634 display, it hasnt any key. I suppose my mail sounds like a feature request! tnx for the quick reply From bsdfan at nurfuerspam.de Tue Jan 20 07:05:38 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Tue, 20 Jan 2009 08:05:38 +0100 Subject: [Lcdproc] set brightness onthefly In-Reply-To: <4974BA8C.6020409@dottout.com> References: <4974BA8C.6020409@dottout.com> Message-ID: <497577C2.10202@nurfuerspam.de> Andrea Rizzolo wrote: > hi, is there any way to change brightness onthefly? Id like to play > with brightness level eg during night (I dont want to shutdown my > mediacenter, but I need to sleep ;) ) > Hello, you can change the brightness on-the-fly, but there are some restrictions: First of all you need a display with controlable backlight. This is true for most lcdproc drivers. Then you need some way to interact with the lcdproc server to change the backlight setting. Currently there are two ways to do this: 1. Using keys: If your display has keys attached and configured you can access the server's menu. There you can switch the backlight on / off and change the on/off brightness if the drivers supports this. 2. Using a client: A software client can change the backlight setting by sending a command. However, clients can only turn the backlight on or off (or make it flashing) but cannot control on/off brightness. Furthermore the setting is only valid for that particular client, I think. You wrote in another mail that you have a Crystalfontz display without keys. In this case the second method is way to go. Regards Markus From andrea at dottout.com Tue Jan 20 13:14:12 2009 From: andrea at dottout.com (Andrea Rizzolo) Date: Tue, 20 Jan 2009 14:14:12 +0100 Subject: [Lcdproc] set brightness onthefly In-Reply-To: <497577C2.10202@nurfuerspam.de> References: <4974BA8C.6020409@dottout.com> <497577C2.10202@nurfuerspam.de> Message-ID: <4975CE24.1060508@dottout.com> On 20/01/2009 08:05, Markus Dolze wrote: > Andrea Rizzolo wrote: >> hi, is there any way to change brightness onthefly? Id like to play >> with brightness level eg during night (I dont want to shutdown my >> mediacenter, but I need to sleep ;) ) >> > Hello, > > you can change the brightness on-the-fly, but there are some > restrictions: > > First of all you need a display with controlable backlight. This is > true for most lcdproc drivers. > > Then you need some way to interact with the lcdproc server to change > the backlight setting. Currently there are two ways to do this: > > 1. Using keys: If your display has keys attached and configured you > can access the server's menu. There you can switch the backlight on / > off and change the on/off brightness if the drivers supports this. > > 2. Using a client: A software client can change the backlight setting > by sending a command. However, clients can only turn the backlight on > or off (or make it flashing) but cannot control on/off brightness. > Furthermore the setting is only valid for that particular client, I > think. > > You wrote in another mail that you have a Crystalfontz display without > keys. In this case the second method is way to go. > > Regards > Markus > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > right, the second way is what Im looking for. the capability to set backlight on/off is my main purpose. telnet 127.0.0.1 13666, and screen_set -backlight off works, but I need to kill lcd-stuff and other clients to make it permanent. so Im going to crontab some bash script ;) From sascha.zielinski at gmx.de Thu Jan 22 17:23:01 2009 From: sascha.zielinski at gmx.de (Sascha) Date: Thu, 22 Jan 2009 18:23:01 +0100 Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring Message-ID: <200901221823.01323.> Hi, I bought a 40x4 LCD with LED Backlight, I connected the Display as shown below: Printer LCD 1 9 EN1 2 8 DB0 3 7 DB2 4 6 DB3 5 5 DB4 6 4 DB5 7 3 DB6 8 2 DB7 9 1 DB8 14 10 R/W 16 11 RS 12 Contrast 13 GND 14 +5V 17 15 EN2 18-25 GND Additionally there are the pins 17+18 on the LCD, which are not in the Datasheet. These pins are for the LED Backlight I think. The Documentation describes to connect the Backlight pin through the BC327 Transistor to Pin 17 of the Printer Port. Should I then connect the EN2 to GND? I use Debian Unstable/Experimental. The Version 0.5.2 compiles fine and runs now for about a day without a problem. I tried also the the version from cvs server (checked out on 01.22.09 at 5.00 pm CET). If I start LCDd with my LCDd.conf from stable version, the Lines 3+4 stays blank. Hope you will understand my problem. Sascha Zielinski From ethan.dicks at gmail.com Thu Jan 22 17:48:25 2009 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Thu, 22 Jan 2009 12:48:25 -0500 Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring In-Reply-To: <9185341920196262063@unknownmsgid> References: <9185341920196262063@unknownmsgid> Message-ID: On Thu, Jan 22, 2009 at 12:23 PM, Sascha wrote: > Hi, > > I bought a 40x4 LCD with LED Backlight... Nice. I have a couple of those. > I connected the Display as shown below... > Printer LCD > 1 9 EN1 . . . > 17 15 EN2 OK.... 8-bit wiring w/dual enable. Standard AFAIK. > Additionally there are the pins 17+18 on the LCD, which are not in the > Datasheet. These pins are for the LED Backlight I think. Probably. Mine have extra pins for backlight - one is away from the interface connector, one is extra pins on the interface connector. > The Documentation describes to connect the Backlight pin through the BC327 > Transistor to Pin 17 of the Printer Port. Yes. That is the "standard" way to hook up a backlight. > Should I then connect the EN2 to GND? If you do that, then you will only be able to use half of your display. The "problem" is that there aren't enough pins for an 8-bit interface, plus 2xHD44780 (EN1 + EN2), *plus* backlight. AFAIK, all 40x4 displays are implemented as two HD44780s with all pins tied together except enables. This is because there isn't enough onboard RAM (or column/row drivers, too?) to handle 160 on-screen chars with a regular HD44780, and I don't think anyone extended the chip that way - it's easy enough to add a second controller chip to the back of the LCD, and there's plenty of room. > I use Debian Unstable/Experimental. The Version 0.5.2 compiles fine and runs > now for about a day without a problem. I tried also the the version from cvs > server (checked out on 01.22.09 at 5.00 pm CET). If I start LCDd with my > LCDd.conf from stable version, the Lines 3+4 stays blank. Interesting... if your displays is two 40x2s together, it sounds like you aren't getting the second enable lit up when it needs to be. The stable 0.5.2 is quite old now. It's entirely possible that features have been added that are affecting your experience. I've been using nightly tarballs for years now, since I do driver development, and have had no problems with either of my 40x4s on a usb4lcd interface (which uses the HD44780 driver, the same as what you should be using). I have not tried using my 40x4s with the stable version of the code, nor do I have a handy cable to trying them out on the parallel port, sorry. If you read C, you could try browsing the hd44780*.c code and see if there were any changes made since 0.5.2-stable that might come into play. I'm wondering how long tying two displays into one virtual screen has been around, or if perhaps the default line for EN2 may have changed in the past couple of years. I don't know that lots of the people on this list have 40x4 displays, but perhaps someone with a parallel-attached LCD can comment. I mostly work from laptops now, and few laptops provide parallel ports anymore. Even serial ports are getting scarce. :-( I'm doing more and more work with USB-attached displays even though I miss the directness of driving ones own I/O ports without an intervening software layer to debug. -ethan From bsdfan at nurfuerspam.de Thu Jan 22 19:24:31 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 22 Jan 2009 20:24:31 +0100 Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring In-Reply-To: References: <9185341920196262063@unknownmsgid> Message-ID: <4978C7EF.8090902@nurfuerspam.de> Ethan Dicks wrote: > On Thu, Jan 22, 2009 at 12:23 PM, Sascha wrote: > >> Hi, >> >> I bought a 40x4 LCD with LED Backlight... >> >> The Documentation describes to connect the Backlight pin through the BC327 >> Transistor to Pin 17 of the Printer Port. >> > > Yes. That is the "standard" way to hook up a backlight. > > >> Should I then connect the EN2 to GND? >> > > If you do that, then you will only be able to use half of your display. > > The "problem" is that there aren't enough pins for an 8-bit interface, > plus 2xHD44780 (EN1 + EN2), *plus* backlight. AFAIK, all 40x4 > displays are implemented as two HD44780s with all pins tied together > except enables. This is because there isn't enough onboard RAM (or > column/row drivers, too?) to handle 160 on-screen chars with a regular > HD44780, and I don't think anyone extended the chip that way - it's > easy enough to add a second controller chip to the back of the LCD, > and there's plenty of room. > It is not only RAM. The display controller has to address each pixel by a row and column line. There would be just too many lines for a single chip. Additionally there are limitation regarding the current flowing through the chip. On displays like 40x4 you will not only find two controllers but also some extension driver chips which are conntected through an internal interface to the controller. >> I use Debian Unstable/Experimental. The Version 0.5.2 compiles fine and runs >> now for about a day without a problem. I tried also the the version from cvs >> server (checked out on 01.22.09 at 5.00 pm CET). If I start LCDd with my >> LCDd.conf from stable version, the Lines 3+4 stays blank. >> > > If you read C, you could try browsing the hd44780*.c code and see if > there were any changes made since 0.5.2-stable that might come into > play. I'm wondering how long tying two displays into one virtual > screen has been around, or if perhaps the default line for EN2 may > have changed in the past couple of years. > It is true that you cannot have a switchable backlight and a multi controller display like a 40x4. As there has been no change between 0.5.2 and HEAD regarding this, something other must be wrong. If you do like to have both you could just change the one or two lines of code, but you will have to keep track of this change. > I don't know that lots of the people on this list have 40x4 displays, > but perhaps someone with a parallel-attached LCD can comment. I > mostly work from laptops now, and few laptops provide parallel ports > anymore. Even serial ports are getting scarce. :-( I'm doing more > and more work with USB-attached displays even though I miss the > directness of driving ones own I/O ports without an intervening > software layer to debug. > I have one 40x4 I use with lcd2usb, but I currently don't have a spare connector to hook it up to the parallel port directly. I may give it a try this weekend. Regards Markus From sascha.zielinski at gmx.de Thu Jan 22 20:16:27 2009 From: sascha.zielinski at gmx.de (Sascha) Date: Thu, 22 Jan 2009 21:16:27 +0100 Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring In-Reply-To: <4978C7EF.8090902@nurfuerspam.de> References: <9185341920196262063@unknownmsgid> <4978C7EF.8090902@nurfuerspam.de> Message-ID: <200901222116.28304.sascha.zielinski@gmx.de> Am Donnerstag 22 Januar 2009 20:24:31 schrieben Sie: > Ethan Dicks wrote: > > On Thu, Jan 22, 2009 at 12:23 PM, Sascha wrote: > >> Hi, > >> > >> I bought a 40x4 LCD with LED Backlight... > >> > >> The Documentation describes to connect the Backlight pin through the > >> BC327 Transistor to Pin 17 of the Printer Port. > > > > Yes. That is the "standard" way to hook up a backlight. > > > >> Should I then connect the EN2 to GND? > > > > If you do that, then you will only be able to use half of your display. > > > > The "problem" is that there aren't enough pins for an 8-bit interface, > > plus 2xHD44780 (EN1 + EN2), *plus* backlight. AFAIK, all 40x4 > > displays are implemented as two HD44780s with all pins tied together > > except enables. This is because there isn't enough onboard RAM (or > > column/row drivers, too?) to handle 160 on-screen chars with a regular > > HD44780, and I don't think anyone extended the chip that way - it's > > easy enough to add a second controller chip to the back of the LCD, > > and there's plenty of room. > > It is not only RAM. The display controller has to address each pixel by > a row and column line. There would be just too many lines for a single > chip. Additionally there are limitation regarding the current flowing > through the chip. > > On displays like 40x4 you will not only find two controllers but also > some extension driver chips which are conntected through an internal > interface to the controller. > > >> I use Debian Unstable/Experimental. The Version 0.5.2 compiles fine and > >> runs now for about a day without a problem. I tried also the the version > >> from cvs server (checked out on 01.22.09 at 5.00 pm CET). If I start > >> LCDd with my LCDd.conf from stable version, the Lines 3+4 stays blank. > > > > If you read C, you could try browsing the hd44780*.c code and see if > > there were any changes made since 0.5.2-stable that might come into > > play. I'm wondering how long tying two displays into one virtual > > screen has been around, or if perhaps the default line for EN2 may > > have changed in the past couple of years. > > It is true that you cannot have a switchable backlight and a multi > controller display like a 40x4. As there has been no change between > 0.5.2 and HEAD regarding this, something other must be wrong. > > If you do like to have both you could just change the one or two lines > of code, but you will have to keep track of this change. > > > I don't know that lots of the people on this list have 40x4 displays, > > but perhaps someone with a parallel-attached LCD can comment. I > > mostly work from laptops now, and few laptops provide parallel ports > > anymore. Even serial ports are getting scarce. :-( I'm doing more > > and more work with USB-attached displays even though I miss the > > directness of driving ones own I/O ports without an intervening > > software layer to debug. > > I have one 40x4 I use with lcd2usb, but I currently don't have a spare > connector to hook it up to the parallel port directly. I may give it a > try this weekend. > > Regards > Markus Thanks for the fast replies. I've tried to switch the Backlight menu Option on and off. If the Backlight in Menu is on, I am getting the same behavior as in the cvs version. So I think setting Pin 17 to High/Low. This is why The LCD thinks there is no 2nd controller anymore. Is The Backlight Menu Option on by default in CVS? And how could I change / reset the settings in the menu? I tried changing the Menu Backlight option by using the joy driver. But I wasn't able to disable / enable this option I think. Sascha Zielinski From sascha.zielinski at gmx.de Thu Jan 22 20:25:42 2009 From: sascha.zielinski at gmx.de (Sascha) Date: Thu, 22 Jan 2009 21:25:42 +0100 Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring In-Reply-To: References: <-5301487089854434133@unknownmsgid> Message-ID: <200901222125.42986.sascha.zielinski@gmx.de> Am Donnerstag 22 Januar 2009 20:43:00 schrieben Sie: > On Thu, Jan 22, 2009 at 12:23 PM, Sascha wrote: > > Hi, > > > > I bought a 40x4 LCD with LED Backlight, [...] > > Hi Sascha, > > Where did you buy the display? I have a 40x4 now, but it's not backlit. > ;-) > > Thanks, > > Jeff I bought it at Conrad (www.conrad.de) for ~80 ?. Sascha From ernie.cline at gmail.com Fri Jan 23 05:14:08 2009 From: ernie.cline at gmail.com (Ernie Cline) Date: Thu, 22 Jan 2009 21:14:08 -0800 Subject: [Lcdproc] More LCD weirdness Message-ID: <1b9f9a570901222114m728716cp53872302406bb2b1@mail.gmail.com> So last week I was having trouble getting my Pico LCD 4x20 to work with FreeBSD and LCDProc. This works now thanks to some patches. However, now when I've recompiled a new kernel and put it on my alix hardware, it finds the device, but I still can't seem to get LCDProc to see my hardware. I played around with various options without much luck. I did a truss, and this is what I'm getting: open("/dev/ugen0",O_RDWR,05006536142) = 5 (0x5) nanosleep({0.000100000}) = 0 (0x0) ioctl(5,USB_SET_ALTINTERFACE,0xbfbfeb50) = 0 (0x0) open("/dev/ugen0.1",O_RDWR,05006536004) = 6 (0x6) ioctl(6,USB_SET_TIMEOUT,0xbfbfeb80) = 0 (0x0) And that's it. Just hangs and never returns, even Ctrl-C doesn't seem to do anything. This is FreeBSD 7.0 and the cvs version of lcdproc, which does seem to work with this hardware in VMWare. So is this and lcdproc thing or a freebsd thing? I've googled around for USB_SET_TIMEOUT without much luck. From bsdfan at nurfuerspam.de Sat Jan 24 14:14:13 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sat, 24 Jan 2009 15:14:13 +0100 Subject: [Lcdproc] HD44780 40x4 with Backlight and winamp wiring In-Reply-To: <200901222116.28304.sascha.zielinski@gmx.de> References: <9185341920196262063@unknownmsgid> <4978C7EF.8090902@nurfuerspam.de> <200901222116.28304.sascha.zielinski@gmx.de> Message-ID: <497B2235.6070701@nurfuerspam.de> Sascha wrote: > Thanks for the fast replies. I've tried to switch the Backlight menu Option on > and off. If the Backlight in Menu is on, I am getting the same behavior as in > the cvs version. So I think setting Pin 17 to High/Low. This is why The LCD > thinks there is no 2nd controller anymore. Is The Backlight Menu Option on by > default in CVS? And how could I change / reset the settings in the menu? > > I tried changing the Menu Backlight option by using the joy driver. But I > wasn't able to disable / enable this option I think. > > Sascha Zielinski > > Today I hook up my 40x4 to the parallel port and discovered the same behaviour as you. The first thing you should verify is that you have the settings: Size=40x4 vspan=2,2 set in your LCDd.conf. I also had a look at how the backlight setting is handled within the hd44780 driver: 1) The hd44780 driver checks a) if the "Backlight" setting is ON and b) if the connection type sub-driver (winamp) has a backlight function. As the winamp connection type has a BL function (whether or not a the hardware has a switchable backlight) the latter is always true. If the "Backlight" setting is "off", the BL function is called with "state=0", which in turn results in the PIN on the parallel port to be set high (as the BC327 is PNP transisitor). The backlight PIN is changed at two locations: First within the BL function and second with each senddata() call. Interestingly the display is correctly initialized (all lines turn blank on startup) because the BL fuctions is first called with the first screen rendering call. Before that the backlight PIN should be low and the display's backlight should light up. So anybody with a backlight and a "one controller display" with "Backlight=off" in LCDd.conf should see the display light up upon LCDd startup and then going it out with the switch to the server screen. The above is true for all hd44780 connection-types. Depending on the default state of the backlight you will see the backlight turning off with the server screen IF "Backlight=Off" in LCDd.conf. I have seen this with the lcd2usb i.e. But as this device stores the brightness setting accross power / reset-cycle it is off upon the next startup. 2) The driver's backlight function is called upon each screen rendering, even if the backlight state has not changed. For parallel port devices this has no negative effect. But for devices like the lcd2usb this means that the backlight setting is updated with each screen, resulting in an EEPROM write every time. This applies to other displays as well (MtxOrb, CFontz). I think this could be optimized as well. Solution for 1) Try with the attached patch. It makes the hd44780 BL function return immediately instead of calling the connection BL function with (state=0) if no switchable backlight is attached. Solution for 2) Outstanding. Regards Markus -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-server__drivers__hd44780.diff URL: From bsdfan at nurfuerspam.de Sun Jan 25 11:49:33 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sun, 25 Jan 2009 12:49:33 +0100 Subject: [Lcdproc] Please test: hd44780 backlight update Message-ID: <497C51CD.1080801@nurfuerspam.de> Hello, After analyzing Sascha's problem with 40x4 winamp-wired display I had a closer look how the backlight is used. I found that: 1. In render.c the backlight state is determined. 2. drivers.c passed the BL state to all drivers, if supported 3. The hd44780 passed the BL to the connection type, if supported 4. The conntection type sets the hardware accordingly. Besides a possible problem in 3. because the hardware is asked to set the backlight off if the user specified no backlight being available in the config file, the whole chain is executed with every screen rendering. Looking at how other drivers handle this I found some implement an "incremental" backlight change (only update hardware if the the state has really changed) while others do not. I decided to implement this "incremental update" for the hd44780 driver as well. Patch attached. As this applies to all connection types, I ask developers and users with hd44780 type displays and backlight to test the impact of this change. I already tested with lcd2usb and winamp (but without switchable backlight) and found no problems so far. Please also test what happens if "Backlight=off" is set in LCDd.conf. Regards Markus -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-hd44780-backlight.diff URL: From bsdfan at nurfuerspam.de Sun Jan 25 12:20:09 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sun, 25 Jan 2009 13:20:09 +0100 Subject: [Lcdproc] More LCD weirdness In-Reply-To: <1b9f9a570901222114m728716cp53872302406bb2b1@mail.gmail.com> References: <1b9f9a570901222114m728716cp53872302406bb2b1@mail.gmail.com> Message-ID: <497C58F9.4000701@nurfuerspam.de> Ernie Cline wrote: > So last week I was having trouble getting my Pico LCD 4x20 to work > with FreeBSD and LCDProc. This works now thanks to some patches. > However, now when I've recompiled a new kernel and put it on my alix > hardware, it finds the device, but I still can't seem to get LCDProc > to see my hardware. I played around with various options without much > luck. I did a truss, and this is what I'm getting: > > open("/dev/ugen0",O_RDWR,05006536142) = 5 (0x5) > nanosleep({0.000100000}) = 0 (0x0) > ioctl(5,USB_SET_ALTINTERFACE,0xbfbfeb50) = 0 (0x0) > open("/dev/ugen0.1",O_RDWR,05006536004) = 6 (0x6) > ioctl(6,USB_SET_TIMEOUT,0xbfbfeb80) = 0 (0x0) > > > And that's it. Just hangs and never returns, even Ctrl-C doesn't seem > to do anything. > > This is FreeBSD 7.0 and the cvs version of lcdproc, which does seem to > work with this hardware in VMWare. So is this and lcdproc thing or a > freebsd thing? I've googled around for USB_SET_TIMEOUT without much > luck. > > I am a little bit confused: The picolcd *does* work if it is attached to a VMware running FreeBSD + LCDd, but it *does not* work if you run the same software on real hardware? The USB_SET_TIMEOUT ioctl is part of libusb's usb_interrupt_write() which is used to communicate with the device. If this is failing it is either a problem with libusb, FreeBSD, some hardware, or is the wrong way to talk to the device. Regards, Markus From andy at siliconlandmark.com Sun Jan 25 17:23:18 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Sun, 25 Jan 2009 12:23:18 -0500 Subject: [Lcdproc] More LCD weirdness In-Reply-To: <497C58F9.4000701@nurfuerspam.de> References: <1b9f9a570901222114m728716cp53872302406bb2b1@mail.gmail.com> <497C58F9.4000701@nurfuerspam.de> Message-ID: <6E8CBDF0-966F-4B03-AC91-C7F5C3AD4820@siliconlandmark.com> On Jan 25, 2009, at 7:20 AM, Markus Dolze wrote: > Ernie Cline wrote: >> So last week I was having trouble getting my Pico LCD 4x20 to work >> with FreeBSD and LCDProc. This works now thanks to some patches. >> However, now when I've recompiled a new kernel and put it on my alix >> hardware, it finds the device, but I still can't seem to get LCDProc >> to see my hardware. I played around with various options without >> much >> luck. I did a truss, and this is what I'm getting: >> >> open("/dev/ugen0",O_RDWR,05006536142) = 5 (0x5) >> nanosleep({0.000100000}) = 0 (0x0) >> ioctl(5,USB_SET_ALTINTERFACE,0xbfbfeb50) = 0 (0x0) >> open("/dev/ugen0.1",O_RDWR,05006536004) = 6 (0x6) >> ioctl(6,USB_SET_TIMEOUT,0xbfbfeb80) = 0 (0x0) >> >> >> And that's it. Just hangs and never returns, even Ctrl-C doesn't >> seem >> to do anything. >> >> This is FreeBSD 7.0 and the cvs version of lcdproc, which does seem >> to >> work with this hardware in VMWare. So is this and lcdproc thing or a >> freebsd thing? I've googled around for USB_SET_TIMEOUT without much >> luck. >> >> > I am a little bit confused: The picolcd *does* work if it is > attached to a VMware running FreeBSD + LCDd, but it *does not* work > if you run the same software on real hardware? > > The USB_SET_TIMEOUT ioctl is part of libusb's usb_interrupt_write() > which is used to communicate with the device. If this is failing it > is either a problem with libusb, FreeBSD, some hardware, or is the > wrong way to > talk to the device. Another data point: I have had the very same model PicoLCD working on FreeBSD 7.1-PRERELEASE and 7.1-RELEASE on amd64 hardware working on real hardware for quite a while. 8-CURRENT brings in HPS's newusb stack, and the new libusb20 along with it. I have patches that make LCDproc work on CURRENT and any system that uses libusb20. The patches add some autoconf magic and a bunch of pre-processor macros. I will send those along once I am done polishing them up. Cheers, Andy /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From ernie.cline at gmail.com Sun Jan 25 18:16:41 2009 From: ernie.cline at gmail.com (Ernie Cline) Date: Sun, 25 Jan 2009 10:16:41 -0800 Subject: [Lcdproc] More LCD weirdness In-Reply-To: <497C58F9.4000701@nurfuerspam.de> References: <1b9f9a570901222114m728716cp53872302406bb2b1@mail.gmail.com> <497C58F9.4000701@nurfuerspam.de> Message-ID: <1b9f9a570901251016t1348e603l72beb41dcf3a3f6c@mail.gmail.com> Yes, weird isn't it? Works on VMware, works on my Mac, but doesn't work on my little alix box. Its running the same version of LCDProc that works in VMware, so I don't think its the hardware or LCDProc ... that said, I guess I am chasing a FreeBSD problem? The next version of pfSense (based on m0n0wall, which is based on FreeBSD) is moving to 7.1 as its base, so maybe I should just wait until that? Appreciate the help in this case... On Sun, Jan 25, 2009 at 4:20 AM, Markus Dolze wrote: > Ernie Cline wrote: >> >> So last week I was having trouble getting my Pico LCD 4x20 to work >> with FreeBSD and LCDProc. This works now thanks to some patches. >> However, now when I've recompiled a new kernel and put it on my alix >> hardware, it finds the device, but I still can't seem to get LCDProc >> to see my hardware. I played around with various options without much >> luck. I did a truss, and this is what I'm getting: >> >> open("/dev/ugen0",O_RDWR,05006536142) = 5 (0x5) >> nanosleep({0.000100000}) = 0 (0x0) >> ioctl(5,USB_SET_ALTINTERFACE,0xbfbfeb50) = 0 (0x0) >> open("/dev/ugen0.1",O_RDWR,05006536004) = 6 (0x6) >> ioctl(6,USB_SET_TIMEOUT,0xbfbfeb80) = 0 (0x0) >> >> >> And that's it. Just hangs and never returns, even Ctrl-C doesn't seem >> to do anything. >> >> This is FreeBSD 7.0 and the cvs version of lcdproc, which does seem to >> work with this hardware in VMWare. So is this and lcdproc thing or a >> freebsd thing? I've googled around for USB_SET_TIMEOUT without much >> luck. >> >> > > I am a little bit confused: The picolcd *does* work if it is attached to a > VMware running FreeBSD + LCDd, but it *does not* work if you run the same > software on real hardware? > > The USB_SET_TIMEOUT ioctl is part of libusb's usb_interrupt_write() which is > used to communicate with the device. If this is failing it is either a > problem with libusb, FreeBSD, some hardware, or is the wrong way to talk to > the device. > > Regards, > Markus > > From andy at siliconlandmark.com Mon Jan 26 02:10:07 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Sun, 25 Jan 2009 21:10:07 -0500 Subject: [Lcdproc] [PATCH] FreeBSD's new USB stack support (configure.in changes, testing needed) Message-ID: <90B881CB-06A2-4436-8F65-630309EC5279@siliconlandmark.com> Hi, I have attached a patch that extends LCDproc's USB support, and allows for its use on the upcoming FreeBSD 8.0 (Presently 8-CURRENT). This patch changes configure.in as well as all of LCDproc's USB drivers and though I have made every effort to not introduce side- effects, it needs wide-scale testing. For users of non-FreeBSD systems, this patch should not change anything. I have verified this statement with OSX, but I have not tested against any flavor of Linux (I suspect that it should "just work"). For pre-8.0-CURRENT FreeBSD users, the absence of the new USB's stack's headers keeps the present dependance on libusb. Let me know if this patch works or breaks anything for you. Cheers, Andy /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ -------------- next part -------------- A non-text attachment was scrubbed... Name: freebsd.8current.diff Type: application/octet-stream Size: 8459 bytes Desc: not available URL: -------------- next part -------------- From ethan.dicks at gmail.com Mon Jan 26 04:05:22 2009 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Sun, 25 Jan 2009 23:05:22 -0500 Subject: [Lcdproc] Is anyone making the latest LCDproc from a fresh CVS pull and having compile issues with MacOS? Message-ID: Hi, All, I've been working from nightly tarballs for so long that I don't remember the last time I built from a fresh CVS pull. I tried that tonight on my Macbook running 10.4 to get ready to submit patches for the jw002 24x8 LCD and immediately ran into problems in a non-essential area of the build. I fetched the code with the instructions from the sourceforge page... $ cvs -d:pserver:anonymous at lcdproc.cvs.sourceforge.net:/cvsroot/lcdproc login $ cvs -z3 -d:pserver:anonymous at lcdproc.cvs.sourceforge.net:/cvsroot/lcdproc co -P lcdproc ... and ran autogen.sh(per the note in INSTALL), but after a config... $ ./configure --enable-drivers=curses,MtxOrb,hd44780,picolcd --enable-libusb --enable-debug --disable-libftdi ... I got this when I tried a 'make'... $ make cd . && /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-recursive Making all in shared make[2]: *** No rule to make target `sockets.c', needed by `sockets.o'. Stop. make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 $ So... looking for sockets.c, I found it in lcdproc/contrib/interface-demo2. A 'make' there was even less successful... $ make make: *** No rule to make target `/usr/include/wait.h', needed by `if_demo.o'. Stop. $ Now _this_ seems to be an issue that's come up with other software packages - the code expects to find 'wait.h' but the system provides 'sys/wait.h', and someone commented somewhere that there are dummy 'wait.h' files that just '#include " to get around this sort of thing. I glanced over the Pyramid demo code but couldn't tell any details about what platform or distro it was written for. In contrast, on a recently built openSUSE 11 machine (Linux linux-cjw3 2.6.27.7-9-pae), I was able to cut my install/build commands from this e-mail and it pulled down, configured, and built with essentially no squawks (I did notice a complaint about #pragmas in hd44780-uss720.c). Admittedly, I'm on a Mac, not a Linux box, so I guess I have to ask - is anyone else doing development on Macs? It's BSD under the hood, which I know hasn't always been a primary LCDproc development platform, but I would hope that things work. I won't be upgrading this machine to 10.5 since I have to return it to my employer soon - I'll just reimage it rather than try to uproot everything I have going on it. Obviously, I have other machines to work from, but for the past 18 months, this has been "my" space for a variety of tasks. I _do_ have LCDproc running on it, but I've only used nightly tarballs, not a fresh CVS pull, certainly not since the Pyramid demo was put into the CVS tree. So in summary - SUSE, no problems building from CVS fetch; MacOS 10.4 w/gcc version 4.0.1, not even the first file compiles on a system that _does_ have LCDproc compiled and running from non-CVS-acquired sources. I am willing to entertain the notion that I'm missing something component or some step on the Mac, but it's not like I've _never_ gotten things to work - just this fresh CVS fetch. Am I alone in this? -ethan From andy at siliconlandmark.com Mon Jan 26 04:15:43 2009 From: andy at siliconlandmark.com (Andre Guibert de Bruet) Date: Sun, 25 Jan 2009 23:15:43 -0500 Subject: [Lcdproc] Is anyone making the latest LCDproc from a fresh CVS pull and having compile issues with MacOS? In-Reply-To: References: Message-ID: <47BA8AAC-1913-45CC-A3CA-12AAA107B1BD@siliconlandmark.com> On Jan 25, 2009, at 11:05 PM, Ethan Dicks wrote: > I've been working from nightly tarballs for so long that I don't > remember the last time I built from a fresh CVS pull. I tried that > tonight on my Macbook running 10.4 to get ready to submit patches for > the jw002 24x8 LCD and immediately ran into problems in a > non-essential area of the build. > > I fetched the code with the instructions from the sourceforge page... > > $ cvs -d:pserver:anonymous at lcdproc.cvs.sourceforge.net:/cvsroot/ > lcdproc login > $ cvs -z3 -d:pserver:anonymous at lcdproc.cvs.sourceforge.net:/cvsroot/ > lcdproc co -P lcdproc > > ... and ran autogen.sh(per the note in INSTALL), but after a config... > > $ ./configure --enable-drivers=curses,MtxOrb,hd44780,picolcd > --enable-libusb --enable-debug --disable-libftdi > > ... I got this when I tried a 'make'... > > $ make > cd . && /bin/sh ./config.status config.h > config.status: creating config.h > config.status: config.h is unchanged > make all-recursive > Making all in shared > make[2]: *** No rule to make target `sockets.c', needed by > `sockets.o'. Stop. > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > $ > > So... looking for sockets.c, I found it in > lcdproc/contrib/interface-demo2. A 'make' there was even less > successful... > > $ make > make: *** No rule to make target `/usr/include/wait.h', needed by > `if_demo.o'. Stop. > $ ... > > So in summary - SUSE, no problems building from CVS fetch; MacOS 10.4 > w/gcc version 4.0.1, not even the first file compiles on a system that > _does_ have LCDproc compiled and running from non-CVS-acquired > sources. I am willing to entertain the notion that I'm missing > something component or some step on the Mac, but it's not like I've > _never_ gotten things to work - just this fresh CVS fetch. > > Am I alone in this? CVS HEAD on 10.5, configured using the same steps you used, works here. uname -a: Darwin lysdexia.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 Cheers, Andy /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From epooch at cox.net Mon Jan 26 06:46:26 2009 From: epooch at cox.net (epooch at cox.net) Date: Sun, 25 Jan 2009 22:46:26 -0800 Subject: [Lcdproc] Is anyone making the latest LCDproc from a fresh CVS pull and having compile issues with MacOS? In-Reply-To: <47BA8AAC-1913-45CC-A3CA-12AAA107B1BD@siliconlandmark.com> Message-ID: <20090126014626.IAI0Q.849565.imail@fed1rmwml35> If you are using 10.4, make sure you update automake and pkg-config (if you are using usb). I know I had to install an updated version of it to get autogen.sh to work, but only for the cvs, not from the tarball. When I had a version newer than what was installed on 10.4 by default, but older than the newest version, the autogen.sh did not give me an error, it just made a messed up configure script that would not build correctly. http://lists.omnipotent.net/pipermail/lcdproc/2008-October/012386.html If that doesn't work diff the configure script that is generated by autogen.sh with the one in the tarball to see what is different. --Eric ---- Andre Guibert de Bruet wrote: > On Jan 25, 2009, at 11:05 PM, Ethan Dicks wrote: > > > I've been working from nightly tarballs for so long that I don't > > remember the last time I built from a fresh CVS pull. I tried that > > tonight on my Macbook running 10.4 to get ready to submit patches for > > the jw002 24x8 LCD and immediately ran into problems in a > > non-essential area of the build. > > > > I fetched the code with the instructions from the sourceforge page... > > > > $ cvs -d:pserver:anonymous at lcdproc.cvs.sourceforge.net:/cvsroot/ > > lcdproc login > > $ cvs -z3 -d:pserver:anonymous at lcdproc.cvs.sourceforge.net:/cvsroot/ > > lcdproc co -P lcdproc > > > > ... and ran autogen.sh(per the note in INSTALL), but after a config... > > > > $ ./configure --enable-drivers=curses,MtxOrb,hd44780,picolcd > > --enable-libusb --enable-debug --disable-libftdi > > > > ... I got this when I tried a 'make'... > > > > $ make > > cd . && /bin/sh ./config.status config.h > > config.status: creating config.h > > config.status: config.h is unchanged > > make all-recursive > > Making all in shared > > make[2]: *** No rule to make target `sockets.c', needed by > > `sockets.o'. Stop. > > make[1]: *** [all-recursive] Error 1 > > make: *** [all] Error 2 > > $ > > > > So... looking for sockets.c, I found it in > > lcdproc/contrib/interface-demo2. A 'make' there was even less > > successful... > > > > $ make > > make: *** No rule to make target `/usr/include/wait.h', needed by > > `if_demo.o'. Stop. > > $ > ... > > > > So in summary - SUSE, no problems building from CVS fetch; MacOS 10.4 > > w/gcc version 4.0.1, not even the first file compiles on a system that > > _does_ have LCDproc compiled and running from non-CVS-acquired > > sources. I am willing to entertain the notion that I'm missing > > something component or some step on the Mac, but it's not like I've > > _never_ gotten things to work - just this fresh CVS fetch. > > > > Am I alone in this? > > CVS HEAD on 10.5, configured using the same steps you used, works here. > > uname -a: > Darwin lysdexia.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 > 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 > > Cheers, > Andy > > /* Andre Guibert de Bruet * 436f 6465 2070 6f65 742e 2042 6974 206a */ > /* Managing Partner * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */ > /* GSM: +1 734 846 8758 * 2055 4e49 5820 736c 6575 7468 2e00 0000 */ > /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc From ethan.dicks at gmail.com Mon Jan 26 13:40:36 2009 From: ethan.dicks at gmail.com (Ethan Dicks) Date: Mon, 26 Jan 2009 08:40:36 -0500 Subject: [Lcdproc] Is anyone making the latest LCDproc from a fresh CVS pull and having compile issues with MacOS? In-Reply-To: <20090126014626.IAI0Q.849565.imail@fed1rmwml35> References: <47BA8AAC-1913-45CC-A3CA-12AAA107B1BD@siliconlandmark.com> <20090126014626.IAI0Q.849565.imail@fed1rmwml35> Message-ID: On Mon, Jan 26, 2009 at 1:46 AM, wrote: > If you are using 10.4, make sure you update automake and pkg-config (if you are using usb). I know I had to install an updated version of it to get autogen.sh to work, but only for the cvs, not from the tarball. When I had a version newer than what was installed on 10.4 by default, but older than the newest version, the autogen.sh did not give me an error, it just made a messed up configure script that would not build correctly. > http://lists.omnipotent.net/pipermail/lcdproc/2008-October/012386.html Ah... good advice. Looking back, I see that I did get a warning about some version of some part of my tool chain - I'll go make that go away and try again. > If that doesn't work diff the configure script that is generated by autogen.sh with the one in the tarball to see what is different. Indeed. Thanks for the tip, -ethan From b.l at housenet.at Mon Jan 26 16:09:50 2009 From: b.l at housenet.at (Bernhard L) Date: Mon, 26 Jan 2009 17:09:50 +0100 Subject: [Lcdproc] Shuttle xpc Display Message-ID: <000c01c97fd0$853ecba0$8fbc62e0$@l@housenet.at> I tested support with shuttle XPC Display from cvs and it works fine. but it only works with lcdproc internal system diagnostic External Software don?t work with shuttle Display but there is no /dev/lcd0 Is there another way to connect to lcdproc and type some text to shuttle vfd? Bernhard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsdfan at nurfuerspam.de Mon Jan 26 17:58:21 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 26 Jan 2009 18:58:21 +0100 Subject: [Lcdproc] New driver for LCDproc (Acer Idea 500/501 built in VFD display) In-Reply-To: <261dc0680901191126l1bad8cc1o28315bd407a8da00@mail.gmail.com> References: <261dc0680901110133x41d1dd1dr5c48e46b509778cd@mail.gmail.com> <496FAB39.3090907@nurfuerspam.de> <261dc0680901191126l1bad8cc1o28315bd407a8da00@mail.gmail.com> Message-ID: <497DF9BD.5030604@nurfuerspam.de> Erik H?ggstr?m wrote: > Right, here it is. The kernel driver is not included yet, needs some > tidying. > > On Thu, Jan 15, 2009 at 9:31 PM, Markus Dolze > wrote: > > Erik H?ggstr?m wrote: > > Hello All, > > I have written a kernel module and a driver module for LCDproc > to control the Acer VFD display. > What is the procedure for getting this into LCDproc and does the > kernel module go in a different package? > > The kernel module works standalone with 'echo > "Something" > /dev/lcd0' > > Regards, > > Erik > > Hello Erik, > > you found the right place. Please send a diff against the current > CVS version to this mailing list. > > It will have to be discussed what to do with the kernel driver. But > please submit it as well. > > Regards > Markus > Hello Erik, thank you for your contribution. I had a look at the driver. But before going into the details I would like to learn more about the display. Does it support something else than displaying plain text? Does it use a 'standard' controller that supports custom characters? How is it connected to the system (I/O, serial, USB)? Does that interface require exact hardware timings? Does it have keys? And what are your plans / ideas? In the current state the driver does not differ much from the "text" driver except it outputs to your kernel driver pipe instead to stdout. Therefore I vote to not add a separate driver but perhaps modify the "text" driver, although I am not to decide about this. Regards Markus From junk_inbox at verizon.net Thu Jan 29 05:21:21 2009 From: junk_inbox at verizon.net (Jeff Artz) Date: Thu, 29 Jan 2009 00:21:21 -0500 Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome> Message-ID: Does anybody have anything to suggest? It's now been a month since I posted my issue, but haven't even gotten a single response... :-( Jeff ----- Original Message ----- From: Jeff Artz To: lcdproc Sent: Sunday, December 28, 2008 11:07 PM Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD Ok, I've googled and found some references to this hang, and my new CF 634 display does the same, exactly as described in this thread from last year: http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS LCDproc v0.5.2 Here's what happens: [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start Starting up LCDd: ps ax of above hang scenerio: [root at mythbackend mythtv]# ps ax | grep LCDd 16361 pts/1 S+ 0:00 /bin/sh /sbin/service LCDd start 16368 pts/1 S+ 0:00 /bin/sh /etc/init.d/LCDd start 16373 pts/1 S+ 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf 16374 pts/1 S+ 0:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf 16375 ? Ss 0:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf 16381 pts/3 R+ 0:00 grep LCDd [root at mythbackend mythtv]# If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the prompt will come back and everything works fine. So, to help troubleshoot, I changed the ReportLevel to 5, and here's what I get to stdout: [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start Starting up LCDd: LCDd version 0.5.2 starting Built on Dec 22 2008, protocol version 0.3, API version 0.5 Using Configuration File: /home/mythtv/lcd/LCDd.conf Set report level to 5, output to stderr Server forking to background Listening for queries on 127.0.0.1:13666 screenlist_init() driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so") CFontz: using Device /dev/lcd CFontz: init() done Key "Escape" is now reserved in exclusive mode by client [-1] Key "Enter" is now reserved in shared mode by client [-1] Key "Up" is now reserved in shared mode by client [-1] Key "Down" is now reserved in shared mode by client [-1] screenlist_process() screenlist_switch(s=[_server_screen]) screenlist_switch: switched to screen [_server_screen] screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() screenlist_process() (Which doesn't seem very helpful to me - perhaps it will to the developers) So for the moment I can't setup LCDd to start at boot time, or it will hang my system. I manually start it after booting. (Thankfully that's not very often, as it's my MythTV backend system) How can I help troubleshoot this further? (Suggestions of a debugger and/or the process, not quite step-by-step, but the more explict the better - ie please don't reply with simply "just debug the process"... I don't know how to do that [yet]!) Thanks! ------------------------------------------------------------------------------ _______________________________________________ LCDproc mailing list LCDproc at lists.omnipotent.net http://lists.omnipotent.net/mailman/listinfo/lcdproc -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark.Vallevand at UNISYS.com Thu Jan 29 15:05:45 2009 From: Mark.Vallevand at UNISYS.com (Vallevand, Mark K) Date: Thu, 29 Jan 2009 09:05:45 -0600 Subject: [Lcdproc] Big bug in server/main.c Message-ID: While testing with my embedded Linux and also on SUSE 11 Linux, I found that if time goes backwards, LCDd will stall until time catches up. Try it. Set the time back 2 minutes. For 2 minutes LCDd does nothing. Here's the fix. server/main.c 813c813 < if ((t_diff + 1) > (LONG_MAX / 1e6)) { --- > if ( ((t_diff + 1) > (LONG_MAX / 1e6)) || (t_diff<0) ) { If someone has the time, this really should be rewritten to use something not based on the time and date of Linux. But, this fix suffices and we are now using it. Regards. Mark K Vallevand "I got free checking at Bear Stearns!" THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyatt at prairieturtle.ca Thu Jan 29 20:08:59 2009 From: wyatt at prairieturtle.ca (Daryl F) Date: Thu, 29 Jan 2009 14:08:59 -0600 (CST) Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD In-Reply-To: References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome> Message-ID: On Thu, 29 Jan 2009, Jeff Artz wrote: > Does anybody have anything to suggest? It's now been a month since I > posted my issue, but haven't even gotten a single response... > > :-( > > Jeff > ----- Original Message ----- > From: Jeff Artz > To: lcdproc > Sent: Sunday, December 28, 2008 11:07 PM > Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD > > > Ok, I've googled and found some references to this hang, and my new CF > 634 display does the same, exactly as described in this thread from last > year: > http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html > > I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS LCDproc v0.5.2 > > Here's what happens: > [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start > Starting up LCDd: > > > ps ax of above hang scenerio: > [root at mythbackend mythtv]# ps ax | grep LCDd > 16361 pts/1 S+ 0:00 /bin/sh /sbin/service LCDd start > 16368 pts/1 S+ 0:00 /bin/sh /etc/init.d/LCDd start > 16373 pts/1 S+ 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf > 16374 pts/1 S+ 0:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf > 16375 ? Ss 0:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf > 16381 pts/3 R+ 0:00 grep LCDd > [root at mythbackend mythtv]# > > If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the prompt will come back and everything works fine. > > So, to help troubleshoot, I changed the ReportLevel to 5, and here's what I get to stdout: > [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start > Starting up LCDd: LCDd version 0.5.2 starting > Built on Dec 22 2008, protocol version 0.3, API version 0.5 > Using Configuration File: /home/mythtv/lcd/LCDd.conf > Set report level to 5, output to stderr > Server forking to background > Listening for queries on 127.0.0.1:13666 > screenlist_init() > driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so") > CFontz: using Device /dev/lcd > CFontz: init() done > Key "Escape" is now reserved in exclusive mode by client [-1] > Key "Enter" is now reserved in shared mode by client [-1] > Key "Up" is now reserved in shared mode by client [-1] > Key "Down" is now reserved in shared mode by client [-1] > screenlist_process() > screenlist_switch(s=[_server_screen]) > screenlist_switch: switched to screen [_server_screen] > screenlist_process() > screenlist_process() > screenlist_process() > screenlist_process() > screenlist_process() > screenlist_process() > screenlist_process() > screenlist_process() > screenlist_process() > screenlist_process() > > > (Which doesn't seem very helpful to me - perhaps it will to the developers) > > So for the moment I can't setup LCDd to start at boot time, or it will hang my system. I manually start it after booting. (Thankfully that's not very often, as it's my MythTV backend system) > > How can I help troubleshoot this further? (Suggestions of a debugger and/or the process, not quite step-by-step, but the more explict the better - ie please don't reply with simply "just debug the process"... I don't know how to do that [yet]!) > > Thanks! > > > ------------------------------------------------------------------------------ > > > Hi Jeff, It may be that the child is sending the USR1 signal but it is being blocked from the parent because of permissions. Instead of a `ps ax` try `ps -ef` and see who owns the processes. I suspect the init script is running as root and also the parent LCDd process but the child is running as a less privileged user and the signal is not being delivered. The assumption hear is that the `kill -USR1 ' is manually being done from a root login so it gets delivered and then the parent ends and the init script completes and delivers the [ OK ] to the console. Post the `ps -ef'. Maybe someone else on this list can figure out what needs to be done if it is permissions at fault. -Daryl From junk_inbox at verizon.net Fri Jan 30 23:51:29 2009 From: junk_inbox at verizon.net (Jeff) Date: Fri, 30 Jan 2009 18:51:29 -0500 Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD In-Reply-To: References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome> Message-ID: On Thu, Jan 29, 2009 at 3:08 PM, Daryl F wrote: > On Thu, 29 Jan 2009, Jeff Artz wrote: > > Does anybody have anything to suggest? It's now been a month since I >> posted my issue, but haven't even gotten a single response... >> >> :-( >> >> Jeff >> ----- Original Message ----- >> From: Jeff Artz >> To: lcdproc >> Sent: Sunday, December 28, 2008 11:07 PM >> Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD >> >> >> Ok, I've googled and found some references to this hang, and my new CF >> 634 display does the same, exactly as described in this thread from last >> year: >> http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html >> >> I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS LCDproc >> v0.5.2 >> >> Here's what happens: >> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start >> Starting up LCDd: >> >> >> ps ax of above hang scenerio: >> [root at mythbackend mythtv]# ps ax | grep LCDd >> 16361 pts/1 S+ 0:00 /bin/sh /sbin/service LCDd start >> 16368 pts/1 S+ 0:00 /bin/sh /etc/init.d/LCDd start >> 16373 pts/1 S+ 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; >> /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf >> 16374 pts/1 S+ 0:00 /usr/local/sbin/LCDd -c >> /home/mythtv/lcd/LCDd.conf >> 16375 ? Ss 0:00 /usr/local/sbin/LCDd -c >> /home/mythtv/lcd/LCDd.conf >> 16381 pts/3 R+ 0:00 grep LCDd >> [root at mythbackend mythtv]# >> >> If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the >> prompt will come back and everything works fine. >> >> So, to help troubleshoot, I changed the ReportLevel to 5, and here's what >> I get to stdout: >> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start >> Starting up LCDd: LCDd version 0.5.2 starting >> Built on Dec 22 2008, protocol version 0.3, API version 0.5 >> Using Configuration File: /home/mythtv/lcd/LCDd.conf >> Set report level to 5, output to stderr >> Server forking to background >> Listening for queries on 127.0.0.1:13666 >> screenlist_init() >> driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so") >> CFontz: using Device /dev/lcd >> CFontz: init() done >> Key "Escape" is now reserved in exclusive mode by client [-1] >> Key "Enter" is now reserved in shared mode by client [-1] >> Key "Up" is now reserved in shared mode by client [-1] >> Key "Down" is now reserved in shared mode by client [-1] >> screenlist_process() >> screenlist_switch(s=[_server_screen]) >> screenlist_switch: switched to screen [_server_screen] >> screenlist_process() >> screenlist_process() >> screenlist_process() >> screenlist_process() >> screenlist_process() >> screenlist_process() >> screenlist_process() >> screenlist_process() >> screenlist_process() >> screenlist_process() >> > screens within a few seconds> >> >> (Which doesn't seem very helpful to me - perhaps it will to the >> developers) >> >> So for the moment I can't setup LCDd to start at boot time, or it will >> hang my system. I manually start it after booting. (Thankfully that's not >> very often, as it's my MythTV backend system) >> >> How can I help troubleshoot this further? (Suggestions of a debugger >> and/or the process, not quite step-by-step, but the more explict the better >> - ie please don't reply with simply "just debug the process"... I don't know >> how to do that [yet]!) >> >> Thanks! >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> > Hi Jeff, > > It may be that the child is sending the USR1 signal but it is being blocked > from the parent because of permissions. Instead of a `ps ax` try `ps -ef` > and see who owns the processes. > > I suspect the init script is running as root and also the parent LCDd > process but the child is running as a less privileged user and the signal is > not being delivered. The assumption hear is that the `kill -USR1 ' is > manually being done from a root login so it gets delivered and then the > parent ends and the init script completes and delivers the [ OK ] to the > console. > > Post the `ps -ef'. Maybe someone else on this list can figure out what > needs to be done if it is permissions at fault. > > -Daryl > > Thanks Daryl, Here's the "ps -ef |grep LCDd" output while issuing a "/sbin/service start LCDd" command: [root at mythbackend ~]# ps -ef |grep LCDd root 3667 3632 0 20:42 pts/5 00:00:00 /bin/sh /sbin/service LCDd start root 3675 3667 0 20:42 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd start root 3680 3675 0 20:42 pts/5 00:00:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf root 3681 3680 0 20:42 pts/5 00:00:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf nobody 3682 3681 0 20:42 ? 00:00:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf root 3686 23166 0 20:42 pts/1 00:00:00 grep LCDd [root at mythbackend ~]# (and you can see the parent running as root, and the daemon launced as nobody) If I comment out the "User=" line from the conf file, it still starts as 'nobody', and I get the same result. If, however, I change it to "User=root", it starts as root and exhibits the same behavior, so it doesn't appear to be a permissions issue: [root at mythbackend ~]# ps -ef |grep LCDd root 3800 3632 0 20:51 pts/5 00:00:00 /bin/sh /sbin/service LCDd start root 3807 3800 0 20:51 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd start root 3812 3807 0 20:51 pts/5 00:00:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf root 3813 3812 0 20:51 pts/5 00:00:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf root 3814 3813 0 20:51 ? 00:00:00 /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf root 3816 23166 0 20:51 pts/1 00:00:00 grep LCDd [root at mythbackend ~]# PS: Same behavior with latest CVS - revision 1.29.2.4 Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From wyatt at prairieturtle.ca Sat Jan 31 04:56:15 2009 From: wyatt at prairieturtle.ca (Daryl F) Date: Fri, 30 Jan 2009 22:56:15 -0600 (CST) Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD In-Reply-To: References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome> Message-ID: On Fri, 30 Jan 2009, Jeff wrote: > On Thu, Jan 29, 2009 at 3:08 PM, Daryl F wrote: > >> On Thu, 29 Jan 2009, Jeff Artz wrote: >> >> Does anybody have anything to suggest? It's now been a month since I >>> posted my issue, but haven't even gotten a single response... >>> >>> :-( >>> >>> Jeff >>> ----- Original Message ----- >>> From: Jeff Artz >>> To: lcdproc >>> Sent: Sunday, December 28, 2008 11:07 PM >>> Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD >>> >>> >>> Ok, I've googled and found some references to this hang, and my new CF >>> 634 display does the same, exactly as described in this thread from last >>> year: >>> http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html >>> >>> I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS LCDproc >>> v0.5.2 >>> >>> Here's what happens: >>> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start >>> Starting up LCDd: >>> >>> >>> ps ax of above hang scenerio: >>> [root at mythbackend mythtv]# ps ax | grep LCDd >>> 16361 pts/1 S+ 0:00 /bin/sh /sbin/service LCDd start >>> 16368 pts/1 S+ 0:00 /bin/sh /etc/init.d/LCDd start >>> 16373 pts/1 S+ 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; >>> /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf >>> 16374 pts/1 S+ 0:00 /usr/local/sbin/LCDd -c >>> /home/mythtv/lcd/LCDd.conf >>> 16375 ? Ss 0:00 /usr/local/sbin/LCDd -c >>> /home/mythtv/lcd/LCDd.conf >>> 16381 pts/3 R+ 0:00 grep LCDd >>> [root at mythbackend mythtv]# >>> >>> If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the >>> prompt will come back and everything works fine. >>> >>> So, to help troubleshoot, I changed the ReportLevel to 5, and here's what >>> I get to stdout: >>> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start >>> Starting up LCDd: LCDd version 0.5.2 starting >>> Built on Dec 22 2008, protocol version 0.3, API version 0.5 >>> Using Configuration File: /home/mythtv/lcd/LCDd.conf >>> Set report level to 5, output to stderr >>> Server forking to background >>> Listening for queries on 127.0.0.1:13666 >>> screenlist_init() >>> driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so") >>> CFontz: using Device /dev/lcd >>> CFontz: init() done >>> Key "Escape" is now reserved in exclusive mode by client [-1] >>> Key "Enter" is now reserved in shared mode by client [-1] >>> Key "Up" is now reserved in shared mode by client [-1] >>> Key "Down" is now reserved in shared mode by client [-1] >>> screenlist_process() >>> screenlist_switch(s=[_server_screen]) >>> screenlist_switch: switched to screen [_server_screen] >>> screenlist_process() >>> screenlist_process() >>> screenlist_process() >>> screenlist_process() >>> screenlist_process() >>> screenlist_process() >>> screenlist_process() >>> screenlist_process() >>> screenlist_process() >>> screenlist_process() >>> >> screens within a few seconds> >>> >>> (Which doesn't seem very helpful to me - perhaps it will to the >>> developers) >>> >>> So for the moment I can't setup LCDd to start at boot time, or it will >>> hang my system. I manually start it after booting. (Thankfully that's not >>> very often, as it's my MythTV backend system) >>> >>> How can I help troubleshoot this further? (Suggestions of a debugger >>> and/or the process, not quite step-by-step, but the more explict the better >>> - ie please don't reply with simply "just debug the process"... I don't know >>> how to do that [yet]!) >>> >>> Thanks! >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> >>> >> Hi Jeff, >> >> It may be that the child is sending the USR1 signal but it is being blocked >> from the parent because of permissions. Instead of a `ps ax` try `ps -ef` >> and see who owns the processes. >> >> I suspect the init script is running as root and also the parent LCDd >> process but the child is running as a less privileged user and the signal is >> not being delivered. The assumption hear is that the `kill -USR1 ' is >> manually being done from a root login so it gets delivered and then the >> parent ends and the init script completes and delivers the [ OK ] to the >> console. >> >> Post the `ps -ef'. Maybe someone else on this list can figure out what >> needs to be done if it is permissions at fault. >> >> -Daryl >> >> > > Thanks Daryl, > > Here's the "ps -ef |grep LCDd" output while issuing a "/sbin/service start > LCDd" command: > > [root at mythbackend ~]# ps -ef |grep LCDd > root 3667 3632 0 20:42 pts/5 00:00:00 /bin/sh /sbin/service LCDd > start > root 3675 3667 0 20:42 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd > start > root 3680 3675 0 20:42 pts/5 00:00:00 /bin/bash -c ulimit -S -c 0 >> /dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf > root 3681 3680 0 20:42 pts/5 00:00:00 /usr/local/sbin/LCDd -c > /home/mythtv/lcd/LCDd.conf > nobody 3682 3681 0 20:42 ? 00:00:00 /usr/local/sbin/LCDd -c > /home/mythtv/lcd/LCDd.conf > root 3686 23166 0 20:42 pts/1 00:00:00 grep LCDd > [root at mythbackend ~]# > > (and you can see the parent running as root, and the daemon launced as > nobody) > > If I comment out the "User=" line from the conf file, it still starts as > 'nobody', and I get the same result. > > If, however, I change it to "User=root", it starts as root and exhibits the > same behavior, so it doesn't appear to be a permissions issue: > [root at mythbackend ~]# ps -ef |grep LCDd > root 3800 3632 0 20:51 pts/5 00:00:00 /bin/sh /sbin/service LCDd > start > root 3807 3800 0 20:51 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd > start > root 3812 3807 0 20:51 pts/5 00:00:00 /bin/bash -c ulimit -S -c 0 >> /dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf > root 3813 3812 0 20:51 pts/5 00:00:00 /usr/local/sbin/LCDd -c > /home/mythtv/lcd/LCDd.conf > root 3814 3813 0 20:51 ? 00:00:00 /usr/local/sbin/LCDd -c > /home/mythtv/lcd/LCDd.conf > root 3816 23166 0 20:51 pts/1 00:00:00 grep LCDd > [root at mythbackend ~]# > > PS: Same behavior with latest CVS - revision 1.29.2.4 > > Thanks, > > Jeff > Hi Jeff, I run Gentoo so I can't verify the problem here but I can tell you of the strange way Gentoo starts LCDd: it uses the -f option to LCDd to tell it to start in the foreground but the init script uses a function called start-stop-daemon with the --background to force it into the background. I looked at the init scripts packaged with lcdproc for Redhat and it uses the daemon function. I don't know how it works or even if Fedora is using that for the init script but bear with me... I wonder if the method Gentoo uses somehow makes it possible for the child's USR1 signal to actually reach the parent process? It shouldn't matter if the parent is already detached when it forks the child but looking at the code in server/main.c it seems like there has been some problems with this on different platforms. I'm running kernel version 2.6.25. Did starting LCDd ever work with a kernel prior to 2.6.26? Please post a copy of the init script Fedora 8 uses so we can see if the distribution has changed it from what comes with lcdproc. -Daryl From npavel at ituner.com Sat Jan 31 10:13:26 2009 From: npavel at ituner.com (Nicu Pavel) Date: Sat, 31 Jan 2009 12:13:26 +0200 Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD In-Reply-To: References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome> Message-ID: <49842446.7070007@ituner.com> Hi, I don't have a Crystalfontz LCD but I got a similar report on picoLCD 20x4 with mythTV freezeing the LCD output. Do you have the same problem if you run LCDd + lcdproc client ? Either it's something wrong with mythTV LCDd client or another process is taking over LCD device or there is a problem in driver usb implementation. I will check on picoLCD side and post if I find something. Regards, Nicu Pavel > On Fri, 30 Jan 2009, Jeff wrote: > >> On Thu, Jan 29, 2009 at 3:08 PM, Daryl F wrote: >> >>> On Thu, 29 Jan 2009, Jeff Artz wrote: >>> >>> Does anybody have anything to suggest? It's now been a month since I >>>> posted my issue, but haven't even gotten a single response... >>>> >>>> :-( >>>> >>>> Jeff >>>> ----- Original Message ----- >>>> From: Jeff Artz >>>> To: lcdproc >>>> Sent: Sunday, December 28, 2008 11:07 PM >>>> Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD >>>> >>>> >>>> Ok, I've googled and found some references to this hang, and my >>>> new CF >>>> 634 display does the same, exactly as described in this thread from >>>> last >>>> year: >>>> http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html >>>> >>>> I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS >>>> LCDproc >>>> v0.5.2 >>>> >>>> Here's what happens: >>>> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start >>>> Starting up LCDd: >>>> >>> issued...> >>>> >>>> ps ax of above hang scenerio: >>>> [root at mythbackend mythtv]# ps ax | grep LCDd >>>> 16361 pts/1 S+ 0:00 /bin/sh /sbin/service LCDd start >>>> 16368 pts/1 S+ 0:00 /bin/sh /etc/init.d/LCDd start >>>> 16373 pts/1 S+ 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null >>>> 2>&1 ; >>>> /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf >>>> 16374 pts/1 S+ 0:00 /usr/local/sbin/LCDd -c >>>> /home/mythtv/lcd/LCDd.conf >>>> 16375 ? Ss 0:00 /usr/local/sbin/LCDd -c >>>> /home/mythtv/lcd/LCDd.conf >>>> 16381 pts/3 R+ 0:00 grep LCDd >>>> [root at mythbackend mythtv]# >>>> >>>> If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the >>>> prompt will come back and everything works fine. >>>> >>>> So, to help troubleshoot, I changed the ReportLevel to 5, and >>>> here's what >>>> I get to stdout: >>>> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start >>>> Starting up LCDd: LCDd version 0.5.2 starting >>>> Built on Dec 22 2008, protocol version 0.3, API version 0.5 >>>> Using Configuration File: /home/mythtv/lcd/LCDd.conf >>>> Set report level to 5, output to stderr >>>> Server forking to background >>>> Listening for queries on 127.0.0.1:13666 >>>> screenlist_init() >>>> driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so") >>>> CFontz: using Device /dev/lcd >>>> CFontz: init() done >>>> Key "Escape" is now reserved in exclusive mode by client [-1] >>>> Key "Enter" is now reserved in shared mode by client [-1] >>>> Key "Up" is now reserved in shared mode by client [-1] >>>> Key "Down" is now reserved in shared mode by client [-1] >>>> screenlist_process() >>>> screenlist_switch(s=[_server_screen]) >>>> screenlist_switch: switched to screen [_server_screen] >>>> screenlist_process() >>>> screenlist_process() >>>> screenlist_process() >>>> screenlist_process() >>>> screenlist_process() >>>> screenlist_process() >>>> screenlist_process() >>>> screenlist_process() >>>> screenlist_process() >>>> screenlist_process() >>>> >>> displaying >>>> screens within a few seconds> >>>> >>>> (Which doesn't seem very helpful to me - perhaps it will to the >>>> developers) >>>> >>>> So for the moment I can't setup LCDd to start at boot time, or it >>>> will >>>> hang my system. I manually start it after booting. (Thankfully >>>> that's not >>>> very often, as it's my MythTV backend system) >>>> >>>> How can I help troubleshoot this further? (Suggestions of a debugger >>>> and/or the process, not quite step-by-step, but the more explict >>>> the better >>>> - ie please don't reply with simply "just debug the process"... I >>>> don't know >>>> how to do that [yet]!) >>>> >>>> Thanks! >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> >>> Hi Jeff, >>> >>> It may be that the child is sending the USR1 signal but it is being >>> blocked >>> from the parent because of permissions. Instead of a `ps ax` try `ps >>> -ef` >>> and see who owns the processes. >>> >>> I suspect the init script is running as root and also the parent LCDd >>> process but the child is running as a less privileged user and the >>> signal is >>> not being delivered. The assumption hear is that the `kill -USR1 >>> ' is >>> manually being done from a root login so it gets delivered and then the >>> parent ends and the init script completes and delivers the [ OK ] to >>> the >>> console. >>> >>> Post the `ps -ef'. Maybe someone else on this list can figure out what >>> needs to be done if it is permissions at fault. >>> >>> -Daryl >>> >>> >> >> Thanks Daryl, >> >> Here's the "ps -ef |grep LCDd" output while issuing a "/sbin/service >> start >> LCDd" command: >> >> [root at mythbackend ~]# ps -ef |grep LCDd >> root 3667 3632 0 20:42 pts/5 00:00:00 /bin/sh /sbin/service >> LCDd >> start >> root 3675 3667 0 20:42 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd >> start >> root 3680 3675 0 20:42 pts/5 00:00:00 /bin/bash -c ulimit >> -S -c 0 >>> /dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf >> root 3681 3680 0 20:42 pts/5 00:00:00 /usr/local/sbin/LCDd -c >> /home/mythtv/lcd/LCDd.conf >> nobody 3682 3681 0 20:42 ? 00:00:00 /usr/local/sbin/LCDd -c >> /home/mythtv/lcd/LCDd.conf >> root 3686 23166 0 20:42 pts/1 00:00:00 grep LCDd >> [root at mythbackend ~]# >> >> (and you can see the parent running as root, and the daemon launced as >> nobody) >> >> If I comment out the "User=" line from the conf file, it still starts as >> 'nobody', and I get the same result. >> >> If, however, I change it to "User=root", it starts as root and >> exhibits the >> same behavior, so it doesn't appear to be a permissions issue: >> [root at mythbackend ~]# ps -ef |grep LCDd >> root 3800 3632 0 20:51 pts/5 00:00:00 /bin/sh /sbin/service >> LCDd >> start >> root 3807 3800 0 20:51 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd >> start >> root 3812 3807 0 20:51 pts/5 00:00:00 /bin/bash -c ulimit >> -S -c 0 >>> /dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf >> root 3813 3812 0 20:51 pts/5 00:00:00 /usr/local/sbin/LCDd -c >> /home/mythtv/lcd/LCDd.conf >> root 3814 3813 0 20:51 ? 00:00:00 /usr/local/sbin/LCDd -c >> /home/mythtv/lcd/LCDd.conf >> root 3816 23166 0 20:51 pts/1 00:00:00 grep LCDd >> [root at mythbackend ~]# >> >> PS: Same behavior with latest CVS - revision 1.29.2.4 >> >> Thanks, >> >> Jeff >> > > Hi Jeff, > > I run Gentoo so I can't verify the problem here but I can tell you of > the strange way Gentoo starts LCDd: it uses the -f option to LCDd to > tell it to start in the foreground but the init script uses a function > called start-stop-daemon with the --background to force it into the > background. > > I looked at the init scripts packaged with lcdproc for Redhat and it > uses the daemon function. I don't know how it works or even if Fedora > is using that for the init script but bear with me... > > I wonder if the method Gentoo uses somehow makes it possible for the > child's USR1 signal to actually reach the parent process? It shouldn't > matter if the parent is already detached when it forks the child but > looking at the code in server/main.c it seems like there has been some > problems with this on different platforms. > > I'm running kernel version 2.6.25. Did starting LCDd ever work with a > kernel prior to 2.6.26? > > Please post a copy of the init script Fedora 8 uses so we can see if > the distribution has changed it from what comes with lcdproc. > > -Daryl > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From bsdfan at nurfuerspam.de Sat Jan 31 10:49:31 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sat, 31 Jan 2009 11:49:31 +0100 Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD In-Reply-To: References: <4345451E4BEF4958BD79FC703E4B780C@jartzhome> Message-ID: <20090131104931.290160@gmx.net> -------- Original-Nachricht -------- > Datum: Fri, 30 Jan 2009 18:51:29 -0500 > Von: Jeff > An: lcdproc > Betreff: Re: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD > On Thu, Jan 29, 2009 at 3:08 PM, Daryl F wrote: > > > On Thu, 29 Jan 2009, Jeff Artz wrote: > > > > Does anybody have anything to suggest? It's now been a month since I > >> posted my issue, but haven't even gotten a single response... > >> > >> :-( > >> > >> Jeff > >> ----- Original Message ----- > >> From: Jeff Artz > >> To: lcdproc > >> Sent: Sunday, December 28, 2008 11:07 PM > >> Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD > >> > >> > >> Ok, I've googled and found some references to this hang, and my new CF > >> 634 display does the same, exactly as described in this thread from > last > >> year: > >> http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html > >> > >> I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS > LCDproc > >> v0.5.2 > >> > >> Here's what happens: > >> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start > >> Starting up LCDd: > >> issued...> > >> > >> ps ax of above hang scenerio: > >> [root at mythbackend mythtv]# ps ax | grep LCDd > >> 16361 pts/1 S+ 0:00 /bin/sh /sbin/service LCDd start > >> 16368 pts/1 S+ 0:00 /bin/sh /etc/init.d/LCDd start > >> 16373 pts/1 S+ 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 > ; > >> /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf > >> 16374 pts/1 S+ 0:00 /usr/local/sbin/LCDd -c > >> /home/mythtv/lcd/LCDd.conf > >> 16375 ? Ss 0:00 /usr/local/sbin/LCDd -c > >> /home/mythtv/lcd/LCDd.conf > >> 16381 pts/3 R+ 0:00 grep LCDd > >> [root at mythbackend mythtv]# > >> > >> If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the > >> prompt will come back and everything works fine. > >> > >> So, to help troubleshoot, I changed the ReportLevel to 5, and here's > what > >> I get to stdout: > >> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start > >> Starting up LCDd: LCDd version 0.5.2 starting > >> Built on Dec 22 2008, protocol version 0.3, API version 0.5 > >> Using Configuration File: /home/mythtv/lcd/LCDd.conf > >> Set report level to 5, output to stderr > >> Server forking to background > >> Listening for queries on 127.0.0.1:13666 > >> screenlist_init() > >> driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so") > >> CFontz: using Device /dev/lcd > >> CFontz: init() done > >> Key "Escape" is now reserved in exclusive mode by client [-1] > >> Key "Enter" is now reserved in shared mode by client [-1] > >> Key "Up" is now reserved in shared mode by client [-1] > >> Key "Down" is now reserved in shared mode by client [-1] > >> screenlist_process() > >> screenlist_switch(s=[_server_screen]) > >> screenlist_switch: switched to screen [_server_screen] > >> screenlist_process() > >> screenlist_process() > >> screenlist_process() > >> screenlist_process() > >> screenlist_process() > >> screenlist_process() > >> screenlist_process() > >> screenlist_process() > >> screenlist_process() > >> screenlist_process() > >> displaying > >> screens within a few seconds> > >> > >> (Which doesn't seem very helpful to me - perhaps it will to the > >> developers) > >> > >> So for the moment I can't setup LCDd to start at boot time, or it will > >> hang my system. I manually start it after booting. (Thankfully that's > not > >> very often, as it's my MythTV backend system) > >> > >> How can I help troubleshoot this further? (Suggestions of a debugger > >> and/or the process, not quite step-by-step, but the more explict the > better > >> - ie please don't reply with simply "just debug the process"... I don't > know > >> how to do that [yet]!) > >> > >> Thanks! > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> > >> > >> > > Hi Jeff, > > > > It may be that the child is sending the USR1 signal but it is being > blocked > > from the parent because of permissions. Instead of a `ps ax` try `ps > -ef` > > and see who owns the processes. > > > > I suspect the init script is running as root and also the parent LCDd > > process but the child is running as a less privileged user and the > signal is > > not being delivered. The assumption hear is that the `kill -USR1 ' > is > > manually being done from a root login so it gets delivered and then the > > parent ends and the init script completes and delivers the [ OK ] to the > > console. > > > > Post the `ps -ef'. Maybe someone else on this list can figure out what > > needs to be done if it is permissions at fault. > > > > -Daryl > > > > > > Thanks Daryl, > > Here's the "ps -ef |grep LCDd" output while issuing a "/sbin/service > start > LCDd" command: > > [root at mythbackend ~]# ps -ef |grep LCDd > root 3667 3632 0 20:42 pts/5 00:00:00 /bin/sh /sbin/service LCDd > start > root 3675 3667 0 20:42 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd > start > root 3680 3675 0 20:42 pts/5 00:00:00 /bin/bash -c ulimit -S -c > 0 > >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf > root 3681 3680 0 20:42 pts/5 00:00:00 /usr/local/sbin/LCDd -c > /home/mythtv/lcd/LCDd.conf > nobody 3682 3681 0 20:42 ? 00:00:00 /usr/local/sbin/LCDd -c > /home/mythtv/lcd/LCDd.conf > root 3686 23166 0 20:42 pts/1 00:00:00 grep LCDd > [root at mythbackend ~]# > > (and you can see the parent running as root, and the daemon launced as > nobody) > > If I comment out the "User=" line from the conf file, it still starts as > 'nobody', and I get the same result. > > If, however, I change it to "User=root", it starts as root and exhibits > the > same behavior, so it doesn't appear to be a permissions issue: > [root at mythbackend ~]# ps -ef |grep LCDd > root 3800 3632 0 20:51 pts/5 00:00:00 /bin/sh /sbin/service LCDd > start > root 3807 3800 0 20:51 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd > start > root 3812 3807 0 20:51 pts/5 00:00:00 /bin/bash -c ulimit -S -c > 0 > >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf > root 3813 3812 0 20:51 pts/5 00:00:00 /usr/local/sbin/LCDd -c > /home/mythtv/lcd/LCDd.conf > root 3814 3813 0 20:51 ? 00:00:00 /usr/local/sbin/LCDd -c > /home/mythtv/lcd/LCDd.conf > root 3816 23166 0 20:51 pts/1 00:00:00 grep LCDd > [root at mythbackend ~]# > > PS: Same behavior with latest CVS - revision 1.29.2.4 > > Thanks, > > Jeff Hi, the user privilege is changed after the signal has been sent, so this should not be a problem. Would you mind sending a log output of LCDd? You will have to rebuild LCDd and use "configure --enable-debug". Then use ReportLevel=5 and ReportToSyslog=yes in your LCDd.conf. You probably want to add an entry to your syslog.conf as well: !LCDd *.* /var/log/LCDd.conf (I am not sure if this works with Linux, but it should have something similar.) In the end you should see something like this: Jan 31 11:24:38 kirika LCDd: LCDd version 0.5dev starting ... Jan 31 11:24:38 kirika LCDd: Set report level to 5, output to syslog Jan 31 11:24:38 kirika LCDd: Server forking to background Jan 31 11:24:38 kirika LCDd: daemonize() Jan 31 11:24:38 kirika LCDd: parent = 1082 Jan 31 11:24:38 kirika LCDd: child = 1083 Jan 31 11:24:38 kirika LCDd: install_signal_handlers(allow_reload=1) ... Jan 31 11:24:41 kirika LCDd: wave_to_parent(parent_pid=1082) Jan 31 11:24:41 kirika LCDd: child_ok_func(signal=30) Jan 31 11:24:41 kirika LCDd: drop_privs(user="nobody") Jan 31 11:24:41 kirika LCDd: do_mainloop() The lines wave_to_parent() and child_ok_func() should appear. After this you should not see a process with the parent PID anymore! Regards Markus From bsdfan at nurfuerspam.de Sat Jan 31 14:11:47 2009 From: bsdfan at nurfuerspam.de (bsdfan at nurfuerspam.de) Date: Sat, 31 Jan 2009 15:11:47 +0100 Subject: [Lcdproc] Signalling in server/main.c Message-ID: <20090131141147.142390@gmx.net> Hi, after the problem of another user with the server startup I had a look at how this works in the server and found the following comment: /* BUG? According to the man page wait() should also return * when a signal comes in that is caught. Instead it * continues to wait. */ After reading the man page and experimenting a little bit I discovered this to be reasonable, because SA_RESTART is set for the signal. This causes the wait() call to be restarted. Using the attached patch demonstrates the intended behaviour: Jan 31 14:34:23 kirika LCDd: Set report level to 5, output to syslog Jan 31 14:34:23 kirika LCDd: Server forking to background Jan 31 14:34:23 kirika LCDd: daemonize() Jan 31 14:34:23 kirika LCDd: parent = 1185 Jan 31 14:34:23 kirika LCDd: child = 1186 Jan 31 14:34:23 kirika LCDd: install_signal_handlers(allow_reload=1) Jan 31 ... Jan 31 14:34:25 kirika LCDd: wave_to_parent(parent_pid=1185) Jan 31 14:34:25 kirika LCDd: child_ok_func(signal=30) Jan 31 14:34:25 kirika LCDd: wait() failed: Interrupted system call Jan 31 14:34:25 kirika LCDd: Got OK signal from child. Jan 31 14:34:25 kirika LCDd: drop_privs(user="nobody") Jan 31 14:34:25 kirika LCDd: do_mainloop() The likely reason this was introduced was to exit the server with the exit code of the child, if something went wrong in its initialization phase. The part that was supposed to run if the child completes initialization successful was never run, because the server calls _exist() upon receipt of the signal immediately. The whole thing is only necessary because fork() happens before the drivers are initialized. It was after the initialization before 0.5.0. Does anybody of the former developers remember why fork() was moved before the initialization? Regards Markus From bsdfan at nurfuerspam.de Sat Jan 31 14:21:27 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sat, 31 Jan 2009 15:21:27 +0100 Subject: [Lcdproc] Signalling in server/main.c In-Reply-To: <20090131141147.142390@gmx.net> References: <20090131141147.142390@gmx.net> Message-ID: <20090131142127.142370@gmx.net> -------- Original-Nachricht -------- > Datum: Sat, 31 Jan 2009 15:11:47 +0100 > Von: bsdfan at nurfuerspam.de > An: "LCDproc Mailinglist" > Betreff: [Lcdproc] Signalling in server/main.c > Using the attached patch demonstrates the intended behaviour: > Which I forgot to send. Here it comes. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_server_main.diff Type: application/octet-stream Size: 1291 bytes Desc: not available URL: From joris at robijn.net Sat Jan 31 15:06:46 2009 From: joris at robijn.net (Joris Robijn) Date: Sat, 31 Jan 2009 16:06:46 +0100 Subject: [Lcdproc] Signalling in server/main.c In-Reply-To: <20090131141147.142390@gmx.net> References: <20090131141147.142390@gmx.net> Message-ID: <49847716.3252.3A1226@joris.robijn.net> > The whole thing is only necessary because fork() happens before the > drivers are initialized. It was after the initialization before 0.5.0. > > Does anybody of the former developers remember why fork() was moved before > the initialization? The server looses the priviledges on the parallel port after the fork. That's why the drop_privs is done after the fork and after the driver init. Joris -- Joris Robijn Mobile: +31 6 288 41 964