Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Infrastructure → Build environment
  • Assigned To
    kugel.
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by kugel. - 2010-05-02
Last edited by kugel. - 2011-12-22

FS#11234 - Rockbox as an Application

This task should serve as a place for comments on my gsoc work. I also plan to upload patches here occasionally, although my work will always be available at http://repo.or.cz/w/kugel-rb.git.

See also: http://www.rockbox.org/wiki/RockboxAsAnApplication2010

Closed by  kugel.
2011-12-22 15:51
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

RaaA was a success!

This is my first patch that I would like in SVN.

Rework how standard C library handling is done.

  
  * Move standard C libraries into firmware/libc and their headers into firmware/libc/includes.
  * Don't compile these for the sim, and link the OS library instead, and fix up code that didn't work with that.
  * This means a lot of clean up with w.r.t. to includes, so update most files.
  * strlcpy/strlcat/strcasecmp/strcasecmp now in string-extra.h as they're not ANSI C.

The reason for this is that the application should use OS libraries to reduce memory usage and because the OS’ libraries are likely better tailored to a specific machine. They also receive improvements and fixes over time which usually doesn’t happen in our replacements.

[deleted patch as they’re committed and rather long]

I pushed some fixes to the above patch onto the git repo. The general idea doesn’t change however.

Another day, another patch. This makes open/creat posix compliant API-wise, without hitting the core as I managed to wrap the posix functions around the actual core functions (which don’t use the additional parameter of open/creat) I plan to commit tomorrow unless someone speaks up. Ultimatively this should make using the system’s file IO easier and less hacky.

(it’s separate commits for open and creat in my git repo).

[deleted patch as they’re committed and rather long]

