Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: half-idea for #ifdef and key deifnition hell...

Re: half-idea for #ifdef and key deifnition hell...

From: Brandon Low <lostlogic_at_lostlogicx.com>
Date: 2006-03-23

I think that button processing can't be going through lists like that,
too slow.

Something that came up at devcon was the concept of more different
button code modifiers that the button driver can convert to:

BUTTON_NAME | BUTTON_SHORT
BUTTON_NAME | BUTTON_LONG
BUTTON_NAME | BUTTON_REPEAT
BUTTON_NAME

If either the button driver or the button_get function converted a
button release immediately following a button press on the same button
as a button_short and a button press following a repeat on the same
button as a button long now we have a structure that doesn't involve
looping but should give us the same flexibility in action -> button
mapping.

Brandon

On Thu, 03/23/06 at 14:26:51 +1100, Jonathan Gordon wrote:
> ok, well.. iv been playing with this idea anyway..
>
> hmm.. looks like i put it in the wrong plugin :p this 1 doesnt use
> _pre at all... anyway, here is the code iv got...
> **********************
> struct {
> int button_code;
> int ret_code;
> bool needs_pre;
> } ButtonItem;
> int read_button(struct ButtonItem *items, int button_count, int timeout)
> {
> static int last_button = BUTTON_NONE;
> int button = rb->button_get_w_tmo(timeout);
> int i;
> int ret;
> if (button == BUTTON_NONE || button == SYS_USB_CONNECTED)
> {
> last_button = button;
> return button;
> }
> ret = BUTTON_NONE; /* in case the button is not in the list */
> for (i=0;i<button_count;i++)
> {
> if (items[i].button_code == button)
> {
> if (items[i].needs_pre)
> {
> if ((items[i-1].button_code == last_button) ||
> (items[i-1].button_code == BUTTON_NONE))
> { ret = items[i].ret_code; break; }
> }
>
> else if (!items[i].needs_pre)
> { ret = items[i].ret_code; break; }
> }
> }
> last_button = button;
> return ret;
> }
> *****************************
> now if some targets use a _pre for a button and some dont, ud define
> the _pre to BUTTON_NONE on the targets its not used for, so it goes
> through the list and will return the correct code regardless on
> wheather or not _pre is used on a target (while still "sayuing" that
> the button needs a _pre on at least on target).
>
> wtahca think?
>
> On 23/03/06, Brandon Low <lostlogic@lostlogicx.com> wrote:
> > On Thu, 03/23/06 at 10:06:57 +1100, Jonathan Gordon wrote:
> > > On 23/03/06, Brandon Low <lostlogic@lostlogicx.com> wrote:
> > > > Great work! You just took some work off of Christi's plate toward
> > > > cleaning up button definition hell. This is basically very closely
> > > > along the lines of what we were talking about at devcon for button
> > > > functions, and by moving the pre logic up to a higher level, we can
> > > > reduce code size and improve clarity in the button switch loops.
> > > >
> > > > Some questions to ponder:
> > > >
> > > > What is our next step from here?
> > > im not entirely sure :p i was hopeing this msg would get more responses...
> > > im gonna implement the function today in 1 of my plugins that uses
> > > _pre on some targets and see how it goes..
> >
> > I assume that this function will not have to exist within the event
> > loop, so that it can be pulled back to a higher level to avoid code
> > duplication?
> >
> > And also what Daniel said about working on other things that are 3.0
> > material currently (playback.c here I come).
> >
> > > > Are there some button definitions which are optional or nonsensical on
> > > > some targets which should be made optional?
> > > > Where can we implement the _PRE logic so that it doesn't have to be
> > > > duplicated all over the place, and so that (on ipod) scroll touched
> > > > events don't interfere with it's proper operation?
> > > im only worried about the scroll wheel events.. i dont have an ipod so
> > > it might be hard to test it out... but we'll see
> >
> > Scroll events may initially be handled just like other button events,
> > I'm interested in creating (with Mikachu's help) an absolute positioning
> > system for ipod 5g targets, but that doesn't _necessarily_ have to fit
> > into the normal operation of buttons. Would be nice if it did though.
> >
> > Brandon
> > > >
> > > > Thanks much for looking into this,
> > > >
> > > > Brandon
> > > >
> >
Received on Thu Mar 23 14:21:38 2006


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa