From rbu at gentoo.org  Sun May  3 21:48:57 2009
From: rbu at gentoo.org (Robert Buchholz)
Date: Sun, 3 May 2009 23:48:57 +0200
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <49A47CED.7060101@nurfuerspam.de>
References: <49A47CED.7060101@nurfuerspam.de>
Message-ID: <200905032348.59537.rbu@gentoo.org>

On Wednesday 25 February 2009, Markus Dolze wrote:
> Hi,
>
> I would like to point your attention to
> http://sourceforge.net/tracker/index.php?func=detail&aid=2620055&grou
>p_id=119&atid=300119
>
> This is the imonlcd driver from codeka.com. It contains a working
> solution for accessing icons beside the display by using the output()
> function.
>
> The driver is commented well (including doxygen) but misses
> documentation. I have not checked anything else yet and would like to
> hear your comments.

Markus,

what's your take on inclusion of the patches in this thread?


Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090503/e14d2bcd/attachment.pgp>

From rbu at gentoo.org  Sun May  3 21:46:23 2009
From: rbu at gentoo.org (Robert Buchholz)
Date: Sun, 3 May 2009 23:46:23 +0200
Subject: [Lcdproc] Do you want a release?
In-Reply-To: <1239923436.9225.129.camel@antarctica.nelianur.org>
References: <49E6D4E6.1040503@nurfuerspam.de>
	<1239923436.9225.129.camel@antarctica.nelianur.org>
Message-ID: <200905032346.27412.rbu@gentoo.org>

On Friday 17 April 2009, Rene Wagner wrote:
[snip]
> >     * 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? ;)

I fully support Markus as release manager for 0.5.3 and I also concur 
with the need for an update. Put out an RC and the stakeholders in the 
projects have a better chance to find some last minute bugs.


Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090503/fe17271b/attachment.pgp>

From fblack947 at yahoo.com  Mon May  4 04:19:30 2009
From: fblack947 at yahoo.com (jk)
Date: Sun, 3 May 2009 21:19:30 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <200905032348.59537.rbu@gentoo.org>
References: <49A47CED.7060101@nurfuerspam.de>
	<200905032348.59537.rbu@gentoo.org>
Message-ID: <302559.4832.qm@web37508.mail.mud.yahoo.com>

Robert,




________________________________
From: Robert Buchholz <rbu at gentoo.org>
Sent: Sunday, May 3, 2009 5:48:57 PM

>> Hi,
>>
>> I would like to point your attention to
>> http://sourceforge.net/tracker/index.php?func=detail&aid=2620055&grou
>>p_id=119&atid=300119
>>
>> This is the imonlcd driver from codeka.com. It contains a working
>> solution for accessing icons beside the display by using the output()
>> function.
>>
>> The driver is commented well (including doxygen) but misses
>> documentation. I have not checked anything else yet and would like to
>> hear your comments.
>
>Markus,
>
>what's your take on inclusion of the patches in this thread?
>
>Robert

Just pointing you toward updated versions of that driver - with the help of epooch, the code has been streamlined, we've added support to a newer version of the LCD, and we've updated the documentation:
  http://sourceforge.net/tracker/index.php?func=detail&aid=2690871&group_id=119&atid=300119

http://lists.omnipotent.net/pipermail/lcdproc/2009-April/012900.html
http://lists.omnipotent.net/pipermail/lcdproc/2009-April/012901.html

Of course, I'd love to see it get integrated into lcdproc proper.

-Jonathan


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090503/257b474b/attachment.htm>

From ehrnam45 at gmail.com  Mon May  4 13:03:25 2009
From: ehrnam45 at gmail.com (Samuel Rogers)
Date: Mon, 4 May 2009 09:03:25 -0400
Subject: [Lcdproc] MtxOrb adjustable backlight and display detection
In-Reply-To: <49D99E75.7080308@nurfuerspam.de>
References: <20090308140131.9870@gmx.net> <49C893FB.5020909@nurfuerspam.de>
	<f4eb766f0903302153v12d88d55pcdec394966940ce6@mail.gmail.com>
	<49D99E75.7080308@nurfuerspam.de>
Message-ID: <a1454d3d0905040603q6125e081h3e10233a1cc9709a@mail.gmail.com>

On a related note, I also have a MO VFD (VK202-24-USB) and I would like a
bit more intuitive brightness control for these modules.  The VK series only
have 4 brightness settings--5 if you include off--sent as 0x00 (25%) to 0x03
(100%).  I looked over the source for the driver and didn't see anything
that checked for this type of display in the brightness settings nor
anything that would convert the promille value to these brighness values.
As a result, changing the default brigtness in LCDd.conf has no effect on
the brightness of the display.  I also don't see anything in the client
language reference about changing the brightness of a display (unless it's
supposed to be controlled by the backlight setting) and I'd really like to
be able to control that from a client since LCDd doesn't let you pass the
commands directly to the module.  Speaking of which, would it be possible to
make an 'expert' command that allows a client to speak directly to the
module, or is it better to build that functionality into the driver and
access that with screens/widgets?  Would it be helpful for me to tinker with
it on my end and see what I can get working?

Sam

On Mon, Apr 6, 2009 at 2:17 AM, Markus Dolze <bsdfan at nurfuerspam.de> wrote:

> Ethan Dicks wrote:
>
>> On Tue, Mar 24, 2009 at 4:04 AM, Markus Dolze <bsdfan at nurfuerspam.de>
>> 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
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090504/8134a436/attachment.htm>

From ehrnam45 at gmail.com  Mon May  4 17:38:13 2009
From: ehrnam45 at gmail.com (Samuel Rogers)
Date: Mon, 4 May 2009 13:38:13 -0400
Subject: [Lcdproc] MtxOrb adjustable backlight and display detection
In-Reply-To: <a1454d3d0905040603q6125e081h3e10233a1cc9709a@mail.gmail.com>
References: <20090308140131.9870@gmx.net> <49C893FB.5020909@nurfuerspam.de>
	<f4eb766f0903302153v12d88d55pcdec394966940ce6@mail.gmail.com>
	<49D99E75.7080308@nurfuerspam.de>
	<a1454d3d0905040603q6125e081h3e10233a1cc9709a@mail.gmail.com>
Message-ID: <a1454d3d0905041038x36a9bfd8vd0b21a5baccc7568@mail.gmail.com>

Ok, after some digging around in the driver source code, I found that there
is a provision for using the correct brightness levels, but the mauals
differ on what the settings do, as well as have some rather glaring errors.
Here's what I found:

Unit          Version      Notes
VK162-12      2.20/2.30    OK
VK162-12      3.0          1
VK202-25      1.40/1.50    OK
VK202-25      2.0/2.20     OK
VK202-25      3.0          2
VK204-25      1.23         1
VK202-24-USB  1.6          OK
VK204-24-USB  1.0          OK
VK202-25-USB  1.0          2
VK204-25-USB  1.0          2


1) The brightness table is backwards, i.e. 0x00=100%, 0x03=25%
2) The manual has 0x00=0% and 0x01 is listed as BOTH 25% and 50%.
Impossible?

Not all of the manuals list "Y" as the command for brightness, but they do
agree on the decimal value 89 (0x59) which shouldn't present a problem.  I
tried changing the 'Y' to "\x59" on line 756 to match what was listed below
for the standard LCDs but didn't see any change to the brightness once I
restarted LCDd.  Changing the brightness level in my LCDd.conf file doesn't
do anything for the startup brightness either.  Could it be that the
declaration on line 759 as 'long' is generating a decimal point value and
therefore not sending data the display is expecting?  Unless the remainder
is chopped off, there isn't any setting that will give you exactly 1 or 2.
Since there is already a branch checking for IS_VKD_DISPLAY, couldn't we
just skip the promille conversion and add a comment about VKD devices having
valid settings of 0-3 in the .conf file?


On Mon, May 4, 2009 at 9:03 AM, Samuel Rogers <ehrnam45 at gmail.com> wrote:

> On a related note, I also have a MO VFD (VK202-24-USB) and I would like a
> bit more intuitive brightness control for these modules.  The VK series only
> have 4 brightness settings--5 if you include off--sent as 0x00 (25%) to 0x03
> (100%).  I looked over the source for the driver and didn't see anything
> that checked for this type of display in the brightness settings nor
> anything that would convert the promille value to these brighness values.
> As a result, changing the default brigtness in LCDd.conf has no effect on
> the brightness of the display.  I also don't see anything in the client
> language reference about changing the brightness of a display (unless it's
> supposed to be controlled by the backlight setting) and I'd really like to
> be able to control that from a client since LCDd doesn't let you pass the
> commands directly to the module.  Speaking of which, would it be possible to
> make an 'expert' command that allows a client to speak directly to the
> module, or is it better to build that functionality into the driver and
> access that with screens/widgets?  Would it be helpful for me to tinker with
> it on my end and see what I can get working?
>
> Sam
>
>
> On Mon, Apr 6, 2009 at 2:17 AM, Markus Dolze <bsdfan at nurfuerspam.de>wrote:
>
>> Ethan Dicks wrote:
>>
>>> On Tue, Mar 24, 2009 at 4:04 AM, Markus Dolze <bsdfan at nurfuerspam.de>
>>> 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
>>
>> _______________________________________________
>> LCDproc mailing list
>> LCDproc at lists.omnipotent.net
>> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090504/4061fe93/attachment-0001.htm>

From bsdfan at nurfuerspam.de  Mon May  4 18:48:26 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 04 May 2009 20:48:26 +0200
Subject: [Lcdproc] Do you want a release?
In-Reply-To: <1239923436.9225.129.camel@antarctica.nelianur.org>
References: <49E6D4E6.1040503@nurfuerspam.de>
	<1239923436.9225.129.camel@antarctica.nelianur.org>
Message-ID: <49FF387A.3070204@nurfuerspam.de>

Rene Wagner wrote:
> Hi all,
>
> On Thu, 2009-04-16 at 08:49 +0200, Markus Dolze wrote:
>   
>>     * 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
>
>   

Hi all,

if you don't mind I would like to take that hat and prepare the release.

Regards,
Markus

From bsdfan at nurfuerspam.de  Mon May  4 18:53:26 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 04 May 2009 20:53:26 +0200
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <302559.4832.qm@web37508.mail.mud.yahoo.com>
References: <49A47CED.7060101@nurfuerspam.de>	<200905032348.59537.rbu@gentoo.org>
	<302559.4832.qm@web37508.mail.mud.yahoo.com>
Message-ID: <49FF39A6.30208@nurfuerspam.de>

jk wrote:
> Robert,
>
> ------------------------------------------------------------------------
> *From:* Robert Buchholz <rbu at gentoo.org>
> ***Sent:* Sunday, May 3, 2009 5:48:57 PM
> **
> >> Hi,
> >>
> >> I would like to point your attention to
> >> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=2620055&grou 
> <http://sourceforge.net/tracker/index.php?func=detail&aid=2620055&grou>
> >>p_id=119&atid=300119
> >>
> >> This is the imonlcd driver from codeka.com. It contains a working
> >> solution for accessing icons beside the display by using the output()
> >> function.
> >>
> >> The driver is commented well (including doxygen) but misses
> >> documentation. I have not checked anything else yet and would like to
> >> hear your comments.
> >
> >Markus,
> >
> >what's your take on inclusion of the patches in this thread?
> >
> >Robert
>
> Just pointing you toward updated versions of that driver - with the 
> help of epooch, the code has been streamlined, we've added support to 
> a newer version of the LCD, and we've updated the documentation:
>   
> http://sourceforge.net/tracker/index.php?func=detail&aid=2690871&group_id=119&atid=300119 
> <http://sourceforge.net/tracker/index.php?func=detail&aid=2690871&group_id=119&atid=300119>
>
> http://lists.omnipotent.net/pipermail/lcdproc/2009-April/012900.html
> http://lists.omnipotent.net/pipermail/lcdproc/2009-April/012901.html
>
> Of course, I'd love to see it get integrated into lcdproc proper.
>
> -Jonathan

Hi all,

originally I didn't plan to commit it before the 0.5.3 release. But due 
to strong community interrest I agree to commit it if you believe it to 
have 'release quality'. If - on the other hand - you think it needs more 
testing, I will add it after the 0.5.3 release.

Regards
Markus

From jarod at wilsonet.com  Mon May  4 19:30:18 2009
From: jarod at wilsonet.com (Jarod Wilson)
Date: Mon, 4 May 2009 15:30:18 -0400
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <49FF39A6.30208@nurfuerspam.de>
References: <49A47CED.7060101@nurfuerspam.de>	<200905032348.59537.rbu@gentoo.org>
	<302559.4832.qm@web37508.mail.mud.yahoo.com>
	<49FF39A6.30208@nurfuerspam.de>
Message-ID: <895CA9C0-732A-4A17-BB2F-394E49921FA5@wilsonet.com>

On May 4, 2009, at 2:53 PM, Markus Dolze wrote:

