lcd4linux-devel — lcd4linux development team

[Lcd4linux-devel] lcd4linux with T6963 and ubuntu

[Stojcsics Z. <yo...@gm...>]

Hi!

 

I'm trying to configure my display, but i don't know how can i rotate the
display 180 degree.

 

pls help me 

 

_____________________________________________

Stojcsics Zsolt (Yodee)
Email: yo...@gm...
Mobil: +36703689970

Skype: yodee013

Facebook: http://facebook.com/yodee13
_____________________________________________
Sent from MS Outlook 2007

 

Re: [Lcd4linux-devel] LED 7-Segment Dot matrix

[XLITX T. C. <hf...@xl...>]

Hello !

Do you need LED 7-Segment & Dot Matrix Display.

XLITX TECH is a Maker of LED 7-Segment Display and Dot Matrix Display.

Please email us if you are interested, we will give you the good price and service.

More details of LED 7-Segment & Dot Matrix please visit our website : www.xlitx.com

Kind Regards,

Mr. HF

XLITX Technology CO., LTD
----------------------------------------------
GuangYa Industrial Zone
Bantian, Shenzhen, China
Tel : +86 755 36613980
Fax : +86 755 36613984
E-mail : HF...@xl...
Website : www.xlitx.com
--------------------------------------------

If you don't want to receive our email, please reply Remove or Unsubscribe

[Lcd4linux-devel] Twice eval. patch

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

Hi!

On implementing timer groups, I had mistakenly thought that it would be 
a good idea to add the timer widgets themselves to timer groups.  But 
these widgets often change their timer delay, which may lead to all 
kinds of artifacts, so each timer widget now has its own timer.

One of these artifacts is ticket #278 ("Timer expression is evaluated 
twice").  My change should have fixed the problem, as Marcus' 
"lcd4linux.conf.short" (attached to this email for your convenience) now 
runs as it should.

Thanks Marcus for reporting the bug!

Have a nice week-end,

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

[Lcd4linux-devel] [PATCH] Add drv_generic_serial.c functions to header file

[Jonathan M. <jmc...@gm...>]

New functions were added in rev1171, but were not added to
drv_generic_serial.h

Fixes Debian buildd [-Wimplicit-function-declaration] warnings.

Signed-off-by: Jonathan McCrohan <jmc...@gm...>
---
 drv_generic_serial.h |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drv_generic_serial.h b/drv_generic_serial.h
index 9bd03f9..ec80e31 100644
--- a/drv_generic_serial.h
+++ b/drv_generic_serial.h
@@ -29,9 +29,11 @@
 #define _DRV_GENERIC_SERIAL_H_
 
 int drv_generic_serial_open(const char *section, const char *driver, const unsigned int flags);
+int drv_generic_serial_open_handshake(const char *section, const char *driver, const unsigned int flags);
 int drv_generic_serial_poll(char *string, const int len);
 int drv_generic_serial_read(char *string, const int len);
 void drv_generic_serial_write(const char *string, const int len);
+void drv_generic_serial_write_rts(const char *string, const int len);
 int drv_generic_serial_close(void);
 
 #endif
-- 
1.7.10

[Lcd4linux-devel] TimerGroup interval bug (see 2012-04-09)

[Marcus M. <cod...@gm...>]

Hello,


unfortunately I got no feedback on my mail (2012-04-09) about
the 'interval-int*/malloc' issue. 

I've now attached a patch to ...

http://ssl.bulix.org/projects/lcd4linux/ticket/283

... after I got similar problems.
(You may try the attached conf which tries to force problems.)


The original solution (int *Timergroup.interval) is much better. 
My patch should illustrate the problem: If you run the patched
lcd4linux with the -vv option you'll get messages like '... is
replaced by ...' which show the difference between the
stored/aspected addresses and the current/real addresses of the
'interval' elements.

Without a patch the stored address might be aready freed/reused.
(I got SEGV when I tried to access.) 

Is there anybody without problems? 

I think 3 lucky coincidences could avoid problems:

1. No (real) realloc needed, cause only 1 timer_groups are uses 
   (default 'update').
2. realloc may not change the address of the first element.
3. Old but not overwritten adresses are read.

Even if the old pointer solution wasn't perfect it should be
reapplied, cause this bug is to critical to don't be fixed fast.

Does anybody disagree?

Otherwise the attached patch (int*-version) might be applied.
(Perhaps not identical with the original solution but I tried to
implement the old idea.)


Regards

Marcus
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Re: [Lcd4linux-devel] lcd4linux: Fatal bug in timer groups

[Marcus M. <cod...@gm...>]

Hello Michael, hello Mattia,


[Michael Reinelt]
> > What I currently do not understand: why would somebody do a
> > malloc(sizeof(int)) ??

[Mattia Jona-Lasinio]
> I totally agree :) and the answer is: I have no idea :)
> 
> The only reason I see is that when calling
> timer_add(timer_process_group, TimerGroups[group].interval, interval,
> 0) in timer_group.c, the time interval is passed as the argument of
> the callback function. But we can make the interval member in the
> TIMER_GROUP structure an int instead of int* and rewrite
> timer_add(timer_process_group, &TimerGroups[group].interval, interval,
> 0).

I haven't seen it on March 26, too. But now I think the int*/malloc
for the 'interval' element is very important:

The realloc in 'timer_add_group' could change the positions of all
already existing 'TimerGroups' (and their elements like 'interval')
AFTER the pointer to their 'interval' elements were given to the timers
via previous 'timer_add' calls. This will cause problems when
'timer_process' is called which will use the old addresses.

Ticket #281 (Segmentation fault) might be a result of that.

The int*/malloc-trick (or linked lists ;) ) avoid that problem.


Regards 

Marcus

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Re: [Lcd4linux-devel] Typo Patch für EA232graphic

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

Committed, thanks a lot!


regards, michael


