The rationale is that xous-rs should have only architecture
specific code, e.g.: riscv, arm, x86, etc. To make other
crates that depend on it not specify the features.
This could be useful when using xous-rs with `libstd`
for example.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
So there's a bit of a nasty bug that arises from the GAM
both handling drawing primitives and context swaps.
In particular, because the GAM handles both of these in a
single thread, context swaps can't block, because the redraws
triggered by the context swap would be blocked, causing a deadlock.
When the API token for the predictor was introduced, this added
a blocking operation inside the context swap. This would cause
a deadlock under certain conditions.
This patch refactors the API token so that it's not a return
result of swapping the predictors. Instead, the predictors
return the API token as a non-blocking message to the GAM. This
API token is correlated with the *GAM* token (not the app token).
Present me thanks past me for adding the GAM token, which was
as of yet unused, but now, there is a very sensible role for it--
exactly what it was made for, e.g. handling GAM-local API calls
without disclosing the application token.
Anyways, hopefully this patch puts the race condition to
rest, while allowing us to have per-context prediction histories.
The prediction API now takes an API token. This is a 128-bit
number that gets passed to the prediction engine, and it's meant
to be unique for every context that requires a predictor.
It's up to the prediction engine to do anything with the token.
For the "null" engines (such as the icontray for `vault` and
`tts`) the token is just ignored. But for example, in `shellchat`,
the API token is used to store a history record in a HashMap on
a per-token basis. This means that every app that uses the
`shellchat` history function gets their own history that can only
be read out by that app.
The actual token itself is mostly passed through the API. The
token storage is in the Context layer (each Context has a record
for a token, that starts as `None`), and is passed down to
the predictor every time the context swaps, and the predictor
receives the token and passes it back if the token was `Some`,
or allocates a new random token if it was `None`.
Note that everything is a Context, including, for example, menus and
modal dialog boxes, but not all contexts have predictors. Only
Contexts that ask for a predictor have them. This mechanism
works smoothly in this model (as opposed to other hacks and work-arounds
previously tried getting to this solution).
in "menu mode" the predictive area functions as four menu
option keys instead of dynamic prediction updates.
this patch is mostly working but we need to figure out how to
force a redraw of the predction area when the app is raised,
because we get a stale image from the previous app on context
switch.
This macro will be removed, since it is no longer necessary. Remove this
macro across the project and replace it with a standard `main()`
function.
Signed-off-by: Sean Cross <sean@xobs.io>
