lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] Twice eval. patch

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

Hi Marcus!

> I don't understand the realloc error handling in 'timer_add_widget'
> (similar in 'timer_add').In the case of a realloc error 'TimerGroupWidgets'
> was set to NULL. [...]

I honestly just copied this from "timer.c".  You're completely right, 
but being just faintly familiar with allocating and freeing memory in C 
(I mostly use higher programming languages), I hope that someone else 
chimes in. :)

> Why shouldn't a new 'on hold' become 'active' in the same
> loop if 'widget_timer_update' is called multible times?
> And how would you guarantee that 'widget_timer_update'
> will ever be called again (to replace 'on hold' by 'active')
> if there is only one timer widget?

While I don't understand the first part (probably some language 
barrier), your second point is valid.  It was just a first idea to get 
things going.

Still, I don't like the idea of designing a patch for the current 
problem (which could be as simple as changing "timer_add_widget" in 
"widget_timer.c" to "timer_add") and waiting for the problem to creep up 
again in another context.

> Beside that I don't like the idea that third file functions
> which made use of timer.c & timer_group.c (might be many)
> have to make efforts to guarantee that they behave as exspected.

Me neither.  As I said, first idea... :)

I do however quite like Mattias idea of using some sort of linked list. 
  The attached image might be more clear than my words, but I'm thinking 
of this: each timer slot has a variable that points to the next timer 
slot (or to zero if it is the last one).  There is an additional "main" 
pointer which points to the first timer slot (in red).  On looping, the 
loop determines the first timer slot using the "main" pointer and then 
works its way through the linked list until it reaches a slot (the last 
one) whose pointer points to zero.

If a timer slot is removed, the pointer of its predecessor is set to the 
removed slot's pointer.  When a timer slot is added, it is added to the 
*beginning* of the list so it isn't processed prematurely.  To make sure 
it will be processed in the next loop, the "main" pointer is set to the 
new slot.  Already allocated memory would be determined and used just 
like before.

Any comments? :)

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

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

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

Hi Mattia,

nice to read you!

again, I#ll comment just one part of your mail:

> First, all timers are stored in a malloc'ed
> vector that is reallocated every time a new slot is required. This is
> absolutely sub-optimal even when handling a handful of timers. The
> memory where slots are allocated is forced to be contiguous and there
> is no need for that. When no contiguous memory is available, realloc
> has to copy all pointers from the old location to the new one. Not to
> mention the fact that timers are added in a random order, filling the
> first available slot.

I slightly disagree:

normally there is a fixed number of timers used, and these timers are allocated at or very short after initialization of 
the layout.

as soon as the maximum of timers are in use, no more realloc() should occur, even if timers are recreated (for one-shot 
timers). In case of a recreation, a already allocated but available slot will be reused.


For all the discussions, please keep one aspect in mind: the "delay" value of every timer normally is a "property", that 
means that it is an expression, which is evaluated regularly, and its value may change during runtime.


think of an expression like this: "is_working_hour() ? 50 : 2000"


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

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

Hi everybody,

I've been following this discussion about timers and I mostly agree
with Martin when it comes to the implementation of timers in
lcd4linux. As far as I can see there are two major drawbacks in the
present implementation. First, all timers are stored in a malloc'ed
vector that is reallocated every time a new slot is required. This is
absolutely sub-optimal even when handling a handful of timers. The
memory where slots are allocated is forced to be contiguous and there
is no need for that. When no contiguous memory is available, realloc
has to copy all pointers from the old location to the new one. Not to
mention the fact that timers are added in a random order, filling the
first available slot. This strategy requires the extra loop over all
timers to find the next timer to be processed. The second drawback is
that processed and unprocessed timers are kept in the same vector,
triggering the bug  reported by Marcus.

What I propose is to switch to a linked list for timers and to create
two separate linked lists, one for processed timers and one for
unprocessed ones. The timers should be kept time ordered in the list
and this will make the aforementioned extra loop not required. The
processing routine will go through the active list and will process
all timers one by one, unlinking them from the active list as soon as
they are processed and linking them to the inactive list. Once the
active list is empty, all timers will have been processed and are in
the inactive list. Then it is sufficient to swap the active and
inactive list and start again.

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