> jk wrote:
>> Robert,
>>
>> ------------------------------------------------------------------------
>> *From:* Robert Buchholz <rbu at gentoo.org>
>> ***Sent:* Sunday, May 3, 2009 5:48:57 PM
>> **
>> >> Hi,
>> >>
>> >> I would like to point your attention to
>> >> http://sourceforge.net/tracker/index.php?func=detail&aid=2620055&grou 
>>  <http://sourceforge.net/tracker/index.php?func=detail&aid=2620055&grou 
>> >
>> >>p_id=119&atid=300119
>> >>
>> >> This is the imonlcd driver from codeka.com. It contains a working
>> >> solution for accessing icons beside the display by using the  
>> output()
>> >> function.
>> >>
>> >> The driver is commented well (including doxygen) but misses
>> >> documentation. I have not checked anything else yet and would  
>> like to
>> >> hear your comments.
>> >
>> >Markus,
>> >
>> >what's your take on inclusion of the patches in this thread?
>>

[...]

> originally I didn't plan to commit it before the 0.5.3 release. But  
> due to strong community interrest I agree to commit it if you  
> believe it to have 'release quality'. If - on the other hand - you  
> think it needs more testing, I will add it after the 0.5.3 release.

I'm all for seeing it in 0.5.3, its been pretty well tested within the  
mythtv community. My own imon lcd device has always worked just fine  
too, no problems to speak of, using both lcdproc and mythtv's lcd  
support.

-- 
Jarod Wilson
jarod at wilsonet.com





From fblack947 at yahoo.com  Mon May  4 21:03:12 2009
From: fblack947 at yahoo.com (jk)
Date: Mon, 4 May 2009 14:03:12 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
Message-ID: <718517.80997.qm@web37501.mail.mud.yahoo.com>




--- On Mon, 5/4/09, Markus Dolze <bsdfan at nurfuerspam.de> wrote:

> Hi all,
> 
> originally I didn't plan to commit it before the 0.5.3
> release. But due to strong community interrest I agree to
> commit it if you believe it to have 'release quality'. If -
> on the other hand - you think it needs more testing, I will
> add it after the 0.5.3 release.
> 
> Regards
> Markus
> 

To me, it really depends on the plans for a v0.5.4 release.  If it's to be another two years, then I'd recommend getting imonlcd into v0.5.3.  The demand is definitely there (the howto-s on ubuntu forums have over 25,000 views).

The driver is solid for the :ffdc version of Soundgraph's iMon.  The newer :0038 version works for most - the issues I've heard from some testers come down to getting LIRC upgraded and configured properly, not anything in the proposed lcdproc driver.  The :ffdc device requires lirc>=0.8.4a.  The :0038 device requires lirc>=0.8.5

Those dependency issues are highlighted in the docs.

-Jonathan




      

From rickx at libero.it  Tue May  5 06:33:22 2009
From: rickx at libero.it (Federico Leverato)
Date: Tue, 5 May 2009 08:33:22 +0200
Subject: [Lcdproc] imonlcd server driver with icon support + new question
In-Reply-To: <718517.80997.qm@web37501.mail.mud.yahoo.com>
References: <718517.80997.qm@web37501.mail.mud.yahoo.com>
Message-ID: <5B34BB05-359B-41BA-B780-C66F30573ECD@libero.it>

0038 working here, I agree it should be commited.

I add a more general question here: is there a reason the big-number  
methods are
for numbers only? I suppose they were written with showing the clock  
in mind, and
with the problem of having to "design" the font in binary/hex, but is  
there any other reason
or limitation for not generalizing that methods to print any type of  
character in double size/height?

regards,
Federico

Am 04.05.2009 um 23:03 schrieb jk:

>
>
>
> --- On Mon, 5/4/09, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
>
>> Hi all,
>>
>> originally I didn't plan to commit it before the 0.5.3
>> release. But due to strong community interrest I agree to
>> commit it if you believe it to have 'release quality'. If -
>> on the other hand - you think it needs more testing, I will
>> add it after the 0.5.3 release.
>>
>> Regards
>> Markus
>>
>
> To me, it really depends on the plans for a v0.5.4 release.  If it's  
> to be another two years, then I'd recommend getting imonlcd into  
> v0.5.3.  The demand is definitely there (the howto-s on ubuntu  
> forums have over 25,000 views).
>
> The driver is solid for the :ffdc version of Soundgraph's iMon.  The  
> newer :0038 version works for most - the issues I've heard from some  
> testers come down to getting LIRC upgraded and configured properly,  
> not anything in the proposed lcdproc driver.  The :ffdc device  
> requires lirc>=0.8.4a.  The :0038 device requires lirc>=0.8.5
>
> Those dependency issues are highlighted in the docs.
>
> -Jonathan
>
>
>
>
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc


From ethan.dicks at gmail.com  Tue May  5 14:20:57 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 5 May 2009 10:20:57 -0400
Subject: [Lcdproc] Alphanumeric "bignums" (was Re: imonlcd server driver
	with icon support + new question)
Message-ID: <f4eb766f0905050720v1370064bla2a462fea1aab44f@mail.gmail.com>

On Tue, May 5, 2009 at 2:33 AM, Federico Leverato <rickx at libero.it> wrote:
> I add a more general question here: is there a reason the big-number methods
> are for numbers only? I suppose they were written with showing the clock in
> mind, and with the problem of having to "design" the font in binary/hex, but is
> there any other reason or limitation for not generalizing that methods to print
> any type of character in double size/height?

"bignums", like bargraphs, grew out of feature support for original
Matrix Orbital modules, originally the only modules supported by the
earliest versions of LCDproc (check the list archives for early
discussions about supporting other vendors' modules).  It was easy to
send a command to activate firmware-supported bignums on the module,
and yes, clocks were the original target (4x20 gives you just enough
digits to do a clock with a colon separator).

With most modules having a limitation of 8 user-defined characters,
it's tough creating a large "font", and I don't think there's been
enough interest for folks to try.  If you want to try to create a full
"bignum" font, give it a try and see how well you can do with 8 chars
to play with.  If it just doesn't work well, I wouldn't be surprised,
but I don't know that anyone has attempted it recently.

-ethan

From rickx at libero.it  Tue May  5 14:45:16 2009
From: rickx at libero.it (Federico Leverato)
Date: Tue, 5 May 2009 16:45:16 +0200
Subject: [Lcdproc] Alphanumeric "bignums" (was Re: imonlcd server driver
	with icon support + new question)
In-Reply-To: <f4eb766f0905050720v1370064bla2a462fea1aab44f@mail.gmail.com>
References: <f4eb766f0905050720v1370064bla2a462fea1aab44f@mail.gmail.com>
Message-ID: <3BC66900-B821-4F8C-B10C-494B4435F77F@libero.it>

>
> "bignums", like bargraphs, grew out of feature support for original
> Matrix Orbital modules, originally the only modules supported by the
> earliest versions of LCDproc (check the list archives for early
> discussions about supporting other vendors' modules).  It was easy to
> send a command to activate firmware-supported bignums on the module,
> and yes, clocks were the original target (4x20 gives you just enough
> digits to do a clock with a colon separator).
>
> With most modules having a limitation of 8 user-defined characters,

well, I have the imon-lcd and don't think it has any limitation of  
that kind.
You print points on a display with given number of points (96x16).
The windows driver does it using a strange rounded font btw.
I already prepared an excel file giving you the hex corresponding to  
the character
you draw in a rectangle above. So, if I'm not missing anything  
else...I agree
this might not interest the whole lcdproc community, but I think it's  
worth a try.

thanks,
Federico

>
> it's tough creating a large "font", and I don't think there's been
> enough interest for folks to try.  If you want to try to create a full
> "bignum" font, give it a try and see how well you can do with 8 chars
> to play with.  If it just doesn't work well, I wouldn't be surprised,
> but I don't know that anyone has attempted it recently.
>
> -ethan


From ethan.dicks at gmail.com  Tue May  5 14:55:53 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 5 May 2009 10:55:53 -0400
Subject: [Lcdproc] Alphanumeric "bignums" (was Re: imonlcd server driver
	with icon support + new question)
In-Reply-To: <3BC66900-B821-4F8C-B10C-494B4435F77F@libero.it>
References: <f4eb766f0905050720v1370064bla2a462fea1aab44f@mail.gmail.com>
	<3BC66900-B821-4F8C-B10C-494B4435F77F@libero.it>
Message-ID: <f4eb766f0905050755y2c383e66jfae4dc16426707b1@mail.gmail.com>

On Tue, May 5, 2009 at 10:45 AM, Federico Leverato <rickx at libero.it> wrote:
>>
>> "bignums", like bargraphs, grew out of feature support for original
>> Matrix Orbital modules...
>> With most modules having a limitation of 8 user-defined characters,
>
> well, I have the imon-lcd and don't think it has any limitation of that
> kind.

No you don't, and neither do any graphical displays.  LCDproc,
however, was originally written when there were no pure graphical
displays and is still bound by design choices made more than 10 years
ago.

It's easy to write code to favor one display with all its features,
etc.  It's much harder to write code to work across dozens of vendors'
displays with, in many cases, multiple displays per vendor.

> I already prepared an excel file giving you the hex corresponding to the
> character you draw in a rectangle above. So, if I'm not missing anything
> else...I agree this might not interest the whole lcdproc community, but I
> think it's worth a try.

It's easy to create a font when you have a bitmapped display to write
to.  The trick is that the obvious techniques that work with that as
an output device are entirely unsuitable for textual displays.

-ethan

From rickx at libero.it  Tue May  5 20:43:36 2009
From: rickx at libero.it (rickx at libero.it)
Date: Tue, 5 May 2009 22:43:36 +0200
Subject: [Lcdproc] Alphanumeric "bignums"
In-Reply-To: <f4eb766f0905050755y2c383e66jfae4dc16426707b1@mail.gmail.com>
References: <f4eb766f0905050720v1370064bla2a462fea1aab44f@mail.gmail.com>
	<3BC66900-B821-4F8C-B10C-494B4435F77F@libero.it>
	<f4eb766f0905050755y2c383e66jfae4dc16426707b1@mail.gmail.com>
Message-ID: <33169C72-3FC9-43AE-B048-5505E938BB81@libero.it>

>
> No you don't, and neither do any graphical displays.  LCDproc,
> however, was originally written when there were no pure graphical
> displays and is still bound by design choices made more than 10 years
> ago.
>
> It's easy to write code to favor one display with all its features,
> etc.  It's much harder to write code to work across dozens of vendors'
> displays with, in many cases, multiple displays per vendor.
>
>> I already prepared an excel file giving you the hex corresponding  
>> to the
>> character you draw in a rectangle above. So, if I'm not missing  
>> anything
>> else...I agree this might not interest the whole lcdproc community,  
>> but I
>> think it's worth a try.
>
> It's easy to create a font when you have a bitmapped display to write
> to.  The trick is that the obvious techniques that work with that as
> an output device are entirely unsuitable for textual displays.
>
> -ethan

ok, I get it. But these two philosophies can meet...probably they  
should meet!
I did not seriously analyze the whole code, but I thought from the  
beginning that
having a bignum method was strange and that the only logical reason  
was some
hidden and old software/hardware constraint. So that "respectful"  
philosophy
should maybe try to evolve, putting some flexibility in some too  
strict code parts.
So the other, more aggressive philosophy could build upon the
common base, letting the hardware "express itself" a bit more where it  
is possible.
I don't mean to be respectless to other's work - I'm even new here in  
the list - but I don't think
the fact that there is a lot of different hardware to support can be  
the reason not to
evolve, at least not for a long time.
That being said, I'd probably better go and code something instead of  
writing...which
I'll do asap. And...I won't ask about that spectrum analizer idea back  
in 2000... ;-)

Federico


From ethan.dicks at gmail.com  Tue May  5 21:29:39 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 5 May 2009 17:29:39 -0400
Subject: [Lcdproc] Alphanumeric "bignums"
In-Reply-To: <33169C72-3FC9-43AE-B048-5505E938BB81@libero.it>
References: <f4eb766f0905050720v1370064bla2a462fea1aab44f@mail.gmail.com>
	<3BC66900-B821-4F8C-B10C-494B4435F77F@libero.it>
	<f4eb766f0905050755y2c383e66jfae4dc16426707b1@mail.gmail.com>
	<33169C72-3FC9-43AE-B048-5505E938BB81@libero.it>
Message-ID: <f4eb766f0905051429m5232082q25be16b32569cb27@mail.gmail.com>

On Tue, May 5, 2009 at 4:43 PM,  <rickx at libero.it> wrote:
> ok, I get it. But these two philosophies can meet...probably they should
> meet!

Perhaps they should, but with us trying to gather things together for
the first release in two years, they will not meet anytime soon.

> I did not seriously analyze the whole code, but I thought from the beginning
> that
> having a bignum method was strange and that the only logical reason was some
> hidden and old software/hardware constraint.

It's not a "constraint" as much as originally an attempt to express
the features of the one and only supported module.  Modules have
changed in 10+ years and it has become a constraint (except on
HD44780-based modules which haven't changed and are still probably the
most popular type of module used with LCDproc).

> I don't mean to be respectless to other's work - I'm even new here in the
> list - but I don't think
> the fact that there is a lot of different hardware to support can be the
> reason not to
> evolve, at least not for a long time.

It's not being used as a reason not to evolve, but it is a reason that
the evolution isn't particularly fast.

> That being said, I'd probably better go and code something instead of
> writing...which I'll do asap.

If you are new, you've missed much discussion of the direction of
LCDproc and feature additions, but let me just say that anything as
radical as you are proposing is unlike to make into this version. It's
something to propose for 0.6 when we have the ability to open the
doors to new ideas.

-ethan

From epooch at cox.net  Wed May  6 01:20:42 2009
From: epooch at cox.net (epooch at cox.net)
Date: Tue, 5 May 2009 18:20:42 -0700
Subject: [Lcdproc] Alphanumeric "bignums"
In-Reply-To: <f4eb766f0905051429m5232082q25be16b32569cb27@mail.gmail.com>
Message-ID: <20090505212042.PPTNJ.160332.imail@fed1rmwml39>

Federico,
Rather than mess with the bignum implementation,   Add a "CellSize" configuration for imonlcd, and write some code to scale the font to the CellSize specified.  So, between "Size" and "CellSize", you can basically create a pseudo 1 line LCD with a big character size.  It would be transparent to LCDproc and you would not need to mess with legacy support for bignum.  Check out the sed1330, which according to the docs, MIGHT do something like this (but as I recall, CellSize might not be totally implemented).  
Anyway, bignum is not the right way to do what you want.

--Eric

---- Ethan Dicks <ethan.dicks at gmail.com> wrote: 
> On Tue, May 5, 2009 at 4:43 PM,  <rickx at libero.it> wrote:
> > ok, I get it. But these two philosophies can meet...probably they should
> > meet!
> 
> Perhaps they should, but with us trying to gather things together for
> the first release in two years, they will not meet anytime soon.
> 
> > I did not seriously analyze the whole code, but I thought from the beginning
> > that
> > having a bignum method was strange and that the only logical reason was some
> > hidden and old software/hardware constraint.
> 
> It's not a "constraint" as much as originally an attempt to express
> the features of the one and only supported module.  Modules have
> changed in 10+ years and it has become a constraint (except on
> HD44780-based modules which haven't changed and are still probably the
> most popular type of module used with LCDproc).
> 
> > I don't mean to be respectless to other's work - I'm even new here in the
> > list - but I don't think
> > the fact that there is a lot of different hardware to support can be the
> > reason not to
> > evolve, at least not for a long time.
> 
> It's not being used as a reason not to evolve, but it is a reason that
> the evolution isn't particularly fast.
> 
> > That being said, I'd probably better go and code something instead of
> > writing...which I'll do asap.
> 
> If you are new, you've missed much discussion of the direction of
> LCDproc and feature additions, but let me just say that anything as
> radical as you are proposing is unlike to make into this version. It's
> something to propose for 0.6 when we have the ability to open the
> doors to new ideas.
> 
> -ethan
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc


From vincentetsou at nexcom.com.tw  Wed May  6 04:00:22 2009
From: vincentetsou at nexcom.com.tw (Vincente Tsou)
Date: Wed, 6 May 2009 12:00:22 +0800
Subject: [Lcdproc] Submit nexcom lcm driver to lcdproc
Message-ID: <41fde3420905052100y664c5b78wde1841c5d38b3537@mail.gmail.com>

Hi guys,

I'm a nexcom stuff.

I'd like to submit the nexcom lcm driver to lcdproc standard distribution.

The attachment is a tar ball of nexcom lcm that include relational files.

You could download the datasheet from here:
http://cid-e3c8d036c7b873cd.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/LCM%20Tech%20datasheet.PDF



-- 
Regards,
Vincente Tsou

Senior Engineer
R/D, S/W Dept.
NEXCOM (8234) International Co.
Tel: 886-2-82280606 Ext. 3205
Fax: 886-2-82280506
E-mail: vincentetsou at nexcom.com.tw
Web: http://www.nexcom.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090506/3a17eaeb/attachment.htm>

From rw at nelianur.org  Thu May  7 21:02:33 2009
From: rw at nelianur.org (Rene Wagner)
Date: Thu, 07 May 2009 23:02:33 +0200
Subject: [Lcdproc] Do you want a release?
In-Reply-To: <49FF387A.3070204@nurfuerspam.de>
References: <49E6D4E6.1040503@nurfuerspam.de>
	<1239923436.9225.129.camel@antarctica.nelianur.org>
	<49FF387A.3070204@nurfuerspam.de>
Message-ID: <1241730153.3174.24.camel@antarctica.nelianur.org>

Hi Markus,

On Mon, 2009-05-04 at 20:48 +0200, Markus Dolze wrote:
> > Does that mean we have a volunteer for the "release manager" job? ;)
[...]
> if you don't mind I would like to take that hat and prepare the release.