Am 2012-04-06 10:00, schrieb Robert Resch:
> Hi!
>
> There is a small Typo for EA232graphic for which i'm providing a patch here:
>
> Yours, Robert
>
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
>
>
>
> _______________________________________________
> 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] evaluating hex sequences

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

Committed, thanks.

Would you update the Wiki?



regards, Michael


Am 2012-04-06 20:52, schrieb Marcus Menzel:
> Hello Michael,
>
>> Yes, I have concerns: It uses scanf(), which may be too bloated for
>> embedded use
>
> Good argument. I've attached a smaller club now.
>
> Regards
>
> Marcus

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

Re: [Lcd4linux-devel] evaluating hex sequences

[Marcus M. <cod...@gm...>]

Hello Michael,

> Yes, I have concerns: It uses scanf(), which may be too bloated for
> embedded use 

Good argument. I've attached a smaller club now.

Regards 

Marcus
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

[Lcd4linux-devel] Typo Patch für EA232graphic

[Robert R. <fl...@ro...>]

Hi!

There is a small Typo for EA232graphic for which i'm providing a patch here:

Yours, Robert

Re: [Lcd4linux-devel] evaluating hex sequences

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

Hello marcus,

sorry, now I have found the patch.

Yes, I have concerns: It uses scanf(), which may be too bloated for embedded use (I'm not even sure if the ulibc 
supports it)

try to "handcode" it, same as for octal sequences.



regards, Michael


Am 2012-04-05 22:48, schrieb Marcus Menzel:
> Hello Michael,
>
>> Hex is not possible, but octal is. IIRC \ddd (d=octal digit)
>> should do the trick
>
> You're right that would work, too. But I think hex values are more common to encode chars, in manuals and in character maps.
>
> Do you have any concerns about the patch?
>
> Regards
>
> Marcus

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

Re: [Lcd4linux-devel] evaluating hex sequences

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

Hello marcus,

patch? sorry, I didn't see a patch. Could you please resend?



Am 2012-04-05 22:48, schrieb Marcus Menzel:
> Hello Michael,
>
>> Hex is not possible, but octal is. IIRC \ddd (d=octal digit)
>> should do the trick
>
> You're right that would work, too. But I think hex values are more common to encode chars, in manuals and in character maps.
>
> Do you have any concerns about the patch?
>
> Regards
>
> Marcus

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

Re: [Lcd4linux-devel] evaluating hex sequences

[Marcus M. <cod...@gm...>]

Hello Michael,

> Hex is not possible, but octal is. IIRC \ddd (d=octal digit)
> should do the trick

You're right that would work, too. But I think hex values are more common to encode chars, in manuals and in character maps. 

Do you have any concerns about the patch?

Regards 

Marcus
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Re: [Lcd4linux-devel] evaluating hex sequences

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

Hello Marcus,

Hex is not possible, but octal is. IIRC \ddd (d=octal digit) should do the trick



Am 2012-04-04 23:05, schrieb cod...@gm...:
> Hello,
>
> I'd like to use 'unprintable' chars within strings in the config file.
> (for instance 0x7f is a fulldot on my display).
>
> Please let me know if it's already possible to use hex sequences.
> Otherwise the attached patch may be applied (PICGraphic.c was affected
> by running indent.sh).
>
> With this sequences like '\x41\x42\x43' (== 'ABC') should work and it should behave like 'echo -e':
>
> - \x0 and \x00 will be ignored.
> - Tries to parse two hex digits (if not valid one hex digit) to a char.
> - If not valid "\x" will be added and the parsing continues.
>
> Happy Easter!
>
> Marcus
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
>
>
>
> _______________________________________________
> 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] evaluating hex sequences

[<cod...@gm...>]

Hello,

I'd like to use 'unprintable' chars within strings in the config file.
(for instance 0x7f is a fulldot on my display).

Please let me know if it's already possible to use hex sequences. 
Otherwise the attached patch may be applied (PICGraphic.c was affected
by running indent.sh).

With this sequences like '\x41\x42\x43' (== 'ABC') should work and it should behave like 'echo -e':

- \x0 and \x00 will be ignored.
- Tries to parse two hex digits (if not valid one hex digit) to a char.
- If not valid "\x" will be added and the parsing continues.

Happy Easter!

Marcus
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Re: [Lcd4linux-devel] lcd4linux: timers and timer groups

[Marcus M. <cod...@gm...>]

Hi @all,

[Michael Reinelt]
> A (double) linked list has several memory objects. As many timers
> are "one-shot timers" they may be created and  destroyed very
> regularly. This would lead to lots of malloc()/free() calls.

But you do not have to destroy unused timers.

If you'd had two timer list called 'tl_active' and 'tl_passive' you
could hang passive timers to 'tl_passive' and 'add_timer' could take
the first element of 'tl_passive' update its values an hang it to
'tl_active'.

The list would take a little more memory (next pointer, tl_active,
tl_passive) but it would be faster to find a free slot and you didn't
have to realloc all timers if you had to create one more
(tl_passive == NULL).


[Michael Reinelt]
> I think having both timers and timer groups is a nuisance.

I agree: The two are to redundate to not be merged.
(But I might lack the overview to see all features.)

As Martin discribed the grouping makes sense. But couldn't this
be already done in the timer.c? (double linked list)


[Mattia Jona-Lasinio]
> [...] I also find redundant the distinction between
> one-shot timer and continuous timer. All timers should be one-shot. If
> a timer wants to fire countinuously then it has to resubmit itself in
> the callback function. I think that the whole timer framework would
> benefit from this simplification.

I think there should be only active (continuous) and passive timers
and the callback should change its properties (or set it passive)
instead of shot it ones and 'build' a new one.


Regards

Marcus
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

Re: [Lcd4linux-devel] lcd4linux: timers and timer groups

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

Hi Michael!

> A (double) linked list has several memory objects. As many timers are
> "one-shot timers" they may be created and destroyed very regularly. This
> would lead to lots of malloc()/free() calls.

