lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] small patch for plugin_mkfifo

[Michael R. <mi...@re...>]

Hi Mattia,

thanks a bunch for pointing this out! I didn't read the code that careful (fortunately you did!), but I'm afraid even if
I did I would have missed this...

as you already provided a clean solution, could you please check it in?



TIA, Michael

Mattia Jona-Lasinio schrieb:
> Hi Claas, Michael and The List!
> 
> IMHO explicitely clearing the errno variable is generally a _VEEEEERY_
> bad idea and should never be done.
> errno should be treated like a read only variable that one must assume
> to be completely undefined before a function that is allowed to modify
> it, is actually called. This means that its value must not be checked
> before calling the function that might change it, is actually called.
> And in any case the errno value must be checked only after checking
> the return value of the called function.
> Unfortunately in plugin_fifo.c, line 191
> 
> while (bytes > 0 && errno != EINTR) {
>             bytes = read(fd.input, buf, FIFO_BUFFER_SIZE);
> }
> 
> the value of errno is checked BEFORE the very first call to read. Then
> a previous function call might had set its value to EINTR and we are
> not going to read anything just because errno was spuriously set. In
> any case this piece of code is buggy because errno is set by read only
> if bytes < 0 OR 0 <= bytes < FIFO_BUFFER_SIZE, but is untouched
> (therefore still undefined) if bytes == FIFO_BUFFER_SIZE.
> 
> But the solution is not clearing errno, but rather changing the code
> above to fix this bug. Something like
> 
> while ((bytes = read(fd.input, buf, FIFO_BUFFER_SIZE)) > 0) {
>               if (bytes < FIFO_BUFFER_SIZE && errno == EINTR)
>                             break;
> }
> 
> so that the bytes = 1 initialization is not necessary.
> 
> At this point the subsequent test
> 
> if (bytes < 0 || (errno > 0 && errno != EAGAIN)) {
>             error("[FIFO] Error %i: %s", errno, strerror(errno));
> }
> 
> becomes meaningful but one has to distinguish the cases "bytes < 0"
> (read returned an error) from "bytes < FIFO_BUFFER_SIZE" (there was
> just a "short" read), so that it should be something like
> 
> if (bytes < 0 || (bytes < FIFO_BUFFER_SIZE && errno > 0 && errno != EAGAIN)) {
>             error("[FIFO] Error %i: %s", errno, strerror(errno));
> }
> 
> 
> What do you think about all this?
> 
> 
> Bye!
> 
> 
> Mattia
> 
> 
> 
> On Thu, Feb 4, 2010 at 10:38 AM, Michael Reinelt <mi...@re...> wrote:
>> Applied! Thanks!
>>
>> Claas Hilbrecht schrieb:
>>> Hello,
>>>
>>> here is a very small fix (against current svn) for the plugin_fifo. You
>>> need to clear errno after creating the FIFO. Without clearing the errno
>>> variable you will get an error in fiforead() like this:
>>>
>>> [FIFO] Error 2: No such file or directory
>>>
>>>
>>> babel@eisler:~/tmp/lcd4linux$ svn diff plugin_fifo.c
>>> Index: plugin_fifo.c
>>> ===================================================================
>>> --- plugin_fifo.c       (Revision 1097)
>>> +++ plugin_fifo.c       (Arbeitskopie)
>>> @@ -110,6 +110,8 @@
>>>         error("Couldn't create FIFO \"%s\": %s\n", fd.path,
>>> strerror(errno));
>>>         return -1;
>>>      }
>>> +    /* clear errno */
>>> +    errno = 0;
>>>      fd.created = 1;
>>>      return 0;
>>>  }
>>>
>>> Mit freundlichem Gruss
>>> Claas Hilbrecht
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> Stay online with enterprise data centers and the best network in the business
>>> Choose flexible plans and management services without long-term contracts
>>> Personal 24x7 support from experience hosting pros just a phone call away.
>>> http://p.sf.net/sfu/theplanet-com
>>> _______________________________________________
>>> Lcd4linux-devel mailing list
>>> Lcd...@li...
>>> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
>>>
>>>
>> --
>> Michael Reinelt <mi...@re...>
>> http://home.pages.at/reinelt
>> GPG-Key 0xDF13BA50
>> ICQ #288386781
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the business
>> Choose flexible plans and management services without long-term contracts
>> Personal 24x7 support from experience hosting pros just a phone call away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Lcd4linux-devel mailing list
>> Lcd...@li...
>> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
>>
> 
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Lcd4linux-devel mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
> 
> 

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] Comments on "timer.c"

