[RFC] new 7-segments char translation API

[RFC] new 7-segments char translation API

[Henk]

[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]


Hi,

Please consider my proposal:

1 - A linux wide standard notation for seven segment displays.
2 - A standard method for accessing 7-segments character sets
    from user space, by introducing the "map_seg7" sysfs file.
3 - An ASCII based 7-segments character set for reuse by (potential)
    other LCD drivers.
4 - A location for header files, dedicated to conversions and "map's"
    and tables.
    
Background:

I am currently working on a LDC driver for an USB-Phone, unfortunately
each segment must be driven seperately. Therefore I had some need for a
translation map that could convert ASCII chars into a 7-segment
notation.

I know this 7-segments stuff probably won't be used widespread much but it
could be important to have similar projects use the same notation, and
use the same concepts.

This in oder to make user space programmers more happy. At least it
would be worth to keep a small include file, no need for abstaction
layers in the kernel.

1 - Notation

Make things potential interoperable, your character sets will be
portable to other LCD devices.

   +-a-+
   f   b
   +-g-+   => encodes to =>  MSb  76543210 LSb
   e   c                           gfedcba
   +-d-+                     bit7 is reserved.

2 - A standard method for accessing 7-segments character sets

   If a map should be accesible from userspace we should give it a
   standard sysfs file name: "map_seg7" is proposed.
   
   At least we know then where to look.
   
   If multiple maps are needed by a device (god forbid) they should be indexed
   like:

       map_seg7.0
       map_seg7.1
       map_seg7.2 ...
       
3 - An ASCII based 7-segments character set for reuse by (potential)
    other LCD drivers.

    Spare yourself the labour of defining this yourself...!
    

4 - A location for header files, dedicated to conversions and "map's"
    and tables.

    A programmer should know where to look in order to save his time,
    therfore the name should start with map_ and is possibly located
    in a seperate general include directory, proposed is:

    include/linux/map/map_to_7segment.h  

    for this particular instance. However it could be a good location
    also for:
     
       .../map_dram_timings.h
       .../map_mode_line_specs.h
       .../map_...
       

What do you think?


Regards,


Henk Vergonet