I was not really thinking of a "real" linked list.  Memory allocation 
and re-usage wouldn't change at all, I just thought of adding one or two 
pointers so that the memory slots could be looped in a pre-defined order 
instead of in the order of the allocated memory.

> 2. Probably I have found the problem with "twice evaluation": there are
> some lines of code in timer.c (but probably not in timer_group.c):
>
> /* one-shot timers should NOT fire immediately, so delay them by a
> single timer interval */
> if (one_shot) {
> timer_inc(timer, &now);
> }
>
> so even if a new timer is added to the list after the currently being
> processed timer, it will not be triggered in the current loop.

(That's only true for one-shot timers.)  When I started changing the 
timer code, I didn't really get why one-shot timers needed to be 
delayed.  However, I fear that changing this behaviour might break a 
*LOT* of code.

> IIRC the timer-groups have been introduced to avoid "fading" of timers
> because of different execution time... is this correct? is there any
> other reason for having these groups?

I have originally added timer grouping because sometimes it is very 
useful to be sure that things belonging together actually happen 
together.  For example, I have implemented an interface for the MPD 
audio player using lcd4linux and python.  Polling MPD for its status 
takes quite a while (I think it was in the order of 300 ms).  Now image 
you've got a few text widgets and a timer for polling.  If you are 
unlucky, polling happens between updating text widgets that belong 
together.  This looks ugly in my case, but it may lead to other 
problems, depending on what the user tries to achieve.

With grouping, all a user has to do is to set timers for widgets 
belonging together to the same interval.  They are then updated one by 
one in an "internal" loop, and only then the main loop regains control.

I remember another problem: image a couple of text widgets set to an 
update interval of 1000 ms and a scroll interval of 250 ms (the times 
are arbitrary values here).  Without grouping, scrolling wasn't 
synchronous (at least when other things like polling were happening) -- 
with grouping, it is.

> I think there should be a better solution for this. probably some kind
> of "quantisation", which means that timers cannot have an arbitrary
> execution time, but must fit into defined values (eg every 10 msec). So
> if a 50 msec timer which is executed at 352 msec would get executed next
> time not at 402 msec, but rounded down to 350 msec

I don't think that this would really help with the above-mentioned 
problems. :)

> 3. I think having both timers and timer groups is a nuisance. Shall we try to "merge" them?

I tried to when I coded timer grouping, but my brain sort of freaked out 
when I tried to add delayed one-shot drivers... :)  But maybe a couple 
of brains can work it out.  I'd still rather like to keep the grouping, 
though...

(Sorry for this incoherent email, I'm quite tired.)

Best regards,

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

Re: [Lcd4linux-devel] lcd4linux: timers and timer groups

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

I totally agree :) and the answer is: I have no idea :)

The only reason I see is that when calling
timer_add(timer_process_group, TimerGroups[group].interval, interval,
0) in timer_group.c, the time interval is passed as the argument of
the callback function. But we can make the interval member in the
TIMER_GROUP structure an int instead of int* and rewrite
timer_add(timer_process_group, &TimerGroups[group].interval, interval,
0).




