Unmount all filesystems before connecting USB. This ensures that all filehandles are closed, which avoids possible filesystem corruption
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28693 a1c6a512-1295-4272-9138-f99709370657
Remove the hardcoded (and way too small) scroll threshold (the distance moved in pixels before we think the users wants to scroll) and replace it with something based on the actual DPI of the screen.
On Android we call the API for that, on other touchscreens we reimplemented Android's formula (as of 2.2) and calculate it.
Flyspray: 11727
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28548 a1c6a512-1295-4272-9138-f99709370657
This fix implements audiohw_set_monitor for the wm8975 codec (used in ipod nano 1g, nano 2g, color, 4g)
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28341 a1c6a512-1295-4272-9138-f99709370657
The parameter wasn't used yet and it's not clear whether it should be a absolute or relative viewport.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28242 a1c6a512-1295-4272-9138-f99709370657
They work as the drawrect/fillrect pendants but work on a viewport basis; pass NULL to draw the current viewport (the one set with set_viewport()).
In conjunction with action_get_touchscreen_press_in_vp() it should be less of a pain to draw buttons and get presses on them.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28239 a1c6a512-1295-4272-9138-f99709370657
Looks much smoother now as you don't scroll by whole lines anymore.
Add some functions lcd driver to enable the line based scrolling engine to draw the lines with a pixel-based y-offset.
This should also allow for a sensible kinetic scrolling mechanism (still a todo).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28214 a1c6a512-1295-4272-9138-f99709370657
per seconds apparently don't very well.
Not sure if it's the hardware or our threading that doesn't play well enough
here (UI isn't less response despite of the audio drop outs).
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28144 a1c6a512-1295-4272-9138-f99709370657
* Until BUTTON_REPEAT was started, coordinate changes were not exposed. Change
that (post on every coordinate change) so that wiping over the screen does actually
something between the first touch and BUTTON_REPEAT
* Once BUTTON_REPEAT is active, further repeats are posted in an acceleration
fashion (slow at the begginning), which smoothes list scrolling. But this has
the contrary effect on touchscreen, as it makes swiping appear very laggy. So,
remove that acceleration for touchscreen and make it equally fast at all times
so the scrollbar is better usable.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28143 a1c6a512-1295-4272-9138-f99709370657
This doesn't change the value with the current HZ=100,
but makes it easy to change HZ in custome builds and still have buttons be usable
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@28086 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