[Michael R. <mi...@re...>]

Hi Martin,

> So I have changed the corresponding line in "timer.c" from
> 
>    if (timercmp(&Timers[i].when, &now, <=)) {
> 
> to
> 
>    if (!timercmp(&Timers[i].when, &now, >)) {
> 
> and committed this to SVN.

I think this is fine.

> 2) I find the function "timer_inc()" rather messy.  Why not change it to

Well, most of the mess seems to come from the fact that my mind lost the modulo function :-)

apart from that, timeradd() expands to nearly the same code than yours. For me both are ok, but if you feel mess-lesser
with your version, go for it! :-)


bye, Michael

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] Comments on "timer.c"

[Martin Z. <co...@mz...>]

Hi everybody!

On looking through "timer.c", I have found a few things that I want to
share with you.

1) Here's an excerpt of the manpage for "timercmp()":

   Some systems (but not Linux/glibc), have a broken timercmp()
   implementation, in which CMP of >=, <=, and == do not work; portable
   applications can instead use

     !timercmp(..., <)
     !timercmp(..., >)
     !timercmp(..., !=)

So I have changed the corresponding line in "timer.c" from

   if (timercmp(&Timers[i].when, &now, <=)) {

to

   if (!timercmp(&Timers[i].when, &now, >)) {

and committed this to SVN.

2) I find the function "timer_inc()" rather messy.  Why not change it to

   static void timer_inc(struct timeval *tv, const int msec)
   {
       struct timeval diff;
       diff.tv_sec = msec / 1000;
       diff.tv_usec = (msec % 1000) * 1000;

       timeradd(tv, &diff, tv);
   }

This is much less messy and works just as well.  I have not committed
this to SVN, as according to its manpage, "timeradd()" is

   Not in POSIX.1-2001.  Present on most BSD derivatives.

However, you already use "timercmp()", and the same restriction applies
here.  Thus, using "timeradd()" should be fine.  Shall I commit, or
shan't I commit?  That is the question... ;)

3) The variable "flag" in "timer_process()" is completely useless (it is
always "1" when tested).  This variable should either be removed for
clarity, or the code should be changed so it actually serves a purpose.

Best regards,

Martin
-- 
www.mzuther.de
www.radix-musik.de

[Lcd4linux-devel] Comments on "timer.c"

[Martin Z. <co...@mz...>]

Hi everybody!

> 3) The variable "flag" in "timer_process()" is completely useless (it is
> always "1" when tested).  This variable should either be removed for
> clarity, or the code should be changed so it actually serves a purpose.

Please ignore this comment -- "flag" *was* useless in the part marked as

   /* process expired timers */

and I have thus removed it.  It however *does* serve a purpose later on
in the part

   /* find next timer */

Sorry for my mistake...

Martin
-- 
www.mzuther.de
www.radix-musik.de

Re: [Lcd4linux-devel] Synchronised widget updates

[Martin Z. <co...@mz...>]

Hi Michael,

I think you have gotten me wrong.  The timers run pretty fine.  The 
problem is that each widget has its own timer with its own starting 
time, so the widgets aren't synchronised to begin with.

Also, I have *not* rewritten the timer code.  I have only copied 
"timer.c" because I wanted to keep the basic functionality of allocating 
memory for storing callback functions and so on.  I did this to save me 
work and also because I'm not used to programming in C (I'm more used to 
C++).

