[realBytewav]

Hi,
Worth flagging up front: this patch was written with AI assistance (Claude), with me directing the work and reviewing the result. I'd rather you know than find out, and it should colour how you read the testing claims.

What I can stand behind:

• It runs on real hardware. Built and tested on my own TrimUI Brick (NextUI-20260719) — opens at 1024x768 on the mali driver, resolves SDL2 from the device's /usr/trimui/lib, audio initialises, all nine mappings attach, and the song / chain / phrase / instrument / table screens render and navigate. The video above is that device. The binary I tested is what this branch builds.
• TG5050 is genuinely untested. It compiles against NextUI's tg5050 toolchain and its platform definitions match the Smart Pro's, but I don't own the device and won't claim more than that.
• The warnings check was measured, not assumed. Built X64 from master and from this branch: 113 distinct warnings each, none added or removed.
• I'll handle review myself. If something here is wrong, or just not how you'd do it, tell me and I'll fix it properly rather than paste back another generated answer.

The button indices and resolutions aren't invented — they're read out of NextUI's own workspace/tg5040/platform/platform.h and tg5050/platform.h.

TrimUITracker.mp4

Covers the TrimUI Brick and Brick Pro (1024x768) and the Smart Pro (1280x720) as "tg5040", plus "tg5050" (1280x720). NextUI builds those two platforms from different toolchains and sysroots, so each needs its own binary, but the source is identical and both reuse the existing SDL2 adapter set unchanged - the same combination RG35XXPLUS already uses.

Button indices come from NextUI's own platform.h and are the same on both platforms: A is b1 and B is b0, crossed over relative to SDL's positional naming so that A lands on the button physically printed "A". The d-pad is a hat. SELECT and the menu button are left unmapped, the former because there is no /event/select and the latter because the firmware wants it.

SCREENMULT is 3, the largest whole scale that suits every panel involved: 960x720 centred on 1024x768, and exactly full height on 1280x720.

One change outside the new files: the SDL2 window takes the panel's full mode on these platforms. Left windowed_ true, SDL opens a 320x240*mult window - 960x720 on a 1024x768 device - instead of letting appAnchorX_/Y_ centre the grid in the real screen.

DEVKIT follows the /opt convention of the MIYOO, BITTBOY and RG35XXPLUS targets, and is ?= so it can be overridden from the environment.

Tested on a TrimUI Brick running NextUI-20260719: builds clean, resolves SDL2 from the device's /usr/trimui/lib, opens at 1024x768 on the mali driver, and all nine mappings attach. tg5050 is built but untested - I do not have the hardware.

Description

Thank you for contributing to Little Piggy Tracker!
For fixes, please include a summary of the changes and any related issue.
For features, please include a detailed description of the new feature and how it works.

All PR:s are run through line-by-line clang-format and builds for all supported platforms.
clang-format can be applied locally on commit by installing pre-commit from repo root:
cp pre-commit .git/hooks/

In section below, delete any option that isn't relevant.

Type of change

• Running on TrimUI Brick

How Has This Been Tested?

Please describe the tests procedure by which you verified your changes.
Provide instructions on how to reproduce.

Test Configuration:

• Hardware: TrimUI Brick
• Test steps: Opened and played a demo song

Checklist:

• I have performed a self-review of my code
• I have commented particularly in hard-to-understand areas
• I have updated CHANGELOG
• I have updated docs/wiki/What-is-LittlePiggyTracker.md reflecting my changes
• I have version bumped in sources/Application/Model/Project.h
• My changes generate no new warnings (build without your change then apply your change to check this)

[djdiskmachine]

Thank you for contributing to Little Piggy Tracker.

I currently have very little time for maintaining this fork, thank you for understanding.

From what I can tell, this device combination is compatible with portmaster that can install Piggy. Maintaining a device is continuous work, rarely a one-shot. What does this merge request contribute that can't be achieved using Portmaster?

[realBytewav]

ah I just didn't know it was listed on portmaster. Lets just close this