Keyboard setting is "the one and only" exception to user settings
that are saved without encryption. This is because you need your
keyboard layout to be set in order for you to type your password.
Thus, this needed a bit of a special-case to handle its storage record.
We decided to lop off 1 page from the loader and have it store
the keyboard layout code.
Let's hope we can have the discipline to really just store that
one word of information and not later be like "gee wally, you have
a whoooole 4092 unused bytes of space we can cram unencrypted
user settings in, sure would be a waste to not put those use those".
Was doing disjoint loads and stores on an Atomic, really, should
be using the fetch_add, fetch_sub variants to be proper.
Didn't seem to impact anything but maybe there's a future version
of me that high fives me for doing this.
request_focus is "dangerous" because any random server could
request a UX context to pop up. There is a checked version
that requires a GAM token that should be used, but, this leaves
the question of how does the initial app that's supposed to be
focused gets set.
A small mod to the UxRegistration call is made to check for
the name of the default focus app, and when it is seen, a thread
is fired off to request focus for that app. That allows us
to deprecate this otherwise dangerous call.
trust levels now default to a mid-level, with the password
modals explicitly tested for by the Context logic (the idea
being to deny any untrusted canvases the ability to render
inverted text).
ball bounce app also basically works, and context
switching between the bounce app and the main menu
is working too.
The first "app" is just going to be a whole-framebuffer
demo that gets raw keys and does some stuff on the screen.
It's the starting point if you wanted to eg. write a simple
video game or something for the device, but you didn't care
about much of the other UX sugar.
Each Cargo.toml now includes a comment which remnids maintainers
of the dependency policy for Xous (that is, nail down every dependency
to the minor number).
Versions are pinned down to the minor number. Yes, this means that
we don't automatically pull in features and bug updates from crates.io,
but it also means we don't pull in new attack surfaces and code that
hasn't been tested or reviewed. I'd like this process to be very deliberate
and not automatic for Xous.
The `rand` crate is almost pinned down to a single version, except
for an odd dependency that's pulled in by hosted mode that depends
on rand 0.8.4 via a subordinate dependency via the `tempfile` crate.
Pondering if it's worth it to try and eliminate that, because the
0.8.4 version doesn't get compiled into any version that touches
real hardware. It just makes it harder to analyze the Cargo.lock
file, mostly. I think I'll leave it as-is.
