Copy resolution-matched logo and battery images in select_devices.sh

[ronyeh2]

Problem

select_devices.sh copies the DTB pair for the selected device but never touches logo.bmp, so the boot partition keeps the default 640x480 splash regardless of which device was chosen.

On a 720x720 panel (e.g. R36S Plus-V20 2025-03-18) U-Boot then draws 640-pixel-wide rows into a 720-pixel-wide framebuffer. Every row lands 80px offset from the one above, and the splash appears sheared/scrambled for the first few seconds of boot, until the kernel loads the DTB and reinitialises the display.

This is a parity gap, not a missing feature. select_device.ps1 already does the right thing — it reads the resolution key from r36_devices.ini and picks logo-640x480.bmp or logo-720x720.bmp. Only the shell selector is missing it, so Windows users get a correct splash while Mac/Linux users don't.

Changes

1. Copy resolution-matched boot logo — brings select_devices.sh to parity with select_device.ps1.

The filename is built from the resolution string (logo-${resolution}.bmp) rather than hardcoding the two currently-known sizes, so adding a new panel resolution needs only the asset plus the .ini entry — no code change.

2. Install resolution-matched battery images — a genuine gap in both selectors.

dtb/logo/ ships battery-640x480.zip and battery-720x270.zip, but neither script installs them, so the boot partition has no battery_*.bmp at all and U-Boot has nothing to draw for the charging / low-battery screens. Archive names don't always match the resolution exactly — the 720x270 archive actually contains 720x720 bitmaps — so this falls back to matching on width.

The two are split into separate commits in case you'd rather take only the parity fix.

Safety

Both blocks are purely additive and guard before acting:

• no resolution key for the device → leaves the boot images untouched
• no dtb/logo/ folder → skips
• no matching logo-<res>.bmp → leaves logo.bmp untouched
• no matching battery archive, or unzip unavailable → skips with a message

So no currently-working device can regress, including any that relies on the existing default.

Testing

Verified on real hardware — an R36S Plus-V20 2025-03-18 (batch 2551, 720x720) running dArkOSRE_R36_trixie_04262026.

Applying logo-720x720.bmp eliminated the scrambled boot splash entirely; the 720x720 battery set installed cleanly alongside it. Device identification was confirmed against /boot/darkosre_device.log, which reports Hardware string: 'R36S Plus-V20 2025-03-18' and Resolution from devices.ini: 720x720.

The added code was syntax-checked with bash -n.

Known follow-up (not addressed here)

select_devices.sh requires bash 4.2+ — it uses declare -A (line 44) and [[ -v arr[key] ]] (line 90). macOS ships bash 3.2, so the script can't run at all there:

select_devices.sh: line 44: declare: -A: invalid option
select_devices.sh: line 90: syntax error near `grouped_devices["$v"]'

The wiki points Mac users at this script, so in practice they currently have to place DTBs by hand. That's a larger rewrite and out of scope for this PR, but I'm happy to open a separate one if useful.

🤖 Generated with Claude Code

[ronyeh2]

Note: select_devices.sh currently can't run on macOS

Flagging this separately from the change above, since it affects who can actually benefit from it.

select_devices.sh requires bash 4.2+. It uses declare -A (line 44) for the INI parsing and [[ -v arr[key] ]] (line 90) for the variant grouping. macOS still ships bash 3.2 as /bin/bash, which supports neither, so the script aborts immediately:

select_devices.sh: line 44: declare: -A: invalid option
select_devices.sh: line 45: declare: -A: invalid option
select_devices.sh: line 59: HL-R36H-V20 2024-05-18: syntax error in expression (error token is "2024-05-18")
select_devices.sh: line 70: declare: -A: invalid option
select_devices.sh: line 75: conditional binary operator expected
select_devices.sh: line 75: syntax error near `grouped_devices["$v"]'

The wiki's Firmware Installation page directs Mac and Linux users to this script for DTB selection, so in practice Mac users have to identify their board and place the .dtb files by hand — which also means they never get the logo fix in this PR, since it lives in a script they can't execute.

Linux users are unaffected (bash 4+ is standard there), so the change above still helps them today.

Two possible fixes, depending on your preference:

1. Drop the bash 4 requirement — replace the associative arrays with parallel indexed arrays plus a lookup helper, and swap [[ -v arr[k] ]] for a plain string match. Keeps a single script working everywhere, including stock macOS.
2. Fail fast with guidance — detect BASH_VERSINFO[0] -lt 4 at startup and print a clear message pointing Mac users at brew install bash or the manual copy steps. Much smaller change, but doesn't actually fix it.

I'd lean toward option 1, since it makes the script genuinely cross-platform and removes the manual path from the wiki. Happy to open it as a separate PR if that's useful — kept out of this one deliberately, as it's a rewrite of the parsing rather than an addition, and I didn't want to bundle it with a small parity fix.

[igoutta]

This is not the place but I don't know where to address you @southoz, there is no way to open a issue for a K36 Panel 5 for R36S Clone R36S-V12 2023-08-18 I think Variant 3 idk is a weird one.

[Raccoon-F18]

@igoutta currently southoz is taking what seems to the community as an extended personal hiatus, we are unsure as too when he will return but it has been ~4 months since he last made any contact. In the meantime Darkos Enhanced maintained by djparent is designed as a project to bridge the gap for new devices and updates. The best place I have found to find this project is in the r/R36S subreddit.