its really painful needing to override global settings in order to change
some aspects of lists
this patch moves:
[scrollbar position, cursor type,
talk_menus, keyclick,
wrap around, scroll paginated]
to variables within the synclist, it also makes updating
after settings changes a necessity
I think I have the static synclists in core covered
(I think the one in gui/list-skinned can be left as is)
this patch allows easy modification these flags on the fly
Change-Id: Id0dcb8b05eb9ecd78929c0aff7678bf2ab4c70a7
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.
Change-Id: Ia48924d4dcb24c1111509329581809be494d0165
In some circumstances it was possible for a bitmap to overflow its
buffer and overwrite the next handle. The easiest way to trigger it
is with a highly compressed JPEG that is decoded to a large bitmap.
Because the JPEG file size is used to determine how much to allocate
this would cause an obvious buffer overflow when the JPEG is smaller
than the decoded bitmap. Fix this by using the decoded bitmap size as
the allocation size. Some overhead must be added to deal with JPEGs,
but it will be freed once the image is loaded.
A less obvious possibility is the fact that add_handle() will allow
a handle to be added even if there's not enough space for the entire
allocation. This is generally beneficial because it allows the first
part of a file to be loaded while waiting for space to free up, but
for bitmaps it is not valid because the whole image is loaded at once.
Hence if there is not actually enough space in the buffer, the bitmap
load can again overflow the actual free space and overwrite the next
handle.
The buffering code supports an H_ALLOCALL flag for allocations that
need the free space available immediately, so use it for bitmaps to
avoid that bug.
load_image() had a sketchy-looking check for free space which stopped
me from triggering the bug with simple tests, but since guessing the
free space is obviously a bad idea when the caller *knows* how much
free space there really is, remove that guess and let the caller tell
load_image() the real deal.
Change-Id: If62a58759705d83c16ee5b50f26bcbccc3f6c01f
JPEG decoding requires additional space in the bitmap buffer beyond
what is needed for the decoded pixel data. Provide a way to estimate
how much overhead is needed.
The actual overhead is sizeof(struct jpeg) + decode_buf_size, where
the latter depends on the image size and JPEG encoding used. From my
testing decode_buf_size is normally pretty small (under 5 KiB) but
looking at the code it could be large in some cases, primarily with
large images, so 32 KiB seems to be a decent compromise. Someone who
knows better about JPEG should pick a better value if that's too big.
Using a constant is obviously not the most accurate but it seems to
be the simplest option for retrofitting to existing code.
Change-Id: I573b0abb8ca2d79e43f185010487f07226edb793
Not sure what the comment is talking about - signed overflow
is undefined behavior and we don't use -fwrapv or other flags
to make it defined. I can't see how a compiler could abuse it
here, but the overflow is nonetheless easily avoided.
Change-Id: Ibed6d7c0d841db2aa86b9d8ba4c6a0d08c413354
don't stop playback to alloc viewports for the keyboard
For the moment it doesn't make much difference
each vp takes about 40 bytes (double that in the sim?)
so not the end of the world 120 extra bytes
Change-Id: I482d7e3061cf9fb8065dc28bf62a6f830770f3c7
- Update the manual entry for PictureFlow with
the latest features and fix keymap
- Strongly suggest enabling the database's
"Load to RAM" feature (in my experience, this
can lead to a ~60x speedup when building the
album index)
- Suggest enabling the dircache, as it can
noticeably improve the loading times for
album art.
Change-Id: I12c7ce5d5388159da1790fc125f2e20bb78dbf96
While the track number is limited to 99, I know of no documented
constraint on the value of offset minutes to 99.
As we are storing the millisecond offset as unsigned long, assuming
32 bit, we can allow 70,000 minutes (2^32 / 60000).
However, I've been unable to generate a test audio file 48 days long
under 2GB, so I've set the limit to 30,000 minutes.
In addition, this change reduces the maximum number of seconds to 59,
and frames to 74.
I've generated some silent test files with the filenames being
cue_[minutes].mp3
http://peskett.co.uk/rockbox/test_cues/
Change-Id: I3ca4468ebc88ba134c4e785e9395f90bf76941ac
allows items to be moved around with less code changes
remove scrolling I was not overly impressed with it
add test_kbd plugin
Change-Id: Ic183c7221bda9405891632704f3a7bbfd79bfe83
if you skip a track after the halfway point the scrobbler may double post
with slightly different timestamps but the same track info
take a crc of the non-unique part and check against the previously
written track
Change-Id: I676342c4cd76f632131d9cb6d9f7d2f59df357e6
MEM_ALIGN_ATTR should take advantage of cache line alignment on
all native CPUs which define it, not just ARM CPUs. (This could
arguably be done for hosted targets too, but we don't necessarily
know the size of a cache line there.)
Change-Id: Ife9302105ea57388afd55ce31da848b00b5b1b25
Hold "Play" to boot the OF, or boot it from the recovery menu
by holding "Vol. Up". If you had the hosted port installed on your
player before installing the native port, you'll still have to go
through the hosted bootloader.
A couple notes:
- When booting from the menu, the recovery menu disappears, then
reappears before going into the OF.
- You need to hold the play button for like a half second after the
blue light comes on in order to get into the OF.
The recovery appears to be there, but it doesn't seem to be intended
for end users - it just says "Updater V1.1 - Insert TF Pls". I haven't
tested it beyond seeing that it boots, so I'm going to comment it out
for now.
Change-Id: Ie271ee479bb628cc74141b7fe07273b3f193f358
The comment regarding Windows paths was fairly confusing as to
its intent. What the code is trying to do is replace the drive
letter with the volume containing the playlist, which appears
reasonable. The middle of the comment was devoted to explaining
why the code below was potentially incorrect which only served
to add to the confusion.
AFAICT the last volume specifier in a path will cause search to
start from the root of that volume, so any incorrect result can
be avoided by using the new function path_strip_last_volume().
Finally, add a comment at the top of the function that explains
what it does.
Change-Id: If4e4938801f2f81eb52f5d32b5461872995e5e83
This gets the volume that the path eventually refers to by parsing
the last volume specifier and returning the part of the path after
it (which does not contain any volume specifiers). The initial part
of the path therefore contains everything up to and including the
last volume specifier.
Change-Id: I9a935543256f8f22e0b8b1e3c88d4e47bd9dae8a
Enables multiboot for the FiiO M3K, Shanling Q1, and Eros Q native port.
Note this requires an up-to-date Rockbox _and_ bootloader.
Usage instructions will (eventually) be found on the wiki:
https://www.rockbox.org/wiki/MultibootBootloader
Change-Id: Ia2da1ad6ef611e499d2fbafa93838387bc1023ba
Searching in volume 0 is necessary for multiboot targets with only
one drive, like the M3K/Q1/ErosQ. Without this the search code will
never look at the redirect file on these targets.
The search bound is configured with a setting MULTIBOOT_MIN_VOLUME,
which defaults to 0, but is defined to 1 for Sansa players so they
keep their old behavior.
Change-Id: I6dc5cf98db4258731de2c68c3ab1182b4a4a655b
Now offers sorting by:
- Album artist, then album name
- Album artist, then album year
- Album year
- Album name
Years are determined by the most recently
released track appearing on an album, if the
value differs between tracks.
On the M3K, instead of by going into Settings,
volume buttons can also be used for quickly
adjusting the current sorting
Change-Id: I2c50059617114fb418336c466fdd37415473ac7d
It seems Qt6 doesn't require explicit linking to QSvgIconPlugin anymore,
and cmake has trouble finding it. On native Windows builds it isn't
required, so remove it.
Change-Id: I87651f51ab212511947ab9fca3297b0dff276577
Some things in core that should probably be plugins steal the plugin buffer
for their own use, TSR plugins have no way to detect or prevent this
lock buffer reserves buffer_size bytes directly after the plugin itself
returns the unreserved bytes still available from the plugin buffer
Change-Id: I5a7849e209129b09400036a594569ef396b1b85f
There should be no need for any compatibility hacks since this
value was mostly used internally between the SPL and bootloader.
clk_init() was the only user in the main Rockbox binary which
accessed it, but when loaded by the Rockbox bootloader that code
will not be reached since BOOT_FLAG_CLK_INIT is already set.
Change-Id: Idd68b9834172e652b47432bfb1e00c923ea35407
Removes the SPL's dual boot support code, and removes the dual
boot selection code on the M3K and Q1 since they can now do it
from the main bootloader.
Change-Id: Ie1b27e98c6ed4b3e37db86cfb485d6f3a6c5b25e
Screenshots of the recovery menu will be useful for documentation.
This can be disabled by turning off HAVE_BOOTLOADER_SCREENDUMP in
the target config file if the bootloader should ever run up against
max size limits.
Change-Id: I62ec1e465df2ca7a8a0e78625d88b31f6c4ef078
Bad blocks in a kernel flash partition seem to be handled by skipping
ahead to the next block; this is a common bad block management scheme
for simple software like bootloaders (and is the default method for
reading NAND partitions in u-boot).
Extend the uImage flash reader to skip bad blocks while reading.
Change-Id: I815875e83a2418e2642f736e04a3437c31b354ba