Please feel free to comment on both! :)

Mattia


On Sun, Mar 25, 2012 at 2:05 PM, Michael Reinelt <mi...@re...> wrote:
> Hi Marcus, Martin,
>
> I try to think about the other stuff ASAP, but....
>
>> I don't understand the realloc error handling in 'timer_add_widget'
>> (similar in 'timer_add').In the case of a realloc error 'TimerGroupWidgets'
>> was set to NULL. So there's no valid pointer to the existing
>> TimerGroupWidgets after that. Won't that cause a memory leak and
>> following errors cause nTimerGroupWidgets is only decreased by 1
>> instead of set it to 0? Shouldn't a additional pointer be used for
>> the realloc return value to avoid this?
>
> You are *that* right. This is junk. junk junk junk.
>
> OTOH I think this will never happen in real life. When such a small allocation fails, I'm pretty sure that you will have
> other problems :-)
>
> anyway, this should be cleaned up.
>
>
>
> sunny greetings, Michael
>
>
> --
> Michael Reinelt <mi...@re...>
> http://home.pages.at/reinelt
> GPG-Key 0xDF13BA50
> ICQ #288386781
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Lcd4linux-devel mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel

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

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

Hi Marcus, Martin,

I try to think about the other stuff ASAP, but....

> I don't understand the realloc error handling in 'timer_add_widget'
> (similar in 'timer_add').In the case of a realloc error 'TimerGroupWidgets'
> was set to NULL. So there's no valid pointer to the existing
> TimerGroupWidgets after that. Won't that cause a memory leak and
> following errors cause nTimerGroupWidgets is only decreased by 1
> instead of set it to 0? Shouldn't a additional pointer be used for
> the realloc return value to avoid this?

You are *that* right. This is junk. junk junk junk.

OTOH I think this will never happen in real life. When such a small allocation fails, I'm pretty sure that you will have 
other problems :-)

anyway, this should be cleaned up.



sunny greetings, Michael


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

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

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

Hello Martin,


thanks for your feedback and ideas.

Till now I saw the bug located in the timer_group.c only.
But due to the same problem in timer.c (later field elements
might be changed in loop) I fear my patches might fail if
the interval of a widget is changed. 
Both files will have to be patched similar to avoid the bug.

> I have thought of adding a third state "on hold".  New timers 
> should be set to "on hold" to make sure they are not processed in the 
> current loop.  Now, each time "widget_timer_update()" is called, it 
> should change all timers from "on hold" to "active" so will get 
> processed from then on.

Why shouldn't a new 'on hold' become 'active' in the same
loop if 'widget_timer_update' is called multible times?
And how would you guarantee that 'widget_timer_update'
will ever be called again (to replace 'on hold' by 'active')
if there is only one timer widget?

Beside that I don't like the idea that third file functions
which made use of timer.c & timer_group.c (might be many)
have to make efforts to guarantee that they behave as exspected.

But your basic idea might work. For timer_group.c 
(timer.c similar): 

You may replace 'widget' by a global (static) 'currentWidget'
(initialized with -1 and set to -1 after the loop) in the
process loop. In 'timer_add_widget' you set 'active' 
if (currentWidget<0 || widget<=currentWidget), else 'on hold'.
If the process loop finds a 'on hold' it replaces it by
'active' and continues without processing this widget.


If you've opened the files for changes already:

I don't understand the realloc error handling in 'timer_add_widget'
(similar in 'timer_add').In the case of a realloc error 'TimerGroupWidgets'
was set to NULL. So there's no valid pointer to the existing
TimerGroupWidgets after that. Won't that cause a memory leak and
following errors cause nTimerGroupWidgets is only decreased by 1
instead of set it to 0? Shouldn't a additional pointer be used for
the realloc return value to avoid this?


Regards 

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

Re: [Lcd4linux-devel] Twice eval. patch

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

Hi Marcus,

