Menu
▾
▴
lcd4linux-devel
|
From: C. M. <cm...@fr...> - 2006-02-20 19:55:48
Attachments:
keypad_patch_20060220.tgz
|
Howdy y'all--
I tried to make the keypad support as extensible as
possible, but I've only got a Crystalfontz 635 at the
moment. It's built with 6 buttons, and they generate
different events for both press & release.
The attached patch adds a new keypad widget and a generic
keypad driver. The widget is unique because I believe it's
the only one that doesn't update with a timer, instead, it
uses, you guessed it, the key pad. :) The generic driver
is useful for mapping key scan codes from the hardware into
normal positions UP, DOWN, LEFT, RIGHT, etc. so that if you
swap hardware you won't need to re-write the configuration
file that much.
Here's what some of the configuration might look like:
Widget keyup {
class 'Keypad'
position 'up'
state 'pressed'
expression somevar = somevar-1
}
Widget keydown {
class 'Keypad'
position 'down'
state 'pressed'
expression somevar = somevar+1
}
Layout partial_example {
Keypad1 'keyup'
Keypad2 'keydown'
}
It would be great to get some feedback. Particularly if
this is unworkable for other displays with buttons.
Thanks,
--Chris
|
|
From: Michael R. <re...@eu...> - 2006-02-21 06:10:24
|
Hi Chri, > The attached patch adds a new keypad widget and a generic > keypad driver. The widget is unique because I believe it's > the only one that doesn't update with a timer, instead, it > uses, you guessed it, the key pad. :) The generic driver > is useful for mapping key scan codes from the hardware into > normal positions UP, DOWN, LEFT, RIGHT, etc. so that if you > swap hardware you won't need to re-write the configuration > file that much. Hey, that's great news! Finally LCD4Linux gets support for keys! I already committed your patch to CVS. I cannot test it at the moment, because I'd have to dig out a display with keys... I'm really surprised how neat you did integrate things... registering the widget in the generic driver init is the right thing, but it's not self-evident. Great Work! But there is one thing I don't like that much: your extension of the widget structure, especially the two new function pointers 'update' and 'find'. First, I'd say that a keypad widget never has a 'draw' function. So I'd suggest removing the update function and use w->draw instead. I'm not shure about the find call. I'd accept a generic 'widget_find()" function, but i'm unhappy with a widget specific find() callback, because it's very keypad-specific.... maybe we can find a cleaner way to implement this.... by,e Michael -- Michael Reinelt <re...@eu...> http://home.pages.at/reinelt GPG-Key 0xDF13BA50 ICQ #288386781 |
|
From: C. M. <cm...@fr...> - 2006-02-21 16:40:34
|
On Tue, Feb 21, 2006 at 07:10:13AM +0100, Michael Reinelt waxed: > But there is one thing I don't like that much: your extension of the > widget structure, especially the two new function pointers 'update' and > 'find'. > > First, I'd say that a keypad widget never has a 'draw' function. So I'd > suggest removing the update function and use w->draw instead. I've pulled the 'update' in favor of 'draw', as per your suggestion, and committed the changes to CVS. I think this is a good idea, but please let me know if the patch meets your expectations. > I'm not shure about the find call. I'd accept a generic 'widget_find()" > function, but i'm unhappy with a widget specific find() callback, > because it's very keypad-specific.... I agree, at the moment, find is very specific to keypads. > maybe we can find a cleaner way to implement this.... The problem I ran into is that the widgets were designed to be self-updating and standalone. Once they startup, there didn't seem to be a lot of ways to iterate over them and find a specific one. The timer kind of takes the widget away until quit is called on it. I looked at storing the index of the generic Widgets array in the keypad widget itself and searching that, but it was messy. I think another alternative would be coming up with some sort of new 'control'-like abstraction layer to sit alongside the 'widget' layer. That might be overkill, tho. --Chris |
|
From: Till H. <ti...@ha...> - 2006-02-21 21:51:39
|
Hi, On Tuesday 21 February 2006 07:10, Michael Reinelt wrote: > I already committed your patch to CVS. I cannot test it at the moment, > because I'd have to dig out a display with keys... You'll soon get one in the mail ... i have just added keypad support to the LCD2USB driver. But i have a very stupid question: What is this good for? Ok, i can increment and decrement values, but is there some useful real life example? Two more things i notices: - i accidentally put the "Keypad1 'keyup'" line in the display part inside my Row1 statement. This didn't work, but i didn't get a warning or error - why does the driver use two stages? first feed some device dependant data into the keypad driver and then have a callback that interprets this into some keypad specific values? Why don't we just return values the driver expects in the first place? - What is the purpose of the KEYPADSIZE value? (BTW: A coding style question: Why are these variables upper case? Maybe they were constants once, but upper case variables are quite confusing ...) Anyway: I love to see lcd4linux react on my buttons :-) Ciao, Till -- Dr.Ing. Till Harbaum <ti...@ha...> http://www.harbaum.org/till |
|
From: C. M. <cm...@fr...> - 2006-02-22 15:53:33
|
On Tue, Feb 21, 2006 at 10:51:29PM +0100, Till Harbaum waxed:
> H
>
> On Tuesday 21 February 2006 07:10, Michael Reinelt wrote:
> > I already committed your patch to CVS. I cannot test it at the moment,
> > because I'd have to dig out a display with keys...
> You'll soon get one in the mail ... i have just added keypad support to the
> LCD2USB driver.
>
> But i have a very stupid question: What is this good for? Ok, i can increment
> and decrement values, but is there some useful real life example?
I think it could provide for much more interactive displays
like changing layouts, offering confirmation dialogs, menus,
reboot, etc. Potentially helpful stuff for rackmount machines.
Right now I'm making use of it with the file plugin to
scroll thru dmesg output:
Widget dmesg1 {
class 'Text'
expression file::readline('/var/log/dmesg',currline)
width 20
update 250
}
Widget keydown {
class 'Keypad'
position 'down'
state 'pressed'
expression currline = currline+1
}
> Two more things i notices:
> - i accidentally put the "Keypad1 'keyup'" line in the display part inside my
> Row1 statement. This didn't work, but i didn't get a warning or error
I guess I didn't realize that, but it seems to work the same
with GPO lines, silently ignoring them as far as I can tell.
Maybe that should change, too ?
> - why does the driver use two stages? first feed some device dependant
> data into the keypad driver and then have a callback that interprets this
> into some keypad specific values? Why don't we just return values
> the driver expects in the first place?
By forcing you to write a separate translation function, the
code stays cleaner, at least that was one of my thoughts
behind the two-stage setup. Looking at it now, it's not
really necessary and perhaps is a bit confusing. Although
it feels like the driver should have some sort of callback...
> - What is the purpose of the KEYPADSIZE value? (BTW: A coding style
> question: Why are these variables upper case? Maybe they were constants
> once, but upper case variables are quite confusing ...)
I was looking at DCOLS, DROWS, etc., from the generic text
widget, trying to follow that convention. But KEYPADSIZE
itself is just left over cruft, and I'm taking it out now.
> Anyway: I love to see lcd4linux react on my buttons :-)
Super !
--Chris
|
|
From: Mark E. <mj...@po...> - 2006-02-24 08:13:04
|
On Wed, 2006-02-22 at 10:53 -0500, C. Maj wrote: > On Tue, Feb 21, 2006 at 10:51:29PM +0100, Till Harbaum waxed: > > But i have a very stupid question: What is this good for? Ok, i can increment > > and decrement values, but is there some useful real life example? > > I think it could provide for much more interactive displays > like changing layouts, offering confirmation dialogs, menus, > reboot, etc. Potentially helpful stuff for rackmount machines. There used to be a box (racked PC) called Cobolt. This had a small LCD display and 4 buttons. With these 4 buttons you could... Setup/provision the system - ie - provide its IP address and other network settings, reboot or switch off the machine, look at various settings - etc... For my purpose - I want to be able to locally manage some rack-mounted servers - look at various settings and be able to reboot or power down the box. I'm under the assumption that "Pushing Buttons" can be detected as events which can be used to trigger externally called programs on the server? -- . . ___. .__ Posix Systems - Sth Africa. e.164 VOIP ready /| /| / /__ mj...@po... - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 |
|
From: C. M. <cm...@fr...> - 2006-02-27 13:58:00
|
On Fri, Feb 24, 2006 at 10:12:38AM +0200, Mark Elkins waxed:
> For my purpose - I want to be able to locally manage some rack-mounted
> servers - look at various settings and be able to reboot or power down
> the box. I'm under the assumption that "Pushing Buttons" can be detected
> as events which can be used to trigger externally called programs on the
> server?
That's correct. Anything that fits in an 'expression' line
will be evaluated. That could very well be an external
program. I've updated the wiki to provide some more
examples of keypad usage:
http://ssl.bulix.org/projects/lcd4linux/wiki/widget_keypad
--Chris
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X