Excellent. You should have the required permissions to make releases and
post project news on Sourceforge.net now.

Let me know if you run into any issues.

Keep up the good work,

Rene


From manio at skyboo.net  Fri May  8 05:23:37 2009
From: manio at skyboo.net (Manio)
Date: Fri, 08 May 2009 07:23:37 +0200
Subject: [Lcdproc] 'Current' documentation auto-generation
In-Reply-To: <1241730153.3174.24.camel@antarctica.nelianur.org>
References: <49E6D4E6.1040503@nurfuerspam.de>	<1239923436.9225.129.camel@antarctica.nelianur.org>	<49FF387A.3070204@nurfuerspam.de>
	<1241730153.3174.24.camel@antarctica.nelianur.org>
Message-ID: <4A03C1D9.30207@skyboo.net>

Hello
It seems that autogenerated documentation on webpage stuck for at least 
half year and are not generated every night (maybe it is trying - i 
don't know ;)
Simple example (section of my ethlcd connection) on web:
http://lcdproc.sourceforge.net/docs/current-user.html#hd44780-ethlcd
and in cvs:
http://lcdproc.cvs.sourceforge.net/viewvc/lcdproc/lcdproc/docs/lcdproc-user/drivers/hd44780.docbook?r1=1.52&r2=1.53

if somebody know how - please fix it :)

regards,
-- 
Mariusz Bialonczyk
http://manio.skyboo.net
jabber/e-mail: manio at skyboo.net


From bsdfan at nurfuerspam.de  Fri May  8 07:02:24 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 08 May 2009 09:02:24 +0200
Subject: [Lcdproc] 'Current' documentation auto-generation
In-Reply-To: <4A03C1D9.30207@skyboo.net>
References: <49E6D4E6.1040503@nurfuerspam.de>	<1239923436.9225.129.camel@antarctica.nelianur.org>	<49FF387A.3070204@nurfuerspam.de>	<1241730153.3174.24.camel@antarctica.nelianur.org>
	<4A03C1D9.30207@skyboo.net>
Message-ID: <4A03D900.3000802@nurfuerspam.de>

Manio wrote:
> Hello
> It seems that autogenerated documentation on webpage stuck for at 
> least half year and are not generated every night (maybe it is trying 
> - i don't know ;)
> Simple example (section of my ethlcd connection) on web:
> http://lcdproc.sourceforge.net/docs/current-user.html#hd44780-ethlcd
> and in cvs:
> http://lcdproc.cvs.sourceforge.net/viewvc/lcdproc/lcdproc/docs/lcdproc-user/drivers/hd44780.docbook?r1=1.52&r2=1.53 
>
>
> if somebody know how - please fix it :)
>
> regards,
Hi Manio,

I am aware of this problem, but it can only be fixed by Guillaume Filion 
(gfk) who is running the tests.

The doc page will be updated when the new release is made, too.

Rergards,
Markus



From bsdfan at nurfuerspam.de  Sat May  9 07:25:28 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 09 May 2009 09:25:28 +0200
Subject: [Lcdproc] Submit nexcom lcm driver to lcdproc
In-Reply-To: <41fde3420905052100y664c5b78wde1841c5d38b3537@mail.gmail.com>
References: <41fde3420905052100y664c5b78wde1841c5d38b3537@mail.gmail.com>
Message-ID: <4A052FE8.1010505@nurfuerspam.de>

Vincente Tsou wrote:
> Hi guys,
>
> I'm a nexcom stuff.
>
> I'd like to submit the nexcom lcm driver to lcdproc standard distribution.
>
> The attachment is a tar ball of nexcom lcm that include relational files.
>
> You could download the datasheet from here:
> http://cid-e3c8d036c7b873cd.skydrive.live.com/self.aspx/%e5%85%ac%e9%96%8b/LCM%20Tech%20datasheet.PDF
>
>
>
> -- 
> Regards,
> Vincente Tsou
>
> Senior Engineer
> R/D, S/W Dept.
> NEXCOM (8234) International Co.
> Tel: 886-2-82280606 Ext. 3205
> Fax: 886-2-82280506
> E-mail: vincentetsou at nexcom.com.tw <mailto:vincentetsou at nexcom.com.tw>
> Web: http://www.nexcom.com/

Hello Mr. Tsou,

the e-mail did not have the attachment you mention. Please send the 
driver files again.

Regards,
Markus


From bsdfan at nurfuerspam.de  Sat May  9 07:27:59 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 09 May 2009 09:27:59 +0200
Subject: [Lcdproc] Patch: MtxOrb adjustable backlight and display
	detection
In-Reply-To: <20090308140131.9870@gmx.net>
References: <20090308140131.9870@gmx.net>
Message-ID: <4A05307F.40105@nurfuerspam.de>

Markus Dolze wrote:
> Hi,
>
> I added a switch to LCDd.conf to turn off the adjustable backlight (which is on by default). If the adjustable backlight is turn off, the driver uses the old way to switch the backlight on or off.
>
> The switch is necessary because there are still some old MtxOrb displays floating around which do not feature an adjustable backlight but also cannot be identified by the driver. Therefore the user has to set this in the config file.
>
>   

Hi Ethan and others,

do you have any other idea how to work around the backlight problem? If 
not, I will commit the patch from the previous mail to fix the problem 
for the upcoming release.

Regards.
Markus

From bsdfan at nurfuerspam.de  Sun May 10 15:00:38 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 10 May 2009 17:00:38 +0200
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <718517.80997.qm@web37501.mail.mud.yahoo.com>
References: <718517.80997.qm@web37501.mail.mud.yahoo.com>
Message-ID: <4A06EC16.5020903@nurfuerspam.de>

jk wrote:
> 
> --- On Mon, 5/4/09, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> 
>> Hi all,
>> 
>> originally I didn't plan to commit it before the 0.5.3 release. But
>> due to strong community interrest I agree to commit it if you
>> believe it to have 'release quality'. If - on the other hand - you
>> think it needs more testing, I will add it after the 0.5.3 release.
>> 
>> 
>> Regards Markus
>> 
> 
> To me, it really depends on the plans for a v0.5.4 release.  If it's
> to be another two years, then I'd recommend getting imonlcd into
> v0.5.3.  The demand is definitely there (the howto-s on ubuntu forums
> have over 25,000 views).
> 
> The driver is solid for the :ffdc version of Soundgraph's iMon.  The
> newer :0038 version works for most - the issues I've heard from some
> testers come down to getting LIRC upgraded and configured properly,
> not anything in the proposed lcdproc driver.  The :ffdc device
> requires lirc>=0.8.4a.  The :0038 device requires lirc>=0.8.5
> 
> Those dependency issues are highlighted in the docs.
> 
> -Jonathan
> 
> 


Hi,

today I check the version 0.6.1 of the patch.

It turned out that imonlcd.c used a mix of space & tab indention mode. 
So I piped it through indent. Unfortunately indent doesn't like C++ 
style comments so I converted them to C style. It also aligned it with 
the style of other souces files we have.

Regarding LCDd.conf: The "legal" section should list all possible 
values, not only those other than the default.

I also removed some commented out code related to the bars. If I was 
wrong there, it's no problem to revert.

One of the TODOs left is: "Check if either setLineLength or 
setBuiltinProgressBars could be removed as the former is only a wrapper 
to the latter."

What about this?


No functional changes have been made, but please test if the comment 
changes broke something.

Version 0.6.2 of the patch has been uploaded to SF.

Regards,
Markus

From bsdfan at nurfuerspam.de  Sun May 10 15:17:26 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 10 May 2009 17:17:26 +0200
Subject: [Lcdproc] Included vs. system getopt
Message-ID: <4A06F006.7060906@nurfuerspam.de>

Hi,

while working on the Solaris support, I found that we ship a getopt() 
implementation ourselves which cases some trouble.

While it is only used if the system does not provide getopt(), our own 
header file is always used (#include "getopt.h"). This works for the 
server which has '-I./shared' set in the Makefile, but not for the 
clients, which omit this and therefore use the system's getopt.h (or 
fail in case of Solaris).

Additionally 'configure' does not check for the availability of getopt() 
but getopt_long() instead, which is used nowhere in our code.

Was there a specific reason to make the clients not use our own 
getopt.h? If not, I would add '-I$(top_srcdir)/shared' to the client's 
Makefile.

Or can we remove our own getopt implementation all together? getopt() is 
part of many standards, whereis getopt_long() is not, but which we don't 
use.

Regards,
Markus


