Re: License of glk driver

Lonnie Wall <[email protected]>
Newsgroups gmane.comp.sysutils.lcdproc
Message-ID <[email protected]>
The first issue I ran into had to do with fonts... the default font in
position 1 only has characters 32 - 126 (dec) and the code used to set the
font was setting the wrong font metric values ... i.e. adding a pixel to the
left instead of right etc... a lot of the functions would also send
characters not supported by the device.

When I first started working with it I just added in the correct device type
(0x27 for the USB model) to the switch in init() and fired up LCDd ... the
"hello" message displayed... and then the display filled with random
characters caused by the heartbeat and attempts to set the font.

I turned off the heartbeat and commented out the font code... which stopped
the flow of random characters... and then ran lcdproc client. Ended up with
a lot of garbled text on the screen with characters not clearing etc..

In general I found that the mix of pointer and array operations using non
memsize types would result in garbled text on the display in a 64-bit
environment. The use of int types when calculating where to put characters
into the buffer caused problems... casting them to diffptr_t fixed that
issue. I also rewrote flush() to access the buffers using array notation
with memsize types... which fixed issues with garbled text.

I also did a lot of testing WRT flow control and found that using IXON with
updated VSTART and VSTOP variables in termios would cause characters to be
dropped. In the glk19264 driver that I'm writing I opted to implement flow
control in the driver by checking values returned from the device instead of
relying on termios... in my small test app I was able to send thousands of
characters continuously without overflowing the buffer or losing any
characters. The glk19264 also has a larger buffer than what was specified in
the glk driver (128 vs 96).

glk_output was written to support up to two GPO values ... however the 19264
has six ... three LEDs with two GPO values for each.

The keyboard on the 19264 has seven keys ... the glk driver only supports
six and the values it looks for are very different than what is returned
from the 19264

vbar and hbar functions didn't use the associated commands in the 19264
device... the vbar calls used for the E ||||  F display in the lcdproc
client was filling the last five lines on the display <g>.

I had fixed some of these issues and commented some things out trying to
work with the original glk driver but could never get a clean run with the
lcdproc client ... came close but if I let it run for more than 10 minutes
the device would end up getting reset.

I'm sure the original driver works great in a 32-bit environment with the
models it supported. However, all of these differences and my research in
flow control is what prompted me to write a separate glk19264 driver.

I decided to follow all of the coding standards and guidelines so that I can
also publish this for others to use... the GLK19264 is one of the more
popular displays from MatrixOrbital (according to their website) and the
code they provide only works on Windows.

I'm using the GLK19264-7T-1U Technical Manual, Revision: 1.2, from
MatrixOrbital for specifications.

Thanks,
Lonnie


On Tue, Mar 1, 2011 at 1:50 AM, Markus Dolze <[email protected]> wrote:

> Hello,
>
> if you tell me that you have originally written that driver back in 2001
> and want it to be released under GPL I will happily add those few lines.
>
> Regards,
> Markus
>
>
> On 28.02.2011 17:48, Philip Pokorny wrote:
> > Sorry. Yes, I do still lurk on the list.
> >
> > If you need a patch to update the copyright I can work that up.  If it's
> > not 64-bit clean, I would also like to fix that.
> >
> > I still have a set of tools that go with that driver for generating
> > custom fonts and images and downloading them to the GLK which would be
> > handy for people to have.
> >
> > What were the differences that tripped you up?
> >
> > Phil P.
> >
> > --
> > Philip Pokorny, RHCE
> > Chief Hardware Architect
> > PENGUIN COMPUTING, Inc
> > www.penguincomputing.com <http://www.penguincomputing.com>
> >
> >>> On Feb 27, 2011 9:40 AM, "Markus Dolze"
> >>> <<mailto:[email protected]>[email protected]
> >>> <mailto:[email protected]>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> the glk driver does not have copyright and license information.
> >>>
> >>> Who wrote this driver originally? It was first checked in by Philip
> >>> Pokorny.
> >>>
> >>> Philip: Do you read this?
> >>>
> >>> Regards,
> >>> Markus
> _______________________________________________
> LCDproc mailing list
> [email protected]
> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>

_______________________________________________
LCDproc mailing list
[email protected]
http://lists.omnipotent.net/mailman/listinfo/lcdproc
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.