Before xous-ipc's fixed-length string guaranteed this thing
fit into a single page. Now, we can send potentially unbounded
amounts of text between servers.
I don't think it makes sense to send more than a few k of text to
render on the screen at once, given our screen sizes, so I've added
a patch that truncates the text to the previous length that things
would truncate to.
The behavior is the same as before, except that you will
over-allocate memory on the heap in the sending process
as you shove more string data into a TextView than can be rendered.
Previously, the TextView would just truncate the data and discard
the data.
The truncation happens at the point where you try to hand the
record off to another process, so, one could in theory try
to make this recoverable by adding a layer that splits the
textview into more manageable chunks or pages the data, but that
is an exercise for another day.
And I did it! and it's now fixed.
I was using xous-ipc String to make a fixed-length string in a
structure that's not strictly an IPC structure.
The solution to this is to just implement a fixed length string
directly.
There isn't a simple regex to deal with the loss of Copy when
deprecating xous_ipc, so this has to be a manual pass.
Losing the copy trait means (maybe) some loss of efficiency
in the API because we have to clone some structures instead
of copying them, although, I think actually what might have
been happening under the hood anyways is the copy was implemented
as a clone-under-the-hood for the xous-ipc.
Either way, this happens in the high level management structures
for modals, so it's not the end of the world to incur a clone
on the description of the structures -- we'd have to pay
more attention if this happened e.g. at the pixel shuffling
level, but a few UI strings at human-interaction rates
isn't going to kill us.
xous_ipc::<String> had a clear-volatile() API for zeroizing
sensitive strings.
This is now missing in String, so it has been manually implemented
here by casting the String to a slice-u8 and then iterating
through it using raw pointers and volatile writes with a compiler
barrier to hopefully avoid all of the landmines I know of for
zeroizing a string...
commit is called out separately because this one is one of the
more "dangerous" security-related changes in the API migration.
- remove modal pop-up for wifi connection, and replace with
busy animation
- specify units of delay in the constants (_MS to indicate milliseconds;
this is a convention I'm trying to adhere to)
- partial progress on debugging why the animation isn't running
(value of animation variable is not being passed back at the GAM layer).
Also a general note on coding styles that probably is going to cause
confusion now that more people are contributing to the code base.
Generally, when a lot of "generic" library functions fail, we've been
passing an error message up the stack. However, these functions are
actually meant to be infalliable, and when you kick the error up the
stack you just end up with a panic at an unhelpful location (because
you finally catch the error only at the main loop or something and
by that point there's nothing you can really do about it but panic,
since it's supposed to be an infalliable operation).
As a result I have been trying to tamp down on needless error propagations
and having them fail with a unwrap or expect at the point where the
abstraction should be infalliable. This helps in debugging the actual
failure root cause because you're closer to the line of code that
actually broke, instead of just some line at a generic error handler.
Of course if you build with stack unwinding the top-level unwraps are more
useful because you can peer down into the call chain, but even then,
with the limited screen real estate I think deeply nested failures
would probably overflow any panic display. So even with panic unwinding
I think we stil want to keep the root cause within a few stack frames,
instead of errors being passed up sixteen levels of abstraction before
finally dying.
This only applies to things that are meant to be truly infalliable,
like syscalls that should not fail, or like unpacking a buffer or
memory message that has already been allocated. In this case the errors
are more like asserts, and are helpful if they fail at the line where
they break instead of being passed up the call stack (which was the
original architecture).
Probably I should add a note about this to the Xous Book.
`EXPECTED_APP_CONTEXTS' was added to the list of authorized
switchers. I don't think this is ideal, but I think it would be
difficult to come up with a better solution that doesn't make
`app-loader' "special" in some way.
This allows `app-loader' to register new names (which are then used by
the loaded apps to claim tokens). At the moment this is restricted to
apps that are pre-registered, i.e. included in the image.
I decided to go back on the idea of not changing the modals
and now all modals use the new larger font as well.
This creates issue #396, which I will deal with later once
I have the time to do some more testing. I'm pretty sure
some other dialog boxes are broken now too.
default system font can be statically changed by modifying
the SYSTEM_STYLE constant.
This of course will lead to a request for a dynamically
configurable preference for font size. However, early
on it was decided this is a bad idea. Here's why.
We don't provide for dynamic system-wide font selection
because this adds a lot of complexity to what would otherwise
be static code: this is a deliberate choice to improve code
density and performance. If the system font were dynamically
adjustable, then every character rendered we would potentially
have to query the PDDB for the current system font setting.
The impact of this could be mitigated by caching values but
then what happens when you actually change the font? now
you need a registry to fire messages off to all dependent
crates with cached values to flush their caches and redraw
(or you punt and force a reboot if you change font sizes,
but still, you're creating a dependency on a lot of plumbing
for even the simplest crates).
Plus, with a static font selection, the compiler can take constants
like the font height and compose them with other fitting
parameters into optimized load/stores of borders and spacings
for the static case; if you make it dynamic, all those multiplies,
adds and divides now get pulled into the main rendering loop
and are recomputed all the time. For example, if you have a static
const list of items that need to be rendered, even if the code to
compute the height of the list is written as a for loop, the compiler
will know the list is constant, and the font height is constant,
and it can condense that all into a single number at compile time,
eliminating all the code for the for loop.
If you leave the option open to change that, that entire piece
of code has to be generated and executed even though in practice
nobody changes the parameter.
This change is made with the intention of making the xous-rs crate a bit
more freestanding without depending on the xtask build system.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
this is some bit-rot that happened to the `ball` demo because
it's currently the only application that uses the framebuffer
canvas.
the trust level of the framebuffer canvas has to be lower than
that of the modals, otherwise a modals box is not allowed to
draw on top of the framebuffer.
in this case, a patch that was applied when trust levels were
refactored was missed on the framebuffer canvas, which caused
the trust level of the canvas to be higher than that of a modals.
Thus, when a modal attempts to pop up over the ball demo,
one just sees the defacement lines but no actal content.