From fblack947 at yahoo.com  Mon May 11 15:00:52 2009
From: fblack947 at yahoo.com (jk)
Date: Mon, 11 May 2009 08:00:52 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <4A06EC16.5020903@nurfuerspam.de>
References: <718517.80997.qm@web37501.mail.mud.yahoo.com>
	<4A06EC16.5020903@nurfuerspam.de>
Message-ID: <162001.90458.qm@web37502.mail.mud.yahoo.com>


Sorry for the delay - my system is having some issues.  (Not lcdproc related!)

> 
> Hi,
> 
> today I check the version 0.6.1 of the patch.
> 
> It turned out that imonlcd.c used a mix of space & tab indention mode. So I 
> piped it through indent. Unfortunately indent doesn't like C++ style comments so 
> I converted them to C style. It also aligned it with the style of other souces 
> files we have.
> 
> Regarding LCDd.conf: The "legal" section should list all possible values, not 
> only those other than the default.
> 

Looks like you fixed this - thanks.


> I also removed some commented out code related to the bars. If I was wrong 
> there, it's no problem to revert.
> 

Looks good.  


> One of the TODOs left is: "Check if either setLineLength or 
> setBuiltinProgressBars could be removed as the former is only a wrapper to the 
> latter."
> 
> What about this?

It is a wrapper to the latter, but makes the usage of setLineLength a bit easier.  I read the original intent of the separate functions as leaving open the possibility of using the built in progress bars as something other than progress bars in the future.  I recommend leaving as-is for now.


> 
> 
> No functional changes have been made, but please test if the comment changes 
> broke something.
> 

Compiles fine on my non-htpc machine (without the LCD...).  I'll test it out w/ the LCD later today after I get that machine running again...

Thanks,
Jonathan



      

From fblack947 at yahoo.com  Wed May 13 15:39:28 2009
From: fblack947 at yahoo.com (jk)
Date: Wed, 13 May 2009 08:39:28 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <4A06EC16.5020903@nurfuerspam.de>
References: <718517.80997.qm@web37501.mail.mud.yahoo.com>
	<4A06EC16.5020903@nurfuerspam.de>
Message-ID: <570675.7194.qm@web37501.mail.mud.yahoo.com>






----- Original Message ----
> From: Markus Dolze <bsdfan at nurfuerspam.de>
> Sent: Sunday, May 10, 2009 11:00:38 AM
> Subject: Re: [Lcdproc] imonlcd server driver with icon support
> 
> 
> No functional changes have been made, but please test if the comment changes 
> broke something.
> 
> Version 0.6.2 of the patch has been uploaded to SF.
> 
> Regards,
> Markus

Finally revived my htpc.  (Stupid hard drive failures!)

In applying the patch to current CVS, I get a warning about docs/LCDd.8.in:
  Hunk #1 succeeded at 186 (offset 3 lines).

This is likely just to an update to LCDd8.in before I was able to apply the patch.

When making all drivers, I get errors on:
  hd44780-bwct-usb.c:23:17: error: usb.h: No such file or directory

Compiling for just the imonlcd driver is successful.

Driver works great with lcdproc.

Documentation compiles to html and looks good.

The CVS version of lcdproc remains incompatible with mythtv's mythlcdserver.  I believe that this is not specific to a driver, but due to some protocol changes.

v0.5.2 modified with the patched imonlcd files compiles fine and works well with mythlcdserver.

-Jonathan


      

From bsdfan at nurfuerspam.de  Wed May 13 18:03:24 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 13 May 2009 20:03:24 +0200
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <570675.7194.qm@web37501.mail.mud.yahoo.com>
References: <718517.80997.qm@web37501.mail.mud.yahoo.com>
	<4A06EC16.5020903@nurfuerspam.de>
	<570675.7194.qm@web37501.mail.mud.yahoo.com>
Message-ID: <4A0B0B6C.8040507@nurfuerspam.de>

Hi,

jk wrote:
> 
> ----- Original Message ----
>> From: Markus Dolze <bsdfan at nurfuerspam.de> Sent: Sunday, May 10,
>> 2009 11:00:38 AM Subject: Re: [Lcdproc] imonlcd server driver with
>> icon support
>> 
>> 
>> No functional changes have been made, but please test if the
>> comment changes broke something.
>> 
>> Version 0.6.2 of the patch has been uploaded to SF.
>> 
>> Regards, Markus
> 
> Finally revived my htpc.  (Stupid hard drive failures!)
> 
> In applying the patch to current CVS, I get a warning about
> docs/LCDd.8.in: Hunk #1 succeeded at 186 (offset 3 lines).
> 
> This is likely just to an update to LCDd8.in before I was able to
> apply the patch.

Yes, the hd44780-usblcd driver was imported.

> 
> When making all drivers, I get errors on: hd44780-bwct-usb.c:23:17:
> error: usb.h: No such file or directory

This should not happen. Have you deinstalled / updated libusb since the
last time you ran configure? Maybe configure does incorrectly detected
libusb to be installed.

> 
> Compiling for just the imonlcd driver is successful.
> 
> Driver works great with lcdproc.
> 
> Documentation compiles to html and looks good.

Fine.

> 
> The CVS version of lcdproc remains incompatible with mythtv's
> mythlcdserver.  I believe that this is not specific to a driver, but
> due to some protocol changes.

I am not aware of any major changes in the client/server protocol. 
Perhaps the cause for this shows up if more people look at the 0.5.3 
release candidate.

> 
> v0.5.2 modified with the patched imonlcd files compiles fine and
> works well with mythlcdserver.

I will commit the imonlcd to CVS the next days. It will then be part of 
what will become 0.5.3 soon.

Regards
Markus

From fblack947 at yahoo.com  Wed May 13 18:50:13 2009
From: fblack947 at yahoo.com (jk)
Date: Wed, 13 May 2009 11:50:13 -0700 (PDT)
Subject: [Lcdproc] imonlcd server driver with icon support
In-Reply-To: <4A0B0B6C.8040507@nurfuerspam.de>
References: <718517.80997.qm@web37501.mail.mud.yahoo.com>
	<4A06EC16.5020903@nurfuerspam.de>
	<570675.7194.qm@web37501.mail.mud.yahoo.com>
	<4A0B0B6C.8040507@nurfuerspam.de>
Message-ID: <740716.61141.qm@web37504.mail.mud.yahoo.com>


Minor answers below...



----- Original Message ----
> From: Markus Dolze <bsdfan at nurfuerspam.de>
> Sent: Wednesday, May 13, 2009 2:03:24 PM
> Subject: Re: [Lcdproc] imonlcd server driver with icon support
> > 
> > When making all drivers, I get errors on: hd44780-bwct-usb.c:23:17:
> > error: usb.h: No such file or directory
> 
> This should not happen. Have you deinstalled / updated libusb since the
> last time you ran configure? Maybe configure does incorrectly detected
> libusb to be installed.

What, I should actually look at the output of configure?!??  :}

installing libusb-dev cleared that right up.  Must have neglected it on the new install.  make all drivers runs fine.



> 
> > 
> > 
> > The CVS version of lcdproc remains incompatible with mythtv's
> > mythlcdserver.  I believe that this is not specific to a driver, but
> > due to some protocol changes.
> 
> I am not aware of any major changes in the client/server protocol. Perhaps the 
> cause for this shows up if more people look at the 0.5.3 release candidate.
> 

I peeked into mythlcdserver months ago, and remember that the calls it was sending to lcdproc didn't match the lcdproc documentation very well.  I believe some of the mythtv people monitor this list, so if this is you, please take a look!


> > 
> > v0.5.2 modified with the patched imonlcd files compiles fine and
> > works well with mythlcdserver.
> 
> I will commit the imonlcd to CVS the next days. It will then be part of what 
> will become 0.5.3 soon.
> 
> Regards
> Markus

Fantastic!    Thanks.

-Jonathan



      

From marc_bevand at rapid7.com  Thu May 14 18:23:22 2009
From: marc_bevand at rapid7.com (Marc Bevand)
Date: Thu, 14 May 2009 11:23:22 -0700
Subject: [Lcdproc] [PATCH] Fix infinite loop when the continuity of
	gettimeofday() is broken
Message-ID: <OF790DB3EC.F0228F53-ON882575B6.0064BCCF-882575B6.006513DB@rapid7.com>

When changing the time backward on a machine running LCDd, I have noticed 
that it causes the daemon to enter an (practically) infinite loop doing 
nothing but calling gettimeofday(). I fixed it in the attached patch, it 
applies cleanly to LCDproc 0.5.2.



-marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090514/bbd1af92/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lcdproc-infinite-loop-when-time-discontinuity.patch
Type: application/octet-stream
Size: 469 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090514/bbd1af92/attachment.obj>

From bsdfan at nurfuerspam.de  Thu May 14 20:26:39 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 14 May 2009 22:26:39 +0200
Subject: [Lcdproc] [PATCH] Fix infinite loop when the continuity
 of	gettimeofday() is broken
In-Reply-To: <OF790DB3EC.F0228F53-ON882575B6.0064BCCF-882575B6.006513DB@rapid7.com>
References: <OF790DB3EC.F0228F53-ON882575B6.0064BCCF-882575B6.006513DB@rapid7.com>
Message-ID: <4A0C7E7F.4000305@nurfuerspam.de>

Marc Bevand wrote:
>
> When changing the time backward on a machine running LCDd, I have 
> noticed that it causes the daemon to enter an (practically) infinite 
> loop doing nothing but calling gettimeofday(). I fixed it in the 
> attached patch, it applies cleanly to LCDproc 0.5.2.
>
>
Hi,

this has already been patched in CVS two month ago.

Regards,
Markus



From bsdfan at nurfuerspam.de  Thu May 14 22:06:28 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 15 May 2009 00:06:28 +0200
Subject: [Lcdproc] Driver for SoundGraph iMON LCD imported
Message-ID: <4A0C95E4.30901@nurfuerspam.de>

Hi,

thanks to the work of

    * Dean Harding (orginal developer),
    * Christian Leuschen (added the output function),
    * Jonathan Kyler (lot of documentation, added new font, many
      enhancements) and
    * Eric Pooch (did many enhancements)

we are able to present LCDproc with imonlcd driver (SoundGraph iMON LCD 
modules).

The code has just been submitted to CVS HEAD and is available 
immediately. It should also show up in the next -current nightly tarball 
and will be part of release 0.5.3.

If find any bugs please send them to this mailing list.

Regards,
Markus


From TELarson at west.com  Fri May 15 21:44:09 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Fri, 15 May 2009 16:44:09 -0500
Subject: [Lcdproc] Included vs. system getopt
In-Reply-To: <4A06F006.7060906@nurfuerspam.de>
References: <4A06F006.7060906@nurfuerspam.de>
Message-ID: <226316B3E1F749498E28ACA66321D5BA2542B1A7@oma00cexmbx03.corp.westworlds.com>

> Was there a specific reason to make the clients not use our own
> getopt.h? If not, I would add '-I$(top_srcdir)/shared' to the client's
> Makefile.
> 
> Or can we remove our own getopt implementation all together? getopt() is
> part of many standards, whereis getopt_long() is not, but which we don't
> use.

Hmm, no comments yet.

I agree that either one or the other should be done.

I could try making it use the system getopt.h across the board, and see if I can make it build on a couple systems.

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 rbu at gentoo.org  Sat May 16 10:19:25 2009
From: rbu at gentoo.org (Robert Buchholz)
Date: Sat, 16 May 2009 12:19:25 +0200
Subject: [Lcdproc] Driver for SoundGraph iMON LCD imported
In-Reply-To: <4A0C95E4.30901@nurfuerspam.de>
References: <4A0C95E4.30901@nurfuerspam.de>
Message-ID: <200905161219.27804.rbu@gentoo.org>

On Friday 15 May 2009, Markus Dolze wrote:
> Hi,
>
> thanks to the work of
>
>     * Dean Harding (orginal developer),
>     * Christian Leuschen (added the output function),
>     * Jonathan Kyler (lot of documentation, added new font, many
>       enhancements) and
>     * Eric Pooch (did many enhancements)

Thanks a lot, guys. Of course, you forgot to mention yourself. So thanks 
as well :-)


> The code has just been submitted to CVS HEAD and is available
> immediately. It should also show up in the next -current nightly
> tarball and will be part of release 0.5.3.

Will you be preparing an RC or is *now* the time to test this to get 
bugfixes in the release?


Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090516/f5b788d0/attachment-0001.pgp>

From andy at siliconlandmark.com  Sat May 16 17:02:55 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Sat, 16 May 2009 13:02:55 -0400
Subject: [Lcdproc] Do you want a release?
In-Reply-To: <49FF387A.3070204@nurfuerspam.de>
References: <49E6D4E6.1040503@nurfuerspam.de>
	<1239923436.9225.129.camel@antarctica.nelianur.org>
	<49FF387A.3070204@nurfuerspam.de>
Message-ID: <314C9AAB-E708-4711-93E2-1D12056E3D9C@siliconlandmark.com>

On May 4, 2009, at 2:48 PM, Markus Dolze wrote:

> Rene Wagner wrote:
>>
>> On Thu, 2009-04-16 at 08:49 +0200, Markus Dolze wrote:
>>
>>>    * 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? ;)
>>
>
> if you don't mind I would like to take that hat and prepare the  
> release.

Markus,

I just came back from an extended vacation in Germany. Let me know if  
there's anything that I can do to assist you (Producing/testing  
patches, etc).

Cheers,

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */


From bsdfan at nurfuerspam.de  Mon May 18 20:10:21 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 18 May 2009 22:10:21 +0200
Subject: [Lcdproc] Release status report
Message-ID: <4A11C0AD.5030401@nurfuerspam.de>

Hello,

by writing this email I want to let you know of the current status of 
the LCDproc 0.5.3 release.

Last week

    * the imonlcd driver was imported,
    * the hd44780-usblcd connection type was imported,
    * the Matrix Orbital driver was fixed,
    * a bug in handling of priority strings was fixed, and
    * several code style and documentation changes happened.

I believe LCDproc 0.5.3 to be 'feature complete' and that no serious 
bugs remain (but see the BUGS file).

What's next:

   1. Merge everything from HEAD to stable-0-5-x (will happen this week).
   2. Create a release branch (its name will be 'stable-0-5-3').
   3. Update all code and documentation with the new version numbers and
      dates.
   4. Create 'lcdproc-0.5.3-pre1' and upload it to Sourceforge.

Regards,
Markus


From TELarson at west.com  Mon May 18 20:57:20 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Mon, 18 May 2009 15:57:20 -0500
Subject: [Lcdproc] Release status report
In-Reply-To: <4A11C0AD.5030401@nurfuerspam.de>
References: <4A11C0AD.5030401@nurfuerspam.de>
Message-ID: <226316B3E1F749498E28ACA66321D5BA2542B1AD@oma00cexmbx03.corp.westworlds.com>

I'm concerned about the status of Solaris support.  Fortunately I now have access to a NetBSD/i386 system, so that getting this lcdproc release imported to pkgsrc is not dependent on Solaris working.  But if we can't get it to work, the support claim should be removed.  If the next release is another 18-24 months away, that's a long time to claim something that's not quite true.



Tim

From bsdfan at nurfuerspam.de  Tue May 19 20:43:26 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Tue, 19 May 2009 22:43:26 +0200
Subject: [Lcdproc] Release status report
In-Reply-To: <226316B3E1F749498E28ACA66321D5BA2542B1AD@oma00cexmbx03.corp.westworlds.com>
References: <4A11C0AD.5030401@nurfuerspam.de>
	<226316B3E1F749498E28ACA66321D5BA2542B1AD@oma00cexmbx03.corp.westworlds.com>
Message-ID: <4A1319EE.6000207@nurfuerspam.de>

Larson, Timothy E. wrote:
> I'm concerned about the status of Solaris support.  Fortunately I now
> have access to a NetBSD/i386 system, so that getting this lcdproc
> release imported to pkgsrc is not dependent on Solaris working.  But
> if we can't get it to work, the support claim should be removed.  If
> the next release is another 18-24 months away, that's a long time to
> claim something that's not quite true.
> 

Hi Tim,

I will post a patch later this week which should allow building the 
clients on Solaris.

Additionally, the mtx_s16209x driver has to be fixed as you said:

> The mtc_s16209x issue has to do with use of flock vs fcntl.  That looked a
> little more complicated than I wanted to delve into right now.

Are you going to do this?


Anyway, release work will continue in the meantime. But before including 
these fixes in the release, I require explicit OK from someone building 
and testing them on Linux and MacOS X (for FreeBSD I will check myself) 
before including it (and silence will not be OK this time). Otherwise 
the 0.5.3 release notes will tell about Solaris support being broken and 
we will have to do this for the next release.

Regards,
Markus


From rw at nelianur.org  Tue May 19 21:29:01 2009
From: rw at nelianur.org (Rene Wagner)
Date: Tue, 19 May 2009 23:29:01 +0200
Subject: [Lcdproc] [Fwd: SourceForge.net feature deprecation upcoming:
	forums, DocManager, TaskManager, Diary/Notes]
Message-ID: <1242768541.4365.64.camel@antarctica.nelianur.org>

Hi all,

I've never used the affected functionality myself but maybe this is of
interest to some of you.

I'm afraid I won't have the time to actively look into any possibly
required migration within the 30 day period mentioned in the message
below. However, please let me know if you think action by a project
administrator is required and I'll see what I can do.

Cheers,

Rene

-------- Forwarded Message --------
From: SourceForge.net Team <noreply at sourceforge.net>
Subject: SourceForge.net feature deprecation upcoming: forums,
DocManager, TaskManager, Diary/Notes
Date: Tue, 19 May 2009 16:37:24 +0000

Hello,

This mailing is being sent to all project administrators, and all users who
have used the Diary/Notes feature.  Please forward this to other members of
your team as needed.

The SourceForge.net team has been working for the past few months to expand
and refine our feature offering.  The Hosted Apps offering, launched last
September, has been expanded to include new apps, and is continuing to have
a strong rate of adoption among projects.

To best serve the needs of our community, we are electing to eliminate some
of the older site-integrated features in lieu of more viable replacements
we've launched as Hosted Apps.	These old features will be dropped after
data migration occurs, on a date to be announced later (at least 30 days
from now).  Eliminating these crufty, less-capable built-in applications
will allow us to focus our efforts on providing great service to our
projects, and ensure their needs are met.

We will provide an easy-to-use migration path to move the data to the
provided replacements.	We will also provide dumps of this data in case
projects want to do something different with their data.  Additional
information on how to obtain or migrate your data will be provided when the
timeline is announced, in a future mailing.

The following applications are due to be deprecated, replaced by
high-quality Open Source applications we have in our Hosted Apps offering:

 * TaskManager will be replaced by TaskFreak!, dotProject and Trac
(tickets).
 * DocManager will be replaced by MediaWiki and Trac (wiki).
 * Discussion Forums will be replaced by phpBB.
 * Diary and Notes will be replaced by WordPress.

To solicit your feedback on how the migration should be handled, and
alternate options you would like us to consider, we are running a survey
for the next 30 days for the user base of each of these applications.  For
links to the surveys, please see our Site Status post at:
http://tinyurl.com/q3g8o3

If you have questions or concerns, please contact our Support team at:
http://apps.sourceforge.net/trac/sourceforge/wiki/Support

Thank you,

The SourceForge.net team



From TELarson at west.com  Tue May 19 21:30:24 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Tue, 19 May 2009 16:30:24 -0500
Subject: [Lcdproc] Release status report
In-Reply-To: <4A1319EE.6000207@nurfuerspam.de>
References: <4A11C0AD.5030401@nurfuerspam.de>
	<226316B3E1F749498E28ACA66321D5BA2542B1AD@oma00cexmbx03.corp.westworlds.com>
	<4A1319EE.6000207@nurfuerspam.de>
Message-ID: <226316B3E1F749498E28ACA66321D5BA2542B1B2@oma00cexmbx03.corp.westworlds.com>

> I will post a patch later this week which should allow building the clients on Solaris.
> 
> Additionally, the mtx_s16209x driver has to be fixed as you said:

Right now I've got AC_CHECK_HEADERS(getopt.h stdint.h usb.h) in the configure.in, and changed the check for getopt_long to getopt.  I've changed includes of "getopt.h" to <getopt.h> everywhere, and made them conditional on the presence of that header.  The imonlcd driver needs to make the stdint.h include conditional also.  (I assume your patch is something similar.)  But assuming I build without the mtx driver, it builds fine...

>> The mtc_s16209x issue has to do with use of flock vs fcntl.  That 
>> looked a little more complicated than I wanted to delve into right now.
> 
> Are you going to do this?

Unfortunately I don't have the bandwidth to look into that (I've never tried resolving the two locking mechanisms, so it would take a fair bit just to get up to speed), and don't expect to any time soon.  If the other things can be taken care of, I'd say just state it as a known issue so people can build without that driver on Solaris.

> Anyway, release work will continue in the meantime. But before including these fixes in 
> the release, I require explicit OK from someone building and testing them on Linux and 
> MacOS X (for FreeBSD I will check myself) before including it (and silence will not be 
> OK this time). Otherwise the 0.5.3 release notes will tell about Solaris support being 
> broken and we will have to do this for the next release.

FWIW I can test Solaris, Linux, and NetBSD.  I haven't tried Linux yet because I assumed there were enough people already there.  If there's enough interest, I could dust off a SGI and try IRIX too.


Tim

From bsdfan at nurfuerspam.de  Wed May 20 09:00:40 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 20 May 2009 11:00:40 +0200
Subject: [Lcdproc] [Fwd: SourceForge.net feature deprecation
	upcoming:	forums, DocManager, TaskManager, Diary/Notes]
In-Reply-To: <1242768541.4365.64.camel@antarctica.nelianur.org>
References: <1242768541.4365.64.camel@antarctica.nelianur.org>
Message-ID: <20090520090040.83430@gmx.net>

Hi Rene,

I think it's ok to have these removed. In fact I asked in the past to disable some of them.

TaskManager -> unused for 8 years, requires an admin to create tasks
DocManager -> only a link to our documentation page
Forums -> rarely used as we have the mailing list. Problems can/should also be reported to the bug tracker.
Diary / Notes -> I never used it.

For the TaskManager, the XML export offered would allow us to keep the old data just in case someone's interested, but migrating the data to TaskFreak! seems not necessary.

TaskFreak! and IdeaTorrent are very interesting and might be useful for the project.

Regards
Markus

-------- Original-Nachricht --------
> Datum: Tue, 19 May 2009 23:29:01 +0200
> Von: Rene Wagner <rw at nelianur.org>
> An: lcdproc at lists.omnipotent.net
> Betreff: [Lcdproc] [Fwd: SourceForge.net feature deprecation upcoming:	forums, DocManager, TaskManager, Diary/Notes]

> Hi all,
> 
> I've never used the affected functionality myself but maybe this is of
> interest to some of you.
> 
> I'm afraid I won't have the time to actively look into any possibly
> required migration within the 30 day period mentioned in the message
> below. However, please let me know if you think action by a project
> administrator is required and I'll see what I can do.
> 
> Cheers,
> 
> Rene
> 
> -------- Forwarded Message --------
> From: SourceForge.net Team <noreply at sourceforge.net>
> Subject: SourceForge.net feature deprecation upcoming: forums,
> DocManager, TaskManager, Diary/Notes
> Date: Tue, 19 May 2009 16:37:24 +0000
> 
> The following applications are due to be deprecated, replaced by
> high-quality Open Source applications we have in our Hosted Apps offering:
> 
>  * TaskManager will be replaced by TaskFreak!, dotProject and Trac
> (tickets).
>  * DocManager will be replaced by MediaWiki and Trac (wiki).
>  * Discussion Forums will be replaced by phpBB.
>  * Diary and Notes will be replaced by WordPress.
> 

From Matt at mattsmith.cc  Wed May 20 16:50:27 2009
From: Matt at mattsmith.cc (Matt Smith)
Date: Thu, 21 May 2009 02:50:27 +1000 (EST)
Subject: [Lcdproc] Driver for SoundGraph iMON LCD imported
Message-ID: <45476.59.167.59.98.1242838227.squirrel@coolchilli.com>

---------------------------- Original Message ----------------------------
Subject: RE: Driver for SoundGraph iMON LCD imported
Date:    Wed, May 20, 2009 21:27
--------------------------------------------------------------------------
<SNIP>
I just compiled from CVS the other night (18 May 2009, approx 22:15
GMT+10), on a Mythdora 10.21 system (Fedora Core 10, MythTV 0.21), with
kernel 2.6.27.21.
Using LCDd and lcdproc display everything fine, as expected, and the extra
features (turning LCD off) work well (didn't play with any of the extra
icons though).
<SNIP>

Sorry folks...
After some more searching, I decided to grab latest SVN from mythtv and
compile a new mythlcdserver (v0.22).  Once that had built and libraries
were in place, it solved my screen issues.
I am seeing a new error about "client_add_key" having a wrong syntax, but
at this stage it doesn't bother me as my LCD has no keys anyway.

Sorry for wasting bandwidth!  I'm keen to tinker with this LCD and
integrate some of the features exposed by this updated driver to MythTV -
again, thanks for the effort to all so far.

Cheers,
Matt


From fblack947 at yahoo.com  Wed May 20 17:29:26 2009
From: fblack947 at yahoo.com (jk)
Date: Wed, 20 May 2009 10:29:26 -0700 (PDT)
Subject: [Lcdproc] Driver for SoundGraph iMON LCD imported
In-Reply-To: <45476.59.167.59.98.1242838227.squirrel@coolchilli.com>
References: <45476.59.167.59.98.1242838227.squirrel@coolchilli.com>
Message-ID: <683237.18793.qm@web37506.mail.mud.yahoo.com>


Matt,