The *functionality* of "timer_group.c" is completely different from 
"timer.c": it creates a group and a corresponding timer that registers 
"the group" as its callback.  Widgets are added to the group with their 
callback data (callback function and data, "one_shot" and so on) and 
each widget's callback function is called when the group timer "triggers".

Let's look at a simple example of three widgets:

   Widget Line1 {
       [...]
       update 200
   }

   Widget Line2 {
       [...]
       update 500
   }

   Widget Line3 {
       [...]
       update 200
   }


*** Current behaviour ***

When widget "Line1" is initialised, a new timer (200 ms) is set up and 
stores callback function, callback data and a few status things.  This 
is repeated for "Line2" (500 ms) and "Line3" (200 ms), resulting in 
three timers.  As initialisation takes time, there is a small delay 
between starting the timers for "Line1" and "Line3", even though they 
have the same update interval.

This delay (to keep it simple, let's say 1 ms for each widget) is 
responsible for the "drifting".  Normally, "Line1" and "Line3" would be 
updated after each other.  But occasionally, "Line2" gets in between:

  ms   widget
---------------
  200  Line1
  202  Line3

  400  Line1
  402  Line3

  501  Line2

  600  Line1
  602  Line3

  800  Line1
  802  Line3

1000  Line1
1001  Line2  <--
1002  Line3

And this is were my patch comes in.


*** Synchronised widget updates ***

When widget "Line1" is initialised, a group (200 ms) is created and a 
corresponding timer is set up.  However, callback data are *not* stored 
by the timer, but by the group.  The timer instead stores callback data 
of *the group*.

When widget "Line2" is initialised, a second group (500 ms) is created, 
a corresponding timer is set up and callback data are stored in this group.

Now it gets interesting: when widget "Line3" is initialised, *no* new 
group is created.  Instead, the first group (200 ms) is used to store 
this widget's callback data.

  ms   widgets
---------------
  200  Line1, Line3

  400  Line1, Line3

  501  Line2

  600  Line1, Line3

  800  Line1, Line3

1000  Line1, Line3
1001  Line2         <--


So now, you only have two timers instead of three, and widgets with the 
same update interval are updated at the same time.  Nice and easy... :)


This functionality can, however, not be included in "timer.c" -- at 
least not easily.  This is because:

  * many of the display drivers use "timer_add()", but shouldn't be in a
    group with widgets

  * scrolling text widgets (i.e. marquee or ping pong) define two timers,
    and my code breaks if the scrolling timer is added to a group which
    already contains widgets (this could probably be solved easily)

Now that was a long email. :)  Hopefully, I have clarified myself...

Martin
-- 
www.mzuther.de
www.radix-musik.de

Re: [Lcd4linux-devel] small patch for plugin_mkfifo

[Mattia Jona-L. <mat...@gm...>]

Hi Claas, Michael and The List!

IMHO explicitely clearing the errno variable is generally a _VEEEEERY_
bad idea and should never be done.
errno should be treated like a read only variable that one must assume
to be completely undefined before a function that is allowed to modify
it, is actually called. This means that its value must not be checked
before calling the function that might change it, is actually called.
And in any case the errno value must be checked only after checking
the return value of the called function.
Unfortunately in plugin_fifo.c, line 191

while (bytes > 0 && errno != EINTR) {
            bytes = read(fd.input, buf, FIFO_BUFFER_SIZE);
}

the value of errno is checked BEFORE the very first call to read. Then
a previous function call might had set its value to EINTR and we are
not going to read anything just because errno was spuriously set. In
any case this piece of code is buggy because errno is set by read only
if bytes < 0 OR 0 <= bytes < FIFO_BUFFER_SIZE, but is untouched
(therefore still undefined) if bytes == FIFO_BUFFER_SIZE.

But the solution is not clearing errno, but rather changing the code
above to fix this bug. Something like

while ((bytes = read(fd.input, buf, FIFO_BUFFER_SIZE)) > 0) {
              if (bytes < FIFO_BUFFER_SIZE && errno == EINTR)
                            break;
}

so that the bytes = 1 initialization is not necessary.

