Sleep (After Backlight Off) option

Is Settings - General Settings - Display - LCD Settings - Sleep (After Backlight Off) option used by anyone?
It keeps touchscreen work after backlight is off. Why does it have default setting to 10s instead of Always?
It looks like a very annoying bug for users who don’t suppose there’s such an option.

Ishi Kahon via rockbox-dev | 21 May 00:12 2015

Why can't I power off my Sansa Clip Plus when charging?

My  Sansa Clip Plus doesn't power off when plugged to power source. I've held the power button on for a long time, but it just won't turn off.  Why not? And how can I power off my Sansa Clip+ when charging?
Ishi Kahon via rockbox-dev | 21 May 00:10 2015

How do I "disable hardware components" for power savings?

The Rockbox manual for my Sansa Clip Plus  has the following section:

Optimising battery runtime

Rockbox offers a lot of settings that have high impact on the battery runtime of your
player. The largest power savings can be achieved through disabling unneeded hardware
components ­ for some of those there are settings available. Another area of savings is
avoiding or reducing CPU boosting through disabling computing intense features (e.g.
sound processing) or using effective audio codecs. The following provides a short
overview of the most relevant settings and rules of thumb.

I'd like to save power by "disabling unneeded hardware components". How do I do this?
Ishi Kahon via rockbox-dev | 20 May 23:59 2015

Have different Playback settings based on folder

My audio consumption could be divided into two groups: spoken-word and music.

Is there a way to customize Rockbox so that when I'm listening to any file contained in the /spokenword/ folder, the playback buttons function differently than when I'm listening to a file contained in the /music/ folder? I know I could do this manually, but I'd rather Rockbox be able to automatically switch back and forth between 2 configurations.

Here are some of the differences I want:

For all files in music folder or all its subfolders
Device sleeps if no key-press in 30 minutes, with 30-minute time resetting after every keypress. This is to save on power in case I accidentally forget to shutdown/power-off.

For all files in spoken-word folder or any subfolder:

Playback speed set to 1.6X
Pressing Forward or Backward buttons do not skip to the next or previous track.
To skip to tracks, double-tapping Forward or Backward is needed. Or holding Home, and then tapping Backward or Forward button.
Pressing Backward goes back 10 seconds, while pressing Forward  advances 10 seconds.

I would like to get this on my Sansa Clip Plus (running Rockbox 3.13).
Lorenzo Miori | 10 May 16:49 2015

Re-purpose of forgotten gadgets: palm tungsten e2

Ladies and gents,

I'm proud to announce another new target, a vintage gadget from the 2005 palmOne tungsten e2, whose test bench has been setup in a couple of hours thanks to the union of a kernel and a solid audio software :)

I invite you to have a look here

The steps have been the following:

1) testing of existing stuff; bootloading a Linux kernel
2) compilation of the newest kernel (yes, 4.x, yes hardware support out of the box)
3) creation of a fresh toolchain plus a shiny little rootfs (buildroot)
4) quick & dirty hack of ypr0 target to make it runnable on this platform (the canonical logo show-off)

Everything but framebuffer isn't working; in the next days I will setup a new target and writing some drivers for it.

Specs: CPU Intel xscale pxa 255; 16mb ram; 200mhz. Sdcard storage (dunno what is the max size perhaps around 2 gigs? Maybe Linux does a better job). Audio out is kind of powerful but the quality made me wondering ... I'm quite sure the problem is not in the DAC/analog section but rather in the crappy r**l player palm os edition !

New possibilities:
- generic touchpad support (Linux)
- generic gpio keypad (Linux)
- ac97 audio (alsa should be fine; volume etc to implement)
- this time HW specific features at a minimum, since everything should be Linux API in theory. Study is needed.

Alongside in the series will be a crappybook based on a Wolfson SOC which also supports Linux well enough for Rockbox! The big screen opens up possibilities for video playback. USB are present etc!

Hybrid RaaA isn't that bad, is it? Perhaps we should invent another specific term as well....

Cheers & Have a nice day!


Boris Gjenero | 25 Apr 15:11 2015

File creation can take a long time

