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.