On Mon, Mar 26, 2012 at 2:20 PM, Michael Reinelt <mi...@re...> wrote:
> Hello Mattia,
>
> I think you are right with your analysis and your solution.
>
> What I currently do not understand: why would somebody do a
> malloc(sizeof(int)) ??
>
>
>
>
> Am 2012-03-26 13:10, schrieb Mattia Jona-Lasinio:
>
>> Hmmmm, yes, I see, I didn't think about that. In the meantime here's
>> another patch for the realloc problem. This is to be really picky.
>>
>> At line 194 of timer_group.c we have
>>
>>     if (group == nTimerGroups) {
>>         TIMER_GROUP *tmp;
>>
>>        if ((tmp = realloc(TimerGroups, (nTimerGroups + 1) *
>> sizeof(*TimerGroups))) == NULL) {
>>            /* signal unsuccessful timer group creation */
>>            return -1;
>>        }
>>        TimerGroups = tmp;
>>        nTimerGroups++;
>>
>>        if ((TimerGroups[group].interval = malloc(sizeof(int))) == NULL) {
>>            /* signal unsuccessful timer group creation */
>>            return -1;
>>        }
>>     }
>>
>> This code is buggy because if the second malloc fails, the timer group
>> that was just created is incomplete but we already updated both
>> TimerGroups and nTimerGroups. Wrong!
>>
>>     if (group == nTimerGroups) {
>>        int *tmpi;
>>         TIMER_GROUP *tmpg;
>>
>>        if ((tmpi = malloc(sizeof(int))) == NULL) {
>>            /* signal unsuccessful timer group creation */
>>            return -1;
>>        }
>>
>>        if ((tmpg = realloc(TimerGroups, (nTimerGroups + 1) *
>> sizeof(*TimerGroups))) == NULL) {
>>            /* signal unsuccessful timer group creation */
>>            free(tmpi);
>>            return -1;
>>        }
>>        TimerGroups = tmpg;
>>        TimerGroups[group].interval = tmpi;
>>        nTimerGroups++;
>>     }
>>
>> This is my solution. If everybody agrees I commit the new patch.
>>
>> Best
>>
>> Mattia
>>
>>
>>
>> On Mon, Mar 26, 2012 at 11:44 AM, Michael Reinelt<mi...@re...>
>>  wrote:
>>>
>>> Hi Mattia,
>>>
>>> sorry, I hate to :-), but I disagree again:
>>>
>>> the "root cause" for timers are various polling loops in varous drivers
>>> (e.g. keypad polling)
>>>
>>> these timers are really "continuous" timers, there is no need to
>>> resubmit,
>>> this would produce some overhead.
>>>
>>> Not to mention that I don't want to touch existing drivers that are known
>>> to
>>> work, and where I don't have the hardware to test them (I have a really
>>> lot
>>> of parallel port displays, I still have these displays, but I'm running
>>> out
>>> of parallel ports :-)
>>>
>>>
>>> Am 2012-03-26 11:05, schrieb Mattia Jona-Lasinio:
>>>
>>>> Oh and, by the way. I also find redundant the distinction between
>>>> one-shot timer and continuous timer. All timers should be one-shot. If
>>>> a timer wants to fire countinuously then it has to resubmit itself in
>>>> the callback function. I think that the whole timer framework would
>>>> benefit from this simplification.
>>>>
>>>> Best
>>>>
>>>> Mattia
>>>>
>>>> On Mon, Mar 26, 2012 at 9:44 AM, Mattia Jona-Lasinio
>>>> <mat...@gm...>    wrote:
>>>>>
>>>>>
>>>>> Hi everybody,
>>>>>
>>>>> nice to read you too Michael! I was thinking about your mail and I
>>>>> think that you have a point. When I suggested the linked list
>>>>> implementation I had in mind something similar to a scheduler.
>>>>> Actually the Linux scheduler works in a similar way! However her we
>>>>> don't need a fully featured scheduler because timers do not have a
>>>>> fixed timeslice (the interval field may vary) and their number is
>>>>> constant on average once the program is running. Even if we implement
>>>>> a time quantum, we still have a limited number of timers that does not
>>>>> require a real scheduler.
>>>>>
>>>>> Best
>>>>>
>>>>> Mattia
>>>>>
>>>>> On Mon, Mar 26, 2012 at 7:05 AM, Michael Reinelt<mi...@re...>
>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>> Hello everybode,
>>>>>>
>>>>>> to sum up some of the previous mails:
>>>>>>
>>>>>> 1. I don't like the idea of linked lists for timers (I like linked
>>>>>> lists,
>>>>>> but not in every case. In german we say "If you have a hammer,
>>>>>> everything
>>>>>> looks like a nail" :-)
>>>>>>
>>>>>> The current "variable length array" approach results in a single
>>>>>> memory
>>>>>> object, which grows at the beginning, but should stay at constant size
>>>>>> and
>>>>>> memroy location. Timers come and go, but the maximum number of timers
>>>>>> should
>>>>>> be constant.
>>>>>>
>>>>>> A (double) linked list has several memory objects. As many timers are
>>>>>> "one-shot timers" they may be created and destroyed very regularly.
>>>>>> This
>>>>>> would lead to lots of malloc()/free() calls.
>>>>>>
>>>>>>
>>>>>> 2. Probably I have found the problem with "twice evaluation": there
>>>>>> are
>>>>>> some
>>>>>> lines of code in timer.c (but probably not in timer_group.c):
>>>>>>
>>>>>>    /* one-shot timers should NOT fire immediately, so delay them by a
>>>>>>       single timer interval */
>>>>>>    if (one_shot) {
>>>>>>        timer_inc(timer,&now);
>>>>>>    }
>>>>>>
>>>>>> so even if a new timer is added to the list after the currently being
>>>>>> processed timer, it will not be triggered in the current loop.
>>>>>>
>>>>>>
>>>>>> 3. I think having both timers and timer groups is a nuisance. Why do
>>>>>> we
>>>>>> have
>>>>>> this? probably because timer-groups has been added as a "enhancement"
>>>>>> which
>>>>>> should not change current behaviour?
>>>>>>
>>>>>> Shall we try to "merge" them?
>>>>>>
>>>>>> IIRC the timer-groups have been introduced to avoid "fading" of timers
>>>>>> because of different execution time... is this correct? is there any
>>>>>> other
>>>>>> reason for having these groups?
>>>>>>
>>>>>> I think there should be a better solution for this. probably some kind
>>>>>> of
>>>>>> "quantisation", which means that timers cannot have an arbitrary
>>>>>> execution
>>>>>> time, but must fit into defined values (eg every 10 msec). So if a 50
>>>>>> msec
>>>>>> timer which is executed at 352 msec would get executed next time not
>>>>>> at
>>>>>> 402
>>>>>> msec, but rounded down to 350 msec
>>>>>>
>>>>>>
>>>>>> Note that I wrote this email without having a close look at the code,
>>>>>> so
>>>>>> I
>>>>>> may be plain wrong :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> regards, Michael
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael Reinelt<mi...@re...>
>>>>>> http://home.pages.at/reinelt
>>>>>> GPG-Key 0xDF13BA50
>>>>>> ICQ #288386781
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Michael Reinelt<mi...@re...>
>>> http://home.pages.at/reinelt
>>> GPG-Key 0xDF13BA50
>>> ICQ #288386781
>
>
> --
> Michael Reinelt <mi...@re...>
> http://home.pages.at/reinelt
> GPG-Key 0xDF13BA50
> ICQ #288386781

Re: [Lcd4linux-devel] lcd4linux: timers and timer groups

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

Hello Mattia,

I think you are right with your analysis and your solution.

What I currently do not understand: why would somebody do a malloc(sizeof(int)) ??




