chore: bake QR scan glyph into device fonts - #58
Conversation
Drop 22 OpenMV image-processing source files (~50.5k lines) whose symbols are unreachable from Krux Python.
image_entropy_16b() copied the whole input frame into a scratch buffer sized for QVGA RGB565 (320*240*2 = 153600 bytes). A CIF frame, which the Maix Bit produced, is 352*288*2 = 202752 bytes and overflowed it by 49152 bytes. Drop the scratch copy and read the caller's buffer directly, which also frees 150KB of heap per call. Cap the read length at QVGA and round it down to whole 16 bit pixels so the i + 1 read stays in bounds on odd-length input. The cap also preserves the invariant that at most one pixel value can exceed a uint16_t count.
No Krux code ever called os.urandom(), and it plays no part in generating keys, mnemonics, or any other secret. Entropy for those comes from the camera or from dice rolls, and none of that is affected by this change. The function was backed by rng_get(), a Yasmarang PRNG with a hardcoded initial state, so it returned the same byte stream on every boot. Its name, and its comment claiming a hardware random number, made it look like a safe source, so a future contributor could reasonably have reached for it. Remove the binding so that cannot happen, and document rng_get() as deterministic. rng_get() itself stays, since mbedtls and lwIP need the symbol. The separate urandom module is unaffected.
Support for the device was discontinued in Krux 25.09.0 and it has no known users. Its CIF framesize was also the only path that triggered the shannon heap overflow.
Adds 选项 and 션옵, needed by the new Chinese and Korean translations of the grouped Wallet Options entry.
gcm_get_tag() drains 4 hardware registers into the caller's buffer and reads them back through a uint32_t* cast, but aes.h documents a 4 byte buffer. AES_run() followed the header, so every GCM encrypt and decrypt wrote 12 bytes past the end of a stack array. Widen the local to 16 bytes with 4 byte alignment, and copy using sizeof(self->gcm_tag) so the struct field stays 4 bytes. digest() and verify() return the same bytes as before, so existing KEF envelopes are unaffected. Document why mac_len stays pinned at 4, since the SDK header still claims a 4 byte tag buffer and the upper 12 tag bytes are unverified.
…flow fix: size GCM tag buffer to the 16 bytes the SDK writes
Adds the QR scan glyph at the private-use codepoint U+E000 to the wide font of every device profile, used by the keypad scan action in krux. Output of bdftokff.py from the krux tree. Co-authored-by: Naman Gupta <55298452+Naman015@users.noreply.github.com>
|
@qlrd this is the fix for the submodule pointer issue blocking CI on selfcustody/krux#811 — the glyph commit here is rebased onto |
Sure |
|
Noting that I'm just seeing this pr now. We will certainly get back to looking at this, with hopes that PRs will be merged to "develop" branch during normal development cycle and that "develop" will be merged into "master" upon releases. For now, I understand it as a new glyph available to all devices w/ versions for fonts 14, 16 and 24 pixels in height, font-height-24font-height-16font-height-14 |
|
Thanks for double-checking the glyph rendering — that's exactly it, U+E000 baked into all three heights (14/16/24px) for No urgency here beyond wanting CI unblocked on selfcustody/krux#811, which is still in draft. Happy to follow the normal develop→master cycle whenever you and qlrd have bandwidth to review. |
|
Please excuse me for not realizing an issue you mentioned (honestly, I didn't understand and didn't dig in) about this selfcustody/MaixPy repo NOT having this actual commit. Normally when I test locally at home, I'll pull the pr branch directly from the author, into my local MaixPy repo, so that the commit does exist for me locally. So that others are not forced to trial-and-error the same, I have cherry-picked this one commit (which adds 1 glyph shown above, and ALSO removes another (0x79c1 = "私"), into it's own branch named "v26.09.0_plus_qrglyph" in this selfcustody/MaixPy repo. Please let me know if it works. This PR itself can be re-targeted to the "develop" branch, which will be a more standard flow in the future: "Contributors point their feature branch to "develop", and just before release, "develop" will be merged into "master". |
Rebaked from krux's redesigned qr-u{14,16,24}.bdf per feedback
from odudex/qlrd on selfcustody/krux#811.
4 participants
What is this PR for?
Bakes the QR scan glyph into the wide font of every device profile, at the
private-use codepoint
U+E000.This is a dependency of selfcustody/krux#811,
which adds a QR scan action to Krux's text keypads. The glyph is the key label
for that action. Without it the key renders blank on device.
The direction was agreed in that PR's discussion: @odudex asked for the glyph to
live in the BDF sources and be baked into MaixPy rather than drawn at runtime.
What it changes
Regenerated
font_device.hfor the ten device projects:maixpy_amigo,maixpy_cube,maixpy_dock,maixpy_embed_fire,maixpy_m5stickv,maixpy_tzt,maixpy_wonder_k,maixpy_wonder_mv,maixpy_yahboom,maixpy_yahboom_devkit.The output comes from
bdftokff.pyin the Krux tree, from theqr-u14.bdf/qr-u16.bdf/qr-u24.bdfsources added in krux#811(8x14, 8x16 and 12x24 cells).
Only the
U+E000slot changes; no existing glyph is touched.Why it is separate
krux#811's submodule pointer currently references a commit that only exists
locally, which breaks
git submodule update --recursivefor reviewers and failsevery CI job at checkout. Merging this lets that PR point at a published commit.
The glyph design is @Naman015's, credited as coauthor on the commit.
Validation
Built and flashed on a TZT. Glyph renders on the keypad scan key at all three
font heights.