[-- Attachment #2: map_to_7segment.h.diff --]
[-- Type: text/plain, Size: 7570 bytes --]

--- map_to_7segment.h.orig	2005-05-31 22:42:17.000000000 +0200
+++ map_to_7segment.h	2005-05-31 22:57:16.000000000 +0200
@@ -0,0 +1,189 @@
+/*
+ * include/map/map_to_7segment.h
+ *
+ * Copyright (c) 2005 Henk Vergonet <Henk.Vergonet@gmail.com>
+ *
+ * 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 of
+ * the License, 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef MAP_TO_7SEGMENT_H
+#define MAP_TO_7SEGMENT_H
+
+/* This file provides translation primitives and tables for the conversion 
+ * of (ASCII) characters to a 7-segments notation.
+ *
+ * The 7 segment's notation below s used as standard, as it looks like it is
+ * the most commonly used.
+ *
+ * See: http://en.wikipedia.org/wiki/Seven_segment_display
+ *
+ * Notation:	+-a-+
+ *		f   b
+ *		+-g-+
+ *		e   c
+ *		+-d-+
+ *
+ * Usage:
+ *
+ *   Register a map variable, and fill it with a character set:
+ * 	static SEG7_DEFAULT_MAP(map_seg7);
+ *
+ *
+ *   Then use for conversion:
+ *	seg7 = map_to_seg7(&map_seg7, some_char);
+ *	...
+ * 
+ * In device drivers it is recommended to make the map accessible via the
+ * sysfs interface, please use the MAP_SEG7_SYSFS_FILE naming convention:
+ *
+ * static ssize_t show_map(struct device *dev, char *buf) {
+ *	memcpy(buf, &map_seg7, sizeof(map_seg7));
+ *	return sizeof(map_seg7);
+ * }
+ * static ssize_t store_map(struct device *dev, const char *buf, size_t cnt) {
+ *	memcpy(&map_seg7, buf, cnt > sizeof(map_seg7) ? sizeof(map_seg7) : cnt);
+ *	return cnt;
+ * }
+ * static DEVICE_ATTR(map_seg7, PERMS_RW, show_map, store_map);
+ *
+ * History:
+ * 2005-05-31	RFC linux-kernel@vger.kernel.org
+ */
+#include <linux/errno.h>
+
+
+#define BIT_SEG7_A		0
+#define BIT_SEG7_B		1
+#define BIT_SEG7_C		2
+#define BIT_SEG7_D		3
+#define BIT_SEG7_E		4
+#define BIT_SEG7_F		5
+#define BIT_SEG7_G		6
+#define BIT_SEG7_RESERVED	7
+
+struct seg7_conversion_map {
+	unsigned char	table[128];
+};
+
+static inline int map_to_seg7(struct seg7_conversion_map *map, int c)
+{
+	return c & 0x7f ? map->table[c] : -EINVAL;
+}
+
+#define SEG7_CONVERSION_MAP(_name, _map)	\
+	struct seg7_conversion_map _name = { .table = { _map } }
+
+/*
+ * It is recommended to use a facility that allows user space to redefine
+ * custom character sets for LCD devices. Please use a sysfs interface
+ * as described above.
+ */
+#define MAP_TO_SEG7_SYSFS_FILE	"map_seg7"
+
+/*******************************************************************************
+ * ASCII conversion table
+ ******************************************************************************/
+
+#define _SEG7(l,a,b,c,d,e,f,g)	\
+      (	a<<BIT_SEG7_A |	b<<BIT_SEG7_B |	c<<BIT_SEG7_C |	d<<BIT_SEG7_D |	\
+	e<<BIT_SEG7_E |	f<<BIT_SEG7_F |	g<<BIT_SEG7_G )
+
+#define _MAP_0_32_ASCII_SEG7_NON_PRINTABLE	\
+	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
+
+#define _MAP_33_47_ASCII_SEG7_SYMBOL		\
+ _SEG7('!',0,0,0,0,1,1,0), _SEG7('"',0,1,0,0,0,1,0), _SEG7('#',0,1,1,0,1,1,0),\
+ _SEG7('$',1,0,1,1,0,1,1), _SEG7('%',0,0,1,0,0,1,0), _SEG7('&',1,0,1,1,1,1,1),\
+ _SEG7('\'',0,0,0,0,0,1,0),_SEG7('(',1,0,0,1,1,1,0), _SEG7(')',1,1,1,1,0,0,0),\
+ _SEG7('*',0,1,1,0,1,1,1), _SEG7('+',0,1,1,0,0,0,1), _SEG7(',',0,0,0,0,1,0,0),\
+ _SEG7('-',0,0,0,0,0,0,1), _SEG7('.',0,0,0,0,1,0,0), _SEG7('/',0,1,0,0,1,0,1),
+
+#define _MAP_48_57_ASCII_SEG7_NUMERIC		\
+ _SEG7('0',1,1,1,1,1,1,0), _SEG7('1',0,1,1,0,0,0,0), _SEG7('2',1,1,0,1,1,0,1),\
+ _SEG7('3',1,1,1,1,0,0,1), _SEG7('4',0,1,1,0,0,1,1), _SEG7('5',1,0,1,1,0,1,1),\
+ _SEG7('6',1,0,1,1,1,1,1), _SEG7('7',1,1,1,0,0,0,0), _SEG7('8',1,1,1,1,1,1,1),\
+ _SEG7('9',1,1,1,1,0,1,1),
+
+#define _MAP_58_64_ASCII_SEG7_SYMBOL		\
+ _SEG7(':',0,0,0,1,0,0,1), _SEG7(';',0,0,0,1,0,0,1), _SEG7('<',1,0,0,0,0,1,1),\
+ _SEG7('=',0,0,0,1,0,0,1), _SEG7('>',1,1,0,0,0,0,1), _SEG7('?',1,1,1,0,0,1,0),\
+ _SEG7('@',1,1,0,1,1,1,1), 
+
+#define _MAP_65_90_ASCII_SEG7_ALPHA_UPPR	\
+ _SEG7('A',1,1,1,0,1,1,1), _SEG7('B',1,1,1,1,1,1,1), _SEG7('C',1,0,0,1,1,1,0),\
+ _SEG7('D',1,1,1,1,1,1,0), _SEG7('E',1,0,0,1,1,1,1), _SEG7('F',1,0,0,0,1,1,1),\
+ _SEG7('G',1,1,1,1,0,1,1), _SEG7('H',0,1,1,0,1,1,1), _SEG7('I',0,1,1,0,0,0,0),\
+ _SEG7('J',0,1,1,1,0,0,0), _SEG7('K',0,1,1,0,1,1,1), _SEG7('L',0,0,0,1,1,1,0),\
+ _SEG7('M',1,1,1,0,1,1,0), _SEG7('N',1,1,1,0,1,1,0), _SEG7('O',1,1,1,1,1,1,0),\
+ _SEG7('P',1,1,0,0,1,1,1), _SEG7('Q',1,1,1,1,1,1,0), _SEG7('R',1,1,1,0,1,1,1),\
+ _SEG7('S',1,0,1,1,0,1,1), _SEG7('T',0,0,0,1,1,1,1), _SEG7('U',0,1,1,1,1,1,0),\
+ _SEG7('V',0,1,1,1,1,1,0), _SEG7('W',0,1,1,1,1,1,1), _SEG7('X',0,1,1,0,1,1,1),\
+ _SEG7('Y',0,1,1,0,0,1,1), _SEG7('Z',1,1,0,1,1,0,1),
+
+#define _MAP_91_96_ASCII_SEG7_SYMBOL		\
+ _SEG7('[',1,0,0,1,1,1,0), _SEG7('\\',0,0,1,0,0,1,1),_SEG7(']',1,1,1,1,0,0,0),\
+ _SEG7('^',1,1,0,0,0,1,0), _SEG7('_',0,0,0,1,0,0,0), _SEG7('`',0,1,0,0,0,0,0),
+
+#define _MAP_97_122_ASCII_SEG7_ALPHA_LOWER	\
+ _SEG7('A',1,1,1,0,1,1,1), _SEG7('b',0,0,1,1,1,1,1), _SEG7('c',0,0,0,1,1,0,1),\
+ _SEG7('d',0,1,1,1,1,0,1), _SEG7('E',1,0,0,1,1,1,1), _SEG7('F',1,0,0,0,1,1,1),\
+ _SEG7('G',1,1,1,1,0,1,1), _SEG7('h',0,0,1,0,1,1,1), _SEG7('i',0,0,1,0,0,0,0),\
+ _SEG7('j',0,0,1,1,0,0,0), _SEG7('k',0,0,1,0,1,1,1), _SEG7('L',0,0,0,1,1,1,0),\
+ _SEG7('M',1,1,1,0,1,1,0), _SEG7('n',0,0,1,0,1,0,1), _SEG7('o',0,0,1,1,1,0,1),\
+ _SEG7('P',1,1,0,0,1,1,1), _SEG7('q',1,1,1,0,0,1,1), _SEG7('r',0,0,0,0,1,0,1),\
+ _SEG7('S',1,0,1,1,0,1,1), _SEG7('T',0,0,0,1,1,1,1), _SEG7('u',0,0,1,1,1,0,0),\
+ _SEG7('v',0,0,1,1,1,0,0), _SEG7('W',0,1,1,1,1,1,1), _SEG7('X',0,1,1,0,1,1,1),\
+ _SEG7('y',0,1,1,1,0,1,1), _SEG7('Z',1,1,0,1,1,0,1),
+
+#define _MAP_123_126_ASCII_SEG7_SYMBOL		\
+ _SEG7('{',1,0,0,1,1,1,0), _SEG7('|',0,0,0,0,1,1,0), _SEG7('}',1,1,1,1,0,0,0),\
+ _SEG7('~',1,0,0,0,0,0,0),
+
+/* Maps */
+
+/* This set tries to map as close as possible to the visible characteristics
+ * of the ASCII symbol, lowercase and uppercase letters may differ in
+ * presentation on the display.
+ */
+#define MAP_ASCII7SEG_ALPHANUM			\
+	_MAP_0_32_ASCII_SEG7_NON_PRINTABLE	\
+	_MAP_33_47_ASCII_SEG7_SYMBOL		\
+	_MAP_48_57_ASCII_SEG7_NUMERIC		\
+	_MAP_58_64_ASCII_SEG7_SYMBOL		\
+	_MAP_65_90_ASCII_SEG7_ALPHA_UPPR	\
+	_MAP_91_96_ASCII_SEG7_SYMBOL		\
+	_MAP_97_122_ASCII_SEG7_ALPHA_LOWER	\
+	_MAP_123_126_ASCII_SEG7_SYMBOL
+
+/* This set tries to map as close as possible to the symbolic characteristics
+ * of the ASCII character for maximum discrimination.
+ * For now this means all alpha chars are in lower case representations.
+ * (This for example facilitates the use of hex numbers with uppercase input.)
+ */
+#define MAP_ASCII7SEG_ALPHANUM_LC			\
+	_MAP_0_32_ASCII_SEG7_NON_PRINTABLE	\
+	_MAP_33_47_ASCII_SEG7_SYMBOL		\
+	_MAP_48_57_ASCII_SEG7_NUMERIC		\
+	_MAP_58_64_ASCII_SEG7_SYMBOL		\
+	_MAP_97_122_ASCII_SEG7_ALPHA_LOWER	\
+	_MAP_91_96_ASCII_SEG7_SYMBOL		\
+	_MAP_97_122_ASCII_SEG7_ALPHA_LOWER	\
+	_MAP_123_126_ASCII_SEG7_SYMBOL
+
+#define SEG7_DEFAULT_MAP(_name)		\
+	SEG7_CONVERSION_MAP(_name,MAP_ASCII7SEG_ALPHANUM)
+
+#endif	/* MAP_TO_7SEGMENT_H */
+

Re: [RFC] new 7-segments char translation API

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

On Wed, 2005-06-01 00:07:38 +0200, Henk <Henk.Vergonet@gmail.com> wrote:
> I know this 7-segments stuff probably won't be used widespread much but it
> could be important to have similar projects use the same notation, and
> use the same concepts.

I don't know if a real API is really needed for that. For example, I
played a bit with the (single) 7-segment display of one of my VAXen
running Linux. Other VAXen only have 8 LEDs in a row.  Using these LEDs
for debugging, I most probably just want to output *anything* to the
LEDs so I just use defined constants for that.

However, the principle could be reversed by using a 7-segment "font", a
mapping function and an initializer which specifies which bit belongs to
which bar of the 7-segment display... But maybe it's really worth
mplementing it as a library function...

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] new 7-segments char translation API