----- Original Message ----
> From: Matt Smith <Matt at mattsmith.cc>
> To: lcdproc at lists.omnipotent.net
> Sent: Wednesday, May 20, 2009 12:50:27 PM
> Subject: Re: [Lcdproc] Driver for SoundGraph iMON LCD imported
> 
> 
> I just compiled from CVS the other night (18 May 2009, approx 22:15
> GMT+10), on a Mythdora 10.21 system (Fedora Core 10, MythTV 0.21), with
> kernel 2.6.27.21.
> Using LCDd and lcdproc display everything fine, as expected, and the extra
> features (turning LCD off) work well (didn't play with any of the extra
> icons though).
> ...

I somehow missed part of this conversation.

Glad to hear that the newer version of mythlcdserver is playing more nicely with lcdproc.  It is unfortunate that the current mythlcdserver is unlikely to work with our proposed lcdproc v0.5.3.  Maybe mythtv 0.22 will be released around the same time as lcdproc v0.5.3?  That'd be neat.

Keep us updated on your testing - particularly as we're now pushing to get a lcdproc release out.  I've worked with a number of people to iron out any bugs with the driver, so I hope that there aren't any left, but if there are, I'd rather find them sooner or later!

-Jonathan


      

From TELarson at west.com  Wed May 20 19:14:59 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Wed, 20 May 2009 14:14:59 -0500
Subject: [Lcdproc] small driver patches to support older compilers and
	systems
Message-ID: <226316B3E1F749498E28ACA66321D5BA2542B1BC@oma00cexmbx03.corp.westworlds.com>

Index: hd44780-serial.c
===================================================================
RCS file: /cvsroot/lcdproc/lcdproc/server/drivers/hd44780-serial.c,v
retrieving revision 1.19
diff -u -p -r1.19 hd44780-serial.c
--- hd44780-serial.c    21 Dec 2008 14:58:51 -0000      1.19
+++ hd44780-serial.c    20 May 2009 19:07:21 -0000
@@ -67,9 +67,13 @@ unsigned int bitrate_conversion[][2] = {
        { 4800, B4800 },
        { 9600, B9600 },
        { 19200, B19200 },
-       { 38400, B38400 },
-       { 57600, B57600 },
-       { 115200, B115200 }
+       { 38400, B38400 }
+#if defined(B57600)
+       , { 57600, B57600 }
+#endif
+#if defined(B115200)
+       , { 115200, B115200 }
+#endif
 #if defined(B230400)
        , { 230400, B230400 }
 #endif
@@ -143,6 +147,9 @@ hd_init_serial(Driver *drvthis)
        struct termios portset;
        char device[256] = DEFAULT_DEVICE;

+       unsigned int conf_bitrate;
+       size_t bitrate;
+
        /* READ CONFIG FILE */

        /* Get interface type */
@@ -173,9 +180,6 @@ hd_init_serial(Driver *drvthis)
        }

        /* Get bitrate */
-       unsigned int conf_bitrate;
-       size_t bitrate;
-
        conf_bitrate = drvthis->config_get_int(drvthis->name, "Speed", 0, SERIAL_IF.default_bitrate);
        if (conf_bitrate == 0)
                conf_bitrate = SERIAL_IF.default_bitrate;
Index: hd44780.c
===================================================================
RCS file: /cvsroot/lcdproc/lcdproc/server/drivers/hd44780.c,v
retrieving revision 1.90
diff -u -p -r1.90 hd44780.c
--- hd44780.c   26 Mar 2009 19:52:09 -0000      1.90
+++ hd44780.c   20 May 2009 19:07:21 -0000
@@ -73,6 +73,7 @@
 #include <unistd.h>
 #include <fcntl.h>
 #include <string.h>
+#include <strings.h>
 #include <errno.h>

 #ifdef HAVE_CONFIG_H
@@ -149,6 +150,7 @@ HD44780_init(Driver *drvthis)
        int if_type = IF_TYPE_UNKNOWN;
        int tmp;
        PrivateData *p;
+       char conf_charmap[MAX_CHARMAP_NAME_LENGTH];

        // Alocate and store private data
        p = (PrivateData *) calloc(1, sizeof(PrivateData));
@@ -346,8 +348,6 @@ HD44780_init(Driver *drvthis)
        }

        // Get configured charmap
-       char conf_charmap[MAX_CHARMAP_NAME_LENGTH];
-
        strncpy(conf_charmap, drvthis->config_get_string(drvthis->name, "charmap", 0, "hd44780_default"), MAX_CHARMAP_NAME_LENGTH);
        conf_charmap[MAX_CHARMAP_NAME_LENGTH-1] = '\0';
        p->charmap = 0;
Index: imonlcd.c
===================================================================
RCS file: /cvsroot/lcdproc/lcdproc/server/drivers/imonlcd.c,v
retrieving revision 1.1
diff -u -p -r1.1 imonlcd.c
--- imonlcd.c   14 May 2009 21:45:52 -0000      1.1
+++ imonlcd.c   20 May 2009 19:07:22 -0000
@@ -39,7 +39,9 @@
 #include <string.h>
 #include <errno.h>
 #include <time.h>
+#ifdef HAVE_STDINT_H
 #include <stdint.h>
+#endif
 #include <math.h>

 #ifdef HAVE_CONFIG_H

From Matt at mattsmith.cc  Thu May 21 04:08:03 2009
From: Matt at mattsmith.cc (Matt Smith)
Date: Thu, 21 May 2009 14:08:03 +1000
Subject: [Lcdproc] Driver for SoundGraph iMON LCD imported
In-Reply-To: <683237.18793.qm@web37506.mail.mud.yahoo.com>
References: <45476.59.167.59.98.1242838227.squirrel@coolchilli.com>
	<683237.18793.qm@web37506.mail.mud.yahoo.com>
Message-ID: <4A14D3A3.6000501@mattsmith.cc>

Hi Jonathan,

On 21/05/09 03:29 jk said the following:

> I somehow missed part of this conversation.
> 
> Glad to hear that the newer version of mythlcdserver is playing more nicely with lcdproc.  

I sent the original email before I subscribed to the list - perhaps the 
moderator either hasn't yet approved the original, or saw my response 
reply and decided not to approve.  Either way, I've supplied the 
original email for archive purposes at the bottom.

It is very strange to see that mythlcdserver doesn't play nice with teh 
proposed lcdproc 0.5.3 - I have looked (briefly, I must admit) at both 
change logs for recent modified files, and cannot see why it wouldn't work.
There is an entry in mythlcdserver which DOES explicitly advise that it 
has been changed to work with lcdproc 0.5.3 and it's priority codes - 
something which I believe was my original problem (ie. It's already 
fixed, just awaiting an "official" release).

I'm happy to assist with any testing for this driver and it's 
interactions with MythTV in particular - but my coding ability is 
somewhat limited.
Please keep me in mind if you require something tested.

As mentioned in my "follow-up" email, LCDd is still reporting a syntax 
error with the "client_add_key" call from mythlcdserver, so I'll have a 
look around the mythtv-dev list and see if I can find a fix there.

Thanks for your response, Jonathan.

Cheers,
Matt






-------- Original Message --------
Subject: RE: Driver for SoundGraph iMON LCD imported
Date: Wed, 20 May 2009 21:27:52 +1000 (EST)
From: Matt Smith
To: lcdproc at lists.omnipotent.net

Hi List,

 >The code has just been submitted to CVS HEAD and is available
 >immediately. It should also show up in the next -current nightly
 >tarball and will be part of release 0.5.3.

Firstly, Thanks for Markus et al for the fantastic work on this driver.
I've got a Soundgraph iMon (version 0038 from lsusb) from an Antec
MicroFusion remote (http://www.antec.com/Believe_it/product.php?id=NzEz).

I just compiled from CVS the other night (18 May 2009, approx 22:15
GMT+10), on a Mythdora 10.21 system (Fedora Core 10, MythTV 0.21), with
kernel 2.6.27.21.
Using LCDd and lcdproc display everything fine, as expected, and the extra
features (turning LCD off) work well (didn't play with any of the extra
icons though).

HOWEVER, MythTV talking to the screen via mythlcdserver results in just
blank screens, occasionally displaying the clock, but the colon isn't
animated (doesn't flash each second).
I also see an occasional error in LCDd (error: huh? invalid argument at
-priority) when running "LCDd -f -r 5", which, looking at some source from
both mythlcdserver and LCDd appears to relate to Mythlcdserver's use of
setting the priority to "0" to turn a screen off.

I'm using the protocol option "1" in the driver, other stuff is fairly
default.  The screen does turn off when the exit option is "2" - a feature
which i *love*!
Using lcdproc from yum repositories, lcdproc 0.5.2.7-fc10, works fine
including from mythlcdserver, just without the extra bits.

I'm no C programmer, so i'm struggling to find what is going on here.
I can manually connect to the LCDd deamon and create a screen, and set a
priority to "0". I'm confused where to look further.  The blank screens
are the strangest issue - as to why mythlcdserver isn't able to
create/draw the screens with the new version, I don't get it.

I'd appreciate any guidance and advice on where to look, and how to
troubleshoot this issue.
Again, I'm a big fan of the LCDd project, and combined with MythTV my Myth
Front End has never looked better!

Cheers,
Matt

From bsdfan at nurfuerspam.de  Thu May 21 18:42:04 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 21 May 2009 20:42:04 +0200
Subject: [Lcdproc] small driver patches to support older compilers
	and	systems
In-Reply-To: <226316B3E1F749498E28ACA66321D5BA2542B1BC@oma00cexmbx03.corp.westworlds.com>
References: <226316B3E1F749498E28ACA66321D5BA2542B1BC@oma00cexmbx03.corp.westworlds.com>
Message-ID: <20090521184204.111250@gmx.net>

-------- Original-Nachricht --------
> Datum: Wed, 20 May 2009 14:14:59 -0500
> Von: "Larson, Timothy E." <TELarson at west.com>
> An: "lcdproc at lists.omnipotent.net" <lcdproc at lists.omnipotent.net>
> Betreff: [Lcdproc] small driver patches to support older compilers and	systems

Hi,

would you please tell for which 'older compilers and systems' this patch is for?

I am especially curious about the '<strings.h>' requirement for hd44780.

The conditional includes with <termios.h> would affect the wirz-sli driver as well?


Please add patches as attachment to youe e-mail instead of inline text. Thank you.

Regards,
Markus

From bsdfan at nurfuerspam.de  Thu May 21 18:52:13 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 21 May 2009 20:52:13 +0200
Subject: [Lcdproc] LCDproc 0.5.3 release branch created
Message-ID: <20090521185213.63150@gmx.net>

Hi,

the day before yesterday I merged all changes from HEAD to stable-0-5-x. Today I created a release branch for the upcoming release.

Thus everybody interested testing what will be the next release should checkout / update their CVS sources:

'cvs update -d -P -r lcdproc-0-5-3'
or
'cvs -d:pserver:anonymous at lcdproc.cvs.sourceforge.net/cvsroot/lcdproc checkout -P -r lcdproc-0-5-3 lcdproc'

Regards
Markus

From TELarson at west.com  Thu May 21 19:00:46 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Thu, 21 May 2009 14:00:46 -0500
Subject: [Lcdproc] small driver patches to support older compilers
	and	systems
In-Reply-To: <20090521184204.111250@gmx.net>
References: <226316B3E1F749498E28ACA66321D5BA2542B1BC@oma00cexmbx03.corp.westworlds.com>
	<20090521184204.111250@gmx.net>
Message-ID: <226316B3E1F749498E28ACA66321D5BA2542B1C9@oma00cexmbx03.corp.westworlds.com>

> would you please tell for which 'older compilers and systems' this patch is for?
> 
> I am especially curious about the '<strings.h>' requirement for hd44780.

Using gcc 2.95, variable declarations evidently need to be at the top of the function.

AIX has the strcmp() family in strings.h instead of string.h.  Normally I wouldn't care too much about AIX, except that my Apple Network Server is what sparked my interest in this project to begin with.  :)  It would be really nice to get it (at least the server, meaning hd44780) working.

Related to that, AIX uses termiox.  I'm reading up on this now, but if anyone has experience and can point in the right direction, I'd appreciate it.

Thanks,
Tim

From bsdfan at nurfuerspam.de  Thu May 21 19:14:14 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 21 May 2009 21:14:14 +0200
Subject: [Lcdproc] Call for testers: getopt for clients
Message-ID: <20090521191414.111280@gmx.net>

Hi,

I need your help in testing the attached patch.

First the patch adds "shared" to the list of default include directories. Therefore the LCDproc shipped "getopt.h" will now be used for the clients as it is already used for the server.

Second it looks for getopt() rather then getopt_long() in the configure script to decide wether to use our own getopt implementation.

I tested it on FreeBSD and found no difference in behaviour.

This patch should allow building the clients on Solaris, but I need also request feedback for Linux and MacOS.

Thank you,
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clients.patch
Type: application/octet-stream
Size: 2563 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090521/3fac97aa/attachment.obj>

From bsdfan at nurfuerspam.de  Thu May 21 19:51:11 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 21 May 2009 21:51:11 +0200
Subject: [Lcdproc] Updating docs for 0.5.3 release
Message-ID: <20090521195111.293110@gmx.net>

Hi Guillaume,

I would like to update the documentation (user and developer's guide) for LCDproc 0.5.3 and the docs/index.html on our Sourceforge page as well as to remove some outdated doc downloads.

Currently all files are only writable by you. Please make them group writable so I can update them.

Additionally I remind you that the -current and -stable-0-5-x files generated every night still do not pull the latest changes from CVS.

Regards,
Markus

From gfk at logidac.com  Thu May 21 20:53:55 2009
From: gfk at logidac.com (Guillaume Filion)
Date: Thu, 21 May 2009 16:53:55 -0400
Subject: [Lcdproc] Updating docs for 0.5.3 release
In-Reply-To: <20090521195111.293110@gmx.net>
References: <20090521195111.293110@gmx.net>
Message-ID: <C4140BCE-3EF4-40F0-BA39-A488C182597D@logidac.com>

Le 09-05-21 ? 15:51, Markus Dolze a ?crit :
> Hi Guillaume,

Hi Markus,

> I would like to update the documentation (user and developer's  
> guide) for LCDproc 0.5.3 and the docs/index.html on our Sourceforge  
> page as well as to remove some outdated doc downloads.
>
> Currently all files are only writable by you. Please make them group  
> writable so I can update them.

Ok, I made nightly, docs, smoketests recursively group writable.

> Additionally I remind you that the -current and -stable-0-5-x files  
> generated every night still do not pull the latest changes from CVS.

Sorry for such a long delay. It's code that's I've not worked on for  
years and every time I try to figure out how it works, I get something  
more urgent to do... :-( I'll try to fix it tonight.

Thanks,
GFK's

From gfk at logidac.com  Fri May 22 13:30:11 2009
From: gfk at logidac.com (Guillaume Filion)
Date: Fri, 22 May 2009 09:30:11 -0400
Subject: [Lcdproc] Updating docs for 0.5.3 release
In-Reply-To: <20090522122940.146870@gmx.net>
References: <20090522122940.146870@gmx.net>
Message-ID: <4A16A8E3.6040506@logidac.com>

Markus Dolze a ?crit :
> Hi,

Hello Markus,

> it looks like I am missing some mails from the last days, so I cannot answer correctly, but I read http://lists.omnipotent.net/pipermail/lcdproc/2009-May/012960.html.

I got this bounce when writing to bsdfan at nurfuerspam.de:
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 550 550 5.7.1 We do not relay - access denied
{mx017} (state 14).

> Are you using scripts/nightly/make-docs.sh to create and upload the files? I tried it and it worked, except that xmlto and rsync live in /usr/local/bin instead of /usr/bin on my system. Unfortunately I have not installed the software necessary to create TXT and PDF formats.

Yes, it's the script that I'm using. I'm not sure how useful the PDF and
TXT formats were. HTML is definitely the most useful.

> I tried and uploaded {current|stable-0-5-x}-{dev|user}.html to SF and also created a new index page with is available as http://lcdproc.sourceforge.net/docs/index-new.html for preview.
> 
> What do you think?

It looks great.

> I would like to remove the outdated pdf,txt,split-html,tar.gz,tar.bz2 for {current|stable-0-5-x}{dev|user}.

Go for it.

> For the 0.5.3 release I plan to release the User Guide and Developers Guide as single html for online viewing and as split-html tar.gz for download.

Good idea.

Cheers,
GFK's

> Regards,
> Markus
-- 
Guillaume Filion
http://guillaume.filion.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090522/d5ba7ae8/attachment.pgp>

From bsdfan at nurfuerspam.de  Sun May 24 10:44:18 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 24 May 2009 12:44:18 +0200
Subject: [Lcdproc] small driver patches to support older compilers
	and	systems
In-Reply-To: <226316B3E1F749498E28ACA66321D5BA2542B1BC@oma00cexmbx03.corp.westworlds.com>
References: <226316B3E1F749498E28ACA66321D5BA2542B1BC@oma00cexmbx03.corp.westworlds.com>
Message-ID: <20090524104418.27260@gmx.net>

Hi Tim,

I had a closer look at your patches and the implications of it.

First here is a summary of your patches:
1. Changes required to build with gcc 2.95
2. Changes requires to build hd44780 on AIX
   a) Definitions from termios.h
   b) Including <strings.h>
   c) Conditionally include <stdint.h>

Here is what I observed:
1. No problem. I fixed a couple of those last week.

2a) This turned out to be a larger thing. Standardized (Open Group, Posix) are only speeds up to 38400. Everything larger is an extension. Thus not only the hd44780 driver is affected, but those as well:

CFontz, CFontz633, CFontzPaket, MD8800, NoritakeVFD, glk, pylcd, serialVFD and wirz-sli.

2b) This is specifically related to 'strcasecmp' and 'strncasecmp'. Some systems (looks like all those we supported up to now) either have those prototypes in string.h or include strings.h. AIX does not seem to do this.

This affects not only the hd44780 driver, but 
clients/lcdexec/lcdexec.c
clients/lcdexec/menu.c
clients/lcdproc/iface.c
clients/lcdproc/main.c
server/main.c
server/widget.c
server/drivers/curses_drv.c
server/drivers/hd44780.c
shared/configfile.c
server/drivers/MtxOrb.c
server/drivers/serialPOS.c
as well.

2c) Not a problem.

So, I will include 1 and 2c, but to fix building on AIX a lot of changes are required. Fixing 2b) could be done easily, but fixing 2a) is too much work than I want to put into fixing this for the release right now.

If you only want to use the hd44780 driver on AIX, I would include your fix, but if you want to have it fixed completely, I will defer this to 0.5.4.

Regards,
Markus

From andy at siliconlandmark.com  Sun May 24 16:42:55 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Sun, 24 May 2009 12:42:55 -0400
Subject: [Lcdproc] [PATCH] Missing NULL malloc() check in server/menuitem.c
Message-ID: <BC238BC5-A298-4350-B643-C3EAEAA060A5@siliconlandmark.com>

Hi,

I found an instance in server/menuitem.c where the return value of  
malloc() is not checked before the pointer is used in a call to  
strncpy(). The attached patch addresses the issue.

Could it be committed upon review?

Cheers,

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */


-------------- next part --------------
A non-text attachment was scrubbed...
Name: menuitem.diff
Type: application/octet-stream
Size: 674 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090524/99d4f06d/attachment.obj>

From bsdfan at nurfuerspam.de  Sun May 24 22:41:07 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 25 May 2009 00:41:07 +0200
Subject: [Lcdproc] [PATCH] Missing NULL malloc() check in
	server/menuitem.c
In-Reply-To: <BC238BC5-A298-4350-B643-C3EAEAA060A5@siliconlandmark.com>
References: <BC238BC5-A298-4350-B643-C3EAEAA060A5@siliconlandmark.com>
Message-ID: <4A19CD03.6050400@nurfuerspam.de>

Andre Guibert de Bruet wrote:
> Hi,
>
> I found an instance in server/menuitem.c where the return value of 
> malloc() is not checked before the pointer is used in a call to 
> strncpy(). The attached patch addresses the issue.
>
> Could it be committed upon review?
>
> Cheers,

Hi,

committed this to: HEAD
Merge to: stable-0-5-x: pending
Merge to: lcdproc-0-5-3: pending

looking closer at menuitem.c there are some more malloc which are not 
checked before used -> put this on the todo list.

Regards,
Markus


From andy at siliconlandmark.com  Mon May 25 14:06:08 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Mon, 25 May 2009 10:06:08 -0400
Subject: [Lcdproc] [PATCH] Missing NULL malloc() check in
	server/menuitem.c
In-Reply-To: <4A19CD03.6050400@nurfuerspam.de>
References: <BC238BC5-A298-4350-B643-C3EAEAA060A5@siliconlandmark.com>
	<4A19CD03.6050400@nurfuerspam.de>
Message-ID: <43B2391A-8B6C-464D-9675-CA174B45805D@siliconlandmark.com>

On May 24, 2009, at 6:41 PM, Markus Dolze wrote:

> Andre Guibert de Bruet wrote:
>>
>> I found an instance in server/menuitem.c where the return value of  
>> malloc() is not checked before the pointer is used in a call to  
>> strncpy(). The attached patch addresses the issue.
>>
>> Could it be committed upon review?
>>
>> Cheers,
>
> committed this to: HEAD
> Merge to: stable-0-5-x: pending
> Merge to: lcdproc-0-5-3: pending
>
> looking closer at menuitem.c there are some more malloc which are  
> not checked before used -> put this on the todo list.

I have some time today that I will use to look into this. Stay tuned.

Cheers,

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */



From andy at siliconlandmark.com  Mon May 25 14:39:43 2009
From: andy at siliconlandmark.com (Andre Guibert de Bruet)
Date: Mon, 25 May 2009 10:39:43 -0400
Subject: [Lcdproc] [PATCH] Missing NULL malloc() check in
	server/menuitem.c
In-Reply-To: <4A19CD03.6050400@nurfuerspam.de>
References: <BC238BC5-A298-4350-B643-C3EAEAA060A5@siliconlandmark.com>
	<4A19CD03.6050400@nurfuerspam.de>
Message-ID: <6149728D-A454-4F1E-AD43-77200A762A06@siliconlandmark.com>

On May 24, 2009, at 6:41 PM, Markus Dolze wrote:

> Andre Guibert de Bruet wrote:
>>
>> I found an instance in server/menuitem.c where the return value of  
>> malloc() is not checked before the pointer is used in a call to  
>> strncpy(). The attached patch addresses the issue.
>>
>> Could it be committed upon review?
>>
> committed this to: HEAD
> Merge to: stable-0-5-x: pending
> Merge to: lcdproc-0-5-3: pending
>
> looking closer at menuitem.c there are some more malloc which are  
> not checked before used -> put this on the todo list.

I have addressed a bunch of malloc-related issues this source file in  
the attached patch (Against HEAD). I have a list of additional issues  
with menuitem.c which I will address at a later date.

Could the attached patch be committed upon review?

Cheers,

/*  Andre Guibert de Bruet  * 436f 6465 2070 6f65 742e 2042 6974 206a */
/*     Managing Partner     * 6f63 6b65 792e 2053 7973 4164 6d69 6e2e */
/*   GSM: +1 734 846 8758   * 2055 4e49 5820 736c 6575 7468 2e00 0000 */
/* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */


-------------- next part --------------
A non-text attachment was scrubbed...
Name: menuitem.malloc.diff
Type: application/octet-stream
Size: 1908 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090525/7d4d7379/attachment.obj>
-------------- next part --------------


From rfc822sucks at hotmail.com  Tue May 26 21:15:59 2009
From: rfc822sucks at hotmail.com (nobody important)
Date: Tue, 26 May 2009 15:15:59 -0600
Subject: [Lcdproc] LCDproc telnet session hangs
Message-ID: <BAY124-W42E923D19CB8B0AB278A57FD520@phx.gbl>


Hello,

I threw together a script that does peak level meters for audio on FreeBSD.  A C program listens to the audio and spits out integers which is popen then a ruby loop then and 


vulcd.puts "widget_set stats vuleft 2 2 #{leftval}"
vulcd.puts "widget_set stats vuright 2 3 #{rightval}"

what I found is when I failed to 

vulcd.gets
vulcd.gets

and didn't read the success messages the LCDd process would start to use 26% CPU and fail to respond to new telnet sessions.   This owuld happen after about 30 minutes or 18000 messages.

this was using lcdproc-CVS-stable-0-5-x-20090522

Now in retrospect I should have likely read these messages, but it also seems LCDd could be more graceful and either discard the oldest or make some sort of warning to the logs (with highest verbosity i didn't see anything)

Just thought you guys might wanna know.   Otherwise thanks, things work well with a CFA-635 on FreeBSD 7.1 i386.

I don't know how to go about patching this, but I htought it might helop to let you know.

Steps to reproduce:  write out thousands of commands to LCDd telnet.  Fail to read any responses.

Thanks.

Douglas





_________________________________________________________________
Internet explorer 8 lets you browse the web faster.
http://go.microsoft.com/?linkid=9655582
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090526/43ac78b7/attachment.htm>

From TELarson at west.com  Wed May 27 03:31:16 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Tue, 26 May 2009 22:31:16 -0500
Subject: [Lcdproc] Call for testers: getopt for clients
In-Reply-To: <20090521191414.111280@gmx.net>
References: <20090521191414.111280@gmx.net>
Message-ID: <226316B3E1F749498E28ACA66321D5BA2542B1D7@oma00cexmbx03.corp.westworlds.com>

For Solaris, this patch worked fine (albeit building without the mtc_s16209x driver) after one small change - making inclusion of stdint.h conditional.

Tim


From TELarson at west.com  Wed May 27 03:44:07 2009
From: TELarson at west.com (Larson, Timothy E.)
Date: Tue, 26 May 2009 22:44:07 -0500
Subject: [Lcdproc] small driver patches to support older compilers
	and	systems
In-Reply-To: <20090524104418.27260@gmx.net>
References: <226316B3E1F749498E28ACA66321D5BA2542B1BC@oma00cexmbx03.corp.westworlds.com>
	<20090524104418.27260@gmx.net>
Message-ID: <226316B3E1F749498E28ACA66321D5BA2542B1D8@oma00cexmbx03.corp.westworlds.com>

> First here is a summary of your patches:
> 1. Changes required to build with gcc 2.95
> 2. Changes requires to build hd44780 on AIX
>    a) Definitions from termios.h
>    b) Including <strings.h>
>    c) Conditionally include <stdint.h>
> 
> Here is what I observed:
> 1. No problem. I fixed a couple of those last week.

