Gerrit is operational
2015-09-25 08:45:11 GMT
Dear rockboxers, here you go, Fuze+ with up/down sliding support! http://gerrit.rockbox.org/r/#/c/1199/ To be honest I wrote this patch to promote my scrollstrip patch (g#786) and give it - or rather it's extension - a larger tester base. The challenge of this code is: while the original patch works quite well with up/down movements, the Fuze+ also uses the centre as Select button (and other scrollstrip targets as well, like Philips HDD1630). So it's mandatory to implement long-button-presses, at least for the centre button, to not completely break rockbox' user interface philosophy. For this reasen this patch allows different strip-button-modes, accessible via: Settings > General Settings > System > Scrollstrip handling * "Doubleclick mode": a short tap directly followed by a tap-and-hold will send a long button press (like your laptop's touchpad). Disadvantage: you get a latency on single taps. * "Long press mode": just stay long enough on the same spot, and you'll get repeated button events. Disadvantage: you get a big delay for long button presses, and you get inadvertent button activity if you accidentally stay too long on the same place. * Both of the above can be set to only work on the centre button. * "Off": The usual behaviour; Sometimes the best setting. Try playing Doom with scrollstrip mode :) If you like to play with the timing constants: I was too lazy to make them configurable via menu, so look out for BUTTON_DOUBLECLICK_TIME and BUTTON_LONG_PRESS_TIME. You find them in firmware/target/arm/imx233/sansa-fuzeplus/button-target.h You may also like to play with the Settings > General Settings > System > Scrollstrip speed and afterscroll settings. I'd appreciate any comments (via mailing list, gerrit or via IRC - I read the logs), especialy to these questions: * I don't think we need all of the above settings. So which setting do you like best, and which can be discarded? * Any Opinions about the doubleclick/long-press timing setting? Should it be configurable? Have fun, Sebastian
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.
Optimising battery runtimeI'd like to save power by "disabling unneeded hardware components". How do I do this?
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.
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 !
- 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!
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 |RRaA............| 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 |....rrAa......2.| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 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, Boris