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: Classic holdswitch polling

Re: Classic holdswitch polling

From: Cástor Muñoz <cmvidal_at_gmail.com>
Date: Sat, 10 Mar 2012 20:05:54 +0100

On Thu, Mar 8, 2012 at 10:01 PM, Michael Sparmann <theseven_at_gmx.net> wrote:

> The least invasive way to fix this bug would probably be to figure out
> if I2C is already in use when trying to read the hold switch in the tick
> task, and if it is just skip updating the hold switch status for that tick.

Really a nice hack, just one line of code to check if the mutex is locked.

Its great to see as many ideas for solving this issue, i am new to
Rockbox code so prefer to stay a bit away, will try to summarize:

1) Use an existing thread: this is a target specific patch, it should
not be placed into unrelated sections in order to maintain clean a big
multitarget project, discarded?

2) Async I2C: i will look at this code ASAP, seems it could be
implemented as a generic driver for all targets that HAVE_I2C_STACK?,
will it work for the holdswitch polling?

3) Create a specific thread for Classic: other targets are using this
method, to factorize code a generic target thread (?) could be added,
all targets defining HAVE_TARGET_THREAD can use it to register some
specific tasks, and continue using the tick IRQ handler for other
tasks.

4) Create a new button thread for all targets: should this option
include other input methods? (clickwheel, touchscreen, remotes...),
maybe some actions actually done on the target drivers should be moved
to a more generic input thread.
Received on 2012-03-10


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