Occasionally I use text_editor to take notes on my 5G 30GB iPod. This 
has always worked well in the past with the stock MK3008GAL hard drive. 
(BTW I recommend opti2.kbd 
http://www.rockbox.org/wiki/LoadableKeyboardLayouts ) Recently I 
upgraded to a HS12YHA, which is 120GB with 4k sectors.

I was playing WMA. When I saved in text_editor, creating a new file, it 
seemed to hang. The wait was long enough that I reset the iPod, leaving 
a 0 length file. Then I tried again, also playing WMA and waiting longer 
and it worked. This made me think that Rockbox took a long time to look 
through the FAT because the drive was mostly full and free space was 
toward the end.

Specific conditions are needed to reproduce this. FAT32 has an fsinfo 
sector with a hint value telling where the first free cluster should be 
located. Rockbox makes use of this, allowing fast cluster allocation. 
After mounting the iPod in Windows, the free space hint was 0x1da2. Then 
I played that same WMA album, and reproduced the problem. The free space 
hint was now 0x321da2, showing that Rockbox must have scanned though 
many clusters in the FAT. Here is sudo dd if=/dev/sdb2 bs=512 count=1 
skip=1 | hexdump -C
00000000  52 52 61 41 00 00 00 00  00 00 00 00 00 00 00 00 
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
000001e0  00 00 00 00 72 72 41 61  0a a2 05 00 a2 1d 32 00 
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa 

This gave me the idea to cache the FAT in dircache. If the drive isn't 
terribly fragmented, the FAT information would take less space than the 
file names. Assuming you store start cluster and chain length for each 
contiguous chunk and 32 bit values are used, an unfragmented file would 
need 8 bytes. Free space could be stored as another file. Space that's 
marked bad or otherwise reserved would not need to be stored. With this, 
buffering would only have to read file data. I didn't try to implement 
this yet; I'm just wondering what others think about this idea.

When I tried to reproduce without playback being active, I could see 
file creation taking longer but it wasn't ridiculous. I guess this is 
because Rockbox will boost if necessary for proper playback without 
breaks, but other stuff might not get much CPU time. I've never had a 
problem with this before though.

I'm also wondering about why the free space hint was set to 0x1da2 in 
Windows and 0x321da2 in Rockbox. Does something have a bug causing it to 
write only 16 bits of the hint value, or do I have a crazy coincidence 
of free space locations?

Finally, I'd like to apologize for disappearing the way I did in the 
past. I got myself hung up on details worrying about what others would 
think of various possible solutions. It became unpleasant and killed my 
motivation to continue. This is my problem; I'm not blaming anyone else 
for causing this.

I have posted my TCC780 RCA RC3000A port at 
https://github.com/dreamlayers/rockbox/tree/rc3000a . I have no plans to 
work toward committing that, because nobody else seems interested in it, 
so I don't see how it would benefit Rockbox. In other words, I don't 
want to commit a port that only I am going to run.

Best regards,


Michael Gindonis | 10 Apr 09:27 2015

OpenID 2 end of life....


I was about to register to gerrit so I could add some of my patches to
rockbox and came across this note from google about the end of support
for OpenID 2.0 on the 20th of April.


Is there a plan in place for move to OAuth?


Michael Gindonis

Frank Gevaerts | 16 Feb 11:47 2015

"User selectable freq scaling governor"


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?



"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 
index 53fede1..afe108b 100644
--- a/apps/plugins/pictureflow/pictureflow.c
+++ b/apps/plugins/pictureflow/pictureflow.c
 <at>  <at>  -443,6 +443,18  <at>  <at>  static int track_list_visible_entries = 0;
  static int track_list_y;
  static int track_list_h;

+static int locked_buflib_handle;
+static int move_callback(int handle, void *current, void *new)
+    (void)current; (void)new;
+    if (handle == locked_buflib_handle)
+        return BUFLIB_CB_CANNOT_MOVE;
+    return BUFLIB_CB_OK;
+static struct buflib_callbacks pictureflow_ops = {
+    .move_callback = move_callback,
      Proposals for transitions:

 <at>  <at>  -1534,7 +1546,7  <at>  <at>  static int read_pfraw(char* filename, int prio)

      int hid;
      do {
-        hid = rb->buflib_alloc(&buf_ctx, size);
+        hid = rb->buflib_alloc_ex(&buf_ctx, size, "PictureFlow", 
      } while (hid < 0 && free_slide_prio(prio));

      if (hid < 0) {
 <at>  <at>  -1544,6 +1556,7  <at>  <at>  static int read_pfraw(char* filename, int prio)

      rb->yield(); /* allow audio to play when fast scrolling */
      struct dim *bm = rb->buflib_get_data(&buf_ctx, hid);
+    locked_buflib_handle = hid;

      bm->width = bmph.width;
      bm->height = bmph.height;
 <at>  <at>  -1555,6 +1568,7  <at>  <at>  static int read_pfraw(char* filename, int prio)
          rb->read( fh, data , sizeof( pix_t ) * bm->width );
          data += bm->width;
+    locked_buflib_handle = -1;
      rb->close( fh );
      return hid;
 <at>  <at>  -1709,6 +1723,7  <at>  <at>  static inline struct dim *get_slide(const int hid)
      struct dim *bmp;

      bmp = rb->buflib_get_data(&buf_ctx, hid);
+    locked_buflib_handle = hid;

      return bmp;
 <at>  <at>  -2100,6 +2115,9  <at>  <at>  static void render_all_slides(void)
      if (step != 0 && num_slides <= 2) /* fading out center slide */
          alpha = (step > 0) ? 256 - fade / 2 : 128 + fade / 2;
      render_slide(&center_slide, alpha);
+    /* free up lock on last used slide */
+    locked_buflib_handle = -1;

diff --git a/firmware/buflib.c b/firmware/buflib.c
index 9ee721a..a47f0a0 100644
--- a/firmware/buflib.c
+++ b/firmware/buflib.c
 <at>  <at>  -677,7 +677,7  <at>  <at>  buflib_free(struct buflib_context *ctx, int handle_num)
      /* Otherwise, set block to the newly-freed block, and mark it 
free, before
-     * continuing on, since the code below exects block to point to a free
+     * continuing on, since the code below expects block to point to a free
       * block which may have free space after it.
          block = freed_block;

Mike Giacomelli | 8 Feb 00:21 2015

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.


Udo Schläpfer | 31 Jan 14:25 2015

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


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.


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

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.


The Android specific configuration has changed: 

The configure script will now create a local (as in the build directory) 
copy of the Android NDK toolchain via Androids NDK 
make_standalone_toolchain.sh script.

I do now know how well (or no so well) this will work with the 

Is there a way to test this, before I submit?
Who can/will adapt the buildserver configuration?

TschÖ Udo.