At this point the subsequent test

if (bytes < 0 || (errno > 0 && errno != EAGAIN)) {
            error("[FIFO] Error %i: %s", errno, strerror(errno));
}

becomes meaningful but one has to distinguish the cases "bytes < 0"
(read returned an error) from "bytes < FIFO_BUFFER_SIZE" (there was
just a "short" read), so that it should be something like

if (bytes < 0 || (bytes < FIFO_BUFFER_SIZE && errno > 0 && errno != EAGAIN)) {
            error("[FIFO] Error %i: %s", errno, strerror(errno));
}


What do you think about all this?


Bye!


Mattia



On Thu, Feb 4, 2010 at 10:38 AM, Michael Reinelt <mi...@re...> wrote:
> Applied! Thanks!
>
> Claas Hilbrecht schrieb:
>> Hello,
>>
>> here is a very small fix (against current svn) for the plugin_fifo. You
>> need to clear errno after creating the FIFO. Without clearing the errno
>> variable you will get an error in fiforead() like this:
>>
>> [FIFO] Error 2: No such file or directory
>>
>>
>> babel@eisler:~/tmp/lcd4linux$ svn diff plugin_fifo.c
>> Index: plugin_fifo.c
>> ===================================================================
>> --- plugin_fifo.c       (Revision 1097)
>> +++ plugin_fifo.c       (Arbeitskopie)
>> @@ -110,6 +110,8 @@
>>         error("Couldn't create FIFO \"%s\": %s\n", fd.path,
>> strerror(errno));
>>         return -1;
>>      }
>> +    /* clear errno */
>> +    errno = 0;
>>      fd.created = 1;
>>      return 0;
>>  }
>>
>> Mit freundlichem Gruss
>> Claas Hilbrecht
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the business
>> Choose flexible plans and management services without long-term contracts
>> Personal 24x7 support from experience hosting pros just a phone call away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Lcd4linux-devel mailing list
>> Lcd...@li...
>> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
>>
>>
>
> --
> Michael Reinelt <mi...@re...>
> http://home.pages.at/reinelt
> GPG-Key 0xDF13BA50
> ICQ #288386781
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Lcd4linux-devel mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
>

Re: [Lcd4linux-devel] small patch for plugin_mkfifo

[Michael R. <mi...@re...>]

Applied! Thanks!

Claas Hilbrecht schrieb:
> Hello,
> 
> here is a very small fix (against current svn) for the plugin_fifo. You 
> need to clear errno after creating the FIFO. Without clearing the errno 
> variable you will get an error in fiforead() like this:
> 
> [FIFO] Error 2: No such file or directory
> 
> 
> babel@eisler:~/tmp/lcd4linux$ svn diff plugin_fifo.c
> Index: plugin_fifo.c
> ===================================================================
> --- plugin_fifo.c       (Revision 1097)
> +++ plugin_fifo.c       (Arbeitskopie)
> @@ -110,6 +110,8 @@
>         error("Couldn't create FIFO \"%s\": %s\n", fd.path, 
> strerror(errno));
>         return -1;
>      }
> +    /* clear errno */
> +    errno = 0;
>      fd.created = 1;
>      return 0;
>  }
> 
> Mit freundlichem Gruss
> Claas Hilbrecht
> 
> 
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Lcd4linux-devel mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
> 
> 

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] small patch for plugin_mkfifo

[Claas H. <Cla...@li...>]

Hello,

here is a very small fix (against current svn) for the plugin_fifo. You 
need to clear errno after creating the FIFO. Without clearing the errno 
variable you will get an error in fiforead() like this:

[FIFO] Error 2: No such file or directory


babel@eisler:~/tmp/lcd4linux$ svn diff plugin_fifo.c
Index: plugin_fifo.c
===================================================================
--- plugin_fifo.c       (Revision 1097)
+++ plugin_fifo.c       (Arbeitskopie)
@@ -110,6 +110,8 @@
        error("Couldn't create FIFO \"%s\": %s\n", fd.path, 
strerror(errno));
        return -1;
     }
