HibyOS-based target: keymaps, LED, powermgmt, bootloader and sim support,
plus cabbiev2 for the new 360x640x16 screen. Opus 5 helped w/ debugging
and the initial scaffolding.
Updated name to FB_STRIDE_MISMATCH, added simulator bmp and specs.
Change-Id: If797ac6581cf75d9d1fcf36e615ee03cf6f905d6
* Dedicated FIFO mode requires a non-zero multi-count for periodic INs
* Add ISO frame polarity
* Correct max packet size for high-speed ISOC operation
Change-Id: I2c0d40b5f8d0e1e4cf43369631f17c7f80c6fab2
Debug -> USB Serial calls usb_core_enable_driver(USB_DRIVER_SERIAL, ...), which sets a flag inside usb_core. usb_core_init() clears every driver's enabled flag on each connect and runs after the toggle, so the choice is gone before any descriptor is built: the menu reports the new state and nothing changes.
Hold the setting in firmware/usb.c and reapply it from usb_configure_drivers() on each connect, which is where the other drivers are already configured. usb_set_serial()/usb_get_serial() sit alongside usb_set_hid(), which works this way for the same reason.
toggle_usb_core_driver() goes with it: toggle_usb_serial() was its only
caller, and a generic wrapper around a call that cannot persist is not worth keeping.
Affects any target building USB_ENABLE_SERIAL.
Change-Id: I171a532d23cc9cf0efe0a01c2836b69846333a4d
Co-Authored-By: Claude Opus 4.8
usb_serial_control_request() copies the line coding and returns handled = true without calling usb_core_control_response(). usb_core only answers requests a driver declines, so returning handled makes the status stage the driver's responsibility and nothing sends it. The host sees the request accepted and then times out waiting for status.
Every other branch in this function already responds but this one was missed.
Affects any target building USB_ENABLE_SERIAL. The symptom is a CDC console that enumerates and then stalls when a terminal opens it and sets the line rate.
Change-Id: Icd97805971c68ce3a599cf01e9f6aa103c61c2ec
Co-Authored-By: Claude Opus 4.8
nand_init() guards its one-time setup with a static `inited` flag that
nothing ever assigns, so every call re-runs the initialiser. That resets
refcount to 0 on a driver another caller may already hold open, and the next nand_close() then decrements from zero and tears the driver down underneath its user.
Assign the flag, and fix the caller that reaches this. On a failed open the installer's updater_cleanup() would call nand_close() against a driver nand_open() never took a reference on, because nand_open() only takes one once it has identified the chip; release the lock and drop the pointer instead.
Change-Id: I88d54ac5bca9bcebb62fd9c6f50f1acf982a9a3b
Co-Authored-By: Claude Opus 4.8
backup_bootloader() and restore_bootloader() initialise `fd = 0` and their error paths close it unconditionally. Any failure before the file is opened updater_init(), or the size check between them therefore reaches close(0) and closes whatever fd 0 happens to be. On a native target that is whatever the filesystem layer handed out first, so an unrelated open file is closed and the damage surfaces somewhere else entirely.
Initialise to -1 instead, which is the value close() ignores.
Found by inspection while bringing up another Ingenic target. Not run on
X1000 hardware.
Change-Id: Ib043f79f0b7edc7c70ccd77cbff54e264ed2b2de
Co-Authored-By: Claude Opus 4.8
The enable check read
if(r & (1 << info->en_bit) == 0)
`==` binds tighter than `&`, so this evaluates as `r & ((1 << bit) == 0)`,
i.e. `r & 0`, which is always false. The check never fired, and a supply
that was switched off reported the voltage it would have had if enabled.
Callers cannot tell "off" from "on at this voltage", so anything reading a rail back to confirm it came up gets a false confirmation.
Found by inspection while bringing up another Ingenic target. Not run on
X1000 hardware as I do not have one of these devices.
Change-Id: I19fc89ff33cce047160d826ce2344cc34b26e224
Co-Authored-By: Claude Opus 4.8
iap-serial was hardcoded to return "ROCKBOX", and it was
not implemented at all in iap-usb.
Extend the iap-serial implementation to return the contents of
<ROCKBOX_DIR>/playername.txt, or "Rockbox" if there is an error
opening/reading that file.
And cut-n-paste this into the iap-usb side of things
Change-Id: I9d328be390b4cc8bd92237f996c41ef1e5e19724
Both Ubuntu and Windows fail to report the proper sample rate on my machines, causing crackling sound on my hiby r1. Since we explicitly specify the only supported sample rate (48 kHz), just ignore the reported value.
Change-Id: Ie6e85bf94f9e15fca0c968441d5a8ce5a0088b77
Last patch didn't swap both x and y so was wrong and messed up the coord pair
I didn't want to add more swapping due to extra overhead
ultimately the issue is that you have 1/2 pixel error (-1 0 1)
and when doing the reverse line the error is on the wrong side
so instead get the first point from the opposite dinc
Change-Id: I141c4af36a601314f2b509a9ebfcfab3b5213bcd
Decode the jack remote's play/pause and volume buttons via the
"Mikey" controller (I2C 0x72) and report them as multimedia keys so
they work on every screen, like the OF. Protocol reverse engineered
on-device, notes in mikey-6g.c.
Change-Id: If5f3d3abf043c0ce0d8ca7beb0f4b591e41c5c43
PictureFlow refuses to start on the larger panels in this family with
"Not enough memory for album art cache", no matter how small the
library is.
It is PF_PLAYBACK_CAPABLE here, so it deliberately takes the plugin
buffer instead of stealing the audio buffer in order to keep playback
running. It then gives a quarter of that buffer to its album art cache,
which needs DISPLAY_WIDTH * DISPLAY_HEIGHT * sizeof(pix_t) bytes:
HiBy R1 480x800 -> 400x533 -> 416 KiB
HiBy R3 Pro II 480x720 -> 360x480 -> 338 KiB
Surfans F28 320x480 -> 240x320 -> 150 KiB
A quarter of 512KiB is only 128KiB, so all three fail the check before
they ever look at the library. The rest of the family tops out at
320x240 and needs at most 68KiB, which is why the old value went
unnoticed.
Most hibyos devices only have 32MB of RAM in total, and the OS and its
daemons eat about two thirds of that, so there is nothing spare to hand
out and the buffer stays at 512KiB. The three affected targets happen to
be exactly the 64MB ones, and they are also the only members of the
family configured with MEMORYSIZE >= 16, so key the size off that.
Plugins are dlopen()ed on hosted targets, so pluginbuf is plain BSS and
plugin.lds/DRAMSIZE do not apply.
Change-Id: I38db01231bbb8d139cb2239623a79250e0e46b61
`channel_stopped` compacts the `active_channels` array, so we should check the same index for the next active channel.
Change-Id: I54c42f9b6c97f0c54d43b8faae0052e856f3c06d
Implement the USB Audio Class DAC on the HiBy R1 and R3ProII, driven by
the usb_audio setting from the scaffolding patch: the host plays audio
over USB and the player's CS43131 renders it.
The vendor kernel provides a UAC gadget function "uac_sa" whose char
device /dev/uac_sa delivers the host's PCM: the isochronous OUT frames
are converted to left-justified S16-in-S32 stereo and queued in a kernel
ring, drained with a non-blocking read(). The data path lives in
usb-dac-hiby.c -- a pump thread drains /dev/uac_sa into a small
single-producer/single-consumer ring and the mixer callback hands that
PCM to the codec through the normal ALSA output path. No resampling is
needed because Rockbox clocks the codec at the host-negotiated rate.
The DAC is built on the existing configfs gadget and binds the UDC like
ADB, while usb_power_only keeps the USB thread out of the way. In charge
mode it is a standalone self-bound gadget. In adb mode it is composed
alongside adb on one gadget so the host gets a sound card and adb at
once; uac_sa must be the first-linked function (audio interfaces 0-1)
because the vendor function hard-codes its interface numbers.
The pump is hardware-only, so usb-dac-hiby.c is excluded from simulator
builds; the usb_audio_get_active() playback-interlock stub lives with the
scaffolding.
The R3ProII shares this hosted HiBy port and the same userspace gadget,
and the data path is codec-agnostic, so nothing here is R1-specific.
Only the R1 has been validated on-device.
Co-Authored-By: Claude Opus 4.8
Change-Id: I64c57ede27f411a2c61d41a7e0fa127b51a7b5b9
Introduce the generic, target-agnostic pieces for a gadget-driven USB
Audio Class DAC, gated by the HAVE_HOST_USB_AUDIO target flag so they stay
inert unless a target opts in.
Rather than adding a new USB mode, reuse the existing usb_audio setting
(never / always / while charge-only / while mass-storage) with its
LANG_USB_DAC string, usb_set_audio() callback and the
PCM_MIXER_CHAN_USBAUDIO mixer channel. HAVE_HOST_USB_AUDIO becomes the
umbrella capability flag for this common code; USB_ENABLE_AUDIO stays the
native usbstack class-driver contract (which needs HAVE_USBSTACK and so
cannot be used by hosted ports whose kernel owns the USB controller).
usb_set_audio() is declared here and implemented by the target (natively
by the usbstack driver, or in the hosted port for gadget targets, as with
usb_audio_get_active()), and applied at settings load. The playback
interlock in wps.c/playback.c keeps local playback from mixing with host
audio while the DAC is active. Simulator stubs for usb_set_audio() and
usb_audio_get_active() keep sim builds linking.
Co-Authored-By: Claude Opus 4.8
Change-Id: I5b7738508c24721d91d4c32379102a1ac7c6228b
thread_get_debug_info() computes the current stack usage as
stack_used_current * 100 / thread->stack_size with no guard against a zero
stack size. On hosted targets the main thread has stack_size == 0, so
opening the "View OS stacks" debug screen divides by zero and panics with a
floating point exception.
Guard the division and report 0% when the stack size is unknown, which
matches the stack_usage() helper.
Likely affects all hosted non-SDL targets, but tested/confirmed on my
HiBy R1.
Change-Id: I8ecc56f53f1e97e8a59ca71c0e08a66093fecbae
0 is an invalid value to set on Hiby as "Output Port Switch". For devices with multiple outputs, we need to ensure it is set to a valid port.
Change-Id: I16ea2e620fae3034dccf3267d316924d8e2c0a95
hibyr1 defines HAVE_USB_ADB so the USB mode setting offers an ADB
entry, but hiby_set_usb_mode() never handled USB_MODE_ADB (it fell
through to default), so selecting ADB did nothing.
Wire USB_MODE_ADB up to enable_adb(). It builds the adb function on
the gadget and hands the functionfs mount and adbd to the vendor
respawner /sbin/adbserver.sh, rather than mounting functionfs inline
(which the original code flagged as flaky); adbd binds the UDC itself,
so usb_enable() leaves the UDC alone in ADB mode. disable_adb() unlinks
the adb function and unmounts its functionfs but leaves the function in
place to be reused, matching how adbserver.sh cycles it, so re-enabling
adb never re-creates it.
The mass-storage LUN is removable, so the host clears its backing file
when it ejects the volume (Linux does this on unmount). Re-arm the LUN
in usb_enable() on each connect, so the disk is exported on every
insert and not only the first.
Assisted-by: Claude Opus 4.8
Change-Id: Ia8f119a1a599e6dd3c1219cb4e193c753725a06a
Results in cleaner code versus effectively cut-n-pasting the driver's
completion callbacks into the endpoint structure.
Change-Id: I043c46c91796f787dec098a7db043481834950a0
usb_enable(false) wrote "" to the gadget UDC attribute to unbind it, but
sysfs_set_string("") doesn't do a write syscall.
This meant that live USB-mode switches did nothing and required a reboot to take effect.
Change-Id: I0fc9f54fdb2f529bfe24d5c1ed472c873401080e
* Devices with ADB now have HAVE_USB_ADB
* DX50/DX90 no longer set USB_NONE
* stub out necessary functions
* usb_set_mode() and global_settings.usb_mode are now:
* called for all devices with (HAVE_USB_ADB | HAVE_USB_POWER)
* wrapped with consistent #ifdefs
Fixes regression in ce88de54b8
Change-Id: Ib0c16082fe237e8159cd42847355186ea5c74589
bidi_l2v() classified each character with ispunct((int)c), but c is
a decoded Unicode codepoint. ispunct() is only defined for values
that fit in an unsigned char (or EOF); a larger value is undefined
behaviour, and glibc then reads past the ctype table and reports
some codepoints as punctuation.
Hebrew final kaf (U+05DA) and gimel (U+05D2) land on such entries,
so a string ending in one had that letter trimmed off its RTL block
as if it were trailing punctuation and moved to the wrong end of
the line. Limit the punctuation test to ASCII so the result is
well-defined.
Change-Id: Ie6c3d8413f35ec3652e9228e3d5af05ef5bb811a
FONT_UI scans from MAXFONTS-1 to 0 to maximize the chances of getting a loaded
font but this may result in global_status.font_id being ignored even
if set through setuifont
this should take care of all the plugin woes dues to this
by setting the lcd font to the ui font before loading the plugin
and also making FONT_UI map to this font when font_get(FONT_UI) is called
if the desired font is not loaded then fallback to the previous behavior
Change-Id: I101d6f91910c17b08fca2b988a0a99c9e6899bee
Was missing:
* Arabic Supplement
* Arabic Extended B
* Arabic Extended A
* Rumi Numerals
* Arabic Extended C
* Indic Isqaq Numerals
* Ottoman Siyaq Numerals
* Arabic Mathematical Alphabet Symbols
Worth noting that most of these are vanishingly unlikely to ever show up
in the context of Rockbox. (The exceptions are "Arabic Supplement" and
possibly the Mathematical Symbols)
Also corrected "Arabic Presentation" into two distint blocks, as
the characters between them (fe00-fe6f) are NOT indicative of RTL.
Change-Id: I0c5c547921c789d32425682c8c75edb21428f549
Commit d1be73c ("keyboard.c Use viewports, move text box pos")
moved the picker and edit line into dedicated viewports. Under an
RTL UI language these viewports get VP_FLAG_ALIGN_RIGHT, so
lcd_putsxy mirrors every call; with the per-character cell drawing
this reversed the picker grid and the edit line (Hebrew shown
reversed, Latin filenames backwards, wrong caret).
- Clear the alignment flag on the keyboard own viewports so the
picker grid and cell layout are no longer mirrored.
- Draw the edit line as a single string so the bidi engine reorders
mixed Hebrew/Latin correctly, and use the full line width.
- Compute the caret from the bidi (LTR-base) visual layout so it
lands at the insertion point, including mixed Hebrew+Latin text.
- Pick the edit-line direction and invert the left/right cursor
keys based on the text first strong character.
Change-Id: I79f1c444bc9121fd5018ad5f6f4148afe2c1a3e1
Type 0 displays had to update the whole x line due to anything other
than a full line causing corruption and tearing
I figured out that flipping x and x_end
(LCD_W - x and LCD_W - x_end)
makes it work properly
Lowered the refresh rate to 95 Hz
Removed Fade in on screen enable
Change-Id: I0b8f76ad01ce7e48bd0a56aa321c30c30f91ce8d
Now that we have a datasheet for the type 1 display controller
it turns out the gamma correction was not being applied
the screen looks much better with it actually applied
also lowers display refresh from 120 HZ to 90 Hz and applied a mentioned
sleep mode (0x14) to save some power
Adds comments for the LCD commands ala type 0
Change-Id: I2d72df4d24b8bf9f3627bdb96ec9ce43ddd8b10a
Enable HAVE_LCD_FLIP for the Clip Zip and implement lcd_set_flip()
in the LCD driver, making the Display -> Flip Display setting work.
This lets the player be used upside down, e.g. clipped to clothing
with the control buttons pointing up and screen on the bottom.
Defining HAVE_LCD_FLIP also activates the existing button remap in
button_flip() (firmware/drivers/button.c) for this target: while the
display is flipped, LEFT/RIGHT, UP/DOWN and the volume keys are all
swapped to match the new orientation, so the whole device is usable
upside down, not just readable.
The flip is done in hardware by reversing the controller's GRAM write
direction and mirroring the write window in lcd_setup_rect, so partial
updates keep working and there is no per-frame cost. Both panel
variants are handled: the type 0 WiseChip/SEPS114A via MEMORY_WRITE/READ
(1Dh, 0x02), and the type 1 Visionox/LD7134 via the Graphic RAM Writing
Direction register (05h, 0x03). The direction register is written in
lcd_enable(), so it is set while the panel is powered and is re-applied
after display standby; lcd_set_flip() cycles the panel off and on so a
change to the setting takes effect immediately.
For the simulator, which has no real LCD controller, lcd_set_flip() is
implemented in the SDL LCD driver (lcd-bitmap.c) as a software mirror of
the framebuffer, so the flip is visible in theme previews; the generic
uisimulator stub is guarded out when HAVE_LCD_FLIP is defined.
Tested on real type 1 / LD7134 hardware in both orientations: display
content, button remapping and album art are all correct, and test_fps
shows partial updates run at full speed when flipped (1/4 frame 325 fps,
matching the non-flipped rate). The type 0 / SEPS114A path uses the same
approach; the 0x02 direction value was confirmed to flip a type 0 panel
by William Wilgus during review.
Change-Id: I99ef13949102b344826e72d1d90c71e2271448a6
display display type 0 / 1 in debug menu
update the comment on type 1 lcd I believe it to be a LDT LD7134 controller
the commands match up down to the gamma correction tables
Change-Id: Ic5d1d8db994a022a61db4a83a9f476cfafbcf51b
It is referenced by multiple threads, and as such needs to be both
volatile and SHAREDBSS to keep everyone happy.
...should address hangs on startup observed on nano2g and mini2g when
voiced menus are enabled
Regression introduced in dfa33c2 and made far worse by 759ef27
Change-Id: I202ec6c0d5825ff3a319b7d95d600b4ce06dd685
pcm_dma_set_freq expects the frequency index not the actual frequency
bug introduced in Commit dfa33c2 pcm: introduce pcm_sink
Change-Id: Idc521cfe1da22b112a16f81611dac720837eeea9
open the glyph cache in a separate function so we can
get the MAX_PATH alloc off the stack quickly and
deal with the fd instead
Change-Id: I0e991a1286b29c781e3f03b6a49e100c70809920
Always define storage_removable() and storage_present() so
that ifdefs are unnecessary. They were already defined as
constant for the CONFIG_STORAGE_MULTI case, but not in the
case of a single storage type.
Change-Id: I13073b3a72b201b5b11167deb050e6f27139c61c
