Clicking a file that holds a picture - EF_DG2, EF_DG7 - showed nothing at
all: no image, no hex dump, and no error either.
Both panes drew their text into a single Kivy Label, and a Label is one
OpenGL texture, capped at commonly 16384px. A monospace line here is 13px,
so past roughly 1260 lines the texture fails to be created and the pane
draws nothing. A DG2 portrait is 15-25kB, which is 940-1560 dump lines at
16 bytes a row and four times that in a narrow pane, where the dump falls
back to 4 bytes a row. The LOG pane holds 4000 lines, so it blanked as
well once a dump got talkative. The 64kB cap already in the hex view
guarded the wrong bound: it was sized for how long a Label takes to lay
out, not for what the GPU will hold.
Split both over several Labels. split_blocks() chunks at 512 rows, and the
log at 256 because its lines wrap and so cover more rows than they hold.
The log reuses its Labels and only assigns the ones whose text changed, so
streaming output still re-renders just the tail.
The FILES tab now also shows the picture above the dump for the files that
carry one, which is what you actually want to see for a DG2. The PNG is
already decoded at load time for the data page, so image_for() only hands
over what is there.
Behaviour change: a file carrying an image shows it above the hex dump,
with the dump still underneath. Nothing is truncated that was not before.
Testing: 270 passed, 2 skipped (was 265). Checked on screen against a
generated sample - EF_DG2 shows the portrait, EF_DG7 the signature, EF_SOD
the dump at full height, and the LOG tab renders a full 4000-line buffer
as 16 Labels, tallest texture 3328px against the 16384px maximum. black
clean. Python only, so no client or firmware build matrix applies.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Updated the UART4 driver to use circular DMA for RX, improving performance at higher baud rates. Removed the RX interrupt handler and adjusted the RX head calculation.
Signed-off-by: Niel Nielsen <nieldk@gmail.com>
Internal Card-API code restarts the SSP clock before every RF APDU, resetting it to zero. ISO14443A retains NextTransferTime as an absolute timestamp from the prior clock instance, so each next transmit waits for stale time.
The app died with SIGSEGV before drawing anything, on every entry point
including --help.
The window minimum size was pre-seeded into Kivy's Config, and
WindowBase.__init__ is the only place Kivy reads it - so it was applied from
inside WindowSDL.create_window(), while Window.initialized was still False.
If the window SDL has just made is smaller than that minimum, SDL resizes it
on the spot; the resize comes back through the SDL event filter into
EventLoop.idle(), which runs the clock and re-enters create_window(). Still
not initialised, that call runs setup_window() again and resizes again, until
the C stack gives out.
A scaled HiDPI session is enough to reach it: with sdl2-compat on SDL3 under
Wayland sizes come back in logical points, so the inherited 800x600 default
arrives as a 500x375 window, under the 760x520 minimum. Set the minimum on
Window once it exists instead, where the same resize takes Kivy's cheap
already-initialised path.
That exposed a second fault on the same path. _install_kivy_logging attached a
bare StreamHandler() to Kivy's own logger, and kivy.logger replaces sys.stderr
with a stream that feeds whatever is written to it back in as a warning -
kivy/logger.py cautions about exactly this. Any warning _KivyNoise did not
drop answered itself until the recursion limit stopped it, with stderr as the
broken part, so nothing legible came out. Not theoretical: this machine logs
"MTD: Unable to open device" at startup, which would have killed the app as
soon as the segfault was out of the way. Point the handler at the real stderr,
which Kivy leaves alone.
Behaviour change: a window that opens smaller than 760x520 is now grown to it,
rather than the constraint being imposed while the window is built.
Testing: 257 passed, 2 skipped (was 254/2); --help, a plain launch, --dump on
a generated sample and -v all start and stay up; black clean. Python-only
change, so no client or firmware build matrix applies.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PM3_CMD_DATA_SIZE went 512 -> 624 without a capabilities bump, so a new
client connects to old firmware and every oversized command dies at the
device's length check with no message.
Append max_cmd_data_size, bump to v9. The client now accepts an older
capabilities struct - it only ever grows by appending, so an older layout
is a prefix - and defaults the frame size for pre-v9 firmware.
SendCommandNG bounds by the device value instead of the compile time one.
Also zero init capabilities_t on the device, it leaked stack bytes.
Allocate EF_SOD parsing scratch buffers on the heap so macOS worker threads do not exceed their stack while reading protected travel documents.
Co-Authored-By: Codex <noreply@openai.com>
iceman1001