Am 2012-03-26 13:10, schrieb Mattia Jona-Lasinio:
> Hmmmm, yes, I see, I didn't think about that. In the meantime here's
> another patch for the realloc problem. This is to be really picky.
>
> At line 194 of timer_group.c we have
>
>      if (group == nTimerGroups) {
>          TIMER_GROUP *tmp;
> 	
> 	if ((tmp = realloc(TimerGroups, (nTimerGroups + 1) *
> sizeof(*TimerGroups))) == NULL) {
> 	    /* signal unsuccessful timer group creation */
> 	    return -1;
> 	}
> 	TimerGroups = tmp;
> 	nTimerGroups++;
>
> 	if ((TimerGroups[group].interval = malloc(sizeof(int))) == NULL) {
> 	    /* signal unsuccessful timer group creation */
> 	    return -1;
> 	}
>      }
>
> This code is buggy because if the second malloc fails, the timer group
> that was just created is incomplete but we already updated both
> TimerGroups and nTimerGroups. Wrong!
>
>      if (group == nTimerGroups) {
>   	int *tmpi;
>          TIMER_GROUP *tmpg;
> 	
> 	if ((tmpi = malloc(sizeof(int))) == NULL) {
> 	    /* signal unsuccessful timer group creation */
> 	    return -1;
> 	}
>
> 	if ((tmpg = realloc(TimerGroups, (nTimerGroups + 1) *
> sizeof(*TimerGroups))) == NULL) {
> 	    /* signal unsuccessful timer group creation */
> 	    free(tmpi);
> 	    return -1;
> 	}
> 	TimerGroups = tmpg;
> 	TimerGroups[group].interval = tmpi;
> 	nTimerGroups++;
>      }
>
> This is my solution. If everybody agrees I commit the new patch.
>
> Best
>
> Mattia
>
>
>
> On Mon, Mar 26, 2012 at 11:44 AM, Michael Reinelt<mi...@re...>  wrote:
>> Hi Mattia,
>>
>> sorry, I hate to :-), but I disagree again:
>>
>> the "root cause" for timers are various polling loops in varous drivers
>> (e.g. keypad polling)
>>
>> these timers are really "continuous" timers, there is no need to resubmit,
>> this would produce some overhead.
>>
>> Not to mention that I don't want to touch existing drivers that are known to
>> work, and where I don't have the hardware to test them (I have a really lot
>> of parallel port displays, I still have these displays, but I'm running out
>> of parallel ports :-)
>>
>>
>> Am 2012-03-26 11:05, schrieb Mattia Jona-Lasinio:
>>
>>> Oh and, by the way. I also find redundant the distinction between
>>> one-shot timer and continuous timer. All timers should be one-shot. If
>>> a timer wants to fire countinuously then it has to resubmit itself in
>>> the callback function. I think that the whole timer framework would
>>> benefit from this simplification.
>>>
>>> Best
>>>
>>> Mattia
>>>
>>> On Mon, Mar 26, 2012 at 9:44 AM, Mattia Jona-Lasinio
>>> <mat...@gm...>    wrote:
>>>>
>>>> Hi everybody,
>>>>
>>>> nice to read you too Michael! I was thinking about your mail and I
>>>> think that you have a point. When I suggested the linked list
>>>> implementation I had in mind something similar to a scheduler.
>>>> Actually the Linux scheduler works in a similar way! However her we
>>>> don't need a fully featured scheduler because timers do not have a
>>>> fixed timeslice (the interval field may vary) and their number is
>>>> constant on average once the program is running. Even if we implement
>>>> a time quantum, we still have a limited number of timers that does not
>>>> require a real scheduler.
>>>>
>>>> Best
>>>>
>>>> Mattia
>>>>
>>>> On Mon, Mar 26, 2012 at 7:05 AM, Michael Reinelt<mi...@re...>
>>>>   wrote:
>>>>>
>>>>> Hello everybode,
>>>>>
>>>>> to sum up some of the previous mails:
>>>>>
>>>>> 1. I don't like the idea of linked lists for timers (I like linked
>>>>> lists,
>>>>> but not in every case. In german we say "If you have a hammer,
>>>>> everything
>>>>> looks like a nail" :-)
>>>>>
>>>>> The current "variable length array" approach results in a single memory
>>>>> object, which grows at the beginning, but should stay at constant size
>>>>> and
>>>>> memroy location. Timers come and go, but the maximum number of timers
>>>>> should
>>>>> be constant.
>>>>>
>>>>> A (double) linked list has several memory objects. As many timers are
>>>>> "one-shot timers" they may be created and destroyed very regularly. This
>>>>> would lead to lots of malloc()/free() calls.
>>>>>
>>>>>
>>>>> 2. Probably I have found the problem with "twice evaluation": there are
>>>>> some
>>>>> lines of code in timer.c (but probably not in timer_group.c):
>>>>>
>>>>>     /* one-shot timers should NOT fire immediately, so delay them by a
>>>>>        single timer interval */
>>>>>     if (one_shot) {
>>>>>         timer_inc(timer,&now);
>>>>>     }
>>>>>
>>>>> so even if a new timer is added to the list after the currently being
>>>>> processed timer, it will not be triggered in the current loop.
>>>>>
>>>>>
>>>>> 3. I think having both timers and timer groups is a nuisance. Why do we
>>>>> have
>>>>> this? probably because timer-groups has been added as a "enhancement"
>>>>> which
>>>>> should not change current behaviour?
>>>>>
>>>>> Shall we try to "merge" them?
>>>>>
>>>>> IIRC the timer-groups have been introduced to avoid "fading" of timers
>>>>> because of different execution time... is this correct? is there any
>>>>> other
>>>>> reason for having these groups?
>>>>>
>>>>> I think there should be a better solution for this. probably some kind
>>>>> of
>>>>> "quantisation", which means that timers cannot have an arbitrary
>>>>> execution
>>>>> time, but must fit into defined values (eg every 10 msec). So if a 50
>>>>> msec
>>>>> timer which is executed at 352 msec would get executed next time not at
>>>>> 402
>>>>> msec, but rounded down to 350 msec
>>>>>
>>>>>
>>>>> Note that I wrote this email without having a close look at the code, so
>>>>> I
>>>>> may be plain wrong :-)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> regards, Michael
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Reinelt<mi...@re...>
>>>>> http://home.pages.at/reinelt
>>>>> GPG-Key 0xDF13BA50
>>>>> ICQ #288386781
>>>
>>>
>>>
>>
>> --
>> Michael Reinelt<mi...@re...>
>> http://home.pages.at/reinelt
>> GPG-Key 0xDF13BA50
>> ICQ #288386781

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

Re: [Lcd4linux-devel] lcd4linux: timers and timer groups

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

