lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] [AC_PATCH] for compiling lcd4linux-svn 1038

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

applied and checked in. Thanks a lot!


PT M. schrieb:
> Some instructions of the autotools maros was making the compling not
> able to procceed, especially in newer distributions.
> 
> This patch mainly fix for the python checking module, one need to
> download new ax_python_devel.m4 from
> http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_python_devel.m4
> (to replace the old ac_python_devel.m4) to fix the autoconf error.
> 
> And the problem of the plugin mpd, no header files or linking flags were
> added to plugins.m4, this patch done with this by calling pkg-config
> after checking "libmpd"
> 
> I'm now maintaing the package of lcd4linux-svn in Arch User Repo:
> http://aur.archlinux.org/packages.php?ID=20514
> <http://aur.archlinux.org/packages.php?ID=20514%20>

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

[Lcd4linux-devel] [AC_PATCH] for compiling lcd4linux-svn 1038

[PT M. <pe...@gm...>]

Some instructions of the autotools maros was making the compling not able to
procceed, especially in newer distributions.

This patch mainly fix for the python checking module, one need to download
new ax_python_devel.m4 from
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_python_devel.m4(to
replace the old ac_python_devel.m4) to fix the autoconf error.

And the problem of the plugin mpd, no header files or linking flags were
added to plugins.m4, this patch done with this by calling pkg-config after
checking "libmpd"

I'm now maintaing the package of lcd4linux-svn in Arch User Repo:
http://aur.archlinux.org/packages.php?ID=20514
<http://aur.archlinux.org/packages.php?ID=20514%20>

Re: [Lcd4linux-devel] displaylink - samsung u70

[Sven K. <sv...@ki...>]

> -----Original Message-----
> From: Oktay Oeztueter [mailto:in...@ok...]
> Sent: Friday, September 04, 2009 12:49 AM
> To: lcd...@li...
> Subject: [Lcd4linux-devel] displaylink - samsung u70
> 
> any idea how to connect this device to lcd4linux?
> This is a USB monitor. 800x480 pixel
> Support for framebuffer would be fine

You can use either the framebuffer driver from the mailing list
http://libdlo.freedesktop.org/wiki/displaylink-mod
or my console driver
http://sven.killig.de/openwrt/slugterm_dl.html

[Lcd4linux-devel] displaylink - samsung u70

[Oktay O. <in...@ok...>]

Hi, 

any idea how to connect this device to lcd4linux?
This is a USB monitor. 800x480 pixel
Support for framebuffer would be fine

regards,
o oeztueter

Re: [Lcd4linux-devel] Gif widget

[Scott F. <sc...@st...>]

/* $Id: widget_gif.c 1035 2009-05-19 10:42:01Z michael $
 * $URL: https://ssl.bulix.org/svn/lcd4linux/trunk/widget_gif.c $
 *
 * gif widget handling
 *
 * Copyright (C) 2003, 2004 Michael Reinelt <mi...@re...>
 * Copyright (C) 2004 The LCD4Linux Team <lcd...@us...>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2, or (at your option)
 * any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 *
 */

/*
 * exported functions:
 *
 * WIDGET_CLASS Widget_Gif
 *   the gif widget
 *
 */


#include "config.h"

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

#include "debug.h"
#include "cfg.h"
#include "qprintf.h"
#include "property.h"
#include "timer.h"
#include "rgb.h"
#include "widget.h"
#include "widget_gif.h"

#ifdef WITH_DMALLOC
#include <dmalloc.h>
#endif

extern int XRES, YRES;

void widget_gif_update(void *Self)
{
    WIDGET *W = (WIDGET *) Self;
    WIDGET_GIF *Gif = W->data;
    BYTE pixel;
    int row, col;


    FIBITMAP *dib, *dib2;

    if(W->parent == NULL) {
        dib = FreeImage_LockPage(Gif->image, Gif->pagePtr);
        
        if (!dib) {
            error("Unable to lock gif page: %s", W->name);
            return;
        }

        dib2 = FreeImage_ConvertTo8Bits(dib);
        memset(Gif->bitmap, 0, Gif->width * Gif->height * sizeof(RGBA));
    
        for(row = Gif->ypoint; row < Gif->ypoint + Gif->height; row++) {
            for(col = Gif->xpoint; col < Gif->xpoint + Gif->width; col++) {
                if( FreeImage_GetPixelIndex(dib2, col, row, &pixel) ) {
        	        if((int)pixel != Gif->background && (int)pixel != Gif->transparent) {
			//	error("pixel %d, r: %d, g: %d, b: %d", pixel, Gif->palette[pixel].rgbRed, Gif->palette[pixel].rgbGreen, Gif->palette[pixel].rgbBlue );
                	    Gif->bitmap[(Gif->height-row-1) * Gif->width + col].R = Gif->palette[pixel].rgbRed;
	                    Gif->bitmap[(Gif->height-row-1) * Gif->width + col].G = Gif->palette[pixel].rgbGreen;
        	            Gif->bitmap[(Gif->height-row-1) * Gif->width + col].B = Gif->palette[pixel].rgbBlue;
                            Gif->bitmap[(Gif->height-row-1) * Gif->width + col].A = 255;
                	}
		}
            }
        }
        
        FreeImage_UnlockPage(Gif->image, dib, FALSE);
        Gif->pagePtr++;
        if( Gif->pagePtr > Gif->end) {
            Gif->pagePtr = Gif->start;
        }

        property_eval(&Gif->visible);
    } 


    /* finally, draw it! */
    if (W->class->draw)
        W->class->draw(W);

}



