The backlight driver always writes a bogus value
from memory into the LCD brightness register.
Fix it up by adding bounds checks and
use a more sane default value.
While looking at the code, I noticed
that BACKLIGHT_CONTROL_SET probably ignores
the desired brightness level, too.
Note: Please test on real hardware, I don't own it.
cppcheck reported:
[rockbox/firmware/target/arm/s3c2440/mini2440/backlight-mini2440.c:53]: (error) Array 'log_brightness[13]' accessed at index 255, which is out of bounds.
Change-Id: Iaafa929a8adaa97b93ebcb66e1f6bd3bf0dad84e
While the right GPIO location is accessed,
the result of the logical AND was tested wrong.
I don't have this hardware, but I can imagine
that bug caused ide_power_enable() to be called
more times than it needed to be.
cppcheck reported:
[rockbox/firmware/target/arm/pbell/vibe500/power-vibe500.c:101]: (style) Expression '(X & 0x8) == 0x1' is always false.
Change-Id: I98498f79d383c6f29869e170bfc94ba9a0d2ba7e
No need to go out of memory, too ;)
cppcheck reported:
[rockbox/firmware/logf.c:338]: (error) va_list 'ap' was opened but not closed by va_end().
Change-Id: I00e4c04d7e3d5d1415aa5066487ce1d9209e53aa
We should be safe since STM_Load() should
never be called if STM_Test() fails.
Still it's better safe than sorry.
cppcheck reported:
[rockbox/apps/plugins/mikmod/load_stm.c:302]: (error) Array 'STM_Version[3]' accessed at index 3, which is out of bounds.
Change-Id: I914935fd108c492d013de24d17dcb9c227af6cd8
This should only be a problem if the last line
is not terminated by \r or \n though.
cppcheck reported:
[rockbox/apps/playlist.c:234]: (style) Array index 'i' is used before limits check.
Change-Id: I8182b66272ba9c024984c81588bd2a6dbb8255b8
Test code:
--------------
int main(void)
{
static unsigned short extra_spaces[] = { 0, 0x3000 };
return sizeof(extra_spaces);
}
--------------
-> returns four instead of two.
cppcheck reported:
[rockbox/apps/plugins/text_viewer/tv_text_processor.c:180]: (error) Array 'break_chars[27]' acces
sed at index 53, which is out of bounds.
[rockbox/apps/plugins/text_viewer/tv_text_processor.c:195]: (error) Array 'extra_spaces[2]' acces
sed at index 3, which is out of bounds.
Change-Id: I66c305cc5c99e59e7c8e0aa9c86cecbe293ff037
The logic was messed up and always evaluated to true
if buflib_handle is non-zero.
Thanks to JdGordon for verifying the change.
cppcheck reported:
[rockbox/apps/gui/skin_engine/skin_backdrops.c:262]: (warning) Comparison of a boolean expression with an integer other than 0 or 1.
Change-Id: Ib52a73e0a6a2017a631e2dec19b638a2974dab83
The refactoring of the audio thread in this commit
-----------------------------------------------
commit 5857c44017
Author: Michael Sevakis <jethead71@rockbox.org>
Date: Fri May 31 02:41:02 2013 -0400
Refactor audio thread to run both recording and playback.
-----------------------------------------------
moved pcm_init() next to dsp_init() in apps/main.c:init().
Before that pcm_init() was called by audio_init().
Unfortunately the maemo init code didn't properly
wait until the maemo thread was fully initialized,
leading to dangling pointers when the code called
by pcm_init() tried to access maemo's variables.
Fix it by refactoring the "very fast shutdown" semaphore
to wait until maemo is initialized in any case.
This should also fix very rare rockbox crashes
on startup that I got once a year or so.
The new code has been tested by a script that
starts and kills rockbox after one second.
Change-Id: I464efce5f2b71ca869c72a5bc578555b8022e459
Turns out maemo's old gcc 4.2.1 doesn't include any arch
optimized swapXX() functions, just plain C implementations.
Before we pull in lots of linux kernel headers for the
C implementation, just stick to rockbox's own version.
Change-Id: Ic28b41b52fe47f814c7f3897ce15334a42b6c5e2
This one is much more efficient than using a generic table widget.
Change-Id: I3578964eead746e656f6b0a8dcec0f8442deb13d
Reviewed-on: http://gerrit.rockbox.org/1022
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
With the previous code, tab names would be ignored if tab is detached
which can happen early on.
Change-Id: I9eac4202850f3e79a04590a4ba1444850ec6a583
Reviewed-on: http://gerrit.rockbox.org/986
Reviewed-by: Amaury Pouly <amaury.pouly@gmail.com>
Optimizes YUV to RGB conversion using ARMv5 multiply-accumulate
intructions for operations and data tables for saturation.
This first patch set includes the three versions i have developed.
Although iPod Classic need to use the latest version to reach 30fps,
old versions may serve other targets.
All versions are based on current SVN algorithm (round->scale->add)
using the same coefficients, so output results are identical.
Version history:
ARMv4:
- use all available registers to calculate four pixels within each
loop iteration.
- avoid LDR interlocks.
ARMv5TE:
- use ARMv5TE+ 1-cycle multiply-accumulate instructions.
ARMv5TE_WST:
- use data tables (256 bytes) for RBG565 saturation.
Benchmarks results using iPod Classic (ARM926EJ 216Mhz):
size test_fps (1) mpegplayer (2)
bytes YUV YUV1/4 average min/max
----- ----------- ------------------
SVN-20141107 528 27.8 110.0 11035 10864/13397
ARMv4 480 28.8 114.0 9767 9586/12126
ARMv5TE 468 29.7 117.5 8751 8584/11118
ARMv5TE_WST 544 33.6 133.0 6355 6316/6403
(1) boosted
(2) play full elephants_dream_320x240.mpg file (15693 frames) using
mpegplayer, patched RB measures YUV to RGB565 frame conversion
time (microseconds)
Compared against the WST version, the ARMV5TE version w/o cached
saturation tables is slower, but it is smaller and i have doubts
about the power consumption.
Change-Id: I2b6a81804636658d85a1bb104ccb2055e77ac120
Reviewed-on: http://gerrit.rockbox.org/1034
Reviewed-by: Cástor Muñoz <cmvidal@gmail.com>
Tested: Cástor Muñoz <cmvidal@gmail.com>
7d1a47cf13 introduced a regression that broke it completely so that
it couldn't boot into the main menu anymore. It had a faulty call to
get_volume_name() which made handle_special_links() act up. This broke
every open() and opendir() (and friends) library calls.
Change-Id: I399960ca8fb6e3bcc1f25c9b4a3c19a6d28b77bd
Commit 7d1a47cf ("Rewrite filesystem code (WIP)") exposed
bug in rk27xx sd driver. Buffer passed to sd_read/write_sectors()
doesn't has to be cacheline aligned. DMA transfers on
unaligned buffers is quiet dangerous thing.
Make sure that the buffer is aligned to cacheline size,
If not use a temporary aligned buffer for DMA transfer.
Change-Id: I91420f2b8d58159c80c3f15f4b35e88ea0dfd14c
This file revealed several problems with our ASF parser:
1) The packet count in the ASF was actually a 64 bit value,
leading to overflow in very long files.
2) Seeking blindly trusted the bitrate listed in the ASF header
rather than computing it from the packet size and number of packets.
Fix these problems and fix a few minor issues.
Change-Id: Ie0f68734e6423e837757528ddb155f3bdcc979f3
The current code assumed that READ/WRITE would produce atomic read/writes for
8/16/32-bit words, which in turned put assumption on the memcpy function.
Since some memcpy implementation do not always guarantee such strong assumption,
introduce two new operation READ/WRITE_ATOMIC which provide the necessary
tools to do correct read and write to register in a single memory access.
Change-Id: I37451bd5057bb0dcaf5a800d8aef8791c792a090
Use 32 bytes for cache line length (arm926ej-s), this prevents
misalignments of ATA storage buffer which in some builds could
cause weird faults.
Change-Id: I88dc595d251315620ec49b0251ddc039ff47181e
Reviewed-on: http://gerrit.rockbox.org/1031
Reviewed-by: Marcin Bukat <marcin.bukat@gmail.com>
