Re: License of glk driver

Hi,

Would you please stop highjacking this subject for technical discussion?
It surely deserves a subject on its own and will perhaps attract more
people if one can guess from the subject what you are talking about.

Thank you

Markus


On 01.03.2011 23:17, Lonnie Wall wrote:
> 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]
> <mailto:[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>
>     <http://www.penguincomputing.com>
>     >
>     >>> On Feb 27, 2011 9:40 AM, "Markus Dolze"
>     >>> <<mailto:[email protected]
>     <mailto:[email protected]>>[email protected]
>     <mailto:[email protected]>
>     >>> <mailto:[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] <mailto:[email protected]>
>     http://lists.omnipotent.net/mailman/listinfo/lcdproc
> 
>