+    /* clear errno */
+    errno = 0;
     fd.created = 1;
     return 0;
 }

Mit freundlichem Gruss
Claas Hilbrecht

Re: [Lcd4linux-devel] Synchronised widget updates

[Michael R. <mi...@re...>]

Hi Martin,

> I had a long train ride today and, after staring at the beautiful,
> snow-filled landscape for hours, had a go at synchronising widget
> updates.  I won't commit this to SVN before I have the all-go, though,
> as I don't know whether my patch might introduce a lag on some LCD
> updates and whether you actually want synchronised widgets.  That being
> said, the patch works flawless on the X display driver and my picoLCD
> 256x64.
> 
> Here's what I did: I basically duplicated "timer.c" and "timer.h".  I
> also changed all the widgets to call "timer_add_widget()" instead of
> "timer_add()".  This function stores all the necessary callback data and
> allocates a new timer -- but only one timer for each update interval.
> This timer then regularly calls "timer_process_group()", which processes
> all widgets with the given update data.  This not only synchronises
> widgets, but also gets rid of a lot of unessesary timers.  Simple, but
> quite effective.

Sounds very interesting!

What do you think is the reason for the various timers loosing sync over time?

I did *not* apply the patch, for a simple reason: I don't think its necessary to duplicate a lot of stuff, because if
the new syncronous timers are fine, why not just replace the olt timers completely?

Is there anybody / anything that relies on the old functionality?


bye, Michael

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] Synchronised widget updates

[Martin Z. <co...@mz...>]

Hi!

I had a long train ride today and, after staring at the beautiful, 
snow-filled landscape for hours, had a go at synchronising widget 
updates.  I won't commit this to SVN before I have the all-go, though, 
as I don't know whether my patch might introduce a lag on some LCD 
updates and whether you actually want synchronised widgets.  That being 
said, the patch works flawless on the X display driver and my picoLCD 
256x64.

Here's what I did: I basically duplicated "timer.c" and "timer.h".  I 
also changed all the widgets to call "timer_add_widget()" instead of 
"timer_add()".  This function stores all the necessary callback data and 
allocates a new timer -- but only one timer for each update interval. 
This timer then regularly calls "timer_process_group()", which processes 
all widgets with the given update data.  This not only synchronises 
widgets, but also gets rid of a lot of unessesary timers.  Simple, but 
quite effective.

If you wish to, please run "lcd4linux" with the attached configuration 
file "synchronise.conf".  You will see a lot of icons that pop up and 
vanish rather irregularly.  After applying my patch, all boxes of a 
given update interval appear at once and vanish in the same way.

By the way, I added "timer_group.c" and "timer_group.h" to 
"Makefile.am", ran "./bootstrap", "./configure" and "make".  I hope that 
this was the correct thing to do -- I have never used "automake" 
before... ;)

Best regards,

Martin
-- 
www.mzuther.de
www.radix-musik.de

Re: [Lcd4linux-devel] Compile error since revision 1082

[Michael R. <mi...@re...>]

Martin Zuther schrieb:
> Hi Mattia!
> 
>  > I could do this this if I had writing permission to the repository.
> 
> Mind you that changing all the plugins is just a cosmetic change.  If it 
> was important, I would have done so already... ;)

Already done. There should be no *.c file that does not include config.h


bye, Michael

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] Compile error since revision 1082

[Martin Z. <co...@mz...>]

Hi Mattia!

 > I could do this this if I had writing permission to the repository.

Mind you that changing all the plugins is just a cosmetic change.  If it 
was important, I would have done so already... ;)

Martin
-- 
www.mzuther.de
www.radix-musik.de

[Lcd4linux-devel] picoLCD 256x64 polling very slow

[Martin Z. <co...@mz...>]

Hi!

