Only the scroll engine calls this, but it's easily replaced
by the return value of set_viewport_ex().
Change-Id: I2e2c8234f969bc07c9ff7d864e58551115175e26
All three functions are nearly identical regardless of the
LCD pixel format. Consolidate them into a generic version in
lcd-bitmap-common.c.
Change-Id: Iab13429ea27ea2b0150b9004535bd27d4a4121a0
In-viewport clipping code is duplicated across 8 files, making
it a chore to change anything related to clipping; refactor the
clipping logic into dedicated functions.
Change-Id: I4ab20bb3c59b0406098d0c7d23833025f17a320a
the loading track splash flashes and is ugly
add a function to display a progressbar along with the splash message
spruce up database commit message as well
Change-Id: I2749b958c1ee5dad2631a5f999a4b00ddca7f225
Only the "Rockbox Info" screen uses it for a rather silly purpose,
so remove the function. This helps to decouple things from the GUI.
Change-Id: Icf73e3ee1230c75bf43016c0f1c05c7fe1a24895
Get rid of the "limit_scroll" member from lists and make it a
local variable of gui_synclist_do_button().
Bump plugin API version since struct gui_synclist was changed.
Change-Id: Ie3244a85e5a1022a2f6e238a506fdbba67724962
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
