Removing the "list_wrap" argument is actually pretty easy.
In practice, almost all lists are using LIST_WRAP_UNLESS_HELD
behavior so we can make that the default. A couple of lists
disable wraparound with LIST_WRAP_OFF; this is now achieved
by setting the list "wraparound" flag to false when setting
up the list. LIST_WRAP_ON was unused and is of questionable
value, so it has been removed entirely.
This makes list wraparound behavior a property of the list,
controlled solely by the "wraparound" flag. The result is a
simpler list API and implementation, without changing the
behavior of any lists.
Change-Id: Ib55d17519e6d92fc95ae17b84ab0aaf4233bcb5a
Since gui_synclist_do_button() overrides the setting at runtime
there is no reason to have a public API call to set it. Really
it should be a local variable, but it will be simpler to do that
after refactoring how list wraparound behavior is handled.
Change-Id: Id09d42197814102693752a9f64db8325118ca796
gui_list_screen_scroll_step() and gui_list_screen_scroll_out_of_view()
just copy the global setting into a local static variable.
Since they don't do anything special when the setting changes
it's simpler to use the global setting directly.
Change-Id: Ib6a7bf4e09b6dabbc1597cf28ddbafc0bc857526
The implementation of the "show_selection_marker" option in
lists isn't great. It's a cosmetic option used to hide the
selection, but it causes the list to do funny things to the
selected_item and doesn't play nice with voiced menus, since
these rely on the selection to determine what item is spoken.
There are only two user-facing lists that use the option, the
"Rockbox Info" screen and a menu in the superdom plugin. The
rest are debug screens, and cosmetics don't matter much there.
Given how little used the option is, and its issues, removing
it seems reasonable.
Change-Id: I2c70b3e4c74ff3cc6dbac46366a371d271dd2d58
Use const char* pointers for list titles. Only one debug menu
actually modifies the title, and in that case it's legal to
cast away const because the title points to a known mutable
buffer on the stack.
Change-Id: Idb8ab307b9a6ec23a93d8420c5e19fafd9f59c30
The %Vs(color) tag doesn't set the text style properly and causes
the background to not be cleared when rendering lines. For static
text this is rarely a problem, but for scrolling text it'll cause
the text to "smear" once it starts scrolling.
Fix this by setting STYLE_DEFAULT, so the background gets redrawn
when the line scrolls.
Bug report: https://forums.rockbox.org/index.php/topic,54320.0.html
Change-Id: I835c806005ea40fd6bac3692e52a9c325581a293
The get_address_fn implementations for some remote LCDs were
checking LCD_STRIDEFORMAT unconditionally, but that macro is
only valid for the main LCD. The remote LCD code only supports
horizontal strides, so when compiling for a remote LCD, force
the use of horizontal stride addressing.
This fixes a buffer overflow and out of bounds write that occurs
with the M:Robe 500 remote LCD. (Tested with sim + ASan only.)
Change-Id: I99c6aa11d38f5105b096fc448948b9ec1b27dfe6
Instead of putting "#ifdef LCD_STRIDEFORMAT" at every usage of the
macro it's simpler to have config.h define LCD_STRIDEFORMAT to the
default of horizontal stride when the target leaves it unspecified.
Change-Id: Ib187012aad65ac678dbd837b1464a83bad722411
This was only enabled for the mrobe500 and sansaconnect targets.
Most targets are therefore running without this "safety" measure,
and presumably we'd have noticed long ago if there was a problem.
So in all likelihood this is just a bunch of dead code that we
don't need to carry around.
Change-Id: I7d27701a38b1c2a985ee73fa6f277ad215d8d385
This makes status by event debounce status changes over
a 200ms period, which is what polling was already using.
This is helpful on targets where events are excessively
noisy and generate a lot of transitions during insertion
and extraction.
Change-Id: I0eae2cca93aaa865e33c94a1318c27e91c7f7c4b
Have action.c control the key remap buflib allocation so that it can
be made movable. With memory management offloaded, core_keymap.c only
needs to deal with loading keymap files. Simplify the code there and
use buflib pinning so the file can be loaded directly into the buffer.
Change-Id: Ia654cc05ce6b286f96c1031fa4f7d4b3859a2c1a
An allocation is pinned by calling buflib_pin() to up its pin count.
The pin count is like a reference count: when above 0, buflib won't
move the allocation and won't call its move callbacks. This makes it
safe to hold the pointer returned by buflib_get_data() across yields
or allocations.
Note that pinned allocations can still shrink because there are some
use cases where this would be valid, if buffer users coordinate with
the shrink callback.
Change-Id: I0d0c2a8ac7d891d3ad6b3d0eb80c5b5a1b4b9a9d
Since allocation is infrequent in Rockbox enabling the extra
checks to catch memory corruption is probably worth the time
and code size cost.
Change-Id: If0d701421054328c57b69e4d0af30759d799d158
Using a length 1 char array to point to the name buffer triggers
a -Warray-bounds warning from GCC when fortified strcpy is used.
This type of construct isn't safe in general -- if the compiler
makes assumptions based on the array bound it can create subtle
bugs when accessing the array out of bounds.
Instead, add a function get_block_name() which returns a pointer
to the name field by casting. This suppresses the warning and it
should be a bit more portable.
Change-Id: I25d4f46f799022ad0ec23bef0218f7595cc741ea
These don't have any users and there is already another way to
print blocks (which is actually used by the debug menu).
Change-Id: Ic6a4f874c6499c42bc046e8af3e4aaddc9e68276
If we don't check or generate CRCs then the CRC field can be left
out of the header, which reduces buflib overhead slightly.
Change-Id: I08b4cf77a701d8f6da453e019a0373d858a79ae4
Move CRC checking and updating behind a paranoia bit, like the
other checks, so it can be enabled and disabled.
Change-Id: Icff66c842cbd5af2d99aa91e6c40447a64e6d4b2
Handle checks ensure that the data in the handle table points
within buflib memory and checks handle entry pointers in block
headers before dereferencing them.
Change-Id: Ic16f1b81c1a0ea63c0e7f48d87938293b75c2419
Tighten up checking by adding length checks to loops which
ensure the iteration stays within bounds. Check is disabled
by default and can be enabled using a BUFLIB_PARANOIA bit.
Change-Id: I35e911e0878797d5ebf732be548ca659f6910fe0
Buflib is written with a lot of hardcoded offsets to header fields,
arbitrary pointer arithmetic, and similar but not quite duplicated
code, making maintenance a nightmare.
Most of the pointer arithmetic involving header fields is replaced
by indexing from two well-defined pointers, the block start and end
pointers. The start pointer points to the first header field, and
he end pointer is one past the end of the header.
Hardcoded field indices are replaced by two enums. Forward indices
(fidx_XXX) are used to access fields from a block start pointer and
negated backward indices (-bidx_XXX) are used to index from a block
end pointer. There is no overlap between the indices because of the
variable length name field in the middle of the header. The length
of the fixed fields in the block header is now a #define'd constant
rather than being open coded.
There is now a function to acquire the block end pointer from the
user data pointer (ie. the pointer stored in the handle table). The
old code was not consistent in this; some functions would handle a
non-aligned user pointer, which may occur as a result of shrinking,
while other uses just assumed the user pointer was aligned.
Block CRC calculations have also been factored out to a function
that accepts block start and end pointers.
Change-Id: I6a7e8a8c58aec6c6eaf0e5021400032d8e5f841e
The block header has a variable length due to the embedded name.
The name length is stored at the back of the header after the
name, in order to allow finding the start of the header if only
the user data pointer is known (eg. from the handle table).
The name length is actually not interesting in itself; storing
the total length of the block header instead is marginally more
efficient, saving one addition in handle_to_block().
Instead the extra arithmetic must be done by buflib_get_name(),
which is a much less common operation than handle_to_block().
Change-Id: Ia339a1d2f556a11a49deae0871203e70548bd234
The way it iterated over the handle table is unsafe if *every*
handle is free, leading to an out of bounds access.
This is a contrived example, but the bug can be triggered by
making several allocations, freeing them out of order so that
the handle table remains uncompacted, and then triggering a
compaction using buflib_alloc_maximum().
Change-Id: I879e2f0b223e6ca596769610ac46f4edf1107f5c
It isn't obvious why the "handle->val = -1" at the end of handle_alloc
is needed so add an explanatory comment. But "handle->val = 1" prior to
calling handle_free is simply a dead store.
Change-Id: I9ab4e96e87e940cfd1a2ed56f089287821669c73
Since we're scanning the handle table for the first free slot,
we know none of the scanned slots are free. Use that knowledge
to update first_free_handle and avoid rescanning filled slots
again when the next handle is allocated.
Change-Id: I457372f66c231168cfffa7e905d1e9fb80002f5f
Use the standard IS_ALIGNED macro and check alignment against
sizeof(buflib_data), as it can be greater than 4 bytes if we're
on a 64-bit platform (eg. simulator).
Change-Id: I15110937d1f2978e733d169050de9531fe218214
Exiting the loop implies next_block == block, so remove that check.
The check ret < block is false only if block is the first block, which
can be checked before the loop, saving a few cycles in that case.
Change-Id: Id493b5259a23a35a70b09dfe4bc4eacaf420760c
This appears to be a bug in GCC 12 due to more aggressive -Waddress
warnings. According to the GCC documentation, the warning should be
suppressed because the "problem" code is coming from a macro, but it
doesn't happen for cases like "if(!SKINOFFSETTOPTR(...))" where the
macro is negated.
Assigning the result of SKINOFFSETTOPTR() to a temporary and checking
that suppresses the warning.
Change-Id: Ia37a1e06a454d29032bb8128a2f059b149ea2b83
This is another chip used in newer Surfans F20 units. Like the
Winbond chip, it's a 1-gigabit chip with on-die ECC. Notably it
has an expanded 128-byte OOB area that is only accessible when
on-die ECC is disabled.
Change-Id: I2203918a15c914097f5a6bbe4afa2d3a60dc67f7
This chip is apparently used in some Surfans F20 units, and has
the same geometry as the ATO25D1GA. It has an on-die ECC engine.
Change-Id: I4d37a2455620ce43cec0a9bcbb32c776d1a8eba1
Decouple chip IDs from chips, and allow the chip ID table to list
which read ID method should be used. Use a safe controller setup
during identification instead of using the first chip's parameters.
Change-Id: Ia725959c31b2838f4a3a30e5bb7fa6652ef377ed
The description for arm-linux mentions "Linux-based Sony NWZ", which
is misleading for people who aren't very familiar with the various
targets and history. People setting up toolchains for the first time
for their "traditional" NWZ will overlook the "linux" part (or not
understand what it means) and build the wrong compiler.
Mentioning "older Sony NWZ" may of course not immediately tell those
people which one to pick, but at least they'll know they need to look
things up.
Change-Id: I5743a6427842db7334cff5479291e2137c35ae0c
* added scroll wheel to doom
* added scroll wheel to brickmania
* changed spacerocks to use scroll wheel instead of buttons
Change-Id: I9d6ff0b4c5deea147178f5cd9f96ae435e7b5cd8
Shuffle and Unshuffle commands are not flushed to
disk when control data is updated. The same applies
to Delete and Reset commands, unless HAVE_DIRCACHE
is undefined (see update_control() function in playlist.c)
playlist_resume() discards cached control data.
This resulted in a bug where (e.g.) removed tracks
from the current playlist would reappear if you stopped
and resumed playing immediately afterwards (instead of
restarting in between).
Change-Id: I273f61e823a1d99426a18079b81aa07915620f30
The disk doesn't need to spin up when the
database is in RAM. Results are usually returned
without any noticeable delay, so the splash only
creates distraction.
Change-Id: I04e5b7d2e00f045143dd86e0561091be3d8f9724