[Henk]

Jan Benedict wrote:

> I don't know if a real API is really needed for that.

No we don't. My term API was confusing, it's only a small include file
and some standardisation.

see the attached patch file

> However, the principle could be reversed by using a 7-segment "font", a
> mapping function and an initializer which specifies which bit belongs to
> which bar of the 7-segment display...

That's exactly what this is, see the attached patch file.

Regards,


Henk

PS please CC me as I am not on the list.

Re: [RFC] new 7-segments char translation API

[Clemens Koller]

Hello, Henk!

> 1 - Notation
> 
> Make things potential interoperable, your character sets will be
> portable to other LCD devices.
> 
>    +-a-+
>    f   b
>    +-g-+   => encodes to =>  MSb  76543210 LSb
>    e   c                           gfedcba
>    +-d-+                     bit7 is reserved.
           (x)

Bit7 is propably useful for the decimal point (x)?
Well, that's how I used it some time ago.

Greets,

Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

Re: [RFC] new 7-segments char translation API

[Henk]

On Wed, Jun 01, 2005 at 02:33:11PM +0200, Clemens Koller wrote:
> Hello, Henk!
> 
> >1 - Notation
> >
> >Make things potential interoperable, your character sets will be
> >portable to other LCD devices.
> >
> >   +-a-+
> >   f   b
> >   +-g-+   => encodes to =>  MSb  76543210 LSb
> >   e   c                           gfedcba
> >   +-d-+                     bit7 is reserved.
>           (x)
> 
> Bit7 is propably useful for the decimal point (x)?
> Well, that's how I used it some time ago.
>
Hi Clemens,