thanks for your bug report and two patches!  I am the one who is 
responsible for rewriting the whole timer code about two years ago, and 
I have also added the timer group code.  However, I think that the 
problem lies in the general way that timers are handled in "lcd4linux" 
and that it's current manifestation in my timer group code is just one 
of the possible problems.  I do not want to defend my code, it's just 
that I've always had a bad feeling about the way that the timers are 
processed in "lcd4linux".

See, timers are (in)activated by a setting a variable to a defined state 
(I have actually *named* these states for easier reading in revision 
1182).  Inactive timers are reused by simply looping through all timers 
and looking for the state "inactive".  And this is where the problem 
lies -- while lcd4linux gets a lot faster by not allocating and freeing 
memory for each and every timer, new timers may end up in any slot.  As 
timers are processed by simply looping through all available timer 
slots, this may lead to some timers being processed more than they 
should (if during looping, a new active timer is placed in a slot with a 
higher number than the loop counter).

So while your patch may work fine (I haven't looked at it yet, as I have 
tried to concentrate on the problem itself), it might be time to fix 
timer processing instead.  We all of a sudden have a problem that we can 
understand.  Just imagine that a similar but much more complex problem 
creeps up again in a couple of months... :(

Here is my solution to the problem (feel free to post your own 
solutions!): right now timers can have two states, either active or 
inactive.  New timers are set to "active" and this is where the problem 
lies.  I have thought of adding a third state "on hold".  New timers 
should be set to "on hold" to make sure they are not processed in the 
current loop.  Now, each time "widget_timer_update()" is called, it 
should change all timers from "on hold" to "active" so will get 
processed from then on.

Any thoughts on this from you or anyone (Michael)?

Best regards,

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

[Lcd4linux-devel] Re: Twice eval. patch

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

Hello again,

the patch offered by me to solve the twice eval. problem is not that effecient. - Sorry for that. I just tried to solve it.
The attached one (no new code only the original in new order) should make the new timer be stored at the right place at once instead of exchanging it later like the old patch does.

It sets the one_shot widgets inactive after the active-test but before the callback. So in the callback that place is free to store a new element.


Regards

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

[Lcd4linux-devel] Re: Twice eval. patch

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

Hello Michael,

in the attachment you'll find a short conf. I hope the curse driver
(more simple to config) is ok for you. You'll notice that the displayed
number (cnt) will increase in steps of 2 each second (not 1 as expected)
because the timer expression is evaluated twice in one timer run.

Causes of the problem: 

The loop in line 367 of 'timer_group.c'.

At first the timer widget is added as one-shot timer to the 
'TimerGroupWidgets' field (timer_group.c) via 'timer_add_widget'
(timer_group.c) called by 'widget_timer_update' called by 
'widget_timer_init' (both in 'widget_timer.c'). 
Ignoring other timers the TimerGroupWidgets will contain:

0: Timer_Cnt active

If 'timer_process_group' (timer_group.c) is called it will call
'widget_timer_update' (widget_timer.c) for 0 via callback _in the loop_.
'widget_timer_update' calls 'timer_add_widget' (timer_group.c) which adds
a new Timer_Cnt to a new place in TimerGroupWidgets cause the old
Timer_Cnt is still active. It'll be set inactive (cause one-shot) in the
loop _after_ 'widget_timer_update' already finished. After that we got...

0: Timer_Cnt inactive
1: Timer_Cnt active

... and the loop continues to process the next active Timer_cnt (1), which
leads to...

0: Timer_Cnt active
1: Timer_Cnt inactive

=> For now on Timer_Cnt is contained twice TimerGroupWidgets and will
processed twice. First 0 that activates 1 for the same run, which
activateds 0 for the next run and so on.

Solution:

My patch exchanges the timer elements (for the same widget) so the active
element will be on the already processed position in TimerGroupWidgets.
So it won't be processed again in the same run. (I hope to not create
unwished side effects.)


Regards 

Marcus


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

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

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

Hi Marcus,

I tried to understand both the timer group code (which was not written by me) and your patch, but I failed on both cases :-)