Yes, these are very minor/trivial.

> 2a) This turned out to be a larger thing. Standardized (Open Group, Posix) are 
> only speeds up to 38400. Everything larger is an extension. Thus not only the 
> hd44780 driver is affected, but those as well:

This termio stuff may be the real stinker, in my opinion.  

> 2b) This is specifically related to 'strcasecmp' and 'strncasecmp'. Some systems 
> (looks like all those we supported up to now) either have those prototypes in 
> string.h or include strings.h. AIX does not seem to do this.
> 
> 2c) Not a problem.

Conditional inclusion of stdint.h is also needed for Solaris support.

> So, I will include 1 and 2c, but to fix building on AIX a lot of changes are 
> required. Fixing 2b) could be done easily, but fixing 2a) is too much work than 
> I want to put into fixing this for the release right now.
> 
> If you only want to use the hd44780 driver on AIX, I would include your fix, but 
> if you want to have it fixed completely, I will defer this to 0.5.4.

For the short term, I only care about hd44780 on AIX.  Obviously it would be better to have a complete fix, but I agree that can be deferred until later.  In fact, I'd support not pushing any of the 2a fixes into this release, if there's any concern of regression.  2b is just a matter of including strings.h in a few files that don't already do this, so should be trivial, but even that could wait.  As much as I'd like to see the AIX support I want, I'd rather see a good/solid release sooner rather than waiting on features only one person cares about.


Tim

From bsdfan at nurfuerspam.de  Sat May 30 10:39:31 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 30 May 2009 12:39:31 +0200
Subject: [Lcdproc] [PATCH] Missing NULL malloc() check in
	server/menuitem.c
In-Reply-To: <6149728D-A454-4F1E-AD43-77200A762A06@siliconlandmark.com>
References: <BC238BC5-A298-4350-B643-C3EAEAA060A5@siliconlandmark.com>
	<4A19CD03.6050400@nurfuerspam.de>
	<6149728D-A454-4F1E-AD43-77200A762A06@siliconlandmark.com>
Message-ID: <4A210CE3.4020708@nurfuerspam.de>

Andre Guibert de Bruet wrote:
> 
> I have addressed a bunch of malloc-related issues this source file in 
> the attached patch (Against HEAD). I have a list of additional issues 
> with menuitem.c which I will address at a later date.
> 
> Could the attached patch be committed upon review?
> 

Hi,


I had a look at your patch and the menu* part. It is perhaps one of the 
most complex part of LCDproc.

Tracing from menuitem_create to all more specific menuitem_create_*() 
functions and the calling functions I was puzzled by the result handling 
and rewrote parts of it. Patch is attached.

Some remarks:

1. All calls to malloc are checked for NULL now (based on Andre's 		 
patch).
2. All calls to strdup are checked as well, because subsequent calls to
    strlen(NULL) will result in core dump.
3. It is not necessary to free allocated memory and duplicates string in
    menuitem_create_*() IF menuitem_destroy() is called (the latter frees
    all allocated strings). However, I am not sure if I need to
    initialize all pointer to NULL before.
4. All calls to menu_create() are checked for NULL, exiting the current
    function in most cases.
5. I moved the creation of the test menu into its own function (as a
    result of 3).

Regards
Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: menu-alloc.patch
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090530/3280bac2/attachment.txt>

From bsdfan at nurfuerspam.de  Sat May 30 11:49:09 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 30 May 2009 13:49:09 +0200
Subject: [Lcdproc] small driver patches to support older compilers	and
 systems
In-Reply-To: <20090524104418.27260@gmx.net>
References: <226316B3E1F749498E28ACA66321D5BA2542B1BC@oma00cexmbx03.corp.westworlds.com>
	<20090524104418.27260@gmx.net>
Message-ID: <4A211D35.6090600@nurfuerspam.de>

Hi,

Markus Dolze wrote:
> Hi Tim,
>
> I had a closer look at your patches and the implications of it.
>
> First here is a summary of your patches:
> 1. Changes required to build with gcc 2.95
> 2. Changes requires to build hd44780 on AIX
>    a) Definitions from termios.h
>    b) Including <strings.h>
>    c) Conditionally include <stdint.h>
>
>   

I committed all ot these to cvs HEAD, but 2a only for hd44780 and added 
an entry to the TODO list.

Merge to: stable-0-5-x: pending
Merge to: lcdproc-0-5-3: pending

Regards,
Markus


From bsdfan at nurfuerspam.de  Sat May 30 16:51:03 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 30 May 2009 18:51:03 +0200
Subject: [Lcdproc] Removing LCDProc's scripts/debian
Message-ID: <4A2163F7.2090301@nurfuerspam.de>

Hi Everyone,

for the upcoming release of LCDproc 0.5.3 I am about to remove the 
scripts/debian directory.

This directory contains Debian specific files for building a package. I 
have not received feedback from Jose Luis and Robert for one week and 
have no idea what to put into these files.

Anyway, the maintainers have their own patch set for Debian so I guess 
not having these files is no problem.

@Jose Luis, Jonathan, and Robert: If you want to keep these files, have 
your patches included, or need any changes for the release, please join 
in this discussion.

Regards,
Markus


From rbu at gentoo.org  Sat May 30 18:29:37 2009
From: rbu at gentoo.org (Robert Buchholz)
Date: Sat, 30 May 2009 20:29:37 +0200
Subject: [Lcdproc] Removing LCDProc's scripts/debian
In-Reply-To: <4A2163F7.2090301@nurfuerspam.de>
References: <4A2163F7.2090301@nurfuerspam.de>
Message-ID: <200905302029.40525.rbu@gentoo.org>

Hi Markus,

On Saturday 30 May 2009, Markus Dolze wrote:
> for the upcoming release of LCDproc 0.5.3 I am about to remove the
> scripts/debian directory.
>
> This directory contains Debian specific files for building a package.
> I have not received feedback from Jose Luis and Robert for one week
> and have no idea what to put into these files.

I have received the CC of an email by Jos? Luis Tall?n last week, and he 
agreed to have the files removed. We don't use anything in scripts/* 
either.



Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090530/6ddc20f5/attachment.pgp>

From rw at nelianur.org  Sat May 30 19:25:42 2009
From: rw at nelianur.org (Rene Wagner)
Date: Sat, 30 May 2009 21:25:42 +0200
Subject: [Lcdproc] Removing LCDProc's scripts/debian
In-Reply-To: <200905302029.40525.rbu@gentoo.org>
References: <4A2163F7.2090301@nurfuerspam.de>
	<200905302029.40525.rbu@gentoo.org>
Message-ID: <1243711542.7671.17.camel@antarctica.nelianur.org>

On Sat, 2009-05-30 at 20:29 +0200, Robert Buchholz wrote:
> Hi Markus,
> 
> On Saturday 30 May 2009, Markus Dolze wrote:
> > for the upcoming release of LCDproc 0.5.3 I am about to remove the
> > scripts/debian directory.
> >
> > This directory contains Debian specific files for building a package.
> > I have not received feedback from Jose Luis and Robert for one week
> > and have no idea what to put into these files.
> 
> I have received the CC of an email by Jos? Luis Tall?n last week, and he 
> agreed to have the files removed. We don't use anything in scripts/* 
> either.

Can we by any chance keep communication on this sort of thing on the
mailing list (unless sensitive in nature)?

Thanks,

Rene


From rw at nelianur.org  Sat May 30 19:41:14 2009
From: rw at nelianur.org (Rene Wagner)
Date: Sat, 30 May 2009 21:41:14 +0200
Subject: [Lcdproc] Removing LCDProc's scripts/debian
In-Reply-To: <4A2163F7.2090301@nurfuerspam.de>
References: <4A2163F7.2090301@nurfuerspam.de>
Message-ID: <1243712474.7671.27.camel@antarctica.nelianur.org>

Hi Markus,

On Sat, 2009-05-30 at 18:51 +0200, Markus Dolze wrote:
> for the upcoming release of LCDproc 0.5.3 I am about to remove the 
> scripts/debian directory.
> 
> This directory contains Debian specific files for building a package. I 
> have not received feedback from Jose Luis and Robert for one week and 
> have no idea what to put into these files.

The directory also contains init scripts. And the CVS log entries
indicate that there are quite a few improvements in our CVS compared to
Debian. It would be unfortunate if those got lost.

I would suggest to have these changes reviewed and merged rather than
removed.

As for where to keep the mandatory copy of Debian init scripts and build
files (Debian vs. LCDproc CVS), I don't think there's an easy answer to
that. The original source of the init scripts was LCDproc CVS. The build
files were apparently added to CVS to build custom Debian packages from
CVS snapshots. The latter is certainly useful and not too uncommon. It's
also usually not a problem for Debian if kept in a directory other than
${toplevel}/debian.

If you feel uncomfortable shipping the directory in the release tarballs
please just drop it from the respective Makefile.am for now until the
above points can be resolved properly.

Cheers,

Rene


From fblack947 at yahoo.com  Sat May 30 22:29:32 2009
From: fblack947 at yahoo.com (jk)
Date: Sat, 30 May 2009 15:29:32 -0700 (PDT)
Subject: [Lcdproc] Removing LCDProc's scripts/debian
In-Reply-To: <4A2163F7.2090301@nurfuerspam.de>
References: <4A2163F7.2090301@nurfuerspam.de>
Message-ID: <594635.58567.qm@web37501.mail.mud.yahoo.com>


More below,



----- Original Message ----
> From: Markus Dolze <bsdfan at nurfuerspam.de>
> To: lcdproc at lists.omnipotent.net
> Sent: Saturday, May 30, 2009 12:51:03 PM
> Subject: [Lcdproc] Removing LCDProc's scripts/debian
> 
> Hi Everyone,
> 
> for the upcoming release of LCDproc 0.5.3 I am about to remove the 
> scripts/debian directory.
> 
> This directory contains Debian specific files for building a package. I have not 
> received feedback from Jose Luis and Robert for one week and have no idea what 
> to put into these files.
> 
> Anyway, the maintainers have their own patch set for Debian so I guess not 
> having these files is no problem.
> 
> @Jose Luis, Jonathan, and Robert: If you want to keep these files, have your 
> patches included, or need any changes for the release, please join in this 
> discussion.
> 
> Regards,
> Markus
> 


I realize you were targeting another Jonathan...

I'm
using Ubuntu versions of Linux, which are debian based, but have little
clue how the maintainers use the scripts to update their distributions.

I'll see if I can get a Ubuntu person to weigh in, or even help out with packaging, as I have no clue about that stuff.

-Jonathan K.


      

From bsdfan at nurfuerspam.de  Sun May 31 09:49:44 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 31 May 2009 11:49:44 +0200
Subject: [Lcdproc] Removing LCDProc's scripts/debian
In-Reply-To: <1243712474.7671.27.camel@antarctica.nelianur.org>
References: <4A2163F7.2090301@nurfuerspam.de>
	<1243712474.7671.27.camel@antarctica.nelianur.org>
Message-ID: <4A2252B8.3020201@nurfuerspam.de>

Hi Rene and others,

Rene Wagner wrote:
> Hi Markus,
> 
> On Sat, 2009-05-30 at 18:51 +0200, Markus Dolze wrote:
>> for the upcoming release of LCDproc 0.5.3 I am about to remove the 
>> scripts/debian directory.
>>
>> This directory contains Debian specific files for building a package. I 
>> have not received feedback from Jose Luis and Robert for one week and 
>> have no idea what to put into these files.
> 
> The directory also contains init scripts. And the CVS log entries
> indicate that there are quite a few improvements in our CVS compared to
> Debian. It would be unfortunate if those got lost.
> 
> I would suggest to have these changes reviewed and merged rather than
> removed.

Indeed, but this is up to the Debian people.

> 
> As for where to keep the mandatory copy of Debian init scripts and build
> files (Debian vs. LCDproc CVS), I don't think there's an easy answer to
> that. The original source of the init scripts was LCDproc CVS. The build
> files were apparently added to CVS to build custom Debian packages from
> CVS snapshots. The latter is certainly useful and not too uncommon. It's
> also usually not a problem for Debian if kept in a directory other than
> ${toplevel}/debian.
> 


This is similar to what I do for FreeBSD. There is an official port 
maintained in FreeBSD's CVS and there is some 'lcdproc-devel' port I 
maintain in a local CVS.

The task is to keep track of the Distribution's changes (e.g. to the 
build infrastructure) for the -devel port and to push new versions into 
the Distribution's main port.


> If you feel uncomfortable shipping the directory in the release tarballs
> please just drop it from the respective Makefile.am for now until the
> above points can be resolved properly.
> 

Shipping these files with our _release_ tarball makes little sense to me 
as the Debian project will (have to) patch them anyway.

I think of removing them from the release branch and merge Debian's 
changes into our files after the release and import them to HEAD branch.

Regards
Markus