RE: [Lcd4linux-devel] Re: I2C Keyboard implementation

[Luis.F.Correia <Lui...@se...>]

Hi!

(thanks for your quick reply) 

> -----Original Message-----
> From: Michael Reinelt [mailto:re...@eu...] 
> Sent: Wednesday, June 08, 2005 2:42 PM
> To: lcd4linux-devel
> Subject: [Lcd4linux-devel] Re: I2C Keyboard implementation
> 
> Hi Luis, Paul,
> 
> I'm moviing this to the devel list...
> 
> > as you know, me and Paul are designing an advanced I2C 
> display with a lot of
> > added features such as keyboard buttons.
> Sounds interesting!
> 
> > Before we start with the actual hardware design, we would 
> like to know how
> > are you planning to read the keys, as we will have to do 
> some jogging to
> > read them from our HW implementation, as a lot of stuff is using the
> > available I2C bits.
> 
> I must admit that I'm not yet sure how this will be implemented.

well, you should know by now...

> > The best thing to do is to prepare a hook function that we 
> will handle, and
> > that would take care of reading the keys between the writes 
> to the LCD.
> 
> No, there will be no hook. For several reasons. And 'polling'
> before/between/after display writes is a *bad* idea: Due to the
> double-buffering in lcd4linux, there may be no display writes 
> for a long
> period of time (when nothing changes on the display). If you want to
> read keys, you have to use a separate thread.

Ok, but we need to 'spinlock' around key polling because writing to
the LCD and reading the buttons uses the same 8 bit bus...

> Have a look into the Crystalfontz driver (or was it MatroxOrbital?)
> These displays have keypads, which send keycodes asynchronously. These
> packets are processed by a separate thread, but just logged and not
> really used (yet).
> 
> Another source would be the HD44780 driver, especially for the LCM162:
> It uses a seperate thread for key polling, too. Have a look at the
> drv_HD_LCM162_timer() function.

Ok, will do that once we have the overall design ready.

> I think there will be some sort of a 'event' system. you can 
> trigger an
> event (or call it a signal if you like) anywhere in 
> lcd4linux, and there
> will be 'handlers' which get the event. If there's no handler for a
> event, it will (more or less) silently be dropped.
> 
> Possible event sources are: keypads, timers, ...
> 
> A handler will be a Evaluator expression.

Ok, something like a plugin then?
We will need to have the output to the LCD and the input from the keys
in the same driver because of that 'spinlock' issue.



> > The only possible problem that I'm seeing is the lack of proper
> > key-debouncing, but that would preferrably done in your 
> side on the code :)
> Oh no, debouncing is your job.

I was afraid of that... unfortunately i have NO idea how to do it
properly...

> 
> 
> bye, Michael
> 
Luis Correia