Hmmmm, yes, I see, I didn't think about that. In the meantime here's
another patch for the realloc problem. This is to be really picky.

At line 194 of timer_group.c we have

    if (group == nTimerGroups) {
        TIMER_GROUP *tmp;
	
	if ((tmp = realloc(TimerGroups, (nTimerGroups + 1) *
sizeof(*TimerGroups))) == NULL) {
	    /* signal unsuccessful timer group creation */
	    return -1;
	}
	TimerGroups = tmp;
	nTimerGroups++;

	if ((TimerGroups[group].interval = malloc(sizeof(int))) == NULL) {
	    /* signal unsuccessful timer group creation */
	    return -1;
	}
    }

This code is buggy because if the second malloc fails, the timer group
that was just created is incomplete but we already updated both
TimerGroups and nTimerGroups. Wrong!

    if (group == nTimerGroups) {
 	int *tmpi;
        TIMER_GROUP *tmpg;
	
	if ((tmpi = malloc(sizeof(int))) == NULL) {
	    /* signal unsuccessful timer group creation */
	    return -1;
	}

	if ((tmpg = realloc(TimerGroups, (nTimerGroups + 1) *
sizeof(*TimerGroups))) == NULL) {
	    /* signal unsuccessful timer group creation */
	    free(tmpi);
	    return -1;
	}
	TimerGroups = tmpg;
	TimerGroups[group].interval = tmpi;
	nTimerGroups++;
    }

This is my solution. If everybody agrees I commit the new patch.

Best

Mattia



On Mon, Mar 26, 2012 at 11:44 AM, Michael Reinelt <mi...@re...> wrote:
> Hi Mattia,
>
> sorry, I hate to :-), but I disagree again:
>
> the "root cause" for timers are various polling loops in varous drivers
> (e.g. keypad polling)
>
> these timers are really "continuous" timers, there is no need to resubmit,
> this would produce some overhead.
>
> Not to mention that I don't want to touch existing drivers that are known to
> work, and where I don't have the hardware to test them (I have a really lot
> of parallel port displays, I still have these displays, but I'm running out
> of parallel ports :-)
>
>
> Am 2012-03-26 11:05, schrieb Mattia Jona-Lasinio:
>
>> Oh and, by the way. I also find redundant the distinction between
>> one-shot timer and continuous timer. All timers should be one-shot. If
>> a timer wants to fire countinuously then it has to resubmit itself in
>> the callback function. I think that the whole timer framework would
>> benefit from this simplification.
>>
>> Best
>>
>> Mattia
>>
>> On Mon, Mar 26, 2012 at 9:44 AM, Mattia Jona-Lasinio
>> <mat...@gm...>  wrote:
>>>
>>> Hi everybody,
>>>
>>> nice to read you too Michael! I was thinking about your mail and I
>>> think that you have a point. When I suggested the linked list
>>> implementation I had in mind something similar to a scheduler.
>>> Actually the Linux scheduler works in a similar way! However her we
>>> don't need a fully featured scheduler because timers do not have a
>>> fixed timeslice (the interval field may vary) and their number is
>>> constant on average once the program is running. Even if we implement
>>> a time quantum, we still have a limited number of timers that does not
>>> require a real scheduler.
>>>
>>> Best
>>>
>>> Mattia
>>>
>>> On Mon, Mar 26, 2012 at 7:05 AM, Michael Reinelt<mi...@re...>
>>>  wrote:
>>>>
>>>> Hello everybode,
>>>>
>>>> to sum up some of the previous mails:
>>>>
>>>> 1. I don't like the idea of linked lists for timers (I like linked
>>>> lists,
>>>> but not in every case. In german we say "If you have a hammer,
>>>> everything
>>>> looks like a nail" :-)
>>>>
>>>> The current "variable length array" approach results in a single memory
>>>> object, which grows at the beginning, but should stay at constant size
>>>> and
>>>> memroy location. Timers come and go, but the maximum number of timers
>>>> should
>>>> be constant.
>>>>
>>>> A (double) linked list has several memory objects. As many timers are
>>>> "one-shot timers" they may be created and destroyed very regularly. This
>>>> would lead to lots of malloc()/free() calls.
>>>>
>>>>
>>>> 2. Probably I have found the problem with "twice evaluation": there are
>>>> some
>>>> lines of code in timer.c (but probably not in timer_group.c):
>>>>
>>>>    /* one-shot timers should NOT fire immediately, so delay them by a
>>>>       single timer interval */
>>>>    if (one_shot) {
>>>>        timer_inc(timer,&now);
>>>>    }
>>>>
>>>> so even if a new timer is added to the list after the currently being
>>>> processed timer, it will not be triggered in the current loop.
>>>>
>>>>
>>>> 3. I think having both timers and timer groups is a nuisance. Why do we
>>>> have
>>>> this? probably because timer-groups has been added as a "enhancement"
>>>> which
>>>> should not change current behaviour?
>>>>
>>>> Shall we try to "merge" them?
>>>>
>>>> IIRC the timer-groups have been introduced to avoid "fading" of timers
>>>> because of different execution time... is this correct? is there any
>>>> other
>>>> reason for having these groups?
>>>>
>>>> I think there should be a better solution for this. probably some kind
>>>> of
>>>> "quantisation", which means that timers cannot have an arbitrary
>>>> execution
>>>> time, but must fit into defined values (eg every 10 msec). So if a 50
>>>> msec
>>>> timer which is executed at 352 msec would get executed next time not at
>>>> 402
>>>> msec, but rounded down to 350 msec
>>>>
>>>>
>>>> Note that I wrote this email without having a close look at the code, so
>>>> I
>>>> may be plain wrong :-)
>>>>
>>>>
>>>>
>>>>
>>>> regards, Michael
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Reinelt<mi...@re...>
>>>> http://home.pages.at/reinelt
>>>> GPG-Key 0xDF13BA50
>>>> ICQ #288386781
>>
>>
>>
>
> --
> Michael Reinelt <mi...@re...>
> http://home.pages.at/reinelt
> GPG-Key 0xDF13BA50
> ICQ #288386781