could you please provide a as-simple-as-possible lcd4linux.conf that shows the bug? (maybe using the X11 driver, because 
currently I don't have a real display available)


Thanks in advance, Michael


Am 2012-03-19 15:49, schrieb Marcus Menzel:
> Hello,
>
> in the attachment you'll find a patch to avoid the malfunction reported at:
>
> http://ssl.bulix.org/projects/lcd4linux/ticket/278
>
> It puts the effected later element to the current position (after the
> callback) - so its callback won't be called this time.
>
> Surely not the most efficient solution, but it seems to work.
>
> Regards
>
> Marcus
>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
>
> _______________________________________________
> 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] [lcd4linux] Twice eval. patch

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

Hello,

in the attachment you'll find a patch to avoid the malfunction reported at:

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

It puts the effected later element to the current position (after the 
callback) - so its callback won't be called this time.

Surely not the most efficient solution, but it seems to work.

Regards

Marcus

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

Re: [Lcd4linux-devel] Driver & Questions: Futaba VFD M402SD06GL

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

Hello Marcus,


> motivated and supported by Robert Resch I wrote a lcd4linux driver to
> run a Futaba VFD M402SD06GL (bought mine in 2005, 40x2 chars) on the
> parallel port. The diff file is attached to this mail.

Fine, thanks! I already committed your driver, so please du a 'svn up' before continueing...


> At the moment the VFD shows no errors, but on the terminal the error
> message...
>
> unable to compact bar characters
> nSegment=3 fSegment=2 CHARS=0 ICONS=0
> Segment[0].val1=0 val2=0
> Segment[1].val1=255 val2=255
> Segment[2].val1=5 val2=1
>
> ... is shown (with variable values). What's to do?

This is because yor display does not support user-defined characters. You have to disable bars and icons in this case.

> Beside this I've some questions/concerns:
>
> 0. I'd like to install a switch on the 5V wire. By connecting the 5V
>     with a status pin (using a 1-10kOhm resistor) I could check in the
>     drivers write function if the VFD is switched off and ignore the
>     commands in this case.
>     But how can I get informed and rewrite all widgets when the VFD
>     is switched on?

lcd4linux does not support this. restarting it (using SIGHUP) is the way to go.

> 1. The driver name might be confusing because current Futaba VFDs seems
>     to run with the HD44780 driver (as LCD emulators).
I see no problem here.

> 2. The VFD supports no user defined chars or icons. So I made
>     drv_generic_text_real_defchar do nothing or should it point to NULL?
set it to NULL

> 3. Char values below 0x20 are controll data (goto, reset, dim...).
>     Should they be filtered (or replaced by blanks) in the write function?
Yes, you could do so.

> 4. Do I have to add drv_generic_parport_hardwire_ctrl for D0-7?
no, because D0..D7 are data lines, the wiring stuff is for control lines only.

> 5. What's the meaning of the first three arguments (val1,val2,dir) of
>     drv_generic_text_bar_add_segment and how must they to be 'constructed'?
Have a look at the drv_WincorNixdorf.c, which is a text-mode driver with no support for user-defined characters. There 
is a "workaround" for such displays, they use a regular character to construct bars (a '*' in the case of WincorNixdorf)


> 6. Should I delete or comment out all the icon lines?
Yes, probably.


if you have further questions, just let me know!


regards, Michael

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

[Lcd4linux-devel] Driver & Questions: Futaba VFD M402SD06GL

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

Hello,

motivated and supported by Robert Resch I wrote a lcd4linux driver to
run a Futaba VFD M402SD06GL (bought mine in 2005, 40x2 chars) on the 
parallel port. The diff file is attached to this mail.

Due C is not my native language, I need a code review. 

At the moment the VFD shows no errors, but on the terminal the error
message...

unable to compact bar characters
nSegment=3 fSegment=2 CHARS=0 ICONS=0
Segment[0].val1=0 val2=0
Segment[1].val1=255 val2=255
Segment[2].val1=5 val2=1

... is shown (with variable values). What's to do?

Beside this I've some questions/concerns:

0. I'd like to install a switch on the 5V wire. By connecting the 5V
   with a status pin (using a 1-10kOhm resistor) I could check in the
   drivers write function if the VFD is switched off and ignore the
   commands in this case.
   But how can I get informed and rewrite all widgets when the VFD
   is switched on?

1. The driver name might be confusing because current Futaba VFDs seems
   to run with the HD44780 driver (as LCD emulators). 

2. The VFD supports no user defined chars or icons. So I made 
   drv_generic_text_real_defchar do nothing or should it point to NULL?

3. Char values below 0x20 are controll data (goto, reset, dim...). 
   Should they be filtered (or replaced by blanks) in the write function?

4. Do I have to add drv_generic_parport_hardwire_ctrl for D0-7?

5. What's the meaning of the first three arguments (val1,val2,dir) of 
   drv_generic_text_bar_add_segment and how must they to be 'constructed'?
   
6. Should I delete or comment out all the icon lines?


Thanks for your help.

Regards 

Marcus

-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

Re: [Lcd4linux-devel] [Patch] New driver: TeakLCM

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

Hi Andreas,

thanks for your contribution! Your patch has been applied and committed.

may I ask you to add some documentation to the Wiki?

There is one small compiler warning about a type mismatch (unsigned int vs. size_t)


regards, Michael


Am 2012-02-13 12:32, schrieb Andreas Thienemann:
> Hi,
>
> attached is a new driver for the so called TeakLCM display.
>
> This is a 2x20 HD44780 compatible display connected to a display
> controller which implements a serial text-ish protocol for the computer
> connection.
>
> This interface is at least used in embedded devices from ARinfotek which
> are resold under a loter of brands and do make nice 19" home routers.
> More info is at http://www.arinfotek.com/product.php?gid=&pid=52
>
> The driver only implements the output portion for now. The TeakLCM
> protocol also supports reading button events and the fsm_handle_datacmd()
> function is prepared to handle this in the CMD_WRITE case.
> We were unsure however how to implement the button handling on the
> lcd4linux side which means it's basically a NOOP.
>
> I'd appreciate if anyone with a better understanding of the input handling
> could help there.
>
> cheers,
>   andreas
>
> diffstat lcd4linux-drv_TeakLCM.patch
>   Makefile.am           |    1
>   drivers.m4            |   14
>   drv.c                 |    4
>   drv_TeakLCM.c         | 1024 ++++++++++++++++++++++++++++++++++++++++++++++++++
>   lcd4linux.conf.sample |   11
>   5 files changed, 1053 insertions(+), 1 deletion(-)
>
>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
>
>
>
> _______________________________________________
> 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] [Patch] New driver: TeakLCM

[Andreas T. <an...@ba...>]

Hi,

attached is a new driver for the so called TeakLCM display.

This is a 2x20 HD44780 compatible display connected to a display 
controller which implements a serial text-ish protocol for the computer 
connection.

This interface is at least used in embedded devices from ARinfotek which 
are resold under a loter of brands and do make nice 19" home routers.
More info is at http://www.arinfotek.com/product.php?gid=&pid=52

The driver only implements the output portion for now. The TeakLCM
protocol also supports reading button events and the fsm_handle_datacmd() 
function is prepared to handle this in the CMD_WRITE case.
We were unsure however how to implement the button handling on the 
lcd4linux side which means it's basically a NOOP.

I'd appreciate if anyone with a better understanding of the input handling 
could help there.

cheers,
 andreas

diffstat lcd4linux-drv_TeakLCM.patch 
 Makefile.am           |    1 
 drivers.m4            |   14 
 drv.c                 |    4 
 drv_TeakLCM.c         | 1024 ++++++++++++++++++++++++++++++++++++++++++++++++++
 lcd4linux.conf.sample |   11 
 5 files changed, 1053 insertions(+), 1 deletion(-)

Re: [Lcd4linux-devel] [lcd4linux]Driver for Futaba M402SD06GJ

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

Hi Max,

> I'd like to run a Futaba VFD M402SD06GJ (2rows, 40 cols) on lcd4linux
> which seems to be used by fli4l.
>
> Is such driver already available (name?) or should I try to write an own one?