Today I have finally received my LCD, a picoLCD 256x64.  I was pretty 
impressed how easy the switch from the X11 driver to the actual LCD was 
-- kudos to all of you!  Everthing works fine, however polling the 
buttons using LCD::GPI(1) considerable slows down output on the LCD.  I 
had a look at "drv_picoLCDGraphic.c" and the problem seems to lie in the 
function "drv_pLG_read()".

   static int drv_pLG_read(unsigned char *data, int size)
   {
       return usb_interrupt_read(lcd, USB_ENDPOINT_IN + 1, (char *) data,
           size, 1000);
   }

When I change the timeout value from 1000 to 25 or so, keypress data are 
still received, but there is no notable delay from polling.  If however 
I change timeout to 10000, there is a delay of ten seconds, leading me 
to the suspicion that the polling times out in every single calls of 
"usb_interrupt_read()".  Is this a bug or actually a feature? ;)

Here's what I get when I start lcd4linux with "-Fvv" (skipping the 
config file dump):

   [config file dump]

   plugin_cfg.c: Variable n = '0' (0)
   lcd4linux.c: initializing driver picoLCDGraphic
   picoLCDGraphic: $Rev: 1068 $
   PICOLCD Graphic initialization

   Setting display inverted to 0
   picoLCDGraphic: scanning for picoLCD 256x64...
   picoLCDGraphic: found picoLCD on bus 003 device 003
   picoLCDGraphic: interface 0 already claimed by 'usbhid'
   picoLCDGraphic: attempting to detach driver...
   picoLCDGraphic: Manufacturer='ITUNER INC' Product='USB-LCD-256x64'
     SerialNumber='Ver.00.03'
   drv_picoLCDGraphic.c: drv_pLG_start(): allocated 

   drv_picoLCDGraphic.c: drv_pLG_start(): zeroed 

   Setting contrast to 230
   Setting backlight to 1
   In drv_pLG_clear

   picoLCDGraphic: using 1 GPI's and 8 GPO's
   initializing layout 'picoLCD'

   [and now the usual stuff of entering main loop and so forth]

If anybody has got this LCD, I'll attach my config file.  It basically 
prints "uptime()" and the keypress state on a couple of lines.

I'll be off for a couple of days, so take your time... :)

Thanks,

Martin
-- 
www.mzuther.de
www.radix-musik.de

Re: [Lcd4linux-devel] Compile error since revision 1082

[Mattia Jona-L. <mat...@gm...>]

Hi Martin

I could do this this if I had writing permission to the repository.
And also modify drv.h and widget.h accordingly.

Does Michael agree on giving me such permission?

Best,

Mattia



On Wed, Jan 20, 2010 at 12:13 AM, Martin Zuther <co...@mz...> wrote:
> Hi Mattia,
>
> as you suggested, I have added "config.h" to "plugin.h" and adapted
> "plugin.c" and "plugin_sample.c".  I *might* do this for all 44 plugins if I
> feel particularly bored, but on the other hand, I might as well not. ;)
>
> Martin
> --
> www.mzuther.de
> www.radix-musik.de
>
>

Re: [Lcd4linux-devel] Compile error since revision 1082

[Martin Z. <co...@mz...>]

Hi Mattia,

as you suggested, I have added "config.h" to "plugin.h" and adapted 
"plugin.c" and "plugin_sample.c".  I *might* do this for all 44 plugins 
if I feel particularly bored, but on the other hand, I might as well not. ;)

Martin
-- 
www.mzuther.de
www.radix-musik.de

Re: [Lcd4linux-devel] Compile error since revision 1082

[Mattia Jona-L. <mat...@gm...>]

Hi Martin,

It definitely makes sense. Though it would be even better to put it in
some general header
like plugin.h. The configuration is not something "per plugin". Since
all plugins include plugin.h,
config.h would be included automatically in a natural way.

In the same spirit it would make sense to put an include config.h in
drv.h and widget.h.

But this is, of course, a matter of taste.

Bye!

Mattia


