Frank Gevaerts | 16 Feb 11:47 2015
Picon

"User selectable freq scaling governor"

Hi,

A setting for user selectable freq scaling governor (for ibasso players)
was added in 040306a. Can anyone explain why this is needed? It's a
setting that the vast majority of users will have no clue about, while
those who actually know what it means won't know what to set it to.

I would expect that for rockbox use, one of those possible governors
will consistently be the best one to use. I'd suggest figuring out which
one that is and then using it. For developer experiments, a debug menu
item is a good way to play with this, but a user-visible setting?
Really?

Frank

--

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Thomas Martitz | 15 Feb 23:45 2015

commit 9076b433

The below commit isn't necessary.

buflib buffers can be passed to yielding functions just fine. Problems 
only arise if the are concurrent allocations, for example if two threads 
allocate from the same context simultaneously or if the callee does it's 
own allocations. This can't happen in the pictureflow case, it has it's 
own context and a single thread allocating from it.

Therefore the problem isn't yield() itself, but possible concurrent 
buflib_alloc() calls that result from the thread switch. This is because 
compaction only ever happens on allocation (and not in a backgroud 
thread or so).

Best regards.

commit 9076b433d18b5db1a1987fe99ca7c70808f22b0e
Author: Thomas Jarosch <tomj <at> simonv.com>
Date:   Thu Jan 1 23:45:24 2015 +0100

     PictureFlow: Add move callback for buflib allocations

     If we don't provide a callback to buflib_alloc(),
     the buffer is always movable (to reduce fragmentation).

     Since we pass our buffer to functions that call yield(),
     this could lead to memory corruption on buflib compaction.

     Change-Id: Id1fad1822479d692551c55cb8bc87cea7b78f759

diff --git a/apps/plugins/pictureflow/pictureflow.c 
(Continue reading)

Mike Giacomelli | 8 Feb 00:21 2015
Picon

d81b362: iBasso DX50: Digital filter roll off setting.

This commit should not have been made without discussion because:

1)  We had previously rejected it
2)  We generally try to avoid giving users frivolous hardware settings.

Mike

Udo Schläpfer | 31 Jan 14:25 2015
Picon

buildserver/buildclient and iBasso DX50/DX90: Major code cleanup and reorganization.

Hello.

As stated here http://gerrit.rockbox.org/r/#/c/1043/ i will submit this 
patchset in a few days.

This will most likely break the current build for ibassodx50.

1.

If http://git.rockbox.org/?p=www.git;a=blob;f=buildserver/builds;hb=HEAD 
is the current configuration of the build server, than this
line

android19:0:ibassodx50:iBasso DX50:rockbox.apk:110450:../tools/configure 
--target=ibassodx50 --type=n && make apk

shoud probably be

android19:0:ibassodx50:iBasso DX50:rockbox.zip:110450:../tools/configure 
--target=ibassodx50 --type=n && make zip

as this is no longer a PLATFORM_ANDROID device (no JAVA parts).

Adding ibassodx90 would be nice.

2.

The Android specific configuration has changed: 
http://gerrit.rockbox.org/r/#/c/1043/18/tools/configure

(Continue reading)

Frank Gevaerts | 11 Jan 18:32 2015
Picon

recorder build

Hi,

The recorder build is still failing due to size limits, and it's
unlikely to get better soon. I'm proposing to remove it from the
automated build system.

It's close enough to the recorderv2 to avoid breakages slipping
through, and having that persistent red makes reds elsewhere less
noticeable.

Any objections?

Frank

--

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Thomas Orgis | 3 Jan 23:19 2015