I don't know... maybe someone else here knows? I assume you already asked google...

Before starting to write your own driver (which would be appreciated very much) try to find out if there is a similar 
driver, so you have a good starting point.

> If I do so: Is this mailing list the right place to ask questions?
Yes :-)



regards, Michael

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

[Lcd4linux-devel] [lcd4linux]Driver for Futaba M402SD06GJ

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

Hi there,


I'd like to run a Futaba VFD M402SD06GJ (2rows, 40 cols) on lcd4linux
which seems to be used by fli4l. 

Is such driver already available (name?) or should I try to write an own one? 

If I do so: Is this mailing list the right place to ask questions?


Thanks for help

max


-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://www.gmx.net/de/go/freephone/

[Lcd4linux-devel] Frage nach speziellem Display / Asking for special new display EA DIP180B-5NLW

[André-Marc R. <ara...@ma...>]

Hallo zusammen,

ich habe bei Electronic Assembly ein Display entdeckt, welches besonders interessante Maße bietet: Model EA DIP180B-5NLW (http://www.lcd-module.de/pdf/grafik/dip180-5.pdf)
Dieses Display wäre perfekt für den Einbau in das Varia 19" Gehäuse für IPCOP (http://shop.varia-store.com/product_info.php?info=p694_19---DualRack-System-fuer-MikroTik-und-PC-Engines-ALIX-Boards.html). Gibt es die Möglichkeit dieses Display mit lcd4linux anzusteuern? Oder ist ein Treiber hierfür in der Entwicklung?


Hello together,

i have seen a very interesting display at Electronic Assembly with special dimensions: Model EA DIP180B-5NLW (http://www.lcd-module.de/pdf/grafik/dip180-5.pdf). This Display would be perfect for using in the Varia Case 19" for IPCOP (http://shop.varia-store.com/product_info.php?info=p694_19---DualRack-System-fuer-MikroTik-und-PC-Engines-ALIX-Boards.html). Would it be possible to use this display with lcd4linux or will be a driver availible in the nearest future?


Thanks a lot, André

Re: [Lcd4linux-devel] [lcd4linux] Patch for Driver EA232Graphic - Updated

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

Hallo Robert,

thanks for your patch! Looks fine, and has been applied and checked in!

Maybe you want to update documentation on the wiki?



regards, Michael


Am 2012-01-15 21:32, schrieb Robert Resch:
> Hi!
>
> There are some Updates to the Patch/Driver.
>
> There are 3 more Displays supported now and GPO should work, too for them.
> Also the Initialization (clear display) disables eventually enabled
> cursors for Protocol 2
>
> Yours, Robert Resch
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Mar 27 - Feb 2
> Save $400 by Jan. 27
> Register now!
> http://p.sf.net/sfu/rsa-sfdev2dev2
>
>
>
> _______________________________________________
> Lcd4linux-users mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd4linux-users

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

Re: [Lcd4linux-devel] [PATCH] scaletext

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

Hello Stefan,

I like your patch :-)

has been applied an committed.


Am 2012-01-12 17:46, schrieb Stefan Kuhne:
> Hello,
>
> I've review and test a patch to make text on graphic displays (at this
> moment only driver dpf) scalable.
>
> It is available at [1].
>
> Regards,
> Stefan Kuhne
>

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

[Lcd4linux-devel] [PATCH] scaletext

[Stefan K. <ste...@gm...>]

Hello,

I've review and test a patch to make text on graphic displays (at this
moment only driver dpf) scalable.

It is available at [1].

Regards,
Stefan Kuhne

-- 
[1]: http://www.skuhne.de/Dinge/lcd4linux/scaletext.patch

Re: [Lcd4linux-devel] Make driver patch ready for commit

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

Hello Stefan,

> who can i configure tell were serdisplib and my dpf lib are on my system?
>
> I think about something lik -L or LDFLAGS.

put them in a "standard" place, and autoconf (configure) should find them. If e.g serdisplib is installed on my system, 
configure will detect it automatically.