I think it could. However for conveniance I implemented it as a
seperate addressable entity.

For userspace I want things to be simple, just a simple echo should be
sufficient to manipulate the LCD:

For example:

   echo -n "3 A  1.0 0 0" > /sys/.../line1

in order to set the lcd. In order to read back the contents of the lcd:

  cat  /sys/.../line1
  8.8.8.8.8.8.8.8.888  <= format string, see below
  3 A   1.0 0 0        <= contents


When the dot is encoded in the digit you would lose a digit when a 
dot is printed. In a two segment display with dots "1.0" can not be 
printed.

I don't want kernelcode trying to decide if it should collapse "1." in
a single digit or not. These implicit functional rules are always a
pain in the ass when not implmented at the right level. And don't 
belong in the kernel.

Best regards,
Henk


/* Format string description:
 *
 * From a user space perspective the world is seperated in "digits" and "icons".
 * A digit can have a character set, an icon can either be ON or OFF.
 *
 * Format specifier
 *   '8' :  Generic 7 segment digits with individual addressable segments
 *
 *   Reduced capabillity 7 segm digits, when segments are hard wired together.
 *   '1' : 2 segments digit only able to produce 1.
 *   'e' : Most significant day of the month digit,
 *         able to produce at least 1 2 3.
 *   'M' : Most significant minute digit,
 *         able to produce at least 0 1 2 3 4 5.
 *
 *   Icons or pictograms:
 *   '.'  : For example like AM, PM, SU, a 'dot' .. or other single segment
 *          elements.
 */

