startFrame()'s default background became UIColor::window_bkg in the 1.17
core, and boards whose DISPLAY_CLASS is a core driver link upstream's
palette — window_bkg=WHITE, primary_txt=BLACK. The boot splash grew a
white frame around the logo, and the radio-halt text would have drawn
black-on-black. Boot splash, halt screen, REMOTE placeholder and the
shutdown screen now pass explicit black/white/red instead of palette
entries whose values depend on which display driver got linked.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The core moved to 1.17 (core-v1.17.0 pin) but the About string on dev
flashes still said v1.16.0-touch — release builds override it via
release.sh, only the #ifndef default was stale.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
All 8 S3 envs rebuilt green against the GitHub tag; the tag's tree is the
PR #46 merge commit (609c903) minus prebuilt/ — identical content to the
local test pin the branch was validated on.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
TanmatsuDisplay.h / RM69A10Display.h / HI8561Display.h still had the 1.16
Color signatures (missed in the first sweep); pagers additionally hand the
core lib scope the TFT_eSPI include path (target.h -> ST7796LCDDisplay.h).
All 8 S3 envs + the Tanmatsu now build green on the 1.17 test pin.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- UIColor migration: DisplayDriver::Color enum -> ColorVal/UIColor statics in the
6 driver headers + 3 driver .cpps + all main.cpp/UITask.cpp call sites.
- ONE palette definition: src/helpers/ui/UIColorPalette.cpp. Envs whose
DISPLAY_CLASS is a core driver (v4_tft, attaky, tdeck, M9) take the palette
the core driver .o carries; envs on our drivers (r8, rak via src_filter;
pagers via helpers/ui glob; both IDF apps via the whole-archive src glob)
compile ours. Never both — same-name core objects collide (core LGFXDisplay).
- 1.17 ESP32Board.cpp includes <target.h>: hand the core lib scope the libdeps
include paths it can't chain to (MicroNMEA everywhere, SensorLib on pagers).
- CustomLR1121Wrapper: setRxBoostedGainMode void->bool (1.17 base).
- IDF: fetch-deps.sh gains durable vendor-time patches (ESP32Board minimal
deep-sleep — no target.h on IDF; SerialBLEInterface esp-nimble-cpp 2.x port
incl. esp_mac.h). helpers/ethernet/ excluded in both meshcore CMakeLists.
- platformio.ini pins point at a LOCAL test tag (mc117-clean#core-v1.17.0-test);
swap to the real core-v1.17.0 before merging to main.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Audited every non-ASCII codepoint in the v9 Hungarian file against the
extras-font ranges: full coverage (incl. Hungarian ő/ű, Latin Extended-A)
except a single „ low opening quote used once — swapped for the covered “
rather than regenerating three fonts for one glyph. Add U+201E to the
extras --symbols on the next font regen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
hu.lang: 43 improved translations + 21 newly covered strings from pisti87,
applied as ver 9; builtin table regenerated.
Lang store (#247): the update check treated ANY version difference as
'update available' — a side-loaded NEWER file than the catalog got
DOWNGRADED on Update. Now numeric: offer only when the catalog is newer
(non-numeric versions keep the old inequality).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The DISCOVER_RESP wire format carries no position, so distance is shown when
the node is also a contact with a known advert position AND we have a GPS
fix — formatted with the existing km/miles badge. Rows without both fixes
are unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ø/Ø and å/Å were already in the o/a accent sets; æ was the missing third.
Long-press a/A now offers it.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
#185: file rows in the Files app now append the modified time (dd Mon HH:MM)
when the filesystem provides a sane one (FAT 1980-epoch / clockless writes
are omitted rather than shown as garbage).
#178: the core's overwrite-oldest eviction already skips contacts with flags
bit 0 set — but the device-side favorite star lived only in TouchPrefs,
invisible to the core, so a starred contact was still evictable when the
table filled. The star toggle now mirrors into the contact table's flags
(uiSetContactFavorite), and a one-shot boot sync stamps the flag for
contacts starred before this fix.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The doc claimed the HI8561 TFT's backlight is panel-internal (DCS 0x51 only);
in reality it's a real LED on GPIO 51 driven by LEDC PWM, which the code has
done since ~beta_53. Stale doc line flagged by bmorcelli.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A dead or absent LoRa module halted boot behind the frozen logo with the only
clue on serial. Retry init once (transient SPI/reset flakes), then paint the
failure on the panel — 'LoRa radio not detected / wadamesh needs the LoRa
module' — before halting, so users aren't left staring at the wordmark.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The composer's send button calls composerSend() and then refreshes the open
detail itself. The two programmatic resend paths (long-press menu Resend and
the failed-bubble one-tap retry) called composerSend() without the refresh,
so the new bubble only appeared once something else redrew the thread.
Mirror the send button: refresh the open dm/ch detail + dirty the thread
list after a successful resend.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Boot-time normalize/repair setters re-put unchanged values every boot; each
one dirtied the shared file cache and bought a full touch.kv A/B snapshot.
On the Pager's internal SPIFFS that is a 0.7-1.5 s flash burst that stalls
both cores (flash-cache suspend -> the reported ui:lvgl/ui:gps stalls) and
widens the interrupted-write window that can drop a user's saved change.
Same-value puts now return success without dirtying, in both the file-mode
and legacy paths. The storage:SPIFFS-despite-SD half of #246 (profile
demotion on upgrade) was fixed separately by #206's 4778347.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Track Pager Wi-Fi/BLE ownership explicitly instead of treating Wi-Fi intent as an active association. Allow BLE with Wi-Fi off or unconfigured, and restore it after a bounded failed association while pausing automatic retry churn until Wi-Fi is explicitly retried.
Signed-off-by: Pixel Perfect <me@pixp.cc>
NimBLEDevice::deinit(true) deletes the NimBLEServer, and ~NimBLEServer()
runs:
if (m_deleteCallbacks && m_pServerCallbacks != &defaultCallbacks)
delete m_pServerCallbacks;
SerialBLEInterface::begin() registers itself with pServer->setCallbacks(this)
and that overload's deleteCallbacks parameter defaults to true. Our
SerialBLEInterface is the by-value member _ble, sitting after _usb/_tcp/_ws
inside MultiTransportCompanionInterface, and main.cpp placement-news that
whole object into one heap_caps_malloc block. So the delete above calls
operator delete on a pointer into the middle of a live allocation:
"CORRUPT HEAP: Bad head at 0x..." and a panic reboot.
origin/main only ever reached deinit(true) from prepareForHttpOta, and
disableBle carried an explicit "we deliberately do NOT NimBLEDevice::deinit()
here" note. This branch removed that note and added deinit(true) to
disableBle() and suspendBleForWifiReconnect(), which puts the crash on the
everyday Bluetooth-off toggle, on every Wi-Fi credential apply, and on the
10 s link-loss retry -- so an AP going down while Bluetooth is on panics the
device.
Detach the callbacks first at all three sites. setCallbacks(nullptr) installs
NimBLE's static defaultCallbacks sentinel, which the destructor explicitly
skips. NimBLECharacteristic never deletes its callbacks, so the rx/tx
setCallbacks(this) registrations need no equivalent.
Also drop an unreachable return in wifiEnableGate(): the Pager branch returns
unconditionally, so the shared LowMemory tail below it was dead on that board.
Signed-off-by: Pixel Perfect <me@pixp.cc>
The two status surfaces read wifiConfigGetBleEnabled() directly, so a
non-Pager board whose stack was never begun showed "Starting..." /
"Mode: BLE starting / low memory" forever -- nothing outside the Pager
retries a saved-but-not-resident preference. Route them through
bleRequestedOrEnabled() so the Pager keeps its pending wording and every
other board reports the truth: off, and one tap away from on.
Both sites are in the else of an isBleEnabled() test, so on non-Pager the
helper is already false there and this reduces to "Off" with no other
behavior change.
Signed-off-by: Pixel Perfect <me@pixp.cc>
Swapping beginBle() for enableBle() at boot introduced a refusal branch
that only logs. The association-timeout branch beside it sets
s_pager_ble_after_wifi, so the two exits left different state for the
retry sites to read. The GOT_IP handler's ble_waiting also ORs
(wifiConfigGetBleEnabled() && !isBleStackBegun()) and so happened to
cover the want_wifi case, but relying on that made the marker's meaning
inconsistent.
Set it in both branches. The residual gap is unchanged and inherent: with
want_wifi false there is no association to retry after, so a BLE-only
boot that loses the heap guard stays deferred until the user toggles
Bluetooth, which takes UITask::enableBle()'s ordered-restart path.
Signed-off-by: Pixel Perfect <me@pixp.cc>
bleRequestedOrEnabled() was guarded on ESP32 && MULTI_TRANSPORT_COMPANION,
so it folded wifiConfigGetBleEnabled() into "BLE is on" for T-Deck, M9,
V4-R8, Heltec V4 and RAK as well. Only the Pager has pending-request
machinery: UITask::enableBle() records intent under #if TLORA_PAGER, and
only main.cpp retries after association. Elsewhere that flag is a plain
persisted preference that DEFAULTS TO ON and can sit true with no stack
begun -- the boot co-init heap guard takes exactly that path.
A T-Deck that deferred BLE at boot therefore showed the control-center
tile ON with the stack dead, and the first tap called disableBle(),
clearing the saved preference instead of starting BLE. The status
indicators were untouched and still read isBleEnabled(), so the toggles
disagreed with the "Starting..." label right next to them.
Narrow the helper and the switch-revert branch to TLORA_PAGER, and build
the Bluetooth switch's initial state from the same helper the callback
compares against so its want == requested early-out cannot swallow a tap.
Signed-off-by: Pixel Perfect <me@pixp.cc>
The quiescence gate I added keyed the "don't paint from a stale backend"
early return on may_swap alone, so mapNoteStorageChanged() dropped every
decoded tile and then returned without repainting whenever ANY tile fetch
was in flight -- including the common case where no backend swap was needed
or deferred at all.
A wedge-recovery remount or a reinsert while already on the card takes
neither branch, so the backend is correct and the map should repaint
immediately. Instead it went blank until the next unrelated pan/zoom/tab
change, and neither sdHealthTick retry covers that case: both require a
pending swap (s_tile_fs == &SD with the card gone, or s_tile_fs != &SD with
it present), so neither fires when nothing needed swapping.
Compute what the swap would actually change and skip the repaint only when
that change was wanted and had to wait.
Signed-off-by: Pixel Perfect <me@pixp.cc>
The quiescence gate drops the decoded tiles and clears the dedup ring
unconditionally, which is right, but it also fell through to
renderMapTiles() with s_tile_fs still pointing at the old backend. On the
teardown side that means probing &SD for a card that is gone -- up to five
opens per tile, each paying a full sd_diskio timeout, on the loop task.
Return after the invalidation when the swap could not be applied.
sdHealthTick renders as soon as it lands it.
Signed-off-by: Pixel Perfect <me@pixp.cc>
The CAP_SD branch no longer references s_map_style or s_tiles_from_sd, so
the OSM-vs-topo explanation above it described a guard that is not there.
Describe what the two branches actually do.
Signed-off-by: Pixel Perfect <me@pixp.cc>
The deferred reinsert swap runs before the Pager removal handler, and
s_sd_mounted stays true until that handler wins quiescence. A card yanked
while the swap was still pending therefore got promoted to s_tile_fs =
&SD, costing a full freeMapTiles() + renderMapTiles() on the loop task,
before the same tick unmounted it and re-rendered again.
Harmless in outcome -- the read path short-circuits on the
s_sd_fail_note_ms that card-detect stamps -- but two wasted map passes on
the UI thread per removal.
Signed-off-by: Pixel Perfect <me@pixp.cc>
The unconditional tileCacheRemove() on a bad JPEG header only covers the
generic cache path, which the microSD branch never reaches in the mode
this PR is about: with SD tiles on and OSM selected, /tiles/<z>/<x>/<y>.jpg
is read by the SD branch, returned as-is, and then fails in
decodeJpegScaledToRgb565(). That path only does ++n_missing, so unlike a
load miss it does not queue a re-fetch either -- a half-written tile sat
there until a manual "Reload visible tiles".
Apply the same 3-byte SOI check to that leg only. /maps/osm packs and PNG
packs dropped into /tiles keep their read-only contract: they cannot be
re-downloaded, so they are never removed.
Signed-off-by: Pixel Perfect <me@pixp.cc>
loadTileJpeg() and tileExistsAt() both qualify the microSD branch with
s_map_style == 0 because SD packs are OSM-only, but the status label and
mapTileSourceReady() did not. With microSD tiles on and topo selected the
empty-map notice told the user to install /maps/osm/z/x/y.png and
suppressed the "Downloading map tiles... ok/fail/http" diagnostics, while
the code was in fact fetching topo tiles into /tiles/topo on the card.
Pre-existing on T-Deck; the persistent Pager source toggle newly exposes
it there.
Signed-off-by: Pixel Perfect <me@pixp.cc>
fmSdDoFormat() armed the deferred f_mkfs with no quiescence check, so a
confirm tap while the tile worker held an open File (the whole of a
download, up to the 12 s cap) ran SD.end() + sdcard_init + f_mkfs
underneath it. The worker's next f.write()/f.close() then acted on a
de-registered pdrv and a freshly rewritten volume. The format-failure
path already comments that a worker File may be open; by then it had
been invalid for tens of seconds.
Gate the confirm on sdRuntimeLifecycleBusy() (the same predicate the
Pager factory reset uses) and re-check on the tick before f_mkfs fires,
since the two ticks that let the notice paint are also two ticks in which
a map repaint can queue fetches. Bounded at 15 s so a stuck consumer
cancels the format instead of hanging behind the "do not power off"
notice.
Also stop arming the countdown on M9 / V4-R8. Those builds offer the
format button but carry no executor for it (the deferred f_mkfs block is
HAS_TDECK_GT911-only), so a single tap left s_sd_format_pending set for
the rest of the boot and sdHealthTick returned early at its
s_sd_format_pending guard forever after — silently disabling wedge
detection, remount and the SD tile-backend swap.
Signed-off-by: Pixel Perfect <me@pixp.cc>
mapNoteStorageChanged() guarded only the adopt direction. The teardown
direction repointed s_tile_fs away from &SD with no check at all, even
though that is the side that strands an open SD File: the worker holds
one for the whole of a download (up to the 12 s cap) and dereferences
the global backend for every filesystem operation of the request.
Every current caller happens to gate, but the format-failure path checks
only tileFetchPendingLoad() and the format-success path checks nothing,
so the invariant was one caller away from being violated.
The adopt branch's early return was also too broad. It skipped the dedup
clear, freeMapTiles() and the re-render that are the whole point of the
call, so swapping cards while a fetch was in flight left the previous
card's tiles on screen with the dedup ring suppressing the re-fetch until
sdHealthTick's retry landed.
Compute may_swap once, apply it to both branches, and always fall through
to the invalidation.
Signed-off-by: Pixel Perfect <me@pixp.cc>
