Hosted platforms use dlopen() for plugin loading, and hibylinux is
relatively RAM constrained, so shrink this will free up more memory to
the OS for plugins to use.
Change-Id: I6b7cb17b964eaf5afc4958db242dfe4b82178e2e
This represents a 256K increase from the former (MEMORYSIZE-0.75), and
is necessary due to the growth in our binary sizes over the past decade
or so.
It is debatable if this is enough given that our actual memory
usage is approximately (MEMORYSIZE+3) megabytes (plus runtime OS
overhead) for the typical hosted build, but giving the host OS a bit
more breathing room is warranted.
Change-Id: I53e044585a32efd50a85e68d64fd21921eda01a3
We used 16-bit variables to store the 'character code' everywhere but
this won't let us represent anything beyond U+FFFF.
This patch changes those variables to a custom type that can be 32 or 16
bits depending on the build, and adjusts numerous internal APIs and
datastructures to match. This includes:
* utf8decode() and friends
* font manipulation, caching, rendering, and generation
* on-screen keyboard
* FAT filesystem (parsing and generating utf16 LFNs)
* WIN32 simulator platform code
Note that this patch doesn't _enable_ >16bit unicode support; a followup
patch will turn that on for appropriate targets.
Appears to work on:
* hosted linux, native, linux simulator in both 16/32-bit modes.
Needs testing on:
* windows and macos simulator (16bit+32bit)
Change-Id: Iba111b27d2433019b6bff937cf1ebd2c4353a0e8
High-frequency files increasingly use a block size of over 4608B, which
means we need larger buffers to decode them. However, larger buffers no
longer fit in IRAM on less-capable devices, hurting performance for
"normal" file playback.
On our slowest devices (M68K and PP-based devices), this is not worth
the tradeoff as they will likely not have enough CPU oomph to decode and
downmix these files in realtime.
S5L87xx-based devices have the raw performance to do this, so we decided
to err on the side of wider file compatibility at the cost of some
performance.
All other devices are unaffected.
Change-Id: I7344cf4c8c6b7b5c14f1ea67381160665d6ece5b
All toolchain dependencies are circa the GCC 10.5.0 release:
GCC 10.5.0, binutils 2.40, gmp 6.2.1, mpfr 4.1.1, mpc 1.3.1, isl 0.24
Native:
* arm - mini2g, nano2g works
- ipod6g hangs at logo display
* mips - xduoox3 works
* m68k - binaries untested
Hosted:
* arm - samsungypr0 works
* mips - xduoox3ii works
* Android NDK - unchanged at GCC 4.9.4
Change-Id: Ic157255d76030e66325719e64331f553cb7c4363
By switching them from (const void* volatile*) to (void* volatile*)
The 'const' bit was causing GCC>4 to optimize away writes to those
addresses when compiled with -Os, badly breaking the interrupt handler.
Change-Id: Ia4b0ca37e082bddf78e084b80a5e550894645f1a
* move all state into IRAM
* eliminate dummy variables
* get rid of 'naked' attribute and (slightly wasteful) hand-written asm
in favor of auto-created 'interrupt' code
Change-Id: Ie6a2e12a4c1a0faa6ae89504cf931657044bd457
Clarifies presumably intentional fall-through for
PF_TRACKLIST and fixes unwanted behavior of
PF_TRACKLIST while scrolling, which may have
started playback instead of showing the track list.
(affected keymaps at the moment are only SANSA_FUZE_PAD,
SAMSUNG_YH820_PAD, SAMSUNG_YH92X_PAD, and FIIO_M3K_PAD)
Change-Id: I335dd1b4a2152caed966b73aaa189bcfddc79734
When you're using a "large" screen device, and the message doesn't need
to scroll, parts of the previous mesage are left behind.
Work around this by explicitly clearing the messgage with a loooong
blank string.
Change-Id: I02f7789eb6567e92ecca174c40dabc4b580ac045
We already use targeted optimization for most codecs, and the
DSP code is just as performance-sensitive.
Improves mp3 decoding performance by a whopping 1% wwhen PBE is
turned on.
Change-Id: I801a6624c0f7068b6cd67961ad3b08f809b92fca
It is particularly stack-heavy (>1.25K, >2.25K with 32-bit unicode)
Its only caller was font_load_ex() but that can be called recursively
which _really_ blew up the stack.
Change-Id: I211cd33ca3478b2bd01d3ddcf6c890399af2fb9c
cRSID natively renders its output as a 16bit mono stream. There's no
reason to not use it as-is, and save a bunch of CPU cycles in the
process.
Change-Id: Ib934c05e77298e377053b29db91d1f05fb65eb76
* Added some missing strings and updated some others that made no sense
(were literal/poor translations).
* More usage of music-relevant terms.
* This translation fits a standard-internationally spoken Spanish,
supported with the use of DLE (Spanish language dictionary) of RAE
(Real Spanish Academmy)
Change-Id: Ie891520bcafe1e880e25dd42ce81393b1f10840d
By default STMP3700 launches from negative edge for capture on positive edge.
If we leave DPL (bit 13 of reg 0x13) to 0, it will be captured on falling edge,
resulting in a potentially undefined behavior. Some make sure LCD captures on
rising edge. Alternatively we could change the dotclk polarity in VDCTRL0.
Change-Id: I4ceb2f5a9be88e07f0af9bf493b7881883320fda
We've received multiple reports from users of 6th gen iPods where we
fail to find any mountable partition. A user was able to supply an MBR
dump, which showed that the "type" listed for parition 0 was set to 0x00
(ie "unused"), leading us to (correctly) completely ignore that entry.
However, it looks like the stock firmware ignores the type and
unconditionally uses the first entry even if it's nominally "invalid"
So, to deal with this, always try to mount partition 0 if it is not one
of the two "extended partition table" types. If that speculative mount
succeeds, we now treat it as type 0x0c (Fat32 w/LBA) internally.
Note that this will not allow the partition to be mountable over USB, as
the MBR is still incorrect, leading the host OS to ignore the partition.
Further complicating things, the stock Apple firmware always constructs
a fake MBR to hand to the host!
To prevent user confusion with these devices, we may consider faking the
MBR too; alternatively we could correct the MBR and write it back to
disk, perhaps via a debug menu option.
Change-Id: I1e9392d20401eb94ecc6d70263fb0e45392a9bd4
musl doesn't unload shared objects when we dlclose() the handle. This means
it also never re-initializes them if we try to re-launch.
This means that global state is persisted across invocations instead of
being wiped. Until we come up with a proper workaround we can apply
globally, have the textviewer clean up the important global state when
it exits.
Change-Id: I43bf38e6e9f0e7d824931740daff6c060537235a
TAG_MAXLEN is 2* MAX_PATH, so this means we don't reject paths
that we could never actually open on the device.
Change-Id: I64363758163c0a6a5f54ebb1c9b455f3cb5b6e56
Battery time estimation works now.
This commit also changes the mksquashfs path to FUNKEY_SDK_PATH.
Change-Id: Ic0aa4c40011b0716f1c36c014377eaccb486e841
Backdrops persist regardless of their location
in the file system since commit d09f978 (FS#12041):
"allows loading of backdrops from anywhere, and
keeps those backdrops after reboot."
Change-Id: I7b8cd2cdbca15b6d9ee7baae20a5d074c9765257
We used 16-bit variables to store the 'character code' everywhere but
this won't let us represent anything beyond U+FFFF.
This patch changes those variables to a custom type that can be 32 or 16
bits depending on the build, and adjusts numerous internal APIs and
datastructures to match. This includes:
* utf8decode() and friends
* on-screen keyboard
* font manipulation, caching, rendering, and generation
* VFAT code parses and generates utf16 dirents
* WIN32 simulator reads and writes utf16 filenames
Note that this patch doesn't _enable_ >16bit unicode support; a followup
patch will turn that on for appropriate targets.
Known bugs:
* Native players in 32-bit unicode mode generate mangled filename
entries if they include UTF16 surrogate codepoints. Root cause
is unclear, and may reside in core dircache code.
Needs testing on:
* windows simulator (16bit+32bit)
Change-Id: I193a00fe2a11a4181ddc82df2d71be52bf00b6e6