On Tue, Jan 19, 2010 at 1:31 PM, Martin Zuther <co...@mz...> wrote:
> Hi Mattia,
>
> thanks!  You're right, "lcd4linux" compiles as a charm after making the
> change, and I have already committed this to SVN.  Moreover, I have
> looked through the other plugins to made sure that all of them include
> "config.h".  (They do. <g>)
>
> Do you think it would make sense to change "plugin_sample.c" from
>
>   /* define the include files you need */
>   #include "config.h"
>
>   #include <stdlib.h>
>   #include <string.h>
>   #include <ctype.h>
>
>   /* these should always be included */
>   (...)
>
> to
>
>   /* this file should always be included */
>   #include "config.h"
>
>   /* define the include files you need */
>   #include <stdlib.h>
>   #include <string.h>
>   #include <ctype.h>
>
>   /* these should always be included */
>   (...)
>
> In this way, everybody would see that "config.h" shouldn't be removed.
>
> Martin
> --
> www.mzuther.de
> www.radix-musik.de
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Lcd4linux-devel mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
>

Re: [Lcd4linux-devel] Compile error since revision 1082

[Martin Z. <co...@mz...>]

Hi Mattia,

thanks!  You're right, "lcd4linux" compiles as a charm after making the 
change, and I have already committed this to SVN.  Moreover, I have 
looked through the other plugins to made sure that all of them include 
"config.h".  (They do. <g>)

Do you think it would make sense to change "plugin_sample.c" from

   /* define the include files you need */
   #include "config.h"

   #include <stdlib.h>
   #include <string.h>
   #include <ctype.h>

   /* these should always be included */
   (...)

to

   /* this file should always be included */
   #include "config.h"

   /* define the include files you need */
   #include <stdlib.h>
   #include <string.h>
   #include <ctype.h>

   /* these should always be included */
   (...)

In this way, everybody would see that "config.h" shouldn't be removed.

Martin
-- 
www.mzuther.de
www.radix-musik.de

Re: [Lcd4linux-devel] Compile error since revision 1082

[Mattia Jona-L. <mat...@gm...>]

Hi Michael and Martin

The problem is simply that the file plugin_python.c does not include
(as it should)
the header config.h

You should add

#include "config.h"

as the first header to include. In this way lcd4linux compiles as a charm.


Bye!

Mattia


On Tue, Jan 19, 2010 at 12:16 PM, Martin Zuther <co...@mz...> wrote:
> Hi Michael,
>
> you're correct, "lcd4linux" does compile without python support.  Also,
> if I replace
>
>   // #ifndef HAVE_STRNDUP
>
> with
>
>   #if ! defined HAVE_STRNDUP && ! defined Py_PYTHON_H
>
> "lcd4linux" compiles with python support.  This does not really help,
> though, as "Python.h" simply includes "string.h" which then adds the
> definition for "strndup".  Therefore, changing the above line to
>
>   #if ! defined HAVE_STRNDUP && ! defined _STRING_H
>
> also works.  And I rather guess that _STRING_H is defined on most systems...
>
> Martin
> --
> www.mzuther.de
> www.radix-musik.de
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Lcd4linux-devel mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel
>

[Lcd4linux-devel] Can lcd4linux used with a TFT Display (8/16 bit 8080 interface)?

[Michelle K. <lin...@ta...>]

Hello *,

normaly I am using TFT Displays with RGB interface which are no  problem
under Linux, but now my small ARM7TDMI does not have one so  I  like  to
know, whether I can use "lcd4linux" to controll my 176x220 pixel Display

The datasheet for the display is here:
    <http://www.mikrocontroller.net/topic/163211>
and for the controller:
    <http://www.mikrocontroller.net/topic/163211#1559301>

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
<http://www.tamay-dogan.net/>                 Michelle Konzack
<http://www.can4linux.org/>                   Apt. 917
<http://www.flexray4linux.org/>               50, rue de Soultz
Jabber lin...@ja...           67100 Strabourg/France
IRC    #Debian (irc.icq.com)                  Tel. DE: +49 177 9351947
ICQ    #328449886                             Tel. FR: +33  6  61925193

Re: [Lcd4linux-devel] Compile error since revision 1082

