Rockbox mail archiveSubject: 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
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