From stefanbelow at gmx.de Wed Apr 1 08:14:31 2009 From: stefanbelow at gmx.de (Stefan Below) Date: Wed, 01 Apr 2009 10:14:31 +0200 Subject: [Lcdproc] hd44870 and IOWarrior problem Message-ID: <49D32267.2030207@gmx.de> Hello, I am trying to port the lcproc to openwrt. Everything is compiling fine, but when i try to start the LCDd daemon with LCDd -d hd44870 I get following error message: root at OpenWrt:~# LCDd -d hd44870 -r 5 LCDd version 0.5.2 starting Built on Apr 1 2009, protocol version 0.3, API version 0.5 Using Configuration File: /etc/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="hd44870", filename="/usr/lib/lcdproc/hd44870.so") Could not open driver module /usr/lib/lcdproc/hd44870.so: File not found Driver [hd44870] binding failed Module /usr/lib/lcdproc/hd44870.so could not be loaded Could not load driver hd44870 There is no output driver Critical error while initializing, abort. Same error message wih IOWarrior: root at OpenWrt:~# LCDd -d IOWarrior -r 5 LCDd version 0.5.2 starting Built on Apr 1 2009, protocol version 0.3, API version 0.5 Using Configuration File: /etc/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="IOWarrior", filename="/usr/lib/lcdproc/IOWarrior.so") Could not open driver module /usr/lib/lcdproc/IOWarrior.so: File not found Driver [IOWarrior] binding failed Module /usr/lib/lcdproc/IOWarrior.so could not be loaded Could not load driver IOWarrior There is no output driver Critical error while initializing, abort. The driver libraries are all in place: root at OpenWrt:~# ls /usr/lib/lcdproc/ CFontz.so EyeboxOne.so NoritakeVFD.so glk.so joy.so ms6931.so sed1520.so stv5730.so CFontz633.so IOWarrior.so bayrad.so hd44780.so lb216.so mtc_s16209x.so serialPOS.so t6963.so CFontzPacket.so MD8800.so curses.so icp_a106.so lcdm001.so pyramid.so serialVFD.so text.so CwLnx.so MtxOrb.so ea65.so imon.so lcterm.so sed1330.so sli.so tyan.so LCDd.conf is the standard configuration file with DriverPath=/usr/lib/lcdproc/ [server] DriverPath=/usr/lib/lcdproc/ # Tells the server to load the given drivers. Multiple lines can be given. # The name of the driver is case sensitive and determines the section # where to look for further configuration options of the specific driver # as well as the name of the dynamic driver module to load at runtime. # The latter one can be changed by giving af File= directive in the # driver specific section. # # The following drivers are supported: # bayrad, CFontz, CFontz633, CFontzPacket, curses, CwLnx, ea65, # EyeboxOne, g15, glcdlib, glk, hd44780, icp_a106, imon, IOWarrior, # irman, joy, lb216, lcdm001, lcterm, lirc, MD8800, ms6931, mtc_s16209x, # MtxOrb, NoritakeVFD, picolcd, pyramid, sed1330, sed1520, serialPOS, # serialVFD, sli, stv5730, svga, t6963, text, tyan, ula200, xosd Driver=curses # Tells the driver to bind to the given interface Bind=127.0.0.1 # Listen on this specified port; defaults to 13666. Port=13666 # Sets the reporting level; defaults to 2 (warnings and errors only). #ReportLevel=3 # Should we report to syslog instead of stderr ? Default: no #ReportToSyslog=yes # Sets the default time in seconds to displays a screen. WaitTime=5 # User to run as. LCDd will drop its root priviledges, # if any, and run as this user instead. User=nobody # If yes, the the serverscreen will be rotated as a usual info screen. If no, # it will be a background screen, only visible when no other screens are # active. #ServerScreen=no # The server will stay in the foreground if set to true. #Foreground=no # Where can we find the driver modules ? # IMPORTANT: Make sure to change this setting to reflect your # specific setup! Otherwise LCDd won't be able to find # the driver modules and will thus not be able to # function properly. # NOTE: Always place a slash as last character ! DriverPath=server/drivers/ # GoodBye message: each entry represents a display line; default: builtin #GoodBye="Thanks for using" #GoodBye=" LCDproc!" # The "...Key=" lines define what the server does with keypresses that # don't go to any client. # These are the defaults: ToggleRotateKey=Enter PrevScreenKey=Left NextScreenKey=Right #ScrollUpKey=Up #ScrollDownKey=Down # If you have only 4 keys, you can choose to use this: #ToggleRotateKey=Enter #PrevScreenKey=Up #NextScreenKey=Down # If you have only 3 keys, you can choose to use this: #ToggleRotateKey=Enter #PrevScreenKey=Up ..... The other driver are looking fine (they are complaining about not finding device on /dev/usb and so one...) Are there any 'hidden' dependencies for hd44780 and IOWarrior? Or can i somehow activate a more verbose output? File not found is not an helpful error message, when the .so file is in place.... root at OpenWrt:~# ls -luisa /usr/lib/lcdproc/hd44780.so 224 41 -rwxr-xr-x 1 root root 40452 Aug 11 02:54 /usr/lib/lcdproc/hd44780.so root at OpenWrt:~# ls -luisa /usr/lib/lcdproc/IOWarrior.so 217 16 -rwxr-xr-x 1 root root 15140 Aug 11 02:54 /usr/lib/lcdproc/IOWarrior.so I hope someone can help me. Stefan From stefanbelow at gmx.de Wed Apr 1 08:45:25 2009 From: stefanbelow at gmx.de (Stefan Below) Date: Wed, 01 Apr 2009 10:45:25 +0200 Subject: [Lcdproc] hd44870 and IOWarrior problem In-Reply-To: <49D32267.2030207@gmx.de> References: <49D32267.2030207@gmx.de> Message-ID: <49D329A5.6010105@gmx.de> Hi, i found the problem. I forgot the libusb package and now everything looks fine. (But still the error message is not good. A patch would be great, but i can not provide one, because i am not a C programmer). Thanks for the great program, Stefan > Hello, > > I am trying to port the lcproc to openwrt. Everything is compiling > fine, but when i try to start the LCDd daemon with LCDd -d hd44870 I > get following error message: > > root at OpenWrt:~# LCDd -d hd44870 -r 5 > LCDd version 0.5.2 starting > Built on Apr 1 2009, protocol version 0.3, API version 0.5 > Using Configuration File: /etc/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="hd44870", filename="/usr/lib/lcdproc/hd44870.so") > Could not open driver module /usr/lib/lcdproc/hd44870.so: File not found > Driver [hd44870] binding failed > Module /usr/lib/lcdproc/hd44870.so could not be loaded > Could not load driver hd44870 > There is no output driver > Critical error while initializing, abort. > > Same error message wih IOWarrior: > > root at OpenWrt:~# LCDd -d IOWarrior -r 5 LCDd version 0.5.2 starting > Built on Apr 1 2009, protocol version 0.3, API version 0.5 > Using Configuration File: /etc/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="IOWarrior", filename="/usr/lib/lcdproc/IOWarrior.so") > Could not open driver module /usr/lib/lcdproc/IOWarrior.so: File not > found > Driver [IOWarrior] binding failed > Module /usr/lib/lcdproc/IOWarrior.so could not be loaded > Could not load driver IOWarrior > There is no output driver > Critical error while initializing, abort. > > > The driver libraries are all in place: > root at OpenWrt:~# ls /usr/lib/lcdproc/ > CFontz.so EyeboxOne.so NoritakeVFD.so glk.so > joy.so ms6931.so sed1520.so stv5730.so > CFontz633.so IOWarrior.so bayrad.so hd44780.so > lb216.so mtc_s16209x.so serialPOS.so t6963.so > CFontzPacket.so MD8800.so curses.so icp_a106.so > lcdm001.so pyramid.so serialVFD.so text.so > CwLnx.so MtxOrb.so ea65.so imon.so > lcterm.so sed1330.so sli.so tyan.so > > > LCDd.conf is the standard configuration file with > DriverPath=/usr/lib/lcdproc/ > > [server] > DriverPath=/usr/lib/lcdproc/ > # Tells the server to load the given drivers. Multiple lines can be > given. > # The name of the driver is case sensitive and determines the > section # where to look for further configuration options of the > specific driver # as well as the name of the dynamic driver module to > load at runtime. # The latter one can be changed by giving af File= > directive in the # driver specific > section. > # > # The following drivers are > supported: # bayrad, CFontz, > CFontz633, CFontzPacket, curses, CwLnx, ea65, # EyeboxOne, > g15, glcdlib, glk, hd44780, icp_a106, imon, IOWarrior, # irman, > joy, lb216, lcdm001, lcterm, lirc, MD8800, ms6931, mtc_s16209x, > # MtxOrb, NoritakeVFD, picolcd, pyramid, sed1330, sed1520, > serialPOS, # serialVFD, sli, stv5730, svga, t6963, text, tyan, > ula200, xosd > Driver=curses > > # Tells the driver to bind to the given > interface > Bind=127.0.0.1 > > # Listen on this specified port; defaults to > 13666. > Port=13666 > > # Sets the reporting level; defaults to 2 (warnings and errors > only). > #ReportLevel=3 > > # Should we report to syslog instead of stderr ? Default: > no > #ReportToSyslog=yes > > # Sets the default time in seconds to displays a screen. > WaitTime=5 > > # User to run as. LCDd will drop its root > priviledges, # if any, and run as this user > instead. > User=nobody > > # If yes, the the serverscreen will be rotated as a usual info screen. > If no, > # it will be a background screen, only visible when no other screens are > # active. > #ServerScreen=no > > # The server will stay in the foreground if set to true. > #Foreground=no > # > Where can we find the driver modules ? # > IMPORTANT: Make sure to change this setting to reflect your > # specific setup! Otherwise LCDd won't be able to find > # the driver modules and will thus not be able to > # function properly. > # NOTE: Always place a slash as last character ! > DriverPath=server/drivers/ > # > GoodBye message: each entry represents a display line; default: builtin > #GoodBye="Thanks for using" > #GoodBye=" LCDproc!" > > # The "...Key=" lines define what the server does with keypresses > that # don't go to any > client. # These are the > defaults: > ToggleRotateKey=Enter > PrevScreenKey=Left > NextScreenKey=Right > #ScrollUpKey=Up > #ScrollDownKey=Down > # > If you have only 4 keys, you can choose to use this: > #ToggleRotateKey=Enter > #PrevScreenKey=Up > #NextScreenKey=Down > # > If you have only 3 keys, you can choose to use this: > #ToggleRotateKey=Enter > #PrevScreenKey=Up > > ..... > The other driver are looking fine (they are complaining about not > finding device on /dev/usb and so one...) > Are there any 'hidden' dependencies for hd44780 and IOWarrior? Or can > i somehow activate a more verbose output? File not found is not an > helpful error message, when the .so file is in place.... > > root at OpenWrt:~# ls -luisa /usr/lib/lcdproc/hd44780.so > 224 41 -rwxr-xr-x 1 root root 40452 Aug 11 02:54 > /usr/lib/lcdproc/hd44780.so > > root at OpenWrt:~# ls -luisa /usr/lib/lcdproc/IOWarrior.so 217 16 > -rwxr-xr-x 1 root root 15140 Aug 11 02:54 > /usr/lib/lcdproc/IOWarrior.so > > > I hope someone can help me. > > Stefan > > > > > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > From " lcdproc" at lists.omnipotent.net Sat Apr 4 14:19:29 2009 From: " lcdproc" at lists.omnipotent.net (lcdproc) Date: Sat, 04 Apr 2009 15:19:29 +0100 Subject: [Lcdproc] Futaba TDOD-5711BB VFD Display Message-ID: <49D76C71.5030004@lists.omnipotent.net> I have an Elonex Artisan case with the above VFD I have been working on writing a driver for it. I have it working but I need some help/input. I have documented my progress (with source code) so far at: http://www.parsonscroft.plus.com/steve/mythtv Any comments/improvements would be most welcome as I still have some issues. Regards Steve From " lcdproc" at lists.omnipotent.net Sun Apr 5 11:43:21 2009 From: " lcdproc" at lists.omnipotent.net (lcdproc) Date: Sun, 05 Apr 2009 12:43:21 +0100 Subject: [Lcdproc] Futaba TDOD-5711BB VFD Display In-Reply-To: References: <49D76C71.5030004@lists.omnipotent.net> Message-ID: <49D89959.1030907@lists.omnipotent.net> Adam Rybak wrote: > HI im trying to load the module futabaquirks.ko and im getting error: > > [ 20.001512] BUG: unable to handle kernel NULL pointer dereference at 00000547 > [ 20.001660] IP: [] ss_initialized+0x2/0x4 > [ 20.001763] *pde = 00000000 > [ 20.001862] Oops: 0002 [#1] SMP > [ 20.002003] Modules linked in: futabaquirks(+) sbp2 lp > snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm lmpcm_usb > snd_seq_dummy lirc_mceusb2 snd_seq_oss snd_seq_midi lirc_dev > snd_rawmidi nvidia(P) snd_seq_midi_event agpgart snd_seq snd_timer > snd_seq_device parport_pc parport snd serio_raw psmouse soundcore wmi > evdev i2c_piix4 button snd_page_alloc shpchp pci_hotplug i2c_core > pcspkr k8temp ext3 jbd mbcache usb_storage sd_mod crc_t10dif libusual > usbhid hid pata_atiixp sg ata_generic ohci1394 ieee1394 pata_acpi ahci > libata r8169 ehci_hcd scsi_mod ohci_hcd dock usbcore thermal processor > fan fbcon tileblit font bitblit softcursor fuse > [ 20.005118] > [ 20.005173] Pid: 4036, comm: modprobe Tainted: P > (2.6.27-9-generic #1) > [ 20.005241] EIP: 0060:[] EFLAGS: 00010246 CPU: 1 > [ 20.005299] EIP is at ss_initialized+0x2/0x4 > [ 20.005356] EAX: 00000547 EBX: c05b6746 ECX: 00000008 EDX: 00007000 > [ 20.005414] ESI: f8b7f020 EDI: 00000000 EBP: f60b3f1c ESP: f60b3f0c > [ 20.005438] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > [ 20.005438] Process modprobe (pid: 4036, ti=f60b2000 task=f5c057f0 > task.ti=f60b2000) > [ 20.005438] Stack: f8b7f042 00000000 00000000 00000000 f60b3f8c > c0101120 00000000 00000000 > [ 20.005438] 00000038 00000000 00000000 00000000 00000000 > 00000000 00000000 f8b617f8 > [ 20.005438] 00000011 f8b7f40c 00000000 00000000 c014c604 > 00000000 00000000 f8b7f400 > [ 20.005438] Call Trace: > [ 20.005438] [] ? futaba_quirks_init+0x22/0x50 [futabaquirks] > [ 20.005438] [] ? _stext+0x30/0x160 > [ 20.005438] [] ? __blocking_notifier_call_chain+0x14/0x70 > [ 20.005438] [] ? sys_init_module+0x88/0x1b0 > [ 20.005438] [] ? sysenter_do_call+0x12/0x2f > [ 20.005438] ======================= > [ 20.005438] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > [ 20.005438] EIP: [] ss_initialized+0x2/0x4 SS:ESP 0068:f60b3f0c > [ 20.010837] ---[ end trace 2a247273909c3671 ]--- > > i added to /etc/modules this module for load before anything else. > > im using kernel 2.6.27-9-generic from ubuntu 8.10. > > Adam > > 2009/4/4 lcdproc <" lcdproc"@lists.omnipotent.net>: >> I have an Elonex Artisan case with the above VFD I have been working on >> writing a driver for it. I have it working but I need some help/input. >> >> I have documented my progress (with source code) so far at: >> >> http://www.parsonscroft.plus.com/steve/mythtv >> >> Any comments/improvements would be most welcome as I still have some issues. >> >> Regards >> >> Steve >> _______________________________________________ >> LCDproc mailing list >> LCDproc at lists.omnipotent.net >> http://lists.omnipotent.net/mailman/listinfo/lcdproc >> > > > Looks like you have not changed the reference to "usbhid_modify_dquirk()" Read the source (Luke): -----SNIP---- static int (*p_usbhid_modify_dquirk)(uint16_t vendor,uint16_t product,uint32_t quirk) = // // Here is the botch. You need to find the address of *your* kernel symbol // usbhid_modify_dquirk() (usually in Symbols.map in /boot) (void *)0xc05b6746; ----SNIP------ You need to change this to the address of YOUR kernel's symbol (should be in your System.map) It may be that your kernel is different to mine, just a few thoughts: Maybe the USB stuff in the kernel has changed. You could try just running the user code and see if that works, also if you have the HID subsystem compiled as a module then try rmmod usbhid (or whatever it is called) and try the user code again. Regards Steve From bsdfan at nurfuerspam.de Mon Apr 6 06:07:59 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 06 Apr 2009 08:07:59 +0200 Subject: [Lcdproc] SMP CPU monitor counts I/O wait as CPU usage In-Reply-To: <200903301653.06636.sascha.zielinski@gmx.de> References: <200903301653.06636.sascha.zielinski@gmx.de> Message-ID: <49D99C3F.90909@nurfuerspam.de> Sascha wrote: > Markus Dolze wrote: > >Markus Dolze wrote: > >> for some time the Linux lcdproc CPU screens did not report CPU load > >> correctly as one user noticed: > >> > >> http://sourceforge.net/tracker2/?func=detail&aid=2580087&group_id=119&atid=100119 > >> > >> > >> Attached is a change that should fix it. As I don't run Linux, please > >> test and if necessary correct it. > >> > >> Note that I decided to make the additional variables local instead of > >> extending /load_type/ as they are Linux specific. > >> > >> > > > >No comments? > > > >I was able to verify the wrong behaviour and that my fix really resolves > >it. I will commit the change if I receive no objections. > > > >Regards, > >Markus > Hi, > Does this patch also may correct my CPU graph "problem"? I see every 2-4 > seconds two bars, which have have the height of my lcd. > Regards, > Sascha Hi, perhaps it solves your problem. The 'G' and 'P' screens use the same way to retrieve system data and it updated it for both. Regards, Markus From bsdfan at nurfuerspam.de Mon Apr 6 06:17:25 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 06 Apr 2009 08:17:25 +0200 Subject: [Lcdproc] MtxOrb adjustable backlight and display detection In-Reply-To: References: <20090308140131.9870@gmx.net> <49C893FB.5020909@nurfuerspam.de> Message-ID: <49D99E75.7080308@nurfuerspam.de> Ethan Dicks wrote: > On Tue, Mar 24, 2009 at 4:04 AM, Markus Dolze wrote: >> Hi, >> >> I have questions on how the Display On / Off and Set Brightness commands of >> Matrix Orbital displays work: >> >> 1. If I use the 'Display Off' command, does it just turns the >> backlight off like for older versions or does it completely turns >> the display off? >> 2. If the display's backlight is off, what happens if I issue a 'Set >> Brightness' command? Does the backlight stays off until a 'Display >> On' command is issued or does the backlight automatically turns on? .. > > I send "display off", the display goes off *and* the backlight goes > off. I had to send both a "backlight brightness" _and_ a "display on" > command to see chars again. It does not matter which is sent first, > but both have to be sent. > > When the backlight is off sending a "set brightness" does not turn the > backlight on right away. It stays off until the "display on" is sent. > > This is the only Matrix Orbital textual LCD I have (an "LKD"). My > other textual MO display is that VFD display that "doesn't like" the > newer LCD commands (but worked fine the last time I tested it as a > "VKD" type display). > Hi, my idea was to implement 'offbrightness=0' as 'display off' command. On older displays this turns off the backlight. But as newer displays turn off completely this is not an option anymore. My second idea was to overload the 'onbrightness' value. As the displays support only 255 brightness values and the driver maps 0-1000 => 0-255 you will increase the brightness values by four to see an effect. I wanted to use 'onbrightness=1' to make the driver send a 'display on' command for those older displays. This is still possible, but does only make sense with 'offbrightness=0' as above. Do you have any other ideas beside adding a new option to the config file? Regards, Markus From bsdfan at nurfuerspam.de Mon Apr 6 06:25:10 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 06 Apr 2009 08:25:10 +0200 Subject: [Lcdproc] improved imon hbars In-Reply-To: <20090331173053.6E24593C47B@tippex.mynet.homeunix.org> References: <20090111142455.2A49E940566@tippex.mynet.homeunix.org> <49B6DD48.9090108@nurfuerspam.de> <20090310223536.DE2122C40DB@tippex.mynet.homeunix.org> <49C80994.7070800@nurfuerspam.de> <20090331173053.6E24593C47B@tippex.mynet.homeunix.org> Message-ID: <49D9A046.2080906@nurfuerspam.de> aeriksson2 at fastmail.fm wrote: > Hi Markus, > > bsdfan at nurfuerspam.de said: >> Hi Anders, >> attached you will find a version of your patch that adds the new hBar as an >> optional feature. Looking at my video convinced me to make it on by default. > >> Would you please test it? Especially I am interrested if the old behaviour >> could be restored. For this you will have to do: > >> export CPPFLAGS="-DIMON_HBARS_OLD" >> ./configure >> make > > I checked and it appears to work as expected. However, why do you want to > make this a compile time decision? If it is to be configurable at all, I'd > wote for a runtime config option. What do you expect distros to choose when > they compile it for the masses? I have chosen it as a compile time option as I didn't want to spam the config file with an option which I would like to remove in future. Anyone configuring it with the default options will see the new behaviour. Only for those who complain the old way will be available for some time. > > Additionally, the logic tricks my head with the ifNdef of an OLD thing. To me, > it seems more natural if the old cruft stuff is NOT ifdeffed out, and you leave > the "standard" stuff free from ifdefs. But this is just cosmetical. > I don't get this. If it is an option, there has to be #ifdef. I have chosen #ifndef as the new behaviour is the default unless you say 'use the old one' and I put the new part first in the file. As it works, I am about to commit this. Any objections? Regards, Markus From bsdfan at nurfuerspam.de Mon Apr 6 06:42:19 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 06 Apr 2009 08:42:19 +0200 Subject: [Lcdproc] Futaba TDOD-5711BB VFD Display In-Reply-To: <49D89959.1030907@lists.omnipotent.net> References: <49D76C71.5030004@lists.omnipotent.net> <49D89959.1030907@lists.omnipotent.net> Message-ID: <49D9A44B.5020808@nurfuerspam.de> lcdproc wrote: > Adam Rybak wrote: >> HI im trying to load the module futabaquirks.ko and im getting error: >> >> ... >> >> i added to /etc/modules this module for load before anything else. >> >> im using kernel 2.6.27-9-generic from ubuntu 8.10. >> >> Adam >> >> 2009/4/4 lcdproc <" lcdproc"@lists.omnipotent.net>: >>> I have an Elonex Artisan case with the above VFD I have been working on >>> writing a driver for it. I have it working but I need some help/input. >>> >>> I have documented my progress (with source code) so far at: >>> >>> http://www.parsonscroft.plus.com/steve/mythtv >>> >>> Any comments/improvements would be most welcome as I still have some >>> issues. >>> >>> Regards >>> >>> Steve >>> _______________________________________________ >>> LCDproc mailing list >>> LCDproc at lists.omnipotent.net >>> http://lists.omnipotent.net/mailman/listinfo/lcdproc >>> >> >> >> > > Looks like you have not changed the reference to "usbhid_modify_dquirk()" > > Read the source (Luke): > > -----SNIP---- > static int (*p_usbhid_modify_dquirk)(uint16_t vendor,uint16_t > product,uint32_t quirk) = > // > // Here is the botch. You need to find the address of *your* kernel > symbol > // usbhid_modify_dquirk() (usually in Symbols.map in /boot) > > (void *)0xc05b6746; > > ----SNIP------ > > You need to change this to the address of YOUR kernel's symbol (should > be in your System.map) > > It may be that your kernel is different to mine, just a few thoughts: > > Maybe the USB stuff in the kernel has changed. You could try just > running the user code and see if that works, also if you have the HID > subsystem compiled as a module then try rmmod usbhid (or whatever it > is called) and try the user code again. > > > Regards > > Steve > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc > Hello, first of all you should check your e-mail setup. Your mails appear with sender 'lcdproc' in the list. If you are not using this sender the list automatically makes this, but I guess it will only do this in case of an error. Please don't just use 'lcdproc' on its own as this may look like some 'official' mail. Back to topic: The name Futaba is already familiar to LCDproc, but only serial types so far. I have not yet look at the code. Is there already a lcdproc driver or just the stand-alone software? Using libusb to talk to the display is ok and also means the driver might be useful on non-Linux systems as well. If you are writing a kernel driver and a lcdproc driver which justs talks to the former please note that we will not add the kernel driver to LCDproc. Regards, Markus From " lcdproc" at lists.omnipotent.net Mon Apr 6 16:28:56 2009 From: " lcdproc" at lists.omnipotent.net (lcdproc) Date: Mon, 06 Apr 2009 17:28:56 +0100 Subject: [Lcdproc] Futaba TDOD-5711BB VFD Display In-Reply-To: <49D9A44B.5020808@nurfuerspam.de> References: <49D76C71.5030004@lists.omnipotent.net> <49D89959.1030907@lists.omnipotent.net> <49D9A44B.5020808@nurfuerspam.de> Message-ID: <49DA2DC8.1070608@lists.omnipotent.net> > Hello, > > first of all you should check your e-mail setup. Your mails appear with > sender 'lcdproc' in the list. If you are not using this sender the list > automatically makes this, but I guess it will only do this in case of an > error. Please don't just use 'lcdproc' on its own as this may look like > some 'official' mail. Back to topic: > > The name Futaba is already familiar to LCDproc, but only serial types so > far. I have not yet look at the code. Is there already a lcdproc driver > or just the stand-alone software? > > Using libusb to talk to the display is ok and also means the driver > might be useful on non-Linux systems as well. If you are writing a > kernel driver and a lcdproc driver which justs talks to the former > please note that we will not add the kernel driver to LCDproc. > > Regards, > Markus Hi Markus I named the mailbox lcdproc at ....... So I could have one incoming mailbox for the list. I can't see where the name "lcdproc" is coming from but I have renamed it anyway. If it still shows up as lcdproc on the list I won't post any more. The Futaba display I am talking about is a USB device so far un-supported, that is part of the FIC Spectra (Elonex Artisan) media center case. I was looking for some help in progressing the rudimentary driver I have so far. Regards Steve From bruce at spearmorgan.com Wed Apr 8 18:31:28 2009 From: bruce at spearmorgan.com (Bruce Wheaton) Date: Wed, 8 Apr 2009 11:31:28 -0700 Subject: [Lcdproc] CrystalFontzPacket driver and 635 - LCD not changing Message-ID: <4AF96CFE-DD52-4C5B-AF9A-9E1C3664A408@spearmorgan.com> Hello, just starting on LCDproc, and I've installed from CVS (using the Mac LCD install script plus some fiddling, lcdproc-CVS-current-20090407) and I can run LCDd with no evident errors, but my LCD never changes. I have a Mac with OS 10.5, a fresh LCDproc and libusb install. When I use the curses driver, I do see data. When I push a button, it's received. If I use CrystalFontz's Linux example, it does compile and work properly on Mac (LCD prints). So it's almost as if nothing gets 'sent' from LCDproc - there's not even a reset, as specified in the driver prefs. There's no evident error reports back from the LCD either. Below is the output from a run. Thanks, Bruce MacBook-Pro:~ bruce$ sudo /usr/local/sbin/LCDd -f -r 5 -s 0 -c /usr/ local/etc/LCDd.conf LCDd version CVS-current-20090407 starting Built on Apr 7 2009, protocol version 0.3, API version 0.5 Using Configuration File: /usr/local/etc/LCDd.conf Set report level to 5, output to stderr LCDd CVS-current-20090407, LCDproc Protocol 0.3 Part of the LCDproc suite Copyright (C) 1998-2007 William Ferrell, Scott Scriven and many other contributors This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. Server running in foreground Listening for queries on 127.0.0.1:13666 screenlist_init() driver_load(name="CFontzPacket", filename="/usr/local/lib/lcdproc/ CFontzPacket.so") CFontzPacket: using Device /dev/tty.usbserial-CF057254 CFontzPacket: rebooting LCD... CFontzPacket: init() done Key "Escape" is now reserved exclusively by client [-1] Key "Enter" is now reserved shared by client [-1] Key "Up" is now reserved shared by client [-1] Key "Down" is now reserved shared by client [-1] screenlist_process() screenlist_switch(s=[_server_screen]) screenlist_switch: switched to screen [_server_screen] screenlist_process() screenlist_process() Connect from host 127.0.0.1:50650 on socket 5 screenlist_process() sock_read_from_client: got message from client 5: "hello " Connect from host 127.0.0.1:50651 on socket 6 screenlist_process() sock_read_from_client: got message from client 6: "hello " screenlist_process() screenlist_process() From epooch at cox.net Wed Apr 8 20:41:28 2009 From: epooch at cox.net (epooch at cox.net) Date: Wed, 8 Apr 2009 13:41:28 -0700 Subject: [Lcdproc] CrystalFontzPacket driver and 635 - LCD not changing In-Reply-To: <4AF96CFE-DD52-4C5B-AF9A-9E1C3664A408@spearmorgan.com> Message-ID: <20090408164128.M134Z.793486.imail@fed1rmwml43> you need to specify the cu.serial device, not the tty. --Eric ---- Bruce Wheaton wrote: > Hello, > > just starting on LCDproc, and I've installed from CVS (using the Mac > LCD install script plus some fiddling, lcdproc-CVS-current-20090407) > and I can run LCDd with no evident errors, but my LCD never changes. > > I have a Mac with OS 10.5, a fresh LCDproc and libusb install. > > When I use the curses driver, I do see data. > When I push a button, it's received. > If I use CrystalFontz's Linux example, it does compile and work > properly on Mac (LCD prints). > > So it's almost as if nothing gets 'sent' from LCDproc - there's not > even a reset, as specified in the driver prefs. There's no evident > error reports back from the LCD either. > > Below is the output from a run. > > Thanks, > > Bruce > > > MacBook-Pro:~ bruce$ sudo /usr/local/sbin/LCDd -f -r 5 -s 0 -c /usr/ > local/etc/LCDd.conf > LCDd version CVS-current-20090407 starting > Built on Apr 7 2009, protocol version 0.3, API version 0.5 > Using Configuration File: /usr/local/etc/LCDd.conf > Set report level to 5, output to stderr > LCDd CVS-current-20090407, LCDproc Protocol 0.3 > Part of the LCDproc suite > Copyright (C) 1998-2007 William Ferrell, Scott Scriven > and many other contributors > > This program is free software; you can redistribute it and/or > modify it under the terms of the GNU General Public License > as published by the Free Software Foundation; either version 2 > of the License, or (at your option) any later version. > > This program is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > GNU General Public License for more details. > > You should have received a copy of the GNU General Public License > along with this program; if not, write to the Free Software Foundation, > Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. > > Server running in foreground > Listening for queries on 127.0.0.1:13666 > screenlist_init() > driver_load(name="CFontzPacket", filename="/usr/local/lib/lcdproc/ > CFontzPacket.so") > CFontzPacket: using Device /dev/tty.usbserial-CF057254 > CFontzPacket: rebooting LCD... > CFontzPacket: init() done > Key "Escape" is now reserved exclusively by client [-1] > Key "Enter" is now reserved shared by client [-1] > Key "Up" is now reserved shared by client [-1] > Key "Down" is now reserved shared by client [-1] > screenlist_process() > screenlist_switch(s=[_server_screen]) > screenlist_switch: switched to screen [_server_screen] > screenlist_process() > screenlist_process() > Connect from host 127.0.0.1:50650 on socket 5 > screenlist_process() > sock_read_from_client: got message from client 5: "hello > " > Connect from host 127.0.0.1:50651 on socket 6 > screenlist_process() > sock_read_from_client: got message from client 6: "hello > " > screenlist_process() > screenlist_process() > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc From bruce at spearmorgan.com Wed Apr 8 20:59:47 2009 From: bruce at spearmorgan.com (Bruce Wheaton) Date: Wed, 8 Apr 2009 13:59:47 -0700 Subject: [Lcdproc] CrystalFontzPacket driver and 635 - LCD not changing In-Reply-To: <20090408164128.M134Z.793486.imail@fed1rmwml43> References: <20090408164128.M134Z.793486.imail@fed1rmwml43> Message-ID: <2B8F1835-ECC4-448B-924C-BD237C81BC7B@spearmorgan.com> Brilliant, thank you. Also thanks for the install script and lcdGrowl! Bruce On Apr 8, 2009, at 1:41 PM, wrote: > you need to specify the cu.serial device, not the tty. > --Eric > > ---- Bruce Wheaton wrote: >> Hello, >> >> just starting on LCDproc, and I've installed from CVS (using the Mac >> LCD install script plus some fiddling, lcdproc-CVS-current-20090407) >> and I can run LCDd with no evident errors, but my LCD never changes. >> >> I have a Mac with OS 10.5, a fresh LCDproc and libusb install. >> >> When I use the curses driver, I do see data. >> When I push a button, it's received. >> If I use CrystalFontz's Linux example, it does compile and work >> properly on Mac (LCD prints). >> >> So it's almost as if nothing gets 'sent' from LCDproc - there's not >> even a reset, as specified in the driver prefs. There's no evident >> error reports back from the LCD either. >> >> Below is the output from a run. >> >> Thanks, >> >> Bruce >> >> >> MacBook-Pro:~ bruce$ sudo /usr/local/sbin/LCDd -f -r 5 -s 0 -c /usr/ >> local/etc/LCDd.conf >> LCDd version CVS-current-20090407 starting >> Built on Apr 7 2009, protocol version 0.3, API version 0.5 >> Using Configuration File: /usr/local/etc/LCDd.conf >> Set report level to 5, output to stderr >> LCDd CVS-current-20090407, LCDproc Protocol 0.3 >> Part of the LCDproc suite >> Copyright (C) 1998-2007 William Ferrell, Scott Scriven >> and many other contributors >> >> This program is free software; you can redistribute it and/or >> modify it under the terms of the GNU General Public License >> as published by the Free Software Foundation; either version 2 >> of the License, or (at your option) any later version. >> >> This program is distributed in the hope that it will be useful, >> but WITHOUT ANY WARRANTY; without even the implied warranty of >> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> GNU General Public License for more details. >> >> You should have received a copy of the GNU General Public License >> along with this program; if not, write to the Free Software >> Foundation, >> Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. >> >> Server running in foreground >> Listening for queries on 127.0.0.1:13666 >> screenlist_init() >> driver_load(name="CFontzPacket", filename="/usr/local/lib/lcdproc/ >> CFontzPacket.so") >> CFontzPacket: using Device /dev/tty.usbserial-CF057254 >> CFontzPacket: rebooting LCD... >> CFontzPacket: init() done >> Key "Escape" is now reserved exclusively by client [-1] >> Key "Enter" is now reserved shared by client [-1] >> Key "Up" is now reserved shared by client [-1] >> Key "Down" is now reserved shared by client [-1] >> screenlist_process() >> screenlist_switch(s=[_server_screen]) >> screenlist_switch: switched to screen [_server_screen] >> screenlist_process() >> screenlist_process() >> Connect from host 127.0.0.1:50650 on socket 5 >> screenlist_process() >> sock_read_from_client: got message from client 5: "hello >> " >> Connect from host 127.0.0.1:50651 on socket 6 >> screenlist_process() >> sock_read_from_client: got message from client 6: "hello >> " >> screenlist_process() >> screenlist_process() >> >> _______________________________________________ >> LCDproc mailing list >> LCDproc at lists.omnipotent.net >> http://lists.omnipotent.net/mailman/listinfo/lcdproc > > _______________________________________________ > LCDproc mailing list > LCDproc at lists.omnipotent.net > http://lists.omnipotent.net/mailman/listinfo/lcdproc From mattia.jona at gmail.com Sun Apr 12 13:46:33 2009 From: mattia.jona at gmail.com (Mattia Jona-Lasinio) Date: Sun, 12 Apr 2009 15:46:33 +0200 Subject: [Lcdproc] New driver Message-ID: <7af880ab0904120646w3f30620dgf851333bea2d2d46@mail.gmail.com> Hi all, and Happy Easter to everybody. I wrote a new lcdproc driver for the lcd-linux kernel driver. LCD-Linux is a kernel level abstraction layer that emulates a VT102 terminal. It consists of two kernel modules: lcd-linux and the display driver. The user simply writes on a character device file and things appear on the display. The idea is that everything related to the low-level driving of the display is a matter of kernel code, not user code. LCD-Linux is a mature project and fully supports up to 7 HD44780 controllers. Drivers for other controllers can be easily written. To compile LCD-Linux you need exactly the kernel sources of your running kernel. You must be able to compile kernel modules. LCD-Linux is available for download at http://lcd-linux.sourceforge.net/. Please use the CVS version. Once the LCD-Linux sources are installed, go into the main directory and type as root make clean install headers_install This will compile and install the two kernel modules and install the headers files lcd-linux.h and hd44780.h into /usr/include/linux The new driver is called lcdlinux and is contained in the two files lcdlinux.[ch]. They must be put in the server/drivers directory. The lcdlinux.diff is a diff file to patch the relevant acinclude.m4 and Makefile.am files. Grab a fresh CVS version of lcdproc and in the main directory type patch -p0 < lcdlinux.diff I hope this will be of some use. I would really appreciate comments and remarks. Thanks! Best, Mattia -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lcdlinux.diff Type: text/x-patch Size: 2433 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lcdlinux.h Type: text/x-chdr Size: 857 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lcdlinux.c Type: text/x-csrc Size: 14431 bytes Desc: not available URL: From sascha.zielinski at gmx.de Mon Apr 13 19:14:48 2009 From: sascha.zielinski at gmx.de (Sascha) Date: Mon, 13 Apr 2009 21:14:48 +0200 Subject: [Lcdproc] CPU Graph only shows a half graph, though all cores are maxed out in SMP CPU screen Message-ID: <200904132114.48538.sascha.zielinski@gmx.de> Hi, Something is wrong with my CPU Graph screen. I started "burnMMX" with "taskset" on all 4 cores. The SMP CPU Graph screen shows the correct ussage, all 4 graph's are at max. In CPU Graph screen I only see, that the graph goes to only the half of what is possible. I can also see 2 Bars, which are going from bottom to top. While normal usage, these two bars end at the middle. I attached Video which may be make some things clearer. http://www.dateiupload.com/files/syNz8bCLOC.ogg Best Regards, Sascha Zielinski From bsdfan at nurfuerspam.de Thu Apr 16 06:49:10 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 16 Apr 2009 08:49:10 +0200 Subject: [Lcdproc] Do you want a release? Message-ID: <49E6D4E6.1040503@nurfuerspam.de> Hello Users, Developers, and Maintainers, I was asked by the admin to raise the question on the list: Do you want a 0.5.3 release? Some of you want it - including myself - but who has the power to decide on this since Peter disappeared? And who will actually make the release? Here are my ideas: * After spending a lot of time with LCDproc the last months I am confident that the code from -HEAD is fine (there are some outstanding fixes which I will commit shortly) * So, the 0.5.3 release will be based on the current -HEAD. * As I expect a last minute rush of requested changes which will not go in stable-0-5-x I would like to make another release (0.5.4) in Q4/2009. * I did have a look at the release process from the other 0.5.x releases and believe to be prepared to make the source distribution of the release, but it will require help from maintainers and driver developers. Regards, Markus From bsdfan at nurfuerspam.de Thu Apr 16 07:01:50 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 16 Apr 2009 09:01:50 +0200 Subject: [Lcdproc] New driver In-Reply-To: <7af880ab0904120646w3f30620dgf851333bea2d2d46@mail.gmail.com> References: <7af880ab0904120646w3f30620dgf851333bea2d2d46@mail.gmail.com> Message-ID: <49E6D7DE.3090707@nurfuerspam.de> Mattia Jona-Lasinio wrote: > > > Hi all, and Happy Easter to everybody. > > I wrote a new lcdproc driver for the lcd-linux kernel driver. > > LCD-Linux is a kernel level abstraction layer that emulates a VT102 > terminal. It consists of two kernel modules: lcd-linux > and the display driver. The user simply writes on a character device file > and things appear on the display. The idea is that everything related > to the low-level driving of the display > is a matter of kernel code, not user code. > LCD-Linux is a mature project and fully supports up to 7 HD44780 > controllers. Drivers for other controllers can be easily written. > To compile LCD-Linux you need exactly the kernel sources of your > running kernel. You must be able to compile kernel modules. > LCD-Linux is available for download at > http://lcd-linux.sourceforge.net/. Please use the CVS version. > Once the LCD-Linux sources are installed, go into the main directory > and type as root > Hello Mattia, thank you for your contribution. Using a kernel driver allows much better timing than possible with a user space application. However, I won't add the driver in it's current state, because: 1. We already do have a HD44780 driver. Your driver should better be a connection type of the hd44780 driver. This duplicates less code than an additional driver. 2. Your code references Linux-only headers unconditionally. The configure script has to check for them and include the driver if they are available. While this is fine for a first test, it has to be changed for the final version. 3. The same goes for the documentation (user guide, man-page). The in-code documentation is already there. Regards, Markus From stefanh at on-luebeck.de Thu Apr 16 07:55:10 2009 From: stefanh at on-luebeck.de (=?ISO-8859-1?Q?Stefan_Hu=DFfeldt?=) Date: Thu, 16 Apr 2009 09:55:10 +0200 Subject: [Lcdproc] Do you want a release? In-Reply-To: <49E6D4E6.1040503@nurfuerspam.de> References: <49E6D4E6.1040503@nurfuerspam.de> Message-ID: <49E6E45E.3070101@on-luebeck.de> Markus Dolze schrieb: > I was asked by the admin to raise the question on the list: Do you want > a 0.5.3 release? I've tried out the current CVS version and it runs fine in my environment: Ubuntu 8.10 amd64, glcdprocdriver-0.0.4, graphlcd-base-0.1.5, T6963C LCD So "yes" from my point of view... From aeriksson2 at fastmail.fm Thu Apr 16 12:06:58 2009 From: aeriksson2 at fastmail.fm (aeriksson2 at fastmail.fm) Date: Thu, 16 Apr 2009 14:06:58 +0200 Subject: [Lcdproc] New driver In-Reply-To: <7af880ab0904120646w3f30620dgf851333bea2d2d46@mail.gmail.com> References: <7af880ab0904120646w3f30620dgf851333bea2d2d46@mail.gmail.com> Message-ID: <20090416120658.66B3393CF18@tippex.mynet.homeunix.org> Hi Mattia, I'm generally in favor of putting hw drivers in the kernel so this project seems like a good thing! But, browsing the project, it appears it lives outside the kernel tree. What are your plans for moving your tree into the kernel tree? Furthermore, (not being a tty expert), how does your /dev/xxx devices differ from the one produced by, say the imon driver from lirc (which I use))? I can already "echo test >/dev/lcd0' and it appears on the display. It would be cool to make it a full tty (whatever that means), so I can e.g. use mplayer's aalib integration and play movies on it :-))) or use it as the main console. /Anders From mattia.jona at gmail.com Thu Apr 16 12:12:17 2009 From: mattia.jona at gmail.com (Mattia Jona-Lasinio) Date: Thu, 16 Apr 2009 14:12:17 +0200 Subject: [Lcdproc] New driver In-Reply-To: <49E6D7DE.3090707@nurfuerspam.de> References: <7af880ab0904120646w3f30620dgf851333bea2d2d46@mail.gmail.com> <49E6D7DE.3090707@nurfuerspam.de> Message-ID: <7af880ab0904160512g11e55dd6h37f8d7fc00a0e350@mail.gmail.com> Hello Markus, The lcdlinux driver is in no way in its final state and still needs improvements but since I'm quite new in lcdproc programming I think I could benefit from suggestions and remarks from the lcdproc community. Concerning your points: > 1. We already do have a HD44780 driver. Your driver should better be > a connection type of the hd44780 driver. This duplicates less code > than an additional driver. Maybe I didn't stress enough this point but the driver I submitted is _not_ a HD44780 driver. It is a general driver for LCD-Linux. LCD-Linux is a kernel-level terminal emulation for LCD displays. This also means that whatever display supported by LCD-Linux is automatically supported by lcdproc through the appropriate driver. Presently the only supported display is the HD44780 but other displays will be eventually supported. Making the lcdlinux driver a connection type would make the lcdlinux driver itself useless because in the end every connection type supported by lcdproc relies on a connection type supported by the kernel (parallel port, usb, ftdi,... etc etc) and can then be implemented as a lcd-linux kernel module. Imagine this scenario: Presently all displays connected via USB need the libusb code. The advantage in using the lcdlinux driver is that all the USB stuff would be handled at kernel level by the appropriate lcd-linux display driver >From the lcdproc point of view the connection type would be just transparent. > 2. Your code references Linux-only headers unconditionally. The > configure script has to check for them and include the driver if > they are available. While this is fine for a first test, it has to > be changed for the final version. > 3. The same goes for the documentation (user guide, man-page). The > in-code documentation is already there. I totally agree with you. It is clear that LCD-Linux is a Linux-related project. Since lcdproc supports operating systems different from Linux, in those cases the lcdlinux driver would simply be excluded from the list of available drivers. Thanks for all your suggestions and improvements! Regards, Mattia On Thu, Apr 16, 2009 at 9:01 AM, Markus Dolze wrote: > > Mattia Jona-Lasinio wrote: >> >> >> Hi all, and Happy Easter to everybody. >> >> I wrote a new lcdproc driver for the lcd-linux kernel driver. >> >> LCD-Linux is a kernel level abstraction layer that emulates a VT102 terminal. It consists of two kernel modules: lcd-linux >> and the display driver. The user simply writes on a character device file >> and things appear on the display. The idea is that everything related to the low-level driving of the display >> is a matter of kernel code, not user code. >> LCD-Linux is a mature project and fully supports up to 7 HD44780 controllers. Drivers for other controllers can be easily written. >> To compile LCD-Linux you need exactly the kernel sources of your running kernel. You must be able to compile kernel modules. >> LCD-Linux is available for download at http://lcd-linux.sourceforge.net/. Please use the CVS version. >> Once the LCD-Linux sources are installed, go into the main directory and type as root >> > Hello Mattia, > > thank you for your contribution. Using a kernel driver allows much better timing than possible with a user space application. > > However, I won't add the driver in it's current state, because: > > ?1. We already do have a HD44780 driver. Your driver should better be > ? ? a connection type of the hd44780 driver. This duplicates less code > ? ? than an additional driver. > ?2. Your code references Linux-only headers unconditionally. The > ? ? configure script has to check for them and include the driver if > ? ? they are available. While this is fine for a first test, it has to > ? ? be changed for the final version. > ?3. The same goes for the documentation (user guide, man-page). The > ? ? in-code documentation is already there. > > Regards, > Markus From mattia.jona at gmail.com Thu Apr 16 12:35:14 2009 From: mattia.jona at gmail.com (Mattia Jona-Lasinio) Date: Thu, 16 Apr 2009 14:35:14 +0200 Subject: [Lcdproc] New driver In-Reply-To: <20090416120658.66B3393CF18@tippex.mynet.homeunix.org> References: <7af880ab0904120646w3f30620dgf851333bea2d2d46@mail.gmail.com> <20090416120658.66B3393CF18@tippex.mynet.homeunix.org> Message-ID: <7af880ab0904160535n2c46725udd61dc334a87b43e@mail.gmail.com> On Thu, Apr 16, 2009 at 2:06 PM, wrote: > > Hi Mattia, > > I'm generally in favor of putting hw drivers in the kernel so this project seems > like a good thing! Thanks! > But, browsing the project, it appears it lives outside the kernel tree. What > are your plans for moving your tree into the kernel tree? I still develop and improve LCD-Linux and before proposing it for inclusion in the kernel tree I would like to better test the implemented features, also to check if I'm not duplicating some kernel code. I would say that in a near future I will propose it for inclusion. > Furthermore, (not being a tty expert), how does your /dev/xxx devices differ > from the one produced by, say the imon driver from lirc (which I use))? That's a VERY GOOD question. In short, my /dev/lcd devices are not ttys because in the end this is not what you want. The Linux tty layer is one of the oldest and least changed part of the Linux kernel, because it works, and it works fine. TTYs are devices where data flow both ways. So the most immediate example are serial devices or the consoles (that in the end emulate a serial terminal console) or, as you said, the lirc devices (which as far as I know are infrared controllers. Am I correct?) A display is not a TTY device, it is more like a display device (obviously :-) ). So as a kernel driver one could imagine something closer to the framebuffer device or the vga device. > I can already "echo test >/dev/lcd0' and it appears on the display. It would > be cool to make it a full tty (whatever that means), so I can e.g. use mplayer's > aalib integration and play movies on it :-))) or use it as the main console. In the LCD-Linux package there is an experimental module called lcdcon that is exactly a display driver for the Linux console layer, allowing you to use a LCD display in exactly the same way as you would with a real display. To compile it type make lcdcon in the main directory. Since LCD-Linux reognises all meaningful escape sequences one could also use the ncurses library on an LCD display. Best, Mattia From TELarson at west.com Thu Apr 16 13:37:02 2009 From: TELarson at west.com (Larson, Timothy E.) Date: Thu, 16 Apr 2009 08:37:02 -0500 Subject: [Lcdproc] Do you want a release? In-Reply-To: <49E6D4E6.1040503@nurfuerspam.de> References: <49E6D4E6.1040503@nurfuerspam.de> Message-ID: <226316B3E1F749498E28ACA66321D5BA0EF57511@oma00cexmbx03.corp.westworlds.com> > I was asked by the admin to raise the question on the list: Do you want > a 0.5.3 release? Very much! > Some of you want it - including myself - but who has the power to decide > on this since Peter disappeared? And who will actually make the release? Good question, since I am fairly new to this, and not the most active follower of development. :) > Here are my ideas: > > * After spending a lot of time with LCDproc the last months I am > confident that the code from -HEAD is fine (there are some > outstanding fixes which I will commit shortly) > * So, the 0.5.3 release will be based on the current -HEAD. > * As I expect a last minute rush of requested changes which will not > go in stable-0-5-x I would like to make another release (0.5.4) in > Q4/2009. > * I did have a look at the release process from the other 0.5.x > releases and believe to be prepared to make the source > distribution of the release, but it will require help from > maintainers and driver developers. As long as it includes some fixes for Solaris, I'm good. :) I presume there will be a release candidate for final testing before 0.5.3 is actually released? I don't know how previous releases were handled. Tim -- Tim Larson??????? AMT2 Unix Systems Administrator ??? InterCall, a division of West Corporation Be always sure you are right, then go ahead. - David Crockett From nombrandue at tsukinokage.net Thu Apr 16 14:31:55 2009 From: nombrandue at tsukinokage.net (Seann Clark) Date: Thu, 16 Apr 2009 09:31:55 -0500 Subject: [Lcdproc] Do you want a release? In-Reply-To: <226316B3E1F749498E28ACA66321D5BA0EF57511@oma00cexmbx03.corp.westworlds.com> References: <49E6D4E6.1040503@nurfuerspam.de> <226316B3E1F749498E28ACA66321D5BA0EF57511@oma00cexmbx03.corp.westworlds.com> Message-ID: <49E7415B.4030602@tsukinokage.net> Larson, Timothy E. wrote: >> I was asked by the admin to raise the question on the list: Do you want >> a 0.5.3 release? >> > > Very much! > > >> Some of you want it - including myself - but who has the power to decide >> on this since Peter disappeared? And who will actually make the release? >> > > Good question, since I am fairly new to this, and not the most active follower of development. :) > > >> Here are my ideas: >> >> * After spending a lot of time with LCDproc the last months I am >> confident that the code from -HEAD is fine (there are some >> outstanding fixes which I will commit shortly) >> * So, the 0.5.3 release will be based on the current -HEAD. >> * As I expect a last minute rush of requested changes which will not >> go in stable-0-5-x I would like to make another release (0.5.4) in >> Q4/2009. >> * I did have a look at the release process from the other 0.5.x >> releases and believe to be prepared to make the source >> distribution of the release, but it will require help from >> maintainers and driver developers. >> > > As long as it includes some fixes for Solaris, I'm good. :) I presume there will be a release candidate for final testing before 0.5.3 is actually released? I don't know how previous releases were handled. > > Tim > I agree with needing at least an RC out for a new version, but as with the rest of the list, I don't know who would make that call. I haven't been as active on this lately due to not having a working display to continue to work on applications for it (My nice matrix orbital in my dev server doesn't play well with the software currently). Having a new release out would also help clarify all that has been done since the previous version, since I have seen many driver changes and platform changes since I joined the list over a year ago, I think having an update that isn't just on the SVN would help out a lot of the newer people as well. ~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 rw at nelianur.org Thu Apr 16 23:10:36 2009 From: rw at nelianur.org (Rene Wagner) Date: Fri, 17 Apr 2009 01:10:36 +0200 Subject: [Lcdproc] Do you want a release? In-Reply-To: <49E6D4E6.1040503@nurfuerspam.de> References: <49E6D4E6.1040503@nurfuerspam.de> Message-ID: <1239923436.9225.129.camel@antarctica.nelianur.org> Hi all, On Thu, 2009-04-16 at 08:49 +0200, Markus Dolze wrote: > I was asked by the admin to raise the question on the list: Do you want > a 0.5.3 release? Since that admin was me I guess I should clarify this a bit. I believe it's only normal for an open source project to roll out releases from time to time. With LCDproc the policy with regard to timing has always been "when it's done", where "done" has usually been "to the best of our knowledge the current code base shouldn't have any major issues". The question now is (a) whether it's "done" or whether more work is needed to get there and (b) who is going to do the "release engineering" to make a release happen. The answer to (a) requires more knowledge of the current code base than I have at the moment. I'd say this is up for discussion on the mailing list. I see a few initial reactions are largely positive. As for (b), I asked Markus to move the discussion to the public list to give more people a chance to get involved and to keep the decision process transparent. > Some of you want it - including myself - but who has the power to decide > on this since Peter disappeared? And who will actually make the release? It's clear that we need volunteers to coordinate the release process, actually get the code base into a release-quality state (if that isn't the case already), and finally upload and announce the release. The latter tasks require additional permissions on Sourceforge. Whoever steps up to take care of those, I will make sure to sort you out with those permissions. Announcements on the lcdproc.org website require access to a separate CVS. I cannot grant that access myself but I'll ask Gareth to do so if the need arises. Markus mentioned in private mail that it might be helpful to have someone in charge of coordinating the release. I support the idea but would like to stress that this "release manager" will need as much support from fellow developers and users as possible. > * I did have a look at the release process from the other 0.5.x > releases and believe to be prepared to make the source > distribution of the release, but it will require help from > maintainers and driver developers. Does that mean we have a volunteer for the "release manager" job? ;) Cheers, Rene From bsdfan at nurfuerspam.de Mon Apr 20 07:19:42 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Mon, 20 Apr 2009 09:19:42 +0200 Subject: [Lcdproc] preliminary Solaris patch for review In-Reply-To: <226316B3E1F749498E28ACA66321D5BA0EF5746A@oma00cexmbx03.corp.westworlds.com> References: <226316B3E1F749498E28ACA66321D5BA0EF5746A@oma00cexmbx03.corp.westworlds.com> Message-ID: <49EC220E.1050106@nurfuerspam.de> Hi Tim, yesterday I had the chance to look at your patch. Find my comments below. Larson, Timothy E. wrote: > With the following patch, and --enable-drivers=all,!mtc_s16209x, I got > today's current branch to compile. This may not be the right or best way to > do it, I'm just offering this as a starting point. > > > tim at marcie 126$ diff -ur current current-hacked > diff -ur current/configure.in current-hacked/configure.in > --- current/configure.in Tue Mar 24 11:04:06 2009 > +++ current-hacked/configure.in Tue Mar 24 11:20:16 2009 > @@ -164,7 +164,7 @@ > AC_HEADER_DIRENT > AC_HEADER_STDC > AC_CHECK_HEADERS(fcntl.h sys/ioctl.h sys/time.h unistd.h sys/io.h errno.h) > -AC_CHECK_HEADERS(limits.h kvm.h sys/param.h sys/dkstat.h) > +AC_CHECK_HEADERS(limits.h kvm.h sys/param.h sys/dkstat.h getopt.h) > > dnl check sys/sysctl.h seperately, as it requires other headers on at least > OpenBSD > AC_CHECK_HEADERS([sys/sysctl.h], [], [], > diff -ur current/clients/lcdexec/lcdexec.c > current-hacked/clients/lcdexec/lcdexec.c > --- current/clients/lcdexec/lcdexec.c Tue Mar 24 11:04:06 2009 > +++ current-hacked/clients/lcdexec/lcdexec.c Tue Mar 24 11:23:49 2009 > @@ -20,7 +20,9 @@ > #include > #include > > +#ifdef HAVE_GETOPT_H > #include "getopt.h" > +#endif > > #include "shared/str.h" > #include "shared/report.h" > This turned out to be a very complicated thing. But first: Using #ifdef will not work if config.h is not included before the #ifdef. This is the case for lcdvc, lcdexec (do not include config.h at all), and lcdproc (includes getopt.h before config.h). Therefore the patch will work as intended. Only server/main includes them and in the correct order. But anyway, the programs include "getopt.h", not - so it should not be your system's getopt.h. This is because LCDproc does have its own getopt implementation, which is not used by default. But I wonder if that really works, or if "shared/getopt.h" needs to be included. More interestingly configure does not check for 'getopt()', but 'getopt_long()' which is used nowhere (see configure.in, line 191). AFAIK 'getopt()' is part specified by posix, but 'getopt_long()' is an extension. On FreeBSD i.e. it is sufficient to include 'unistd.h' to be able to use 'getopt()'. Did compiling failed on Solaris with an error regarding 'getopt()'? After reading the Sun documentation I'm not sure if Solaris 9 has getopt_long(), thus resulting in LCDprocs own getopt() implementation to be used which may not work. In the end it might be sufficient to replace the 'AC_CHECK_FUNC(getopt_long)' with 'AC_CHECK_FUNC(getopt)'. > diff -ur current/server/drivers/hd44780-ethlcd.c > current-hacked/server/drivers/hd44780-ethlcd.c > --- current/server/drivers/hd44780-ethlcd.c Tue Mar 24 11:04:07 2009 > +++ current-hacked/server/drivers/hd44780-ethlcd.c Tue Mar 24 11:57:02 > 2009 > @@ -26,7 +26,11 @@ > #include > #include > > +#ifndef _POSIX_HOST_NAME_MAX > +#define _POSIX_HOST_NAME_MAX 255 > +#endif > > + > void ethlcd_HD44780_senddata(PrivateData *p, unsigned char displayID, > unsigned char flags, unsigned char ch); > unsigned char ethlcd_HD44780_scankeypad(PrivateData *p); > void ethlcd_HD44780_backlight(PrivateData *p, unsigned char state); > Using _POSIX_HOST_NAME_MAX was a change I did myself, because the HOST_NAME_MAX used before was not available on FreeBSD. Today I'm wondering if I used it on purpose or if I confused gethostname() with gethostbyname(). The former does specify _POSIX_HOST_NAME_MAX as the maximum returned length, but for the latter I wasn't able to find a documented limit. I will try to find out what the limit is, maybe we do not have to use _POSIX_HOST_NAME_MAX. _POSIX_HOST_NAME_MAX is defined for Solaris 10, but not for former releases according to Sun's documentation. > diff -ur current/server/drivers/irtrans.c > current-hacked/server/drivers/irtrans.c > --- current/server/drivers/irtrans.c Tue Mar 24 11:04:07 2009 > +++ current-hacked/server/drivers/irtrans.c Tue Mar 24 12:00:22 2009 > @@ -53,7 +53,11 @@ > #include "report.h" > //#include "drv_base.h" > > +#ifndef INADDR_NONE > +#define INADDR_NONE ((unsigned long) -1) > +#endif > > + > // Variables > // TODO init > This is a necessary patch up to Solaris 9. Regards, Markus From TELarson at west.com Mon Apr 20 14:32:53 2009 From: TELarson at west.com (Larson, Timothy E.) Date: Mon, 20 Apr 2009 09:32:53 -0500 Subject: [Lcdproc] preliminary Solaris patch for review In-Reply-To: <49EC220E.1050106@nurfuerspam.de> References: <226316B3E1F749498E28ACA66321D5BA0EF5746A@oma00cexmbx03.corp.westworlds.com> <49EC220E.1050106@nurfuerspam.de> Message-ID: <226316B3E1F749498E28ACA66321D5BA14CBE77F@oma00cexmbx03.corp.westworlds.com> > yesterday I had the chance to look at your patch. Find my comments below. (clients/lcdexec/lcdexec.c) > This turned out to be a very complicated thing. > > But first: Using #ifdef will not work if config.h is not included before > the #ifdef. This is the case for lcdvc, lcdexec (do not include config.h > at all), and lcdproc (includes getopt.h before config.h). Therefore the > patch will work as intended. Only server/main includes them and in the > correct order. > > But anyway, the programs include "getopt.h", not - so it > should not be your system's getopt.h. This is because LCDproc does have > its own getopt implementation, which is not used by default. But I > wonder if that really works, or if "shared/getopt.h" needs to be included. > > More interestingly configure does not check for 'getopt()', but > 'getopt_long()' which is used nowhere (see configure.in, line 191). > > AFAIK 'getopt()' is part specified by posix, but 'getopt_long()' is an > extension. On FreeBSD i.e. it is sufficient to include 'unistd.h' to be > able to use 'getopt()'. > > Did compiling failed on Solaris with an error regarding 'getopt()'? > After reading the Sun documentation I'm not sure if Solaris 9 has > getopt_long(), thus resulting in LCDprocs own getopt() implementation to > be used which may not work. lcdexec.c:23:20: error: getopt.h: No such file or directory Since I did not find a "getopt.h" in the local dir, I assumed there used to be one which had been removed, and the include fell back to search the standard paths for it. I didn't even look in shared. If this is meant to pick up that one, it should be "shared/getopt.h" right? I could try going that route instead, and see if it works. Very strange to me that others are getting this to build. FWIW, my system declares getopt in stdio.h, stdlib.h, and unistd.h. > In the end it might be sufficient to replace the > 'AC_CHECK_FUNC(getopt_long)' with 'AC_CHECK_FUNC(getopt)'. Checking for getopt() and conditionally including the local declaration based on that, rather than existence of getopt.h, makes sense. (server/drivers/hd44780-ethlcd.c) > Using _POSIX_HOST_NAME_MAX was a change I did myself, because the > HOST_NAME_MAX used before was not available on FreeBSD. > > Today I'm wondering if I used it on purpose or if I confused > gethostname() with gethostbyname(). The former does specify > _POSIX_HOST_NAME_MAX as the maximum returned length, but for the latter > I wasn't able to find a documented limit. I will try to find out what > the limit is, maybe we do not have to use _POSIX_HOST_NAME_MAX. > > _POSIX_HOST_NAME_MAX is defined for Solaris 10, but not for former > releases according to Sun's documentation. Right, I'm currently using Solaris 9. This definition ought to be okay AFAICT, as it's conditional. (server/drivers/irtrans.c) > This is a necessary patch up to Solaris 9. Tim -- Tim Larson??????? AMT2 Unix Systems Administrator ??? InterCall, a division of West Corporation Be always sure you are right, then go ahead. - David Crockett From fblack947 at yahoo.com Mon Apr 20 15:43:31 2009 From: fblack947 at yahoo.com (jk) Date: Mon, 20 Apr 2009 08:43:31 -0700 (PDT) Subject: [Lcdproc] imonlcd driver Message-ID: <220428.36441.qm@web37504.mail.mud.yahoo.com> Attached in a following e-mail is a patch to the current CVS which provides support for the Soundgraph iMon LCD devices. (A second e-mail is required due to the rather small limit on the total size of messages to this list). Can this be added to the CVS tree? Addressing previous concerns, this patch adds documentation and improves the stability to the original (v0.3) patch from codeka, as well as adding support for the slightly newer 15c2:0038 version. You should see no compile-time warnings from this patch :} The patch has been tested in Ubuntu 8.10 (Intrepid) with the 15c2:ffdc and 15c2:0038 displays. The 15c2:0038 display may require lirc v0.8.5 (when it is released) or a patched v0.8.4a. I don't own this device, and the people who have tested out this patch don't yet have a consensus on exactly which lirc configuration works for the 15c2:0038 device. -Jonathan From fblack947 at yahoo.com Mon Apr 20 15:48:47 2009 From: fblack947 at yahoo.com (jk) Date: Mon, 20 Apr 2009 08:48:47 -0700 (PDT) Subject: [Lcdproc] imonlcd driver Message-ID: <4581.1607.qm@web37506.mail.mud.yahoo.com> The list keeps bouncing my patch which provides support for the Soundgraph iMON LCD devices. It's available on sourceforge: https://sourceforge.net/tracker/download.php?group_id=119&atid=300119&file_id=323665&aid=2690871 Details are in my previous e-mail. -Jonathan From rfc822sucks at hotmail.com Wed Apr 22 20:48:15 2009 From: rfc822sucks at hotmail.com (nobody important) Date: Wed, 22 Apr 2009 14:48:15 -0600 Subject: [Lcdproc] Problems with checkbox Message-ID: Hi, I am putting together some scripts for an embedded device. They communicate via the telnet interface (using IO.Socket in ruby) One checkbox is for WAN using DHCP the other is for LAN using DHCP. This is the initial menu I upload to LCDd via telnet. client_set name "Fuzzy" menu_add_item "" ask menu "Write changes?" -is_hidden true menu_add_item "ask" ask_yes action "Yes" -next _quit_ menu_add_item "ask" ask_no action "No" -next _close_ menu_add_item "" test menu "Embedded Config" menu_add_item "test" test_wancheckbox checkbox "INET uses DHCP" -value off menu_add_item "test" test_ip1 ip "INET IP" -v6 false -value "192.168.1.1" menu_add_item "test" test_nm1 ip "INET Netmask" -v6 false -value "255.255.255.0" menu_add_item "test" test_gw ip "Default Gateway" -v6 false -value "192.168.1.254" menu_add_item "test" test_lancheckbox checkbox "LAN uses DHCP" -value off menu_add_item "test" test_ip2 ip "LAN IP" -v6 false -value "192.168.1.1" menu_add_item "test" test_nm2 ip "LAN Netmask" -v6 false -value "255.255.255.0" menu_set_item "" test -prev ask menu_set_main "" menu_goto "" What happens is that the LAN checkbox doesn't show the icon, even though otherwise it functions as expected. This is with 0.5.2 as well as CVS-stable-0-5-x-20090422 A simple loop in ruby reads this in from textfile and writes it to the socket. File.open("/usr/local/lcd/menu.widget", "r") do |infile| while (line = infile.gets) next if line =~ /^\s*#/ s.puts "#{line}" # puts (s.gets) counter += 1 end end I am at a bit of a loss as to what is happening. A second thing I noticed is when I have a very busy telnet session (drawing VU meters with telnet) after indefinate lengths of time (from 10 min to 45 minutes) the LCDd would not accept anymore commands, not log to screen (level 5) and end up essentially hung. This was with 0.52 I am trying in CVS-stable-0-5-x-20090422 now. I hadn't had it compiled debug, but if you like i can compile debug and send it SIGSEGV and bt the core. Thanks, Doug _________________________________________________________________ Reinvent how you stay in touch with the new Windows Live Messenger. http://go.microsoft.com/?linkid=9650731 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleza66 at gmail.com Thu Apr 23 13:45:17 2009 From: aleza66 at gmail.com (Alejandro Zan) Date: Thu, 23 Apr 2009 10:45:17 -0300 Subject: [Lcdproc] Doubt on wiring Message-ID: I a bit lost, i want to use my HD4478016x2 with my parallel port. will this wiring work, http://www.overclockers.com.au/techstuff/a_diy_lcd/?? I dont want to use a keypad. Just the lcd to get temperature, swap disk memory usage, things like that. I doest uses a shift register. I wanted to know if i can use a direct wiring to my parallel port. Thanks! alek -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsdfan at nurfuerspam.de Thu Apr 23 17:47:55 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 23 Apr 2009 19:47:55 +0200 Subject: [Lcdproc] Doubt on wiring In-Reply-To: References: Message-ID: <49F0A9CB.60403@nurfuerspam.de> Alejandro Zan wrote: > > I a bit lost, i want to use my HD44780 > 16x2 with my parallel port. > will this wiring work, > http://www.overclockers.com.au/techstuff/a_diy_lcd/?? > I dont want to use a keypad. Just the lcd to get temperature, swap > disk memory usage, things like that. > I doest uses a shift register. > > I wanted to know if i can use a direct wiring to my parallel port. > > Thanks! > > > alek Hi Alejandro, this is what we call the 'winamp connection type' of the HD44780 driver. See http://lcdproc.sourceforge.net/docs/current-user.html#hd44780-8bit-winamp for more info. Regards, Markus From bsdfan at nurfuerspam.de Thu Apr 23 17:51:47 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Thu, 23 Apr 2009 19:51:47 +0200 Subject: [Lcdproc] preliminary Solaris patch for review In-Reply-To: <226316B3E1F749498E28ACA66321D5BA14CBE77F@oma00cexmbx03.corp.westworlds.com> References: <226316B3E1F749498E28ACA66321D5BA0EF5746A@oma00cexmbx03.corp.westworlds.com> <49EC220E.1050106@nurfuerspam.de> <226316B3E1F749498E28ACA66321D5BA14CBE77F@oma00cexmbx03.corp.westworlds.com> Message-ID: <49F0AAB3.7070906@nurfuerspam.de> Larson, Timothy E. wrote: >> yesterday I had the chance to look at your patch. Find my comments below. > > (clients/lcdexec/lcdexec.c) >> >> But anyway, the programs include "getopt.h", not - so it >> should not be your system's getopt.h. This is because LCDproc does have >> its own getopt implementation, which is not used by default. But I >> wonder if that really works, or if "shared/getopt.h" needs to be included. >> >> More interestingly configure does not check for 'getopt()', but >> 'getopt_long()' which is used nowhere (see configure.in, line 191). >> >> AFAIK 'getopt()' is part specified by posix, but 'getopt_long()' is an >> extension. On FreeBSD i.e. it is sufficient to include 'unistd.h' to be >> able to use 'getopt()'. >> >> Did compiling failed on Solaris with an error regarding 'getopt()'? >> After reading the Sun documentation I'm not sure if Solaris 9 has >> getopt_long(), thus resulting in LCDprocs own getopt() implementation to >> be used which may not work. > > lcdexec.c:23:20: error: getopt.h: No such file or directory > > Since I did not find a "getopt.h" in the local dir, I assumed there used to be one which had been removed, and the include fell back to search the standard paths for it. I didn't even look in shared. If this is meant to pick up that one, it should be "shared/getopt.h" right? I could try going that route instead, and see if it works. > > Very strange to me that others are getting this to build. FWIW, my system declares getopt in stdio.h, stdlib.h, and unistd.h. > >> In the end it might be sufficient to replace the >> 'AC_CHECK_FUNC(getopt_long)' with 'AC_CHECK_FUNC(getopt)'. > > Checking for getopt() and conditionally including the local declaration based on that, rather than existence of getopt.h, makes sense. > Hi, does the server compile if you run 'make server' from the top level directory (with your driver patches)? The server core files do include '(top_srcdir)/shared' in the header search path. Regards, Markus From aleza66 at gmail.com Thu Apr 23 17:52:44 2009 From: aleza66 at gmail.com (Alejandro Zanotti) Date: Thu, 23 Apr 2009 14:52:44 -0300 Subject: [Lcdproc] Doubt on wiring In-Reply-To: <49F0A9CB.60403@nurfuerspam.de> References: <49F0A9CB.60403@nurfuerspam.de> Message-ID: <2AD05777-0DBD-422E-BF8F-4F9CA2ABA830@gmail.com> Markus: Thanks a lot, i got confused, I thought if I make a winamp connection, i will only work with winamp. Winamp wiring will work for my needs? Thanks a lot 4 your reply. On Apr 23, 2009, at 2:47 PM, Markus Dolze wrote: > Alejandro Zan wrote: >> >> I a bit lost, i want to use my HD44780 > > 16x2 with my parallel port. will this wiring work, http://www.overclockers.com.au/techstuff/a_diy_lcd/? >> ? >> I dont want to use a keypad. Just the lcd to get temperature, swap >> disk memory usage, things like that. >> I doest uses a shift register. >> >> I wanted to know if i can use a direct wiring to my parallel port. >> >> Thanks! >> >> >> alek > > Hi Alejandro, > > this is what we call the 'winamp connection type' of the HD44780 > driver. See http://lcdproc.sourceforge.net/docs/current-user.html#hd44780-8bit-winamp > for more info. > > Regards, > Markus From ehrnam45 at gmail.com Fri Apr 24 18:37:53 2009 From: ehrnam45 at gmail.com (Samuel Rogers) Date: Fri, 24 Apr 2009 14:37:53 -0400 Subject: [Lcdproc] Send Keysims from client to kernel? Message-ID: I haven't been able to find an exact answer for the problem I'm having, so I thought I'd post up here and see what the experts think. I'm trying to get the matrix keypad buttons on my MtxOrb VK202-24-USB to be usable by programs other than the clients themselves, namely MythTV and other media-related programs. The keypresses show up in the syslog as Apr 24 10:20:40 BigNasty LCDd: MtxOrb: get_key: key 0x47 Apr 24 10:20:41 BigNasty LCDd: MtxOrb: get_key: key 0x44 Which is correctly mapped to the button letters' ASCII value. Setting the buttons in LCDd.conf only seems to work for LCDproc menu commands (up, down, enter, etc.). Setting the buttons to a letter or other keysym doesn't throw any errors, but also doesn't generate any discernible output either. I've trimmed down my LCDd.conf to only show the relevant info: ... ## The menu section. The menu is an internal LCDproc client. ## [menu] # You can configure what keys the menu should use. Note that the MenuKey # will be reserved exclusively, the others work in shared mode. # The following works excellent with 4 keys or more. MenuKey=Escape EnterKey=Enter #UpKey=Up #DownKey=Down # If you have 6 keys you may define these as well #LeftKey=Left #RightKey=Right ### Driver sections are below this line, in alphabetical order ## ## Matrix Orbital driver ## [MtxOrb] # Select the output device to use [default: /dev/lcd] Device=/dev/ttyUSB0 # Set the display size [default: 20x4] Size=20x2 # Set the display type [default: lcd; legal: lcd, lkd, vfd, vkd] Type=vkd # Set the initial contrast [default: 480] # NOTE: The driver will ignore this if the display # is a vfd or vkd as they don't have this feature Contrast=480 # Set the initial brightness [default: 1000; legal: 0 - 1000] Brightness=1000 # Set the initial off-brightness [default: 0; legal: 0 - 1000] # This value is used when the display is normally # switched off in case LCDd is inactive OffBrightness=0 # Set the communication speed [default: 19200; legal: 1200, 2400, 9600, 19200] Speed=19200 # The following table translates from MtxOrb key letters to logical key names. # By default no keys are mapped, meaning the keypad is not used at all. KeyMap_A=Home KeyMap_B=PgUp KeyMap_C=O KeyMap_D=P KeyMap_G=PgDn KeyMap_H=End KeyMap_I=F9 KeyMap_J=Enter KeyMap_Q=Escape # See the [menu] section for an explanation of the key mappings # You can find out which key of your display sends which... keypad_test_mode=no # EOF I've looked through the source code for mythlcdserver and only found what looked to be a way to hard-code new mappings for those buttons, but I would rather make them accessible to the system instead so that they can be seen by other programs. One suggestion I was given was to use LIRC to grab the keypresses. I can see how it would make interacting with the different apps a much more flexible endeavor, but I would either have to write a driver for LIRC to be able to see those keypresses, or make a client for LCDproc that hooks them and uses Xlib(?) to push the keysyms to the input layer or possibly just to LIRC as a 'new' remote. I have a small ammount of programming experience (mostly web scripts and whatnot) and would love to be able to tackle this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsdfan at nurfuerspam.de Sun Apr 26 16:06:39 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sun, 26 Apr 2009 18:06:39 +0200 Subject: [Lcdproc] Send Keysims from client to kernel? In-Reply-To: References: Message-ID: <20090426160639.137510@gmx.net> -------- Original-Nachricht -------- > Datum: Fri, 24 Apr 2009 14:37:53 -0400 > Von: Samuel Rogers > An: lcdproc at lists.omnipotent.net > Betreff: [Lcdproc] Send Keysims from client to kernel? > I haven't been able to find an exact answer for the problem I'm having, so > I > thought I'd post up here and see what the experts think. > > I'm trying to get the matrix keypad buttons on my MtxOrb VK202-24-USB to > be > usable by programs other than the clients themselves, namely MythTV and > other media-related programs. The keypresses show up in the syslog as > > Apr 24 10:20:40 BigNasty LCDd: MtxOrb: get_key: key 0x47 > Apr 24 10:20:41 BigNasty LCDd: MtxOrb: get_key: key 0x44 > > Which is correctly mapped to the button letters' ASCII value. Setting the > buttons in LCDd.conf only seems to work for LCDproc menu commands (up, > down, > enter, etc.). Setting the buttons to a letter or other keysym doesn't > throw > any errors, but also doesn't generate any discernible output either. I've > trimmed down my LCDd.conf to only show the relevant info: > > ... > Hi Samuel, LCDproc does not generate key events like your keyboard. Whenever you press a directly connected key or a key on a matrix keyboard, LCDd sends the client a string telling it which key was pressed. This string is what you define with 'KeyMatrix_X_Y' or 'DirectKey_X' in LCDd.conf. If you put nothing in the config, it depends on the driver which string it creates by default, and if you put e.g. 'KeyMatrix_1_1=PgUp' in the config, the client will receive the message 'key PgUp' and has to take the appropriate action. Thus, if your client doesn't map a lcdproc key event to one of its functions there is nothing you can do about this without rewriting the clients. Sorry. Regards, Markus From bsdfan at nurfuerspam.de Sun Apr 26 16:20:51 2009 From: bsdfan at nurfuerspam.de (Markus Dolze) Date: Sun, 26 Apr 2009 18:20:51 +0200 Subject: [Lcdproc] Send Keysims from client to kernel? In-Reply-To: <20090426160639.137510@gmx.net> References: <20090426160639.137510@gmx.net> Message-ID: <20090426162051.137490@gmx.net> -------- Original-Nachricht -------- > Datum: Sun, 26 Apr 2009 18:06:39 +0200 > Von: "Markus Dolze" > An: Samuel Rogers , lcdproc at lists.omnipotent.net > Betreff: Re: [Lcdproc] Send Keysims from client to kernel? > > -------- Original-Nachricht -------- > > Datum: Fri, 24 Apr 2009 14:37:53 -0400 > > Von: Samuel Rogers > > An: lcdproc at lists.omnipotent.net > > Betreff: [Lcdproc] Send Keysims from client to kernel? > > > I haven't been able to find an exact answer for the problem I'm having, > so > > I > > thought I'd post up here and see what the experts think. > > > > I'm trying to get the matrix keypad buttons on my MtxOrb VK202-24-USB to > > be > > usable by programs other than the clients themselves, namely MythTV and > > other media-related programs. The keypresses show up in the syslog as > > > > Apr 24 10:20:40 BigNasty LCDd: MtxOrb: get_key: key 0x47 > > Apr 24 10:20:41 BigNasty LCDd: MtxOrb: get_key: key 0x44 > > > > Which is correctly mapped to the button letters' ASCII value. Setting > the > > buttons in LCDd.conf only seems to work for LCDproc menu commands (up, > > down, > > enter, etc.). Setting the buttons to a letter or other keysym doesn't > > throw > > any errors, but also doesn't generate any discernible output either. > I've > > trimmed down my LCDd.conf to only show the relevant info: > > > > ... > > > > Hi Samuel, > > LCDproc does not generate key events like your keyboard. Whenever you > press a directly connected key or a key on a matrix keyboard, LCDd sends the > client a string telling it which key was pressed. > > This string is what you define with 'KeyMatrix_X_Y' or 'DirectKey_X' in > LCDd.conf. If you put nothing in the config, it depends on the driver which > string it creates by default, and if you put e.g. 'KeyMatrix_1_1=PgUp' in > the config, the client will receive the message 'key PgUp' and has to take > the appropriate action. For the Matrix Orbital driver the above is true, but the key mapping option is named 'KeyMap_...'. I was looking at the hd44780 driver. > > Thus, if your client doesn't map a lcdproc key event to one of its > functions there is nothing you can do about this without rewriting the clients. > Sorry. > > Regards, > Markus From TELarson at west.com Mon Apr 27 20:27:28 2009 From: TELarson at west.com (Larson, Timothy E.) Date: Mon, 27 Apr 2009 15:27:28 -0500 Subject: [Lcdproc] preliminary Solaris patch for review In-Reply-To: <49F0AAB3.7070906@nurfuerspam.de> References: <226316B3E1F749498E28ACA66321D5BA0EF5746A@oma00cexmbx03.corp.westworlds.com> <49EC220E.1050106@nurfuerspam.de> <226316B3E1F749498E28ACA66321D5BA14CBE77F@oma00cexmbx03.corp.westworlds.com> <49F0AAB3.7070906@nurfuerspam.de> Message-ID: <226316B3E1F749498E28ACA66321D5BA14CBE7CE@oma00cexmbx03.corp.westworlds.com> > does the server compile if you run 'make server' from the top level > directory (with your driver patches)? The server core files do include > '(top_srcdir)/shared' in the header search path. Yes. Here is the output. SunOS 5.9 lcdproc/current-hacked tim at marcie 17$ gmake server gmake -C shared gmake[1]: Entering directory `/export/home/tim/dev/lcdproc/current-hacked/shared' gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wall -O3 -Wno-unused-function -MT LL.o -MD -MP -MF .deps/LL.Tpo -c -o LL.o LL.c mv -f .deps/LL.Tpo .deps/LL.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wall -O3 -Wno-unused-function -MT sockets.o -MD -MP -MF .deps/sockets.Tpo -c -o sockets.o sockets.c mv -f .deps/sockets.Tpo .deps/sockets.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wall -O3 -Wno-unused-function -MT str.o -MD -MP -MF .deps/str.Tpo -c -o str.o str.c mv -f .deps/str.Tpo .deps/str.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wall -O3 -Wno-unused-function -MT configfile.o -MD -MP -MF .deps/configfile.Tpo -c -o configfile.o configfile.c mv -f .deps/configfile.Tpo .deps/configfile.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wall -O3 -Wno-unused-function -MT report.o -MD -MP -MF .deps/report.Tpo -c -o report.o report.c mv -f .deps/report.Tpo .deps/report.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Wall -O3 -Wno-unused-function -MT snprintf.o -MD -MP -MF .deps/snprintf.Tpo -c -o snprintf.o snprintf.c mv -f .deps/snprintf.Tpo .deps/snprintf.Po rm -f libLCDstuff.a ar cru libLCDstuff.a LL.o sockets.o str.o configfile.o report.o snprintf.o ranlib libLCDstuff.a gmake[1]: Leaving directory `/export/home/tim/dev/lcdproc/current-hacked/shared' gmake -C server gmake[1]: Entering directory `/export/home/tim/dev/lcdproc/current-hacked/server' Making all in drivers gmake[2]: Entering directory `/export/home/tim/dev/lcdproc/current-hacked/server/drivers' gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -fPIC -Wall -O3 -Wno-unused-function -MT lcd_lib.o -MD -MP -MF .deps/lcd_lib.Tpo -c -o lcd_lib.o lcd_lib.c mv -f .deps/lcd_lib.Tpo .deps/lcd_lib.Po rm -f libLCD.a ar cru libLCD.a lcd_lib.o ranlib libLCD.a gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -fPIC -Wall -O3 -Wno-unused-function -MT adv_bignum.o -MD -MP -MF .deps/adv_bignum.Tpo -c -o adv_bignum.o adv_bignum.c mv -f .deps/adv_bignum.Tpo .deps/adv_bignum.Po rm -f libbignum.a ar cru libbignum.a adv_bignum.o ranlib libbignum.a gmake[2]: Leaving directory `/export/home/tim/dev/lcdproc/current-hacked/server/drivers' Making all in commands gmake[2]: Entering directory `/export/home/tim/dev/lcdproc/current-hacked/server/commands' gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I./.. -Wall -O3 -Wno-unused-function -MT command_list.o -MD -MP -MF .deps/command_list.Tpo -c -o command_list.o command_list.c mv -f .deps/command_list.Tpo .deps/command_list.Po gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I./.. -Wall -O3 -Wno-unused-function -MT client_commands.o -MD -MP -MF .deps/client_commands.Tpo -c -o client_commands.o client_commands.c mv -f .deps/client_commands.Tpo .deps/client_commands.Po gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I./.. -Wall -O3 -Wno-unused-function -MT menu_commands.o -MD -MP -MF .deps/menu_commands.Tpo -c -o menu_commands.o menu_commands.c mv -f .deps/menu_commands.Tpo .deps/menu_commands.Po gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I./.. -Wall -O3 -Wno-unused-function -MT screen_commands.o -MD -MP -MF .deps/screen_commands.Tpo -c -o screen_commands.o screen_commands.c mv -f .deps/screen_commands.Tpo .deps/screen_commands.Po gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I./.. -Wall -O3 -Wno-unused-function -MT server_commands.o -MD -MP -MF .deps/server_commands.Tpo -c -o server_commands.o server_commands.c mv -f .deps/server_commands.Tpo .deps/server_commands.Po gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I./.. -Wall -O3 -Wno-unused-function -MT widget_commands.o -MD -MP -MF .deps/widget_commands.Tpo -c -o widget_commands.o widget_commands.c mv -f .deps/widget_commands.Tpo .deps/widget_commands.Po rm -f libLCDcommands.a ar cru libLCDcommands.a command_list.o client_commands.o menu_commands.o screen_commands.o server_commands.o widget_commands.o ranlib libLCDcommands.a gmake[2]: Leaving directory `/export/home/tim/dev/lcdproc/current-hacked/server/commands' gmake[2]: Entering directory `/export/home/tim/dev/lcdproc/current-hacked/server' gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT client.o -MD -MP -MF .deps/client.Tpo -c -o client.o client.c mv -f .deps/client.Tpo .deps/client.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT clients.o -MD -MP -MF .deps/clients.Tpo -c -o clients.o clients.c mv -f .deps/clients.Tpo .deps/clients.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT input.o -MD -MP -MF .deps/input.Tpo -c -o input.o input.c mv -f .deps/input.Tpo .deps/input.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c mv -f .deps/main.Tpo .deps/main.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT menuitem.o -MD -MP -MF .deps/menuitem.Tpo -c -o menuitem.o menuitem.c menuitem.c: In function ?menuitem_process_input_numeric?: menuitem.c:1171: warning: array subscript has type ?char? menuitem.c: In function ?menuitem_process_input_ip?: menuitem.c:1448: warning: array subscript has type ?char? menuitem.c:1448: warning: array subscript has type ?char? mv -f .deps/menuitem.Tpo .deps/menuitem.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT menu.o -MD -MP -MF .deps/menu.Tpo -c -o menu.o menu.c mv -f .deps/menu.Tpo .deps/menu.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT menuscreens.o -MD -MP -MF .deps/menuscreens.Tpo -c -o menuscreens.o menuscreens.c mv -f .deps/menuscreens.Tpo .deps/menuscreens.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT parse.o -MD -MP -MF .deps/parse.Tpo -c -o parse.o parse.c mv -f .deps/parse.Tpo .deps/parse.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT render.o -MD -MP -MF .deps/render.Tpo -c -o render.o render.c mv -f .deps/render.Tpo .deps/render.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT screen.o -MD -MP -MF .deps/screen.Tpo -c -o screen.o screen.c mv -f .deps/screen.Tpo .deps/screen.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT screenlist.o -MD -MP -MF .deps/screenlist.Tpo -c -o screenlist.o screenlist.c mv -f .deps/screenlist.Tpo .deps/screenlist.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT serverscreens.o -MD -MP -MF .deps/serverscreens.Tpo -c -o serverscreens.o serverscreens.c mv -f .deps/serverscreens.Tpo .deps/serverscreens.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT sock.o -MD -MP -MF .deps/sock.Tpo -c -o sock.o sock.c mv -f .deps/sock.Tpo .deps/sock.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT widget.o -MD -MP -MF .deps/widget.Tpo -c -o widget.o widget.c mv -f .deps/widget.Tpo .deps/widget.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT drivers.o -MD -MP -MF .deps/drivers.Tpo -c -o drivers.o drivers.c mv -f .deps/drivers.Tpo .deps/drivers.Po gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../shared -DSYSCONFDIR=\"/usr/local/etc\" -Wall -O3 -Wno-unused-function -MT driver.o -MD -MP -MF .deps/driver.Tpo -c -o driver.o driver.c mv -f .deps/driver.Tpo .deps/driver.Po gcc -Wall -O3 -Wno-unused-function -rdynamic -uget_args -o LCDd client.o clients.o input.o main.o menuitem.o menu.o menuscreens.o parse.o render.o screen.o screenlist.o serverscreens.o sock.o widget.o drivers.o driver.o ../shared/libLCDstuff.a commands/libLCDcommands.a -ldl -lkvm -lposix4 -lkstat -lresolv -lsocket -lnsl gcc: unrecognized option '-rdynamic' gmake[2]: Leaving directory `/export/home/tim/dev/lcdproc/current-hacked/server' gmake[1]: Leaving directory `/export/home/tim/dev/lcdproc/current-hacked/server' -- Tim Larson??????? AMT2 Unix Systems Administrator ??? InterCall, a division of West Corporation Be always sure you are right, then go ahead. - David Crockett