|Age||Commit message (Collapse)||Author||Files||Lines|
np_file is a buffer of size MAX_PATH. After
removing only the file name component and
leaving the rest of the path, the
available space may not be sufficient
for appending another file name (possibly of
size MAX_PATH itself) to it.
This can occur after a file of acceptable
length is opened in ImageViewer, and you
then advance to another file whose path
(including the file name) is longer than
The progress callback doesn't rate limit LCD updates, which causes
excessive slowdowns (up to 150x!) on some targets. Limiting updates
to 20fps solves the problem and should boost load speed across the
board, particularly for large images and animated GIFs that may run
the progress callback thousands of times.
ensure 32bit alignment
Don't disable grayscale overlay, don't show "resize" messages
between frames and and don't clear display unless actually
lcd_update was called while the grayscale overlay was running
regression, apparently introduced by 0ceaff2
(only reproducible on target, not in Simulator)
- Audio playback works
- Touchscreen and buttons work
- Bootloader works and is capable of dual boot
- Plugins are working
- Cabbiev2 theme has been ported
- Stable for general usage
Thanks to Marc Aarts for porting Cabbiev2 and plugin bitmaps.
There's a few minor known issues:
- Bootloader must be installed manually using 'usbboot' as there is
no support in jztool yet.
- Keymaps may be lacking, need further testing and feedback.
- Some plugins may not be fully adapted to the screen size and could
benefit from further tweaking.
- LCD shows abnormal effects under some circumstances: for example,
after viewing a mostly black screen an afterimage appears briefly
when going back to a brightly-lit screen. Sudden power-off without
proper shutdown of the backlight causes a "dissolving" effect.
- CW2015 battery reporting driver is buggy, and disabled for now.
Battery reporting is currently voltage-based using the AXP192.
They were never finished, never saw any release ever, and haven't
compiled for the better part of a decade. Given their HW capabilities ,
they are not worth trying to fix.
 1-2MB RAM, ~256MB onboard flash, no expandability