int widget_gif_init(WIDGET * Self)
{
    char *section, *file;
    int i;

    /* prepare config section */
    /* strlen("Widget:")=7 */
    RGBQUAD bkcolor;
    WIDGET_GIF *Gif;
    FIBITMAP *dib2;

    section = malloc(strlen(Self->name) + 8);
    strcpy(section, "Widget:");
    strcat(section, Self->name);

    Gif = malloc(sizeof(WIDGET_GIF));
    memset(Gif, 0, sizeof(WIDGET_GIF));

    /* load properties */
    property_load(section, "update", "200", &Gif->update);
    property_load(section, "visible", "1", &Gif->visible);

    property_eval(&Gif->update);
    
    if (Self->parent == NULL) {
        file = cfg_get(section, "file", NULL);
        if( file == NULL ) {
            error("You must specify a gif file: %s", Self->name);
            return 0;
        }
    
        Gif->image = FreeImage_OpenMultiBitmap(FIF_GIF, file, FALSE, TRUE, FALSE, GIF_PLAYBACK);;
    
        Gif->lastFrame = FreeImage_GetPageCount(Gif->image) - 1;
        FIBITMAP *dib = FreeImage_LockPage(Gif->image, 0);
        if( !dib ) {
            error("Unable to iterate gif: %s", Self->name);
    	    return 0;
        }
    
        dib2 = FreeImage_ConvertTo8Bits(dib);
        FreeImage_GetBackgroundColor(dib2, &bkcolor);
        Gif->background = (&bkcolor)->rgbReserved;
        Gif->transparent = FreeImage_GetTransparentIndex(dib2);
        Gif->palette = FreeImage_GetPalette(dib2);
    
        cfg_number(section, "start", 0, 0, Gif->lastFrame, &Gif->start);
        cfg_number(section, "end", Gif->lastFrame, 0, Gif->lastFrame, &Gif->end);
        cfg_number(section, "width", -1, 0, -1, &Gif->width);
        cfg_number(section, "height", -1, 0, -1, &Gif->height);
        cfg_number(section, "xpoint", 0, 0, Gif->width - 1, &Gif->xpoint);
        cfg_number(section, "ypoint", 0, 0, Gif->height - 1, &Gif->ypoint);
    
        Gif->pagePtr = Gif->start;
        
        if( Gif->height == -1 ) {
            Gif->height = FreeImage_GetHeight(dib2);
        }
    
        if( Gif->width == -1 ) {
            Gif->width = FreeImage_GetWidth(dib2);
        }
        
        FreeImage_UnlockPage(Gif->image, dib, FALSE);
    
        free(section);
        Self->data = Gif;
        Self->x2 = Self->col + Gif->width / XRES - 1;
        Self->y2 = Self->row + Gif->height / YRES - 1;
    
        /* reset ascii  */
        for(i = 0; i < Gif->width / XRES * Gif->height / YRES; i++) {
            Gif->ascii[i] = -1;
        }
    
        Gif->bitmap = malloc(Gif->width * Gif->height * sizeof(RGBA));
    } else {
        Gif = Self->data = Self->parent->data;
        Self->x2 = Self->col + Gif->width / XRES - 1;
        Self->y2 = Self->row + Gif->height / YRES - 1;
    }

    /* just do it! */
    timer_add(widget_gif_update, Self, P2N(&Gif->update), 0);

    return 0;
}


int widget_gif_quit(WIDGET * Self)
{
    if (Self) {
        if (Self->parent == NULL ) {
            if (Self->data) {
                WIDGET_GIF *Gif = Self->data;
                property_free(&Gif->update);
                property_free(&Gif->visible);
                if (Gif->bitmap)
                    free(Gif->bitmap);
                if (Gif->image)
                    FreeImage_CloseMultiBitmap(Gif->image, GIF_PLAYBACK);
                free(Self->data);
                Self->data = NULL;
            }
        }
    }

    return 0;

}



WIDGET_CLASS Widget_Gif = {
    .name = "gif",
    .type = WIDGET_TYPE_RC,
    .init = widget_gif_init,
    .draw = NULL,
    .quit = widget_gif_quit,
};

[Lcd4linux-devel] pyLCDControl and possible widgets for LCD4Linux

[Scott F. <sc...@st...>]

I hope you don't mind. I've rewritten parts of LCD4Linux in Python to use in
my own LCD controller based on gobject and pygtk for a gui. I've used the
widget design, the evaluator, some plugins (I'll be using most probably),
text widget, layouts design, animated icons, and likely other properties.
I've included the following widgets: text, bar (not split, but has hollow
option), histogram, gif animation, big numbers, keypad, timer, and icon. My
goal's to create a GUI designer that saves in either a Config Object file
(pyLCDControl's config system) or a LCD4Linux config file. I'm not looking
to support the full gamut of LCDs. My main focus was Crystalfontz displays
and picoLCD 256x64 graphic display as that's what I own. I also want to buy
one of the 4D OLED displays and play with that as well.

Now you're probably wondering why I didn't just use LCD4linux. Well, I tried
it and found it a nightmare to program with due to the bars code. I find
that special characters are fundamental to the enjoyment a character display
can offer. I feel one must offer as much freedom over these special
characters through widgets as possible. I've actually discovered that I
relied too hard on the special characters so that when it comes to graphics
displays I'll have to write in special code for big numbers and gif
animations, either that or give every graphics display a large amount of
virtual special characters to use, but the problem with that is you lose any
colors in an image file like in pyLCDControl's gif widget. It basically
draws a pixel on the special character for any non-zero, non-background,
non-transparency image pixel.

I want to bring some of these widgets over to LCD4Linux, like the big
numbers and gif animations. I wrote the number fonts so they're a little
ugly, but they're passable, and I'm releasing them under GNU2 with
pyLCDControl so feel free to include them with LCD4Linux. Let me know if
this all sounds interesting and I'll start working on it. These two widgets
don't work on all displays as some displays have gaps between character
cells, so they look a little funny. I didn't know how you would feel about
that, but I figured I'd mention it up front.

Anyhow, if you want to review exactly what I've rewritten for use in
pyLCDControl, here's a link to the code. Be warned that not all of the
Crystalfontz code has been tested. I have two CFA635's, one with SCAB, so
that's all I've tested. Check out the config file (config.ini) to see where
I've headed with this. There's an X11 driver configured, and you can
navigate the layouts via the buttons on the side of the gtk window. Comment
out lines with # if those displays cause problems.

Dependencies are gobject, pygtk, config object (
http://www.voidspace.org.uk/python/configobj.html), and I think that's it.
Should work with Python 2.5 and up. I haven't tested on anything lower.

http://www.starlon.net/files/pyLCDControl.1.tar.gz<http://www.starlon.net/pyLCDControl.php>

Re: [Lcd4linux-devel] Histograms

[Scott F. <sc...@st...>]

Ok, I narrowed it down. Conclusion is that you can't reuse too much of the
bar code for histograms. And working around the bar code to work in some
sort of histogram is going to be a pita I think.

On Wed, May 20, 2009 at 8:24 AM, Scott Flynn <sc...@st...> wrote:

> Bah this isn't working out perfectly. There's some bug I just can't figure
> out. And what's worse is it's impossible to reproduce. You have to wait for
> it to happen then start checking debug messages. The values are all in
> order, but sometimes what gets printed to the LCD isn't what's expected. The
> one scenario that bugs me most is three ticks back to back at full value,
> then zero values, the second segment vanishes, but sometimes shows up later,
> and the third segment stays in position 0. And every once in a while the
> histogram acts like a regular bar, but I think I fixed that one. Got any
> ideas what might be causing the first bug?
>
> Like I said, the values are all correct when the bug occurs. These values:
>
> 0 0 8 8 8 0 0 0 0 0 0
>
> Look like this on the LCD.
>
> 8 0 8 0 8 0 0 0 0 0 0
>
> Then next tick it might look like:
>
> 8 0 0 8 0 8 0 0 0 0 0
>
> Or the initial 8 might turn into a 0.
>
> I'm going to keep at this, but was hoping maybe someone would have
> suggestions. There's also an updated diff attached. I still don't know what
> to do about a width property.
>
> On Tue, May 19, 2009 at 8:22 AM, Scott Flynn <sc...@st...> wrote:
>
>>
>> On Tue, May 19, 2009 at 7:57 AM, Michael Reinelt <mi...@re...>wrote:
>>
>>> Hi Scott,
>>>
>>> > Well, it was an experiment. I wanted to make it complicated I guess.
>>> > That part in define_chars is broken. That's what I was working on when
>>> I
>>> > took a break to check email. Anyhow, I envisioned a left and right half
>>> > per each character cell. Not a good idea? Dealing with 2 values makes
>>> > more sense on a graphical LCD with color settings.
>>>
>>> Well, I thought a histogramm would have one expression as a value, and
>>> this (historic) value is sort of "scrolled" to
>>> the left (or the right or...)
>>
>>
>> Well it certainly simplifies things going with one value. All histograms
>> I've seen have had one value. I just wanted to be difficult. I'll cut this
>> back to a single value, still using the bars structure.
>>
>>
>>>
>>>
>>> >     - you can specify the length of a histogram (as with bars), but
>>> >     shouldn't there be something like a "width"? Looks like
>>> >     you're always using the whole size of the display.....
>>> >
>>> >
>>> > What would be the difference between width and length? When I setup a
>>> > histogram with length of 5, the histogram stays within those limits,
>>> and
>>> > I can place a widget after it. I used this length in adjusting bar
>>> > cells. One cell is discarded each pulse. I may have missed parts where
>>> > an index may fall out of range, but it shouldn't be using the whole
>>> > screen. If it is, point me to the code and I'll figure something out.
>>>
>>> I could not test it, I just wondered.
>>>
>>> think of a display with 8 rows and 40 columns.
>>>
>>> Now I want to place some text in the top line, and below place two
>>> histograms, 7 rows in height, and 19 columns in width
>>> (19 columns to get a gap between the two widgets). Say the histogramm is
>>> heading North (i.e. bars starting at the
>>> bottom, heading top)
>>>
>>> The "length" of the bars would be 7 cells, so one would specify "length
>>> 7" (or whatever the property is called)
>>>
>>> But how would I specify the width of the widget? I couldn't see any
>>> parameter or attribute for this....
>>>
>>
>> Oh I see. In that case width is one character cell (according to the
>> patch). I wasn't thinking along the same lines. I was viewing a histogram as
>> being one cell heigh, and "length" many columns wide for horizontal bars.
>> Vertical bars are one cell wide, and "length" many cells high. I wasn't
>> going to add support for vertical histograms at first, but I went ahead and
>> coded in parts leading towards them.
>>
>>
>>>
>>>
>>>
>>>
>>> --
>>> Michael Reinelt <mi...@re...>
>>> http://home.pages.at/reinelt
>>> GPG-Key <http://home.pages.at/reinelt%0AGPG-Key> 0xDF13BA50
>>> ICQ #288386781
>>>
>>
>>
>

Re: [Lcd4linux-devel] Histograms

[Scott F. <sc...@st...>]

On Tue, May 19, 2009 at 7:57 AM, Michael Reinelt <mi...@re...>wrote:

> Hi Scott,
>
> > Well, it was an experiment. I wanted to make it complicated I guess.
> > That part in define_chars is broken. That's what I was working on when I
> > took a break to check email. Anyhow, I envisioned a left and right half
> > per each character cell. Not a good idea? Dealing with 2 values makes
> > more sense on a graphical LCD with color settings.
>
> Well, I thought a histogramm would have one expression as a value, and this
> (historic) value is sort of "scrolled" to
> the left (or the right or...)


Well it certainly simplifies things going with one value. All histograms
I've seen have had one value. I just wanted to be difficult. I'll cut this
back to a single value, still using the bars structure.


>
>
> >     - you can specify the length of a histogram (as with bars), but
> >     shouldn't there be something like a "width"? Looks like
> >     you're always using the whole size of the display.....
> >
> >
> > What would be the difference between width and length? When I setup a
> > histogram with length of 5, the histogram stays within those limits, and
> > I can place a widget after it. I used this length in adjusting bar
> > cells. One cell is discarded each pulse. I may have missed parts where
> > an index may fall out of range, but it shouldn't be using the whole
> > screen. If it is, point me to the code and I'll figure something out.
>
> I could not test it, I just wondered.
>
> think of a display with 8 rows and 40 columns.
>
> Now I want to place some text in the top line, and below place two
> histograms, 7 rows in height, and 19 columns in width
> (19 columns to get a gap between the two widgets). Say the histogramm is
> heading North (i.e. bars starting at the
> bottom, heading top)
>
> The "length" of the bars would be 7 cells, so one would specify "length 7"
> (or whatever the property is called)
>
> But how would I specify the width of the widget? I couldn't see any
> parameter or attribute for this....
>

Oh I see. In that case width is one character cell (according to the patch).
I wasn't thinking along the same lines. I was viewing a histogram as being
one cell heigh, and "length" many columns wide for horizontal bars. Vertical
bars are one cell wide, and "length" many cells high. I wasn't going to add
support for vertical histograms at first, but I went ahead and coded in
parts leading towards them.


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

[Lcd4linux-devel] Histograms

[Scott F. <sc...@st...>]

On Tue, May 19, 2009 at 5:57 AM, Michael Reinelt <mi...@re...>wrote:

> Hi Scott,
>
> > I decided to work on this.
> Great! Histograms have been on my todo list for years, but as I'm that busy
> all the time...
>
> > I think I'm understanding the bars code. The
> > one thing that confuses me is pack_segments. I found that it cleaned up
> > a lot of garbage however, so I'm assuming that's all it's for.
>
> Well, as I said, the bar code is quite complex. I'll try to explain it a
> bit:
>
> A bar (especially the split bars) are made of custom chars (except the
> "empty" and the "full" cell, empty is always a
> blank, full is used only if a solid block is avaliable.
>
> So if you have several bars (with mixed directions) and split bars
> alltogether at the same time, you'll need a very lot
> of these custom chars. Unfortunately, the number of custom chars is limited
> (usually only eight). So the bar code tries
> to add little "errors" to the bars to combine two chars into one (think of
> two bar cells, one with three pixel rows set,
> one with two. The bar code would either expand one bar to use three columns
> or reduce the other cell to use only two
> rows. This "compaction" is quite complicated, because there are several
> constrains you have to deal with: a bar line
> shall never be "interrupted" (it should not contain "holes", this is
> especially tricky with split bars), you should not
> redefine a custom char that is currently visible (otherwise you'll get some
> flickering) and so on.


The split bars are great. I thought that was one of the cooler things about
LCD4Linux.


>
>
> > I only
> > dealt with direction east in the character creation because only east
> > works for me. Outside of west maybe, It might be a limitation with my
> > CFA635.
> No, there shouldn't be a limitation. bars should work in all directions,
> otherwise there may be a bug.
>
> > I'm ordering a picoLCD here soon so I'll have a graphics display
> > to play with and I can work on a graphics version of the histogram,
> > unless someone else picks it up. Anyhow, there's a diff attached.
>
> graphic histograms would be great, too!
>
>
> > Why don't westbound bars work?
> see above
>
>
> I don't really understand your patch. You tried to reuse the bar code, but:
>
> - a histogram should not deal with "val1" and "val2", this is for split
> bars only (at least there shouldn't be a
> seperate expression)


Well, it was an experiment. I wanted to make it complicated I guess. That
part in define_chars is broken. That's what I was working on when I took a
break to check email. Anyhow, I envisioned a left and right half per each
character cell. Not a good idea? Dealing with 2 values makes more sense on a
graphical LCD with color settings.


>
>
> - you can specify the length of a histogram (as with bars), but shouldn't
> there be something like a "width"? Looks like
> you're always using the whole size of the display.....


What would be the difference between width and length? When I setup a
histogram with length of 5, the histogram stays within those limits, and I
can place a widget after it. I used this length in adjusting bar cells. One
cell is discarded each pulse. I may have missed parts where an index may
fall out of range, but it shouldn't be using the whole screen. If it is,
point me to the code and I'll figure something out.


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

Re: [Lcd4linux-devel] Icons

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

Hi Scott,

> Nah I reset the icon counter. The problem is I want to display a bunch
> of icons in one layout, and some bars in another layout. You can't
> have both with the icons being allocated at the device level. One
> thing you could do is allow a layout to override this value. It's
> unobtrusive that way.

Well, I don't think it's a good idea to make the icon number sort of dynamically. Especially when I think of layers, the
hopefully soon coming screens, and maybe some sort of "blending" between different screens and/or layouts.

In general, I think that more and more only graphic displays will be available, and they don't have this problem at all.


bye, Michael

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

Re: [Lcd4linux-devel] [lcd4linux] Layout transitions

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

Hi Scott,

> You know, Michael, you asked about SVN's state as far as if it was
> release ready or not. I can't run it in the background. I get the following:
> May 17 22:20:03 localhost LCD4Linux[25367]:
> mkstemp(/var/run/lcd4linux.pid.8qKs4S) failed: Permission denied
> May 17 22:20:03 localhost LCD4Linux[25367]: lcd4linux already running as
> process -1
> 
> It runs fine in the foreground.

Strange. looks like a permission issue. did you set a setuid bit or something? what are the permissions on /var/run?


bye, Michael


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

Re: [Lcd4linux-devel] Histograms

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

Hi Scott,

> I decided to work on this. 
Great! Histograms have been on my todo list for years, but as I'm that busy all the time...

> I think I'm understanding the bars code. The
> one thing that confuses me is pack_segments. I found that it cleaned up
> a lot of garbage however, so I'm assuming that's all it's for. 

Well, as I said, the bar code is quite complex. I'll try to explain it a bit:

A bar (especially the split bars) are made of custom chars (except the "empty" and the "full" cell, empty is always a
blank, full is used only if a solid block is avaliable.

So if you have several bars (with mixed directions) and split bars alltogether at the same time, you'll need a very lot
of these custom chars. Unfortunately, the number of custom chars is limited (usually only eight). So the bar code tries
to add little "errors" to the bars to combine two chars into one (think of two bar cells, one with three pixel rows set,
one with two. The bar code would either expand one bar to use three columns or reduce the other cell to use only two
rows. This "compaction" is quite complicated, because there are several constrains you have to deal with: a bar line
shall never be "interrupted" (it should not contain "holes", this is especially tricky with split bars), you should not
redefine a custom char that is currently visible (otherwise you'll get some flickering) and so on.

> I only
> dealt with direction east in the character creation because only east
> works for me. Outside of west maybe, It might be a limitation with my
> CFA635.
No, there shouldn't be a limitation. bars should work in all directions, otherwise there may be a bug.

> I'm ordering a picoLCD here soon so I'll have a graphics display
> to play with and I can work on a graphics version of the histogram,
> unless someone else picks it up. Anyhow, there's a diff attached.

graphic histograms would be great, too!


> Why don't westbound bars work?
see above


I don't really understand your patch. You tried to reuse the bar code, but:

- a histogram should not deal with "val1" and "val2", this is for split bars only (at least there shouldn't be a
seperate expression)

- you can specify the length of a histogram (as with bars), but shouldn't there be something like a "width"? Looks like
you're always using the whole size of the display.....


bye, Michael


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

Re: [Lcd4linux-devel] Histograms

[Scott F. <sc...@st...>]

Nevermind, false alarm. Rebooting my computer fixed it. I guess all the
crashing and debugging corrupted my computer. lol

On Tue, May 19, 2009 at 4:59 AM, Scott Flynn <sc...@st...> wrote:

> Well I did something to it and now there's a bug. I'll try to fix that
> before I go to bed.
>
>
> On Tue, May 19, 2009 at 3:26 AM, Scott Flynn <sc...@st...> wrote:
>
>> I decided to work on this. I think I'm understanding the bars code. The
>> one thing that confuses me is pack_segments. I found that it cleaned up a
>> lot of garbage however, so I'm assuming that's all it's for. I only dealt
>> with direction east in the character creation because only east works for
>> me. Outside of west maybe, It might be a limitation with my CFA635. I'm
>> ordering a picoLCD here soon so I'll have a graphics display to play with
>> and I can work on a graphics version of the histogram, unless someone else
>> picks it up. Anyhow, there's a diff attached.
>>
>> Why don't westbound bars work?
>>
>>
>> On Sat, May 16, 2009 at 9:41 AM, Scott Flynn <sc...@st...> wrote:
>>
>>> I've always liked these, and would love if LCD4Linux had a histogram
>>> widget. Basically it's a heartbeat monitor. The bars are nice, but
>>> they only show the state right now. Histograms show the state over the
>>> past however long. Here's an example of what I mean.
>>>
>>> .....|*****|*****|*****|*****|*****|*****|*****|
>>> .....|.....|*****|*****|*****|*****|*****|*****|
>>> .....|.....|.....|*****|*****|*****|*****|*****|
>>> .....|.....|.....|.....|*****|*****|*****|*****|
>>> .....|.....|.....|.....|.....|*****|*****|*****|
>>> .....|.....|.....|.....|.....|.....|*****|*****|
>>> .....|.....|.....|.....|.....|.....|.....|*****|
>>> .....|.....|.....|.....|.....|.....|.....|.....|
>>>
>>>
>>> That may or may not show up right. Try looking at it in a terminal.
>>> These are the 8 special chars used for the histogram. If you have more
>>> special chars, you can complete the spectrum. For every row in a LCD's
>>> characters, the better the histogram looks. Mine has 8 rows.
>>>
>>> It basically ticks every so often and moves the history right or left,
>>> appending the new value representation (the LCD's special char).
>>>
>>
>>
>

Re: [Lcd4linux-devel] [lcd4linux] Layout transitions

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

Hi Marcus,


> Any chance of adding my layer patch prior to 0.11? (Ref: 20090402)
> Screens _and_ layers together might be interesting to play with ;)

Sorry, I missed that one. I'll take care of that.


bye, Michael

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

Re: [Lcd4linux-devel] Histograms

[Scott F. <sc...@st...>]

Well I did something to it and now there's a bug. I'll try to fix that
before I go to bed.

On Tue, May 19, 2009 at 3:26 AM, Scott Flynn <sc...@st...> wrote:

> I decided to work on this. I think I'm understanding the bars code. The one
> thing that confuses me is pack_segments. I found that it cleaned up a lot of
> garbage however, so I'm assuming that's all it's for. I only dealt with
> direction east in the character creation because only east works for me.
> Outside of west maybe, It might be a limitation with my CFA635. I'm ordering
> a picoLCD here soon so I'll have a graphics display to play with and I can
> work on a graphics version of the histogram, unless someone else picks it
> up. Anyhow, there's a diff attached.
>
> Why don't westbound bars work?
>
>
> On Sat, May 16, 2009 at 9:41 AM, Scott Flynn <sc...@st...> wrote:
>
>> I've always liked these, and would love if LCD4Linux had a histogram
>> widget. Basically it's a heartbeat monitor. The bars are nice, but
>> they only show the state right now. Histograms show the state over the
>> past however long. Here's an example of what I mean.
>>
>> .....|*****|*****|*****|*****|*****|*****|*****|
>> .....|.....|*****|*****|*****|*****|*****|*****|
>> .....|.....|.....|*****|*****|*****|*****|*****|
>> .....|.....|.....|.....|*****|*****|*****|*****|
>> .....|.....|.....|.....|.....|*****|*****|*****|
>> .....|.....|.....|.....|.....|.....|*****|*****|
>> .....|.....|.....|.....|.....|.....|.....|*****|
>> .....|.....|.....|.....|.....|.....|.....|.....|
>>
>>
>> That may or may not show up right. Try looking at it in a terminal.
>> These are the 8 special chars used for the histogram. If you have more
>> special chars, you can complete the spectrum. For every row in a LCD's
>> characters, the better the histogram looks. Mine has 8 rows.
>>
>> It basically ticks every so often and moves the history right or left,
>> appending the new value representation (the LCD's special char).
>>
>
>

Re: [Lcd4linux-devel] [lcd4linux] Layout transitions

[Scott F. <sc...@st...>]

You know, Michael, you asked about SVN's state as far as if it was release
ready or not. I can't run it in the background. I get the following:
May 17 22:20:03 localhost LCD4Linux[25367]:
mkstemp(/var/run/lcd4linux.pid.8qKs4S) failed: Permission denied
May 17 22:20:03 localhost LCD4Linux[25367]: lcd4linux already running as
process -1

It runs fine in the foreground.

On Sun, May 17, 2009 at 7:13 PM, Marcus Brown <mar...@in...
> wrote:

> Hi,
>
> Any chance of adding my layer patch prior to 0.11? (Ref: 20090402)
> Screens _and_ layers together might be interesting to play with ;)
>
> Marcus.
>
>
> On Fri, 2009-05-15 at 17:24 +0200, Michael Reinelt wrote:
> > Hi Scott,
> >
> > > Ok, sorry for sending this twice. I don't know if the first one went
> > > through or not. It's all garbled on the archive.
> >
> > Well, as far as I can see, your first mail did make it perfectly to the
> list.
> >
> > > I know I know, people are going "Not another one" but it ain't so. I
> > > got good news! I have a patch file here that enables layout
> > > transitions. Well, nothing fancy like, but the layouts do change.
> > Well, this is indeed good news!
> >
> > > Each layout has its own timeout, which defaults to 5000. Now I better
> > > warn people, I don't normally program C, so it's likely I missed some
> > > of the memory management. I think I covered everything, but don't hurt
> > > me too bad if something blows up or worse. Reinforce your LCD's
> > > mounting brackets.
> > >From a quick look over your patch, it looks fine, except a few things...
> >
> > > This also adds temperature and fan plugins for the Crystalfontz driver
> > > (most of the work was already there).
> > I'd like to add this as a seperate patch.
> >
> > I hope you did create the diff against current trunk of svn, otherwise
> applying will be a hard job...
> >
> > > And here's how to index your layouts. There should always be a Layout0.
> > This one I do not like. your patch would break every existing
> configuration out there.
> >
> > > One last thing. In order to get things so your screen is cleared
> > > entirely between transitions, you'll have to add a clear callback to
> > > your driver. I only added it to the Crystalfontz driver.
> > This is the second point I don't like: I often thought about a clear()
> call in the display driver, but in fact it should
> > be not necessary. If you clear the framebuffer, this should be
> sufficient. And it should speed up things a lot
> > (especially on graphic displays).
> >
> > anyway, I think we should apply your patch, BUT: I'd really like to
> release 0.11 before. Well, I planned to do the
> > release between cristmas and new year's day 2008 :-( Unfortunately I've
> been too busy
> >
> > But maybe this could be the right motivation to do the release.
> >
> > @all, especially michu: what do you think? Is the current svn code stable
> enough?
> >
> > If yes, I would apply the temp and fan extensions, and release 0.11, and
> afterwards apply your patch. but you should
> > really find a way so lcd4linux runs without a Layout0 (but with a single
> "Layout")
> >
> >
> > One last point: I have been thinking about a similar solution to this
> problem. Maybe you patch will be integrated into
> > this concept: I will call it "screens"
> >
> > The trick is that there will be several widgets (buttons, gpo's and
> stuff) that may be shared by more than one layout,
> > and other widgets (text, bars, timers, buttons) that will be different
> for each layout.
> >
> > the structure will be like the following:
> >
> > Layout 'Default' {
> >    screen 1 {
> >       row1.col1 'CPU'
> >       row2.col1 'Disk'
> >    }
> >    screen 2 {
> >       row1.col1 'LAN'
> >       row2.col1 'WAN'
> >    }
> >    GPO1 'Test_GPO'
> > }
> >
> > So there will be only one active layout, probably containing more than
> one screen, and there will be a plugin which
> > allows you to change screens (scroll or directly access one screen), and
> you can bind this call to a timer, a button, or
> > any other event.
> >
> >
> >
> > bye, Michael
> >
> >
>
>

Re: [Lcd4linux-devel] [lcd4linux] Layout transitions

[Marcus B. <mar...@in...>]

Hi,

Any chance of adding my layer patch prior to 0.11? (Ref: 20090402)
Screens _and_ layers together might be interesting to play with ;)

Marcus.


On Fri, 2009-05-15 at 17:24 +0200, Michael Reinelt wrote:
> Hi Scott,
> 
> > Ok, sorry for sending this twice. I don't know if the first one went
> > through or not. It's all garbled on the archive.
> 
> Well, as far as I can see, your first mail did make it perfectly to the list.
> 
> > I know I know, people are going "Not another one" but it ain't so. I
> > got good news! I have a patch file here that enables layout
> > transitions. Well, nothing fancy like, but the layouts do change.
> Well, this is indeed good news!
> 
> > Each layout has its own timeout, which defaults to 5000. Now I better
> > warn people, I don't normally program C, so it's likely I missed some
> > of the memory management. I think I covered everything, but don't hurt
> > me too bad if something blows up or worse. Reinforce your LCD's
> > mounting brackets.
> >From a quick look over your patch, it looks fine, except a few things...
> 
> > This also adds temperature and fan plugins for the Crystalfontz driver
> > (most of the work was already there).
> I'd like to add this as a seperate patch.
> 
> I hope you did create the diff against current trunk of svn, otherwise applying will be a hard job...
> 
> > And here's how to index your layouts. There should always be a Layout0.
> This one I do not like. your patch would break every existing configuration out there.
> 
> > One last thing. In order to get things so your screen is cleared
> > entirely between transitions, you'll have to add a clear callback to
> > your driver. I only added it to the Crystalfontz driver.
> This is the second point I don't like: I often thought about a clear() call in the display driver, but in fact it should
> be not necessary. If you clear the framebuffer, this should be sufficient. And it should speed up things a lot
> (especially on graphic displays).
> 
> anyway, I think we should apply your patch, BUT: I'd really like to release 0.11 before. Well, I planned to do the
> release between cristmas and new year's day 2008 :-( Unfortunately I've been too busy
> 
> But maybe this could be the right motivation to do the release.
> 
> @all, especially michu: what do you think? Is the current svn code stable enough?
> 
> If yes, I would apply the temp and fan extensions, and release 0.11, and afterwards apply your patch. but you should
> really find a way so lcd4linux runs without a Layout0 (but with a single "Layout")
> 
> 
> One last point: I have been thinking about a similar solution to this problem. Maybe you patch will be integrated into
> this concept: I will call it "screens"
> 
> The trick is that there will be several widgets (buttons, gpo's and stuff) that may be shared by more than one layout,
> and other widgets (text, bars, timers, buttons) that will be different for each layout.
> 
> the structure will be like the following:
> 
> Layout 'Default' {
>    screen 1 {
>       row1.col1 'CPU'
>       row2.col1 'Disk'
>    }
>    screen 2 {
>       row1.col1 'LAN'
>       row2.col1 'WAN'
>    }
>    GPO1 'Test_GPO'
> }
> 
> So there will be only one active layout, probably containing more than one screen, and there will be a plugin which
> allows you to change screens (scroll or directly access one screen), and you can bind this call to a timer, a button, or
> any other event.
> 
> 
> 
> bye, Michael
> 
> 

Re: [Lcd4linux-devel] [lcd4linux] Layout transitions

[Scott F. <sc...@st...>]

On Sun, May 17, 2009 at 2:24 AM, Scott Flynn <sc...@st...> wrote:
>> Ok, good point. I went the route you suggested by clearing the FB, and
>> it brought up another intrusive point about the patch. It defaulted
>> all layouts to a timeout. That causes the framebuffer to be cleared,
>> interrupting the timing, and causing a noticeable change in the
>> display. I defaulted the timeout to 0 (no timeout), but that can be
>> overridden in the Display section.
>>
>> Display CF635 {
>>    Icons 2
>>    Driver 'Crystalfontz'
>>    Model '635'
>>    Port '/dev/ttyUSB1'
>>    Speed 115200
>>    Contrast 120
>>    Backlight 100
>>    DefaultTimeout 5000
>> }
>>
>>>
>
> I found that not all drivers use a text framebuffer. I made that
> assumption and didn't check to see if the text framebuffer existed
> before trying to clear it. It caused a crash of course. Attached is
> the updated patch that checks like it should and it also clears any
> graphic displays. I pulled a fresh copy off the SVN repo for it.
>

Oops. Sorry, I shouldn't be programming C. Or at least I should be
reading more of your code (and more C documentation) before writing
anything. ;)

Make that:
void drv_generic_text_clear(void) {
    if(LayoutFB == NULL) { return; }
    memset(LayoutFB, ' ', LROWS * LCOLS * sizeof(*LayoutFB));
    drv_generic_text_blit(0, 0, LROWS, LCOLS);
}

Re: [Lcd4linux-devel] [lcd4linux] Layout transitions

[Scott F. <sc...@st...>]

> Ok, good point. I went the route you suggested by clearing the FB, and
> it brought up another intrusive point about the patch. It defaulted
> all layouts to a timeout. That causes the framebuffer to be cleared,
> interrupting the timing, and causing a noticeable change in the
> display. I defaulted the timeout to 0 (no timeout), but that can be
> overridden in the Display section.
>
> Display CF635 {
>    Icons 2
>    Driver 'Crystalfontz'
>    Model '635'
>    Port '/dev/ttyUSB1'
>    Speed 115200
>    Contrast 120
>    Backlight 100
>    DefaultTimeout 5000
> }
>
>>

I found that not all drivers use a text framebuffer. I made that
assumption and didn't check to see if the text framebuffer existed
before trying to clear it. It caused a crash of course. Attached is
the updated patch that checks like it should and it also clears any
graphic displays. I pulled a fresh copy off the SVN repo for it.

[Lcd4linux-devel] Histograms

[Scott F. <sc...@st...>]

I've always liked these, and would love if LCD4Linux had a histogram
widget. Basically it's a heartbeat monitor. The bars are nice, but
they only show the state right now. Histograms show the state over the
past however long. Here's an example of what I mean.

.....|*****|*****|*****|*****|*****|*****|*****|
.....|.....|*****|*****|*****|*****|*****|*****|
.....|.....|.....|*****|*****|*****|*****|*****|
.....|.....|.....|.....|*****|*****|*****|*****|
.....|.....|.....|.....|.....|*****|*****|*****|
.....|.....|.....|.....|.....|.....|*****|*****|
.....|.....|.....|.....|.....|.....|.....|*****|
.....|.....|.....|.....|.....|.....|.....|.....|


That may or may not show up right. Try looking at it in a terminal.
These are the 8 special chars used for the histogram. If you have more
special chars, you can complete the spectrum. For every row in a LCD's
characters, the better the histogram looks. Mine has 8 rows.

It basically ticks every so often and moves the history right or left,
appending the new value representation (the LCD's special char).

Re: [Lcd4linux-devel] Icons

[Scott F. <sc...@st...>]

Nah I reset the icon counter. The problem is I want to display a bunch
of icons in one layout, and some bars in another layout. You can't
have both with the icons being allocated at the device level. One
thing you could do is allow a layout to override this value. It's
unobtrusive that way.

On Fri, May 15, 2009 at 11:16 AM, Michael Reinelt <mi...@re...> wrote:
> Hi Scott,
>
>> What's the purpose of allocating space for icons at the driver level?
>> Having this moved to the layout level would allow much more freedom,
>> but that may undermine whatever reason icons were allocated to begin
>> with. I'm just thinking that allowing more freedom at the layout
>> level, the better quality the overall collection of layouts. It's a
>> harsh constraint when you're transitioning between layouts. All those
>> icons go to waste and you're blocked from doing anything about it, but
>> what's worse is you can starve any bars you may want to display. When
>> it comes down to laying this allocation at the layout level, it sort
>> of makes the allocation redundant and just another opcode. The layout
>> author should have enough responsiblity, tech, and math to keep from
>> flooding syslog. So I don't know what I'm suggesting. I'm just
>> suggesting something different than a hard coded allocation. The
>> dynamic allocation, or lack there of, is cheap and simple to
>> implement.
>
> There are several (historic) reasons for this kind of implementation:
>
> - only "text" display require a icon limitation (graphic displays are handling icons and bars in a very different way)
>
> - only text displays that allow the definition of own chars support Icons at all
>
> That's the reason why this has been implemented on a per-driver level
>
> Sort of a "dynamic allocation" is impossible, because the bar driver absolutely requires to know how many chars are
> available. If you dont believe me, take a look at the bar compaction code. This code is very...hrm... 'fragile' :-)
>
> on the other hand, it should be easy to re-use icons used in different layouts. maybe you forgot to free or reset the
> icon counter when closing a layout?
>
> Moving the Icon counter to the layout section should be possible, but I'm not sure if this is the right way to go (think
> of all the new graphic displays which don't care at all about this parameter)
>
>
> bye, Michael
>
> --
> Michael Reinelt <mi...@re...>
> http://home.pages.at/reinelt
> GPG-Key 0xDF13BA50
> ICQ #288386781
>

Re: [Lcd4linux-devel] Icons

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

Hi Scott,

> What's the purpose of allocating space for icons at the driver level?
> Having this moved to the layout level would allow much more freedom,
> but that may undermine whatever reason icons were allocated to begin
> with. I'm just thinking that allowing more freedom at the layout
> level, the better quality the overall collection of layouts. It's a
> harsh constraint when you're transitioning between layouts. All those
> icons go to waste and you're blocked from doing anything about it, but
> what's worse is you can starve any bars you may want to display. When
> it comes down to laying this allocation at the layout level, it sort
> of makes the allocation redundant and just another opcode. The layout
> author should have enough responsiblity, tech, and math to keep from
> flooding syslog. So I don't know what I'm suggesting. I'm just
> suggesting something different than a hard coded allocation. The
> dynamic allocation, or lack there of, is cheap and simple to
> implement.

There are several (historic) reasons for this kind of implementation:

- only "text" display require a icon limitation (graphic displays are handling icons and bars in a very different way)

- only text displays that allow the definition of own chars support Icons at all

That's the reason why this has been implemented on a per-driver level

Sort of a "dynamic allocation" is impossible, because the bar driver absolutely requires to know how many chars are
available. If you dont believe me, take a look at the bar compaction code. This code is very...hrm... 'fragile' :-)

on the other hand, it should be easy to re-use icons used in different layouts. maybe you forgot to free or reset the
icon counter when closing a layout?

Moving the Icon counter to the layout section should be possible, but I'm not sure if this is the right way to go (think
of all the new graphic displays which don't care at all about this parameter)


bye, Michael

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

Re: [Lcd4linux-devel] [lcd4linux] Layout transitions

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

Hi Scott,

> Ok, sorry for sending this twice. I don't know if the first one went
> through or not. It's all garbled on the archive.

Well, as far as I can see, your first mail did make it perfectly to the list.

> I know I know, people are going "Not another one" but it ain't so. I
> got good news! I have a patch file here that enables layout
> transitions. Well, nothing fancy like, but the layouts do change.
Well, this is indeed good news!

> Each layout has its own timeout, which defaults to 5000. Now I better
> warn people, I don't normally program C, so it's likely I missed some
> of the memory management. I think I covered everything, but don't hurt
> me too bad if something blows up or worse. Reinforce your LCD's
> mounting brackets.
>From a quick look over your patch, it looks fine, except a few things...

> This also adds temperature and fan plugins for the Crystalfontz driver
> (most of the work was already there).
I'd like to add this as a seperate patch.

I hope you did create the diff against current trunk of svn, otherwise applying will be a hard job...

> And here's how to index your layouts. There should always be a Layout0.
This one I do not like. your patch would break every existing configuration out there.

> One last thing. In order to get things so your screen is cleared
> entirely between transitions, you'll have to add a clear callback to
> your driver. I only added it to the Crystalfontz driver.
This is the second point I don't like: I often thought about a clear() call in the display driver, but in fact it should
be not necessary. If you clear the framebuffer, this should be sufficient. And it should speed up things a lot
(especially on graphic displays).

anyway, I think we should apply your patch, BUT: I'd really like to release 0.11 before. Well, I planned to do the
release between cristmas and new year's day 2008 :-( Unfortunately I've been too busy

But maybe this could be the right motivation to do the release.

@all, especially michu: what do you think? Is the current svn code stable enough?

If yes, I would apply the temp and fan extensions, and release 0.11, and afterwards apply your patch. but you should
really find a way so lcd4linux runs without a Layout0 (but with a single "Layout")


One last point: I have been thinking about a similar solution to this problem. Maybe you patch will be integrated into
this concept: I will call it "screens"

The trick is that there will be several widgets (buttons, gpo's and stuff) that may be shared by more than one layout,
and other widgets (text, bars, timers, buttons) that will be different for each layout.

the structure will be like the following:

Layout 'Default' {
   screen 1 {
      row1.col1 'CPU'
      row2.col1 'Disk'
   }
   screen 2 {
      row1.col1 'LAN'
      row2.col1 'WAN'
   }
   GPO1 'Test_GPO'
}

So there will be only one active layout, probably containing more than one screen, and there will be a plugin which
allows you to change screens (scroll or directly access one screen), and you can bind this call to a timer, a button, or
any other event.



bye, Michael


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

[Lcd4linux-devel] Icons

[Scott F. <sc...@st...>]

What's the purpose of allocating space for icons at the driver level?
Having this moved to the layout level would allow much more freedom,
but that may undermine whatever reason icons were allocated to begin
with. I'm just thinking that allowing more freedom at the layout
level, the better quality the overall collection of layouts. It's a
harsh constraint when you're transitioning between layouts. All those
icons go to waste and you're blocked from doing anything about it, but
what's worse is you can starve any bars you may want to display. When
it comes down to laying this allocation at the layout level, it sort
of makes the allocation redundant and just another opcode. The layout
author should have enough responsiblity, tech, and math to keep from
flooding syslog. So I don't know what I'm suggesting. I'm just
suggesting something different than a hard coded allocation. The
dynamic allocation, or lack there of, is cheap and simple to
implement.

[Lcd4linux-devel] New plugin for reading Qnap logs

[Ralf T. <tr...@ri...>]

Hi,

i programmed a new plugin for reading the Qnap logs (connections and
events).
The Patch bases on the actual trunk 1032.

I have already added the doku in the wiki.

Best regards
Ralf