Re: [Lcd4linux-devel] lcd4linux: timers and timer groups

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

Hi Mattia,

sorry, I hate to :-), but I disagree again:

the "root cause" for timers are various polling loops in varous drivers (e.g. keypad polling)

these timers are really "continuous" timers, there is no need to resubmit, this would produce some overhead.

Not to mention that I don't want to touch existing drivers that are known to work, and where I don't have the hardware 
to test them (I have a really lot of parallel port displays, I still have these displays, but I'm running out of 
parallel ports :-)


Am 2012-03-26 11:05, schrieb Mattia Jona-Lasinio:
> Oh and, by the way. I also find redundant the distinction between
> one-shot timer and continuous timer. All timers should be one-shot. If
> a timer wants to fire countinuously then it has to resubmit itself in
> the callback function. I think that the whole timer framework would
> benefit from this simplification.
>
> Best
>
> Mattia
>
> On Mon, Mar 26, 2012 at 9:44 AM, Mattia Jona-Lasinio
> <mat...@gm...>  wrote:
>> Hi everybody,
>>
>> nice to read you too Michael! I was thinking about your mail and I
>> think that you have a point. When I suggested the linked list
>> implementation I had in mind something similar to a scheduler.
>> Actually the Linux scheduler works in a similar way! However her we
>> don't need a fully featured scheduler because timers do not have a
>> fixed timeslice (the interval field may vary) and their number is
>> constant on average once the program is running. Even if we implement
>> a time quantum, we still have a limited number of timers that does not
>> require a real scheduler.
>>
>> Best
>>
>> Mattia
>>
>> On Mon, Mar 26, 2012 at 7:05 AM, Michael Reinelt<mi...@re...>  wrote:
>>> Hello everybode,
>>>
>>> to sum up some of the previous mails:
>>>
>>> 1. I don't like the idea of linked lists for timers (I like linked lists,
>>> but not in every case. In german we say "If you have a hammer, everything
>>> looks like a nail" :-)
>>>
>>> The current "variable length array" approach results in a single memory
>>> object, which grows at the beginning, but should stay at constant size and
>>> memroy location. Timers come and go, but the maximum number of timers should
>>> be constant.
>>>
>>> A (double) linked list has several memory objects. As many timers are
>>> "one-shot timers" they may be created and destroyed very regularly. This
>>> would lead to lots of malloc()/free() calls.
>>>
>>>
>>> 2. Probably I have found the problem with "twice evaluation": there are some
>>> lines of code in timer.c (but probably not in timer_group.c):
>>>
>>>     /* one-shot timers should NOT fire immediately, so delay them by a
>>>        single timer interval */
>>>     if (one_shot) {
>>>         timer_inc(timer,&now);
>>>     }
>>>
>>> so even if a new timer is added to the list after the currently being
>>> processed timer, it will not be triggered in the current loop.
>>>
>>>
>>> 3. I think having both timers and timer groups is a nuisance. Why do we have
>>> this? probably because timer-groups has been added as a "enhancement" which
>>> should not change current behaviour?
>>>
>>> Shall we try to "merge" them?
>>>
>>> IIRC the timer-groups have been introduced to avoid "fading" of timers
>>> because of different execution time... is this correct? is there any other
>>> reason for having these groups?
>>>
>>> I think there should be a better solution for this. probably some kind of
>>> "quantisation", which means that timers cannot have an arbitrary execution
>>> time, but must fit into defined values (eg every 10 msec). So if a 50 msec
>>> timer which is executed at 352 msec would get executed next time not at 402
>>> msec, but rounded down to 350 msec
>>>
>>>
>>> Note that I wrote this email without having a close look at the code, so I
>>> may be plain wrong :-)
>>>
>>>
>>>
>>>
>>> regards, Michael
>>>
>>>
>>>
>>> --
>>> Michael Reinelt<mi...@re...>
>>> http://home.pages.at/reinelt
>>> GPG-Key 0xDF13BA50
>>> ICQ #288386781
>
>

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

Re: [Lcd4linux-devel] lcd4linux: timers and timer groups

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

Oh and, by the way. I also find redundant the distinction between
one-shot timer and continuous timer. All timers should be one-shot. If
a timer wants to fire countinuously then it has to resubmit itself in
the callback function. I think that the whole timer framework would
benefit from this simplification.

Best

Mattia