Note that configure produces a (very detailled) logfile "config.log" which should explan all the checks configure does. 
basically it creates a "test.c file" and tries to compile it. You can see the contents of this test file in config.log

I think if libdpf.h can be found in /usr/include (or /usr/local/include) and the lib in /usr/lib (usr/local/lib) 
everything should be fine.


But maybe someone with deeper autoconf knowledge can correct me.


regards, Michael


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

Re: [Lcd4linux-devel] Make driver patch ready for commit

[Stefan K. <ste...@gm...>]

Am 08.01.2012 09:29, schrieb Michael Reinelt:

Hello,

> Currently I'm not sure how to deal with libdpf. I don't think its a good idea to include the code in lcd4linux. So the 
> driver won't compile because autoconf will not find the library.
> 
> Any ideas anyone?
> 
who can i configure tell were serdisplib and my dpf lib are on my system?

I think about something lik -L or LDFLAGS.

Regards,
Stefan Kuhne

Re: [Lcd4linux-devel] Make driver patch ready for commit

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

Hello Stefan,

> I've upload my last version to [2].
> The check is in dpf_mod.patch and the lib is in dpflib.patch.

Thanks a lot, I applied two of your patches (dpf_drv.patch and dpf_mod.patch) and committed your changes.

Currently I'm not sure how to deal with libdpf. I don't think its a good idea to include the code in lcd4linux. So the 
driver won't compile because autoconf will not find the library.

Any ideas anyone?



> PS.: Is this the right E-Mail from my for the list?
Yes, that's fine!



regards, Michael


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

Re: [Lcd4linux-devel] [PATCH 2/2] gcc warnings

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

Hi Jon,

thanks a lot, both patches have been applied and checked in!



On 2012-01-04 23:54, Jonathan McCrohan wrote:
> Hi Michael,
>
> Attached are two small patches which I believe fix the gcc warnings and
> issues listed on the Debian buildd logs page [1].
>
> Thanks,
> Jon
>
> [1] https://buildd.debian.org/~brlink/packages/l/lcd4linux.html
>
>
>
> Signed-off by: Jonathan McCrohan<jmc...@gm...>
>
> diff --git a/Makefile.am b/Makefile.am
> index bdf6b41..cd7d5b4 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -18,7 +18,7 @@ ACLOCAL_AMFLAGS=-I m4
>   # use this for lots of warnings
>   #AM_CFLAGS = -D_GNU_SOURCE -std=c99 -m64 -Wall -W -pedantic -Wno-variadic-macros -fno-strict-aliasing
>
> -lcd4linux_LDFLAGS =
> +lcd4linux_LDFLAGS ="-Wl,--as-needed"
>   lcd4linux_LDADD   = @DRIVERS@ @PLUGINS@ @DRVLIBS@ @PLUGINLIBS@
>   lcd4linux_DEPENDENCIES = @DRIVERS@ @PLUGINS@
>
>

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

Re: [Lcd4linux-devel] Make driver patch ready for commit

[Stefan K. <ste...@gm...>]

Am 05.01.2012 08:30, schrieb Michael Reinelt:
> On 2012-01-04 22:18, Stefan Kuhne wrote:

Hello,

>> I (and a mate) try to make the dpf driver [1] clean and ready for commit
>> to lcd4linux svn and use for fli4l.
> 
> Whaere / What is [1]?
> 
I forgot ...

>> It has an own little lib that wie will seperate in an subfolder.
>> The driver works at one of other guys, but I've a problem with the check
>> for the lib.
>>
>> Or to you think, because of it is in svn too I don't need a check for it?
> 
> As soon as I can have a look at the patch, I may be able to tell :-)
> 
I've upload my last version to [2].
The check is in dpf_mod.patch and the lib is in dpflib.patch.

Thanks and Regards,
Stefan Kuhne

PS.: Is this the right E-Mail from my for the list?

-- 
[1]:
http://geekparadise.de/2011/04/digitaler-bilderrahmen-von-pearl-als-statusdisplay-fur-dockstar/

[2]: http://www.skuhne.de/Dinge/lcd4linux/