Image viewer compiles decoders as a plugin and removes CRT0
A resuklt static vars do not get initialized in decoders
Mainly a straight replacement of FIIO_M3K -> FIIO_M3K_LINUX.
I'm currently running up against the limitations of the lcd_draw functions
I want these functions to be able to be used on any size buffer not
just buffers with a stride matching the underlying device
[DONE] allow the framebuffer to be decoupled from the device framebuffer
[DONE need examples] allow for some simple blit like transformations
[DONE] remove the device framebuffer from the plugin api
[DONE}ditto remote framebuffer
[DONE] remove _viewport_get_framebuffer you can call struct *vp = lcd_set_viewport(NULL) and vp->buffer->fb_ptr
while remote lcds may compile (and work in the sim) its not been tested on targets
[FIXED] backdrops need work to be screen agnostic
[FIXED] screen statusbar is not being combined into the main viewport correctly yet
[FIXED] screen elements are displayed incorrectly after switch to void*
[FIXED] core didn't restore proper viewport on splash etc.
[NEEDS TESTING] remote lcd garbled data
[FIXED] osd lib garbled screen on bmp_part
[FIXED] grey_set_vp needs to return old viewport like lcd_set_viewport
[FIXED] Viewport update now handles viewports with differing buffers/strides by copying to the main buffer
[FIXED] splash on top of WPS leaves old framebuffer data (doesn't redraw)
[UPDATE] refined this a bit more to have clear_viewport set the clean bit and have skin_render do its own screen clear
scrolling viewports no longer trigger wps refresh
also fixed a bug where guisyncyesno was displaying and then disappearing
[ADDED!] New LCD macros that allow you to create properly size frame buffers in you desired size without wasting bytes
(LCD_ and LCD_REMOTE_)
LCD_STRIDE(w, h) same as STRIDE_MAIN
LCD_FBSTRIDE(w, h) returns target specific stride for a buffer W x H
LCD_NBELEMS(w, h) returns the number of fb_data sized elemenst needed for a buffer W x H
LCD_NATIVE_STRIDE(s) conversion between rockbox native vertical and lcd native stride (2bitH)
test_viewports.c has an example of usage
[FIXED!!] 2bit targets don't respect non-native strides
[FIXED] Few define snags
The Q and K have a slightly different case, but the hardware under the
shell is completely identical.
These models are rebadged versions:
* Hifiwalker H2 (== Q)
* AGPTek H3 (== K)
* Surfans F20 (== K)
* Significant improvements in the shared Hiby-platform launcher/loader
* SD card can theoretically be hot-swapped now
* Support external USB mass storage!
* Some consolidation of Hiby-platform targets
* Some consolidation of plugin keymaps
* Keymaps need to be gone over properly
* Convert to HAVE_SCROLLWHEEL?
Most credit goes to: Roman Skylarov
Additional integration and refactoring by myself.
*** COMPLETELY UNTESTED ***
Remove mp3_is_playing() entirely, in favor of pcm_is_playing()
Remove mp3_play_pause() entirely, as it's a dummy/no-op call
Remoce some archos-specific comments
Fixes deficiencies with the button system on the X3
The x3 has an interesting button layout.
Multiple key presses are NOT supported unless
[BUTTON_POWER] is one of the combined keys
As you can imagine this causes problems as the power button takes
precedence in the button system and initiates a shutdown if the
key is held too long
instead of BUTTON_POWER use BUTTON_PWRALT in combination with other keys
IF using as a prerequsite button then BUTTON_POWER should be used
Multiple buttons are emulated by button_read_device but there are a few
caveats to be aware of:
Button Order Matters!
different keys have different priorities, higher priority keys 'overide'
the lower priority keys
VOLUP VOLDN PREV NEXT PLAY OPTION HOME
There will be no true release or repeat events, the user can let off the
button pressed initially and it will still continue to appear to be
pressed as long as the second key is held
Tree scrolling is PLAY+NEXT or PLAY+PREV
This removes all code specific to SH targets
(caught by clang-analyzer)
(A lot of work was done on this thing, for a target that hasn't been compileable
at least since we moved to git..)
Provided by Roman Stolyarov
Integration, Refactoring, and Upstreaming by Solomon Peachy
X3II confirmed working by forum tester, X20 is nearly identical.
This includes bootloader, main firmware, and the flash image patcher.
* Further refactor AGPTek Rocker & xduoo hiby bootloaders
* Further refactor AGPTek Rocker & xduoo hosted platform code
Patch by Igor Poretsky
Taken from the xvortex fork (Roman Stolyarov)
Ported, rebased, and cleaned up by myself.
Cleaned up, rebased, and forward-ported from the xvortex fork.
(original credit to email@example.com)
Signed-off-by: Solomon Peachy <firstname.lastname@example.org>
Patch provided by Aapo Tahkola.
Keymaps aren't tested, there may be room for improvement.
This changes JPEG fill and invalid byte handling to be like
mozjpeg, and bases entropy data start on SOS marker location.
Thanks to Stefan Waldmann and Dean Tersigni for reporting.
seems more logical to me, and is more consistent, since
"SAMSUNG_YH92X_PAD" is already used in the tex files.
The main "innovation" in this patch are two "virtual buttons"
for the record switch on YH92x targets. When the switch state
changes, a single BUTTON_REC_SW_ON or .._OFF button event will
be generated. Thus keymap code can react on switching, but
not on the actual state of the switch.
Wherever sensible, the following user scheme is applied:
- use PLAY as confirm button
- use REW button or Long REW to exit
- use REC (YH820) or FFWD (YH92X) as modifier key for button combos
The port to for this two targets has been entirely developped by Ilia Sergachev (alias Il or xzcc). His source
can be found at https://bitbucket.org/isergachev/rockbox . The few necesary modifications for the DX90 port
was done by headwhacker form head-fi.org. Unfortunately i could not try out the final state of the DX90 port.
The port is hosted on android (without java) as standalone app. The official Firmware is required to run this port.
Ilia did modify the source files for the "android" target in the rockbox source to make the DX port work. The work I did
was to separate the code for DX50 (&DX90) from the android target.
On this Target Ilia used source from tinyalsa from AOSP. I did not touch that part of the code because I do not understand it.
What else I changed from Ilias sources besides the separation from the target "android":
* removed a dirty hack to keep backlight off
* changed value battery meter to voltage battery meter
* made all plugins compile (named target as "standalone") and added keymaps
* i added the graphics for the manual but did not do anything else for the manual yet
* minor optimizations
* timers are slowed donw when playback is active (tinyalsa related?)
* some minor bugs
Things to do:
* The main prolem will be how to install the app correctly. A guy called DOC2008 added a CWM (by androtab.info) to the
official firmware and Ilia made a CWM installation script and a dualboot selector (rbutils/ibassoboot, build with
ndk-build). We will have to find a way to install rockbox in a proper way without breaking any copyrights.
Maybe ADB is an option but it is not enable with OF by default. Patching the OF is probably the way to go.
* All the wiki and manual
needed: android ndk installed, android sdk installed with additional build-tools 19.1.0 installed
select iBasso DX50 or iBasso DX90
make -j apk
the content of rockbox.zip/.rockbox needs to be copied to /system/rockbox/app_rockbox/rockbox/ (rockbox app not needed)
the content of libs/armeabi to /system/rockbox/lib/ (rockbox app needed)
The boot selector is needed as /system/bin/MangoPlayer and the iBasso app as /system/bin/MangoPlayer_original. There
is also the "vold" file. The one from OF does not work with DX50 rockbox (DX90 works!?), the one from Ilia is necessary.
Until we have found a proper way to install it, it can only be installed following the instructions of Ilia on his
bitbucket page, using the CWM-OF and his installation script package.
Tested: Chiwen Chang <email@example.com>
Reviewed-by: Michael Giacomelli <firstname.lastname@example.org>
Plugins on the ZEN/ZEN X-Fi require to increase the plugin buffer size.
Reviewed-by: Amaury Pouly <email@example.com>
With LCD driver all calculation will be performed on RGB888 and the hardware/OS
can display from our 24bit framebuffer.
It is not yet as performance optimized as the existing drivers but should be
good enough.The vast number of small changes is due to the fact that
fb_data can be a struct type now, while most of the code expected a scalar type.
lcd-as-memframe ASM code does not work with 24bit currently so the with 24bit
it enforces the generic C code.
All plugins are ported over. Except for rockpaint. It uses so much memory that
it wouldnt fit into the 512k plugin buffer anymore (patches welcome).
Although both players basically have the same keys, the
differences in the layout is rather big, so I think both
deserve their own keymaps.
(On the yh820 the FFWD/PLAY/REW buttons are located above the
direction keys, on the yh920 at the side of the player.
Furthermore the yh920/925 has a REC switch, whereas
yh820 has a push button.)
Reviewed-by: Szymon Dziok <firstname.lastname@example.org>
This patch completes the plugin keymaps for the Zen X-Fi3 and enables those plugins for compilation.
One key was changed in "button-target.h" for compatibility with Rockboy.
This also caused the changes to "keymap-zenxfi3.c", to keep the stock functionality (no further changes in here).
Reviewed-by: Amaury Pouly <email@example.com>
If disposal method is set to BACKGROUND one would expect that
canvas should be restored to global background color. That is
what gif standard suggests. Most (all?) decoders however treat
this as reseting canvas to transparency or fixed, decoder
specific background color. Virtually all gifs are prepared with
this in mind so to not break them we can't follow standard here.
Reviewed-by: Thomas Martitz <firstname.lastname@example.org>
Reviewed-by: Marcin Bukat <email@example.com>
1) update/complete keymaps (now handle slideshow)
2) update/complete manual
Reviewed-by: Amaury Pouly <firstname.lastname@example.org>
This adds ability to view gif images in rockbox.
Works both on color and gray/monochrome targets (greylib).
Aspect correction is supported as well.
- animated gifs are restricted to 32 frames
- animated gifs loop always (loopcount is ignored)
- plain text extension is not supported
- animated gifs with interframe delay = 0 are treated as still
images (web browsers usually treat delay 0 as 100ms to prevent
exhaustive CPU load by such images)
handles DEBUG builds on hosted targets to keep debug symbols if necessary.