|
Rockbox mail archiveSubject: Re: Classic holdswitch pollingRe: 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 template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |