the implementation relied on a quirk of xous-ipc where the message
ID is 0 for string send/receives. This cleans it up so that the API
is transparent and consistent with other API calls in the system.
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>
cheeseball fix -- just don't draw the "please wait" message
when in hosted mode (because everything mounts so fast, by the
time you put up the please wait message, it's time to clear it).
mount initiator is now back inside of the status thread
(woo, no more app-specific dependency) and there is now a
wait on "attempted to mount" inside the status thread which is
the signal to clear the "waiting on boot" message.
While it's a kind of neat effect to have the "please wait"
message persist right up until the point where the dialog box
pops up, the problem is that the blit of the backplane captures
that, so when the context is reverted that message is still there.
On a very fast mount (empty PDDB under Renode emulation) the
mounting call finishes so quickly that the dialog box that would
normally trigger the redraw to clear this message never renders.
This patch forces the screen to blank before trying to call
PDDB init, ensuring that we don't have that persist after the
mount, even if it is very fast.
The downside is there is a fraction of a second where the please
wait disappears, and the dialog box pops up. That is just the
time it takes for the system to setup for the cryptographic
operations.
There's a race condition between the return of a blocking scalar
and when focus is relinquished.
This causes chained graphics operations to get dropped sometimes.
Move the return result to after the focus switch; this allows us
to elimate some dead waits.
The initial wait message is drawn directly under where
the modals would appear, so the message "goes away"
when modals pop up.
There's still a bit of trickiness around the timing of
some of the calls. Attempting to mount the PDDB too early
before all the contexts have been registered leads to
a lot of needless defacing.
Also, the final redraw needs a short delay to allow
the system to foreground shellchat again after closing
the modals.
- add an autotrigger feature for the basis stress test so it can
be run in a fuzzer loop
- various fixes and improvements to the implementation to help
integrate with CI
takes about 1MiB of heap to decode the test PNG.
Putting the heap increase at boot seems to not
work, it causes other processes to not spawn. The condition
is not terribly reproducible, so it's probably a concurrency
issue of some type.
This allows for `ditherpunk` config to have a much larger
stack size on select processes only.
The cost comes at a 4k fixed overhead for the sacrificial
wrapper thread, so we lose about 20k of runtime RAM, even
when ditherpunk is *not* activated (because we're
always wrapping the threads).
There is no impact on scheduling or CPU utilization, as the
wrapper thread blocks and is never scheduled once the real
main starts. However, it does subtract one thread from the
total available thread pool.
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>
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.
- code is merged into shellchat so there's less alignment overhead
and some library reuse
- server is not spawned until it's needed, so the RAM load is less
Now that I understand how smoltcp does ping better I have regrets.
The demo example in smoltcp uses a funky macro that was a bit
misleading. I have gotten rid of that but I probably would have made
different decisions in implementing this had I understood the API better.
Anyways. It works, but has some trouble handling the cases of timeouts
sometimes.
not fully working yet, but the architecture is there and it builds.
smoltcp's ping implementation (or at least its demo code) was not
very amenable to splitting into modules, had to recode most of it.
the ipv6 is still a hack.
also add some bread crumbs on the more user-facing APIs to
help beginners out. Need to do a good spring cleaning of the
rustdoc tree, though. looks pretty terrible as it is.
this prevents less trusted processes from connecting to servers
after the kernel initializations are done.
this works so long as we don't have disconnects from the kernel
servers. In order to support disconnects we will also need a
way to re-enumerate the SID to guarantee that we don't have a re-use
problem. But for now, the kernel is not designed with any practical
disconnect mechanism; there is no code that calls the Quit mechanism
on any server.
