Rockbox architecture improvements

Possible improvements on the Rockbox architecture

The architecture of the current Main Thread as a monolithic application means that the Rockbox application code is not as flexible as it might be. There is no global method for handling application events and thus most keystokes, system events, etc. are context dependent / modal. This makes functionaly such as global keystrokes and an alarm function very difficult to implement.

I therefore offer up for discussion an idea related to the RockboxUserInterfaceProposal, namely converting the Main Thread into several separate application based threads, in particular

• WPS / playing thread (including track information screen)
• Browser / configuration thread (directory / ID3 browsing / changing Rockbox settings)
• Recording thread
• Radio thread
• Plugin thread

This then leaves open the question of how to control which thread has input focus.

---

Comments

The display & input focus is probably the easiest part.

• Give each UI thread its own lcd buffer instead of one global buffer, and let lcd_update* obey which thread has focus. Only those updates would be propagated to the display. One full lcd_update would be necessary on a focus change. This would be a bit harder to implement for the player lcd though. (Framebuffer updates themselves are expensive, especially on color targets, so having multiple threads updateing framebuffers seems inadvisable -- BrandonLow - 20 Jan 2006)
• Button events are also only received by the thread which has focus. Then there needs to be a global handler that handles the focus change.

The biggest question is how to handle the other shared resources. Some examples:

• Main buffer RAM: Both the WPS thread and the Recording thread would need the buffer, since we surely don't want to give only half the free RAM to each thread. In addition, the plugin thread may also use it. Then there needs to be a mechanism that decides which thread currently uses it. In addition, the handover is difficult, because each thread needs to do some house keeping before the other may use the buffer. E.g. the recording thread would need to stop recording, flush the buffer and close the file before freeing the buffer. Another way would be having a locking mechanism, i.e. not allowing the other thread(s) to use the buffer depending on state. This leaves open the question which thread has priority.
• (SH-based boxes) MAS: The MAS would also be needed both by the WPS and Recording thread, and only one of these may use it at a time. In addition, a handover requires reprogramming the mode the MAS is in.

Furthermore we have to keep an eye on binary size. Rockbox should still run on the SH-based archos devices, and there is a hard limit of 200 KB above which the firmware does no longer get loaded from disk.

JensArnold - 12 Feb 2005