Re: [RFC] new 7-segments char translation API

[Pavel Machek]

Hi!

> I know this 7-segments stuff probably won't be used widespread much but it
> could be important to have similar projects use the same notation, and
> use the same concepts.
....
> What do you think?

Keep 7-segment displays out of kernel. If it is usb, drive it from userspace with libusb...
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [RFC] new 7-segments char translation API

[Henk]

Pavel wrote:
> Keep 7-segment displays out of kernel. If it is usb, drive it from
> userspace with libusb...

I see that you did not provide any arguments.

I think you have not tried to look at it from a perspective
that is presented here. This makes me feel a little sad.

Henk

PS please cc or send mail directly as I am not on the list.

Re: [RFC] new 7-segments char translation API

[Edgar Toernig]

Henk wrote:
>
> Pavel wrote:
> > Keep 7-segment displays out of kernel. If it is usb, drive it from
> > userspace with libusb...
> 
> I see that you did not provide any arguments.

The kernel already provides a method to store arbitrary tables - the
filesystem.  By your reasoning /usr/dict/words had to be in the kernel,
too.

Ciao, ET.

Re: [RFC] new 7-segments char translation API

[Henk]

On Sun, Jun 05, 2005 at 12:53:29AM +0200, Edgar Toernig wrote:
> By your reasoning /usr/dict/words had to be in the kernel,
> too.

Well by my reasoning you should, if possible, define some usefull
standards that will allow te reuse of these dictionaries within other
applications.

And while we're on the subject of whats IN or OUT, (and I'll bet if you
ask 10 kernel developers you'll get 10 answers but I try anyway ;)