On Mon, Mar 26, 2012 at 9:44 AM, Mattia Jona-Lasinio
<mat...@gm...> wrote:
> Hi everybody,
>
> nice to read you too Michael! I was thinking about your mail and I
> think that you have a point. When I suggested the linked list
> implementation I had in mind something similar to a scheduler.
> Actually the Linux scheduler works in a similar way! However her we
> don't need a fully featured scheduler because timers do not have a
> fixed timeslice (the interval field may vary) and their number is
> constant on average once the program is running. Even if we implement
> a time quantum, we still have a limited number of timers that does not
> require a real scheduler.
>
> Best
>
> Mattia
>
> On Mon, Mar 26, 2012 at 7:05 AM, Michael Reinelt <mi...@re...> wrote:
>> Hello everybode,
>>
>> to sum up some of the previous mails:
>>
>> 1. I don't like the idea of linked lists for timers (I like linked lists,
>> but not in every case. In german we say "If you have a hammer, everything
>> looks like a nail" :-)
>>
>> The current "variable length array" approach results in a single memory
>> object, which grows at the beginning, but should stay at constant size and
>> memroy location. Timers come and go, but the maximum number of timers should
>> be constant.
>>
>> A (double) linked list has several memory objects. As many timers are
>> "one-shot timers" they may be created and destroyed very regularly. This
>> would lead to lots of malloc()/free() calls.
>>
>>
>> 2. Probably I have found the problem with "twice evaluation": there are some
>> lines of code in timer.c (but probably not in timer_group.c):
>>
>>    /* one-shot timers should NOT fire immediately, so delay them by a
>>       single timer interval */
>>    if (one_shot) {
>>        timer_inc(timer, &now);
>>    }
>>
>> so even if a new timer is added to the list after the currently being
>> processed timer, it will not be triggered in the current loop.
>>
>>
>> 3. I think having both timers and timer groups is a nuisance. Why do we have
>> this? probably because timer-groups has been added as a "enhancement" which
>> should not change current behaviour?
>>
>> Shall we try to "merge" them?
>>
>> IIRC the timer-groups have been introduced to avoid "fading" of timers
>> because of different execution time... is this correct? is there any other
>> reason for having these groups?
>>
>> I think there should be a better solution for this. probably some kind of
>> "quantisation", which means that timers cannot have an arbitrary execution
>> time, but must fit into defined values (eg every 10 msec). So if a 50 msec
>> timer which is executed at 352 msec would get executed next time not at 402
>> msec, but rounded down to 350 msec
>>
>>
>> Note that I wrote this email without having a close look at the code, so I
>> may be plain wrong :-)
>>
>>
>>
>>
>> regards, Michael
>>
>>
>>
>> --
>> Michael Reinelt <mi...@re...>
>> http://home.pages.at/reinelt
>> GPG-Key 0xDF13BA50
>> ICQ #288386781

Re: [Lcd4linux-devel] lcd4linux: timers and timer groups

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

Hi everybody,

nice to read you too Michael! I was thinking about your mail and I
think that you have a point. When I suggested the linked list
implementation I had in mind something similar to a scheduler.
Actually the Linux scheduler works in a similar way! However her we
don't need a fully featured scheduler because timers do not have a
fixed timeslice (the interval field may vary) and their number is
constant on average once the program is running. Even if we implement
a time quantum, we still have a limited number of timers that does not
require a real scheduler.

Best

Mattia

On Mon, Mar 26, 2012 at 7:05 AM, Michael Reinelt <mi...@re...> wrote:
> Hello everybode,
>
> to sum up some of the previous mails:
>
> 1. I don't like the idea of linked lists for timers (I like linked lists,
> but not in every case. In german we say "If you have a hammer, everything
> looks like a nail" :-)
>
> The current "variable length array" approach results in a single memory
> object, which grows at the beginning, but should stay at constant size and
> memroy location. Timers come and go, but the maximum number of timers should
> be constant.
>
> A (double) linked list has several memory objects. As many timers are
> "one-shot timers" they may be created and destroyed very regularly. This
> would lead to lots of malloc()/free() calls.
>
>
> 2. Probably I have found the problem with "twice evaluation": there are some
> lines of code in timer.c (but probably not in timer_group.c):
>
>    /* one-shot timers should NOT fire immediately, so delay them by a
>       single timer interval */
>    if (one_shot) {
>        timer_inc(timer, &now);
>    }
>
> so even if a new timer is added to the list after the currently being
> processed timer, it will not be triggered in the current loop.
>
>
> 3. I think having both timers and timer groups is a nuisance. Why do we have
> this? probably because timer-groups has been added as a "enhancement" which
> should not change current behaviour?
>
> Shall we try to "merge" them?
>
> IIRC the timer-groups have been introduced to avoid "fading" of timers
> because of different execution time... is this correct? is there any other
> reason for having these groups?
>
> I think there should be a better solution for this. probably some kind of
> "quantisation", which means that timers cannot have an arbitrary execution
> time, but must fit into defined values (eg every 10 msec). So if a 50 msec
> timer which is executed at 352 msec would get executed next time not at 402
> msec, but rounded down to 350 msec
>
>
> Note that I wrote this email without having a close look at the code, so I
> may be plain wrong :-)
>
>
>
>
> regards, Michael
>
>
>
> --
> Michael Reinelt <mi...@re...>
> http://home.pages.at/reinelt
> GPG-Key 0xDF13BA50
> ICQ #288386781

[Lcd4linux-devel] lcd4linux: timers and timer groups

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

Hello everybode,

to sum up some of the previous mails:

1. I don't like the idea of linked lists for timers (I like linked lists, but not in every case. In german we say "If 
you have a hammer, everything looks like a nail" :-)

The current "variable length array" approach results in a single memory object, which grows at the beginning, but should 
stay at constant size and memroy location. Timers come and go, but the maximum number of timers should be constant.

A (double) linked list has several memory objects. As many timers are "one-shot timers" they may be created and 
destroyed very regularly. This would lead to lots of malloc()/free() calls.


2. Probably I have found the problem with "twice evaluation": there are some lines of code in timer.c (but probably not 
in timer_group.c):

     /* one-shot timers should NOT fire immediately, so delay them by a
        single timer interval */
     if (one_shot) {
	timer_inc(timer, &now);
     }

so even if a new timer is added to the list after the currently being processed timer, it will not be triggered in the 
current loop.


3. I think having both timers and timer groups is a nuisance. Why do we have this? probably because timer-groups has 
been added as a "enhancement" which should not change current behaviour?

Shall we try to "merge" them?

IIRC the timer-groups have been introduced to avoid "fading" of timers because of different execution time... is this 
correct? is there any other reason for having these groups?

I think there should be a better solution for this. probably some kind of "quantisation", which means that timers cannot 
have an arbitrary execution time, but must fit into defined values (eg every 10 msec). So if a 50 msec timer which is 
executed at 352 msec would get executed next time not at 402 msec, but rounded down to 350 msec


Note that I wrote this email without having a close look at the code, so I may be plain wrong :-)




regards, Michael



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

Re: [Lcd4linux-devel] [lcd4linux-devel] Re: Twice eval. patch

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

Hello Mattia,

> In the meantime I attach a patch to fix the realloc error handling bug.

applied and checked in, thanks a lot!


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