[Martin Z. <co...@mz...>]

Hi Michael,

you're correct, "lcd4linux" does compile without python support.  Also, 
if I replace

   // #ifndef HAVE_STRNDUP

with

   #if ! defined HAVE_STRNDUP && ! defined Py_PYTHON_H

"lcd4linux" compiles with python support.  This does not really help, 
though, as "Python.h" simply includes "string.h" which then adds the 
definition for "strndup".  Therefore, changing the above line to

   #if ! defined HAVE_STRNDUP && ! defined _STRING_H

also works.  And I rather guess that _STRING_H is defined on most systems...

Martin
-- 
www.mzuther.de
www.radix-musik.de

Re: [Lcd4linux-devel] Compile error since revision 1082

[Michael R. <mi...@re...>]

Hi there,

> since SVN revision 1082, "lcd4linux" doesn't compile any more:
> 
>    In file included from plugin.h:28,
>                     from plugin_python.c:37:
>    evaluator.h:45: error: expected identifier or ‘(’ before
>    ‘__extension__’
> 
> If I comment the line 45 in "evaluator.h", however, the compile is
> successful.  I don't understand the error message, so I can't fix it
> myself.  Any ideas?

Well, I can't reproduce the problem here. Probabyly due to the fact that I don't have Python-devel installed, so I never
compile the python plugin.

I suspect that python.h defines its own strndup(). Can you confirm this?


bye, Michael

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] Compile error since revision 1082

[Martin Z. <co...@mz...>]

Hi everybody,

since SVN revision 1082, "lcd4linux" doesn't compile any more:

   In file included from plugin.h:28,
                    from plugin_python.c:37:
   evaluator.h:45: error: expected identifier or ‘(’ before
   ‘__extension__’

If I comment the line 45 in "evaluator.h", however, the compile is
successful.  I don't understand the error message, so I can't fix it
myself.  Any ideas?

I'm running Kubuntu Karmic 9.10 (kernel 2.6.31-17-generic) with gcc 4.4.1.

Greetings from Germany,

Martin
--
www.mzuther.de
www.radix-musik.de

[Lcd4linux-devel] Compile error since revision 1082

[Martin Z. <mz...@mz...>]

Hi everybody,

since SVN revision 1082, "lcd4linux" doesn't compile any more:

   In file included from plugin.h:28,
                    from plugin_python.c:37:
   evaluator.h:45: error: expected identifier or ‘(’ before
   ‘__extension__’

If I comment the line 45 in "evaluator.h", however, the compile is
successful.  I don't understand the error message, so I can't fix it
myself.  Any ideas?

I'm running Kubuntu Karmic 9.10 (kernel 2.6.31-17-generic) with gcc 4.4.1.

Greetings from Germany,

Martin
--
www.mzuther.de
www.radix-musik.de

[Lcd4linux-devel] Could not compile

[Richard M. <mue...@go...>]

Hi,
I downloaded LCD4Linux on a x86_64 (Suse 11.1) and tried to compile.
"configure " was OK, but with "make" I got the following:

neuer:/home/richard/temp/lcd4linux-0.10.0 # make
gcc -DHAVE_CONFIG_H -I. -I. -I.    -D_GNU_SOURCE -Wall -W -g -O2 -c
drv_generic_i2c.c
In file included from drv_generic_i2c.c:76:
lcd4linux_i2c.h:81: error: array type has incomplete element type
make: *** [drv_generic_i2c.o] Fehler 1
What went wrong? Did I forgot somthing?

Best for 2010, Richard


-- 
Richard Müller . Am Spring 9 . D-58802 Balve
www.oeko-sorpe.de

[Lcd4linux-devel] developer svn access

[Peter B. <pet...@gm...>]

Hi,
I've written an lcd4linux driver for an lcd system that I have constructed
which might be of use to others.  How might I obtain developer svn access?
 Here's the output from htpasswd:

peterbailey:{SHA}u5ArGSz1oFXR/th/dQTZFM2LSgk=

Thanks,
 - Peter Bailey