In my philosophy the OS (kernel + device drivers) is an abstraction of
the machine, it should present the 'machine' in such a way that allows
for other abstractions such as a word processor to operate without having
to know the specifics of hardware devices.

To have a guideline on the 7 segments notation and to have a few defines
that allow ASCII chars to be represented on 7 segments displays also help
to support the 'machine' abstraction.

Wheter or not /usr/dict/words should be 'in the kernel' is not being
discussed here, so I am not going to elaborate on that.

Cheers,

henk


PS I am not on the list, so please use CC if you're interested in a response.
PS Please excuse any spelling mistakes, I don't have a spelling checker
installed...

Re: [RFC] new 7-segments char translation API

[randy_dunlap]

On Mon, 6 Jun 2005 11:26:08 +0200 Henk wrote:

| On Sun, Jun 05, 2005 at 12:53:29AM +0200, Edgar Toernig wrote:
| > By your reasoning /usr/dict/words had to be in the kernel,
| > too.
| 
| Well by my reasoning you should, if possible, define some usefull
| standards that will allow te reuse of these dictionaries within other
| applications.
| 
| And while we're on the subject of whats IN or OUT, (and I'll bet if you
| ask 10 kernel developers you'll get 10 answers but I try anyway ;)
| 
| In my philosophy the OS (kernel + device drivers) is an abstraction of
| the machine, it should present the 'machine' in such a way that allows
| for other abstractions such as a word processor to operate without having
| to know the specifics of hardware devices.

The abstraction also includes libraries, and if lib7segment
could do this from userspace, that's where it should reside.
I'm not saying that it can, but if it can, then that's the
desired place for it.

| To have a guideline on the 7 segments notation and to have a few defines
| that allow ASCII chars to be represented on 7 segments displays also help
| to support the 'machine' abstraction.
| 
| Wheter or not /usr/dict/words should be 'in the kernel' is not being
| discussed here, so I am not going to elaborate on that.
| 
| Cheers,
| 
| henk
| 
| 
| PS I am not on the list, so please use CC if you're interested in a response.
| PS Please excuse any spelling mistakes, I don't have a spelling checker
| installed...


---
~Randy

Re: [RFC] new 7-segments char translation API

[Henk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1968 bytes --]

On Mon, Jun 06, 2005 at 09:19:42AM -0700, randy_dunlap wrote:
> On Mon, 6 Jun 2005 11:26:08 +0200 Henk wrote:
> 
> | On Sun, Jun 05, 2005 at 12:53:29AM +0200, Edgar Toernig wrote:
> | > By your reasoning /usr/dict/words had to be in the kernel,
> | > too.
> | 
> | Well by my reasoning you should, if possible, define some usefull
> | standards that will allow te reuse of these dictionaries within other
> | applications.
> | 
> | And while we're on the subject of whats IN or OUT, (and I'll bet if you
> | ask 10 kernel developers you'll get 10 answers but I try anyway ;)
> | 
> | In my philosophy the OS (kernel + device drivers) is an abstraction of
> | the machine, it should present the 'machine' in such a way that allows
> | for other abstractions such as a word processor to operate without having
> | to know the specifics of hardware devices.
> 
> The abstraction also includes libraries, and if lib7segment
> could do this from userspace, that's where it should reside.
> I'm not saying that it can, but if it can, then that's the
> desired place for it.
> 
Sorry for the late response,

The patch that was at the beginning of this thread is just a standard,
and just enough so a userspace program would never have to know anything
about 7 segments. And its just enough a device driver that needs to know
about this can implement it in a way that is portable and standardised.

I would, with all the love of the world create an userspace lib7segment for
you guys, but all I can think of is just this linux include file.


Well I think that the real issue here is that many of the kernel
developers feel that there´s to much fluff & features in the kernel
already.

>From an operational perspective I imagine its becomming harder and harder
to manage kernel code so I can understand people when they are
saying f**k off with 7-segments Ive got bigger fish to fry.

No offense taken, I just hope I didnt offend anyone either.

Ill be back,)

Henk Vergonet