Here, this is a patch to move uisimulator/sdl/*.[ch] into the target tree. I really only did mv uisimulator/sdl/*.[ch] firmware/target/hosted/sdl/, except for uisdl.c which has been split up across button-sdl.c and system-sdl.c.

An extra change is that the startup is more target like. The entry point is in main.c and then the init functions are called by the main thread (previously the entry point was in uisdl.c, which created an extra thread which would take over the actual main thread).

[deleted patch as it’s committed and rather long]

Add target/hosted/unix/thread-pth.c, which is a working thread implementation
using the Gnu Pth thread library. It has some advantages over SDL threads
because it’s cooperative by design and supports priorities.

It’s not the default yet, enable via tools/configure –with-pth

This is the #ifdef SIMULATOR → #if CONFIG_PLATFORM & PLATFORM_HOSTED patch. I confirmed that the fuzev2 sim & target build still work.

[deleted patch as it’s committed and rather long]

This adds a 320×240 app target to configure. After compiling, run it with “./rockbox –root .”

I couldn’t get it to compile, make errors out with this (haven’t investigated why):

make: *** No rule to make target `/home/mcuelenaere/rockbox_git/buildt/backlight-target.h’, needed by `/home/mcuelenaere/rockbox_git/buildt/firmware/backlight.o’. Stop.

hm, it seems it’s not included in the diff because it’s empty (I just did ‘touch firmware/target/hosted/sdl/app/backlight-target.h’). I did the same with adc-target.h

Should be fixed by headers added.

This patch adds get_user_file_path(), which (for RaaA) evaluates the correct paths to use at runtime; i.e. $HOME/.config/rockbox.org/<dir> if dir exists there. There are a few flags to modify its behavior.

On target, it’s an inline function which does almost nothing, so there shouldn’t be any change to them.

sko commented on 2010-08-05 21:04

Hi, I hope this is the right place for this: I created a statusbar icon which is inspired by the “Icon Design Guideline” (http://developer.android.com/guide/practices/ui_guidelines/icon_design.html#statusbarstructure). Imho the statusbar icon should not be a coloured one. (not the most important part of this project for now, I know ;) )

Oh, I missed that part. The icons look good, is the white line at the bottom of each intentional?

sko commented on 2010-08-06 07:57

There should not be a white line… I can’t see one, there is a grey line on the bottom which is a part of the “inner bevel” effect mentioned in the Icon Design Guideline. But I’ll edit the icon anyway as I noticed that the hdpi icon is a little to big (the so called “safe frame” is to small I think). I’ll have a look at the bevel effect, too.

I meant the gray one, looked pretty white to me tonight :)

Why are so little other apps doing color-less notification icons?

sko commented on 2010-08-06 13:25

- “Why are so little other apps doing color-less notification icons?”

Maybe they missed that part too ;). Or they don’t care about this guideline, you can see this at the launcher icons of many apps too.
I made a new version of the statusbar icon (used Inkscape to create an svg image this time).

Hm, I tried them (the mdpi one to be precise), and I’m not sure. The border makes it the icon look as if it would get wider (from top to bottom). It also appears not very sharp, dunno if that’s the gradient or the way you scaled. I also think the gradient is not strong enough, I find it to bright at the bottom.

I made a screen dump I hope you can see what I mean

   bar.png (6.4 KiB)
sko commented on 2010-08-06 14:13

Hmm… looks really weird… I took the different sizes from the guideline, so I’m wondering about this. I’ll have a look at this when I’m at home, there I have AVD’s for the different screen sizes.
Well the gradient’s color is also taken from the guideline and fits to the standard layout of the other status icons like th wlan- and 3g-indicator.
Your statusbar design is not the standard layout (looks like HTC Sense?)… well, maybe thats the point why many apps don’t care about the guideline: it looks good at devices with the standard layout (Droid, Nexus One…), but not on others (HTC, Motorola with Blur, some Samsung phones).

Yea, HTC sense. That might be the reason indeed.

sko commented on 2010-08-09 19:12

well… I could not figure out a statusbar icon which would look good at all the different layouts (Blur, Sense, the Samsung thing…), so maybe ignoring the guideline in this case is an option (when I came up with this idea I had only the standard layout on my mind, as used on my Motorola Milestone). So I tried something easier: here is a launcher icon inspired by the Icon Design Guideline (and using its color palette).

sko commented on 2010-08-10 06:38

Here is a second version with white border, which looks better imo.

sko commented on 2010-08-10 20:28

Here is a screenshot how it looks on android (mdpi target).

A patch to build Rockbox Android port in Cygwin environment.

A quick solution to resolve Stkov tagcache issue.

I think android.make doesn’t need to be duplicated. You could expose the build host to it and set the tools (and additional cmdlines) depending on it.

About the tagcache, I bet yours works but I’d rather see it fixed properly. Increasing the stack size could work but I think there are generally some more problems with scanning the fs on hosted platforms.

Yeah, The better fix for tagcache is probably giving it a directory to start scanning in (much like the file browser start directory setting). or better yet, use the hosts sqllite (which should be relativly easy on android)

Tagcache fix with “Start Database Update Here” and “Reset Database Root Directory” :) For Android, the default directory is “/sdcard” and “/” for the other.

Have found a bug in the key event code, for an example: there is no different between { ACTION_STD_CANCEL, BUTTON_DPAD_LEFT|BUTTON_REL, BUTTON_DPAD_LEFT } and { ACTION_STD_CANCEL, BUTTON_DPAD_LEFT, BUTTON_NONE } . I hope someone can fix this since I want to implement SEEKBACK and SEEKFWD in WPS.

How about Android RTC implementation since we can read Android localtime directly.

how do you want to implement repeat? I mean the dpap is a press/unpress staright away, (unlike real buttons), so do you want to do magic to see how quickly the user keeps flicking the ball left/right?

Also I see no reason that tagcache change isnt dont for all database targets. I imagine people would find it useful to not have part of their collection (i.e podcasts) in the db and this would be more obvious than the database.ignore.

I want to implement ACTION_WPS_SKIPNEXT, ACTION_WPS_SKIPPREV, ACTION_WPS_SEEKBACK, ACTION_WPS_SEEKFWD, and ACTION_WPS_STOPSEEK using BUTTON_DPAD_LEFT and BUTTON_DPAD_RIGHT. I want a key event occurs when the button “released” not when the button “pressed”. You can check in WPS screen: long press BUTTON_MENU not work as expected. Sorry, my English may be somewhat difficult to understand :(

For the tagcache patch, if it was not problematic at other targets I can just change it. Thank you.

the button events occur at both the press and release. the problem with android is that the dpad driver the press/unpress happens staright away so you cant do repeat events (which rules out seeking AND skipping, you can only do one or the other).
Your english is fine :) and yes, change the tagcache patch to be for all DATABASE targets and it can go in.

Updated tagcache patch, for all database targets.

This is a bit of a cleanup for the above patch, one of the changes is to make sdl app start at ~, but it isnt working yet

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing