- build
- directory structure
- bootloader UI and assets copied from delizia
- FirmwareUI trait functions are empty
- Python layout functions are copied from delizia except some of more
complicated ones which raise NotImplemented for now
By zeroing the stack memory before the workflow runs,
we can estimate how much of it has been used (by reading
the stack memory and looking for the first non-zero value).
[no changelog]
This side-steps a double-import problem that is triggered when we
perform an unimport in a particularly unfortunate order. (don't ask)
The root cause of the problem still exists: we can get into a situation
where a live recovery_homescreen is running from an unimported module,
meaning that any new import of anything from the recovery_device
namespace will _also_ be a double-import. We don't have a fix for that
situation yet, so instead we avoid this particular local import, which
would cause homescreen_dialog to have its own copy of the `recover`
module.
In case the main workflow is restarting after a `DebugLinkDecision`,
sending the response of `DebugLinkGetState` may get interrupted.
We are making the state fetching explicit, in order to avoid the
"restart" race condition (as described in #4401).
Following the above change, text-based layout recording is removed.
[no changelog]
- application layer should not deal with fonts at all
- distinction between MONO and others is preserved by bool argument in
`should_show_more` interpreted as `is_data`
[no changelog]
- seems that keyboard LayoutObj was not properly deallocated resulting
in MemoryError. Fix by calling the dunder `del` method explicitly fixes
the issue
- the problem was on Model T (Bolt), but applying it for all layouts to
prevent similar problem
- follow-up on 862c987779
- layout_bolt stays the same
- layout_samson -> layout_caesar
- layout_quicksilver -> layout_delizia
- use super for importing rust modules in layout code
[no changelog]
- UI layouts name changes:
- model_tt -> layout_bolt
- model_tr -> layout_samson
- model_mercury -> layout_quicksilver
- rust features `model_xyz` freed for different use, now it's
`layout_xyz`
- input_flow function names are based on UI layout and not internal
model name (i.e. quicksilver instead of t3t1)
- directory names and commentary changed accordingly
[no changelog]
For reasons unknown, a previous homescreen layout can sometimes survive
a GC cycle in main's unimport loop. Two homescreen layouts can't exist
simultaneously, so creating a new one would fail.
It _seems_ that after restarting the session, the homescreen object
still exists but is not reachable anymore, so a second GC cycle properly
disposes of it.
So what we do is simply catch the possible MemoryError, invoke GC
explicitly, and try again.
