Recent Posts
11
Theming and Appearance Customization / Re: OneBit_OLED
« Last post by Frankenpod on June 17, 2025, 10:33:22 AM »PS. I wanted to make the accent colour customisable using the foreground colour but because this theme messes a lot with colours, it is actually infeasible. Real bummer.
Yeah, I tried doing things like
%?if(%ss(0,1,%St(background color),number),>,9)<%Vf(000000)|%Vf(ffffff)>%Vb(-)
i.e. querying the background colour and setting other colours based on that
But never really got it to work as expected, beyond, as above, getting a general idea of if it was a light or dark shade and setting foreground colour white or black accordingly. Couldn't work out how to get the chosen colour as a number, that one could then manipulate to produce a different 'accent' colour.
12
Theming and Appearance Customization / OneBit_OLED
« Last post by gnomacor on June 16, 2025, 03:33:38 PM »Oh no, yet another modified OneBit theme? Hear me out, I swear it's not yet another recolouring.
This was in my back burner ever since the original OneBit came out. I was also looking to replicate the 80s/90s audio gear look on Rockbox, down to it being VFD. I appreciate the effort to make it look interesting, but IMHO this theme doesn't really nail the look. But that's not the point here.
What I did notice however is the SBS/menu theme. It had such a clean and organised look, with popping colours to accentuate some elements. I actually felt something. It strongly reminded me of 2000s/2010s MP3 interfaces, hence OLED. I swear I have seen something similar in an actual product but I can't seem to be able to identify them.
So this theme brings the visual of the SBS to the WPS, which is quite interesting if I might say. I wanted it to look as "stock" as possible, as if it could have been in a real product. The result is a text-centric theme with emphasis on colouring. Player informations are all converted into icons. Shuffle and Repeat indicators share space, as some mp3 players did. The theme has otherwise received some quality of life upgrades such as better fallback for music with missing tags (the original had none) and respecting 12/24hr preferences.
If you miss the loud VU meter of the OneBit theme, don't worry! I'm working on it, but it's not as simple as a bar tag. Hopefully I can bring more interesting stuff to the table soon.
PS. I wanted to make the accent colour customisable using the foreground colour but because this theme messes a lot with colours, it is actually infeasible. Real bummer.
This was in my back burner ever since the original OneBit came out. I was also looking to replicate the 80s/90s audio gear look on Rockbox, down to it being VFD. I appreciate the effort to make it look interesting, but IMHO this theme doesn't really nail the look. But that's not the point here.
What I did notice however is the SBS/menu theme. It had such a clean and organised look, with popping colours to accentuate some elements. I actually felt something. It strongly reminded me of 2000s/2010s MP3 interfaces, hence OLED. I swear I have seen something similar in an actual product but I can't seem to be able to identify them.
So this theme brings the visual of the SBS to the WPS, which is quite interesting if I might say. I wanted it to look as "stock" as possible, as if it could have been in a real product. The result is a text-centric theme with emphasis on colouring. Player informations are all converted into icons. Shuffle and Repeat indicators share space, as some mp3 players did. The theme has otherwise received some quality of life upgrades such as better fallback for music with missing tags (the original had none) and respecting 12/24hr preferences.
If you miss the loud VU meter of the OneBit theme, don't worry! I'm working on it, but it's not as simple as a bar tag. Hopefully I can bring more interesting stuff to the table soon.
PS. I wanted to make the accent colour customisable using the foreground colour but because this theme messes a lot with colours, it is actually infeasible. Real bummer.
13
Hardware / Re: HiBy R1
« Last post by 7o9 on June 16, 2025, 11:24:03 AM »Yes, through adb.
You can turn on adb in the boot menu and then connect over usb to play around.
It does not matter if you run Rockbox or the HiBy player after that.
You can turn on adb in the boot menu and then connect over usb to play around.
It does not matter if you run Rockbox or the HiBy player after that.
14
Rockbox General Discussion / Re: Rockbox on HiFi Walker H2
« Last post by dconrad on June 16, 2025, 07:14:30 AM »I am still failing and need help with another issue. I have tried again and again to follow installations instructions. When I boot into native firmware, called Eros, and try to run firmware update I get the error, "update failed. not found update file".
Any more suggestions, please?
Is the update file on the root of the card, and named "update.upt"? The file being named something else is usually the culprit.
15
Rockbox General Discussion / Re: Rockbox on HiFi Walker H2
« Last post by psyscott on June 16, 2025, 01:40:33 AM »I am still failing and need help with another issue. I have tried again and again to follow installations instructions. When I boot into native firmware, called Eros, and try to run firmware update I get the error, "update failed. not found update file".
Any more suggestions, please?
Any more suggestions, please?
16
Hardware / Re: HiBy R1
« Last post by Milardo on June 16, 2025, 12:52:50 AM »In firmware/export/config/hibyr1.h I have set HAVE_DUMMY_CODEC.
If you enable HAVE_HIBY_R1_LINUX_CODEC instead, you would have to implement firmware/drivers/audio/hibylinux_codec.c.
However, ALSA shows no devices when you run ‘amixer’ or ‘amixer contents’ like described here for the AGPtEK Rocker device: https://www.rockbox.org/wiki/AgptekRocker.html
This part seems to be different in this ‘X1600E’ generation of HibyOS.
OK.
How do you access R1 to check "amixer", etc.?
Is it through adb?
If so, how do you get R1 to be recognized by adb?
I noticed that there is an option to start adb through your rockbox bootloader.
Is that the correct way to get R1 to be recognized by adb?
It does come up as an Ingenic device and there is to something related to alsa in: " /dev/snd "
Not sure I'm doing that right though.
17
New Ports / Re: TempoTec V3
« Last post by vitt13 on June 15, 2025, 03:11:07 PM »But I understand that it is relatively simple, also because I imagine that the sequence of steps to get to the porting is something like:I think those will be last steps.
I'm not good in programming but I watched for developing FiiO M3K native port steps because I own this DAP.
amachronic done a lot of work to allow use the general code in future X1000/E based ports.
* it needs to port bootloader
* it needs to know about key mapping, LCD driver and GPIO. There is guide howto find out that from RE kernel image https://forums.rockbox.org/index.php/topic,53896.0.html (it starts here https://forums.rockbox.org/index.php/topic,53601.msg248763.html#msg248763 )
My guess about useful *.ko from V3 Blaze fw was just guess to simplify this step of RE kernel image. And may be irrelevant if hardware is different in real.
V3-A has not enough hardware keys to control Rockbox without touchscreen so it will be hard to do everything touch-controlled.
Even Surfans F28 hosted port has struggled with touchscreen use
(Audio works but is quite distorted, rotary wheel isn't working yet, very crude keymap, touchscreen hooked up but not being utilized, no plugins enabled, etc etc etc..)
The rotary wheel now works, audio quality (and volume control) fixed. Given that I have no desire to use a touchscreen-based player like the F28 myself, I don't have the patience to rework the very crude global keymap to incorporate the touch screen, implement keymaps for the bajillion plugins, and tweak the default theme to be less ... BIG.
And what about hosted port there is the answer
All of the non-Android Hiby devices (and many more from other manufacturers) are built on the same underlying software framework ("hibyos"), with the messy details nearly entirely handled by custom, per-device kernel drivers and existing platform daemons+scripts.
Rockbox has already been ported to multiple hibyos devices. To port it to another one just needs to handle:
* Display properties
* Button layout
* Audio output switcher and mixer names
* Power management properties (battery and charging device names, plus discharge curves)
The information in the list you provide would be enough for a hosted port?
The AGPTek Rocker was the first port to hibyos, and the X3II, X20, and hosted ErosQ/K ports were relatively minor tweaks from there.
You only need to build enough to get the "bootloader" (ie a glorified boot menu) to build, for this you need to have the basic display stuff (eg dimensions, resolution) and how to map the various buttons (ie /dev/input*) into something useful. Next you'll need to figure out power management and how to talk to the audio hardware, and from there you should be able to do a plugin-less build. Getting the plugins building will require creating keymaps for many (if not most) of them. It's still a bit of work, but far, far less than a native port would be.I am sure I can provide most of that for the R1 based on disassembly of the firmware/driver .ko’s. All drivers are provided as modules and decompile very well.
To create a new native port, you need to effectively reverse-engineer the hardware schematic to figure out how things are connected. Disassembly of the original firmware can help with that, and of course it should hopefully be able to tell you how to talk to some of the custom hardware. FWIW it's possible (if not likely) that the FPGA stuff is handled by the bootloader before Linux ever starts.
( See https://www.rockbox.org/wiki/NewPort )
18
Feature Ideas / Re: Default location of Recent Bookmarks item in Main Menu
« Last post by chris_s on June 15, 2025, 11:37:49 AM »Setting aside the question of how items should be arranged by default, the order can also be changed from the GUI, not just using a .cfg file:
https://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buildch5.html#x10-990005.7.6
https://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buildch5.html#x10-990005.7.6
19
Audio Playback, Database and Playlists / Re: How to disable new "Prevent sleep timer from shutting down when charging" ?
« Last post by chris_s on June 15, 2025, 11:27:29 AM »How can I disable the new default "setting" "2025-03-14: Prevent sleep timer from shutting down when charging" in v4.0?
I'd like the sleep timer to actually act like a sleep timer, not a "save my battery timer" or what the new default aims to address, i.e., shutting down after the set time no matter is the device is charging or not.
Is the some setting that can revert the behavior to the old default setting?
There isn't a setting for this. Targets that used USB charging already weren't able to be turned off while charging, so this at least makes all players behave the same. It also matches the behavior of the idle timer, which only considers a player idle if it is not connected to a charger. Kind of makes sense to me that the two mechanisms would work the same. In theory the change could easily be reverted, except it was specifically adjusted at the request of someone else. Personally, I don't have a preference either way (nor a player that would be affected by this).
There seems to be another change to the behavior of the sleep timer: When playback is paused, with v3.15 the device would shut down after sleep timer's time i up. With v4.0 it shuts down after idle power of time is up. I personally like the previous behavior better. Pausing playback isn't really the same as being idle. Stopping playback would be.Rockbox considered the player to be idle when it is stopped or paused, even before this change (https://download.rockbox.org/daily/manual/rockbox-ipodvideo/rockbox-buildch8.html#x13-1760008.7.3). Arguably it was inconsistent that a running sleep timer unnecessarily kept the player awake when the idle timer had run out. Do you have a specific use case in mind that conflicts with the new behavior?
20
Rockbox General Discussion / Re: iPod Nano 3generation
« Last post by speachy on June 15, 2025, 10:52:45 AM »*Writing* code is the easy part.
The (much, much) harder part is figuring out *what* code needs to be written.
This is a high-level overview of the necessary steps: https://www.rockbox.org/wiki/NewPort
Beyond that, look at https://www.rockbox.org/wiki/PortingHowTo. The existing source code for the Nano2G port will give you an idea roughly how much work is involved. And keep in mind that all of the hardware-specific information needed to write that code was obtained via reverse-engineering, a notoriously time-intensive task even for those fairly skilled in the field.
The (much, much) harder part is figuring out *what* code needs to be written.
This is a high-level overview of the necessary steps: https://www.rockbox.org/wiki/NewPort
Beyond that, look at https://www.rockbox.org/wiki/PortingHowTo. The existing source code for the Nano2G port will give you an idea roughly how much work is involved. And keep in mind that all of the hardware-specific information needed to write that code was obtained via reverse-engineering, a notoriously time-intensive task even for those fairly skilled in the field.