Completed extended metronome plugin (gerrit #887)

Hi,

after a few prototypes I have pushed my (first) final version of an
extended metronome plugin to Gerrit:

	http://gerrit.rockbox.org/r/#/c/887/

Testing and eventually merging of that into rockbox proper would be
welcome. This replaces the existing metronome plugin now, as all the
functionality is there.

PS: Gerrit items 1100 to 1116 are junk caused by me not squashing
commits before pushing ... they can be ignored and I would abandon them
if I could remember where my OpenID thingy for Gerrit came from.

Robert Durkacz | 20 Dec 02:16 2014
Picon

build error (missing header files) on cygwin

Hello,

I am trying to build for sansa clip + on cygwin following the
instructions. I have a few missing header files as follows:
/home/robert/rockbox/apps/language.c:36:31: error:
max_language_size.h: No such file or directory
/home/robert/rockbox/firmware/common/version.c:22:23: error:
rbversion.h: No such file or directory
/home/robert/rockbox/apps/recorder/jpeg_idct_arm.S:25:31: error:
apps/core_asmdefs.h: No such file or directory
/home/robert/rockbox/apps/plugins/credits.c:27:71: error: credits.raw:
No such file or directory

How do I go about sorting this out please?

h | 11 Dec 21:11 2014
Picon

Ladies and gentlemen, we have sound on Android/ARM - Pono Player!

  I'm pleased to announce that Rockbox on my Pono Player
running a slightly customized Android 2.3.3 (GB), which has an OMAP3 
ARMv7 CPU,
successfully played its first track on the evening of December the 10.:
Sly Fox by KOAN Sound

I will add the Details to the wiki in the next few days.

Lukas

Andrey Ryabinin | 29 Nov 09:55 2014
Picon

Revert "Rewrite filesystem code (WIP)"

[Duplicating [3] in mailing list for wider audience and discussion.]

Commit 7d1a47cf ("Rewrite filesystem code (WIP)") introduced
regressions ([1],[2]) on several rk27xx targets, making them nearly unusable.

Due to size of this change it's nearly impossible to find the root
of the problem, so I'm suggesting to revert it for now.

I'll keep searching the source of problem. It definitely will take a
lot of time. But once I'll find it we could revert the revert back.

We don't have stable release for this targets, cause they are never
been officially stable. So dev builds is the only option for users and
I would like to not keep them broken yet another hell knows how many
month.

[1] http://forums.rockbox.org/index.php/topic,48658.0.html
[2] http://forums.rockbox.org/index.php/topic,48675.msg230556.html#msg230556
[3] http://gerrit.rockbox.org/r/#/c/1056/

--

-- 
Best regards,
Andrey Ryabinin

Mike Giacomelli | 23 Nov 03:36 2014
Picon

g#922 (new DSP effects)


Does anyone mind if I commit these?  Code looks good to me, but Mike S is the DSP engine expert.

Mike
Pierluigi Vicinanza | 1 Oct 01:16 2014
Picon

Rick Dangerous coming to Rockbox... a new (old) game for the best DAP firmware ever! :)

Hi all!

I'd like to introduce you xrick - a clone of the game Rick Dangerous, which has now been officially ported to Rockbox.
You can find more info about it on wikipedia:
http://en.wikipedia.org/wiki/Rick_Dangerous

and on the original xrick author's website:
http://www.bigorno.net/xrick/

This port is based on my own "fork" of xrick, which has undergone substantial changes to accommodate the needs of non-desktop environments, plus several bugfixes.

You can see a video of it running here:
http://www.youtube.com/watch?v=FKpxQzKP5ss

Sources and iPod/iRiver binaries can be downloaded from:
https://github.com/pierluigi-vicinanza/xrick/releases/tag/2.0.0-Rockbox



Please find below some notes/questions:

--------------------------------------------------------
= About code review/integration into main Rockbox tree =

How best to proceed from here? Should I open a new bug/feature in Flyspray? Should I just push a new commit to gerrit following the steps mentioned in "www.rockbox.org/wiki/UsingGit"?
What's the preferred way to integrate my code into git repo? I am no git expert, but I was thinking about doing a subtree merge into "${ROCKBOX_DIR}/apps/plugins/xrick" folder... or maybe a adding a submodule... What do you guys suggest?
Ideally I'd like to keep all commit history and allow any future fixes eventually done on my repo to be easily merged back into Rockbox.

---------------
= Legal stuff =

All hardcoded data (graphics, text, etc) has been removed from source files -data is now loaded from external resource files- to (hopefully) avoid any legal troubles in integrating xrick sources.
I've spoken to the original author of xrick and He's planning to tweak the README to reflect all this.
In the meanwhile, any feedback/suggestion to ease this integration is highly appreciated.

------------------
= Current status =

The port has been tested on iRiver H320 and iPod Video, on these targets it's fully working and complete.
I've added support for grayscale targets and been able to successfully compile and run the game on iRiver H120 Simulator.
All other targets are untested. It would be nice if someone could test and report which targets are capable to run current code.


Last but not least, a big thank you to all Rockbox developers for providing such an awesome firmware.

Pierluigi Vicinanza


Gmane