* Forward Java KeyEvents to C layer and translate them to Rockbox BUTTON_*.
* Add a basic Android keymap
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27832 a1c6a512-1295-4272-9138-f99709370657
Stop explicitely if a call comes in, and resume playback (if it was playing before the call) upon hang up.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27746 a1c6a512-1295-4272-9138-f99709370657
this greatly reduces CPU load. lcd_update_rect shoves a bit as well.
CPU usage with Rockbox in background is between 3% (with a 200kbps vbr mp3) and 12% (320kbps cbr mp3), so it's low but still dependent on codecs and even particular files.
Driving a WPS with peakmeter, e.g. the builtin one, adds about 30% cpu usage.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27689 a1c6a512-1295-4272-9138-f99709370657
the activity only attaches to the framebuffer for displaying it. An icon
in the notification area is displayed (it could be prettier I guess).
Note: Some HTC phones won't, includng mine, get enough CPU time to do background decoding
fluently, see: http://code.google.com/p/android/issues/detail?id=9663
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27686 a1c6a512-1295-4272-9138-f99709370657
General state is: Rockbox is usable (plays music, saves configuration, touchscreen works too).
Problems:
- Playing music in the background (i.e. when switching to another app) doesn't work reliably, but I'm working on that now.
- no cabbiev2 (only some preliminary files for it), no other default theme.
- screen flickers sometimes if the updates are too frequent
- no multi screen apk/package
- strange behavior when a phone call comes in
The java files (and the eclipse project) resides in android/, which is also supposed to be the build folder.
I've put a small README in there for instructions. There are some steps needed after the make part, which are described there,
and which eclipse mostly handles. But there ought to be some script/makefile rules which do that instead in the future.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27668 a1c6a512-1295-4272-9138-f99709370657
BUTTON_LEFT is a rockbox define, we must use SDL_BUTTON_LEFT
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27367 a1c6a512-1295-4272-9138-f99709370657
- remove infinite loop after exit()
- make sure picture_surface is initialized, and free it
- split gui_message_loop() in 3 functions and change prototype
- some code is only used in simulator
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27366 a1c6a512-1295-4272-9138-f99709370657
It still works mostly like the simulator. There's also some minor left overs from the sim, but it does not define SIMULATOR.
It installs into the current (build) dir, and you need to run it with '--root .' (because it looks for ./.rockbox and not ./simdisk/rockbox) as options. That's one of the few kludges left that should be resolved soon'ish.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27310 a1c6a512-1295-4272-9138-f99709370657
keypad.
Copyright is restored for each keymap according to git blame.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26615 a1c6a512-1295-4272-9138-f99709370657
since it's now the default thread which is implicitely created by starting the sim.
This caused a segfault that r26283 tried to fix. Revert r26283 and protect
the main thread from being removed.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26315 a1c6a512-1295-4272-9138-f99709370657
SDL docs say SDL_PumpEvent (implicitely called by SDL_Poll/WaitEvent)
may only be called from the thread that initializes the video subsystem,
apparently because Windows requires that.
So create an (or bring it back) SDL thread (with preemtive behavior) to read the
event queue for buttons and initialize the video subsystem.
I'd probably would have done that anyway because it enables an interrupt-like method to read them (no polling).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26113 a1c6a512-1295-4272-9138-f99709370657
- Refactor the program startup. main() is now in main.c like on target, and the implicit application thread will now act as our main thread (previously a separate one was created for this in thread initialization).
This is part of Rockbox as an application and is the first step to make an application port from the uisimulator. In a further step the sim bits from the sdl build will be separated out.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26065 a1c6a512-1295-4272-9138-f99709370657