there's something....weird....going on in the initializers
here and ... something about configurations not being
applicable to expressions??
i'm a little confused, but, the original work-around I had to
this isuse somehow side-effected things in some way that I didn't
expect. this reverts those side effects.
a "small" memory target is created, which maps only a subset
of fonts to memory for targets that have extremely limited amounts
of on-chip storage.
the main thing I'm not happy about with this change is that the
origin offset of the font table is hard-coded into the template,
but also, I'm not quite sure if there's a better way to do this
that doesn't make things unnecessarily complicated. The origin
offset *is* target specific, and the templates already
reference targets specifically in the config lists...so if this
were to be made more generic, the path you'd end up on is something
like parsing link.x files out of various configurations which seems
like an extreme amount of work for a constant that rarely changes.
So, it's a footgun, but one where mending the foot is several times
less effort than putting a safety on the footgun.
far from complete, lots of warnings, but a good start.
most of the io setup and FB manipulation is done.
The main thing left is to puzzle through the UDMA block and
setup the SPIM accordingly.
Regenerate the font files after adjusting the template to generate files
that will not get changed by rustfmt.
Signed-off-by: Sean Cross <sean@xobs.io>
Generate code that can be put through rustfmt without being altered.
This removes an issue where the font tables can be rearraged by simply
running `rustfmt` on the repository.
Signed-off-by: Sean Cross <sean@xobs.io>
XOR op should not be usable to create fake security boxes
but it also looks really ugly to have it defaced.
This small tweak makes the XOR function look decent for the initial
purpose of the function (chat status bar wait indicator).
Eventually, this will be a controversial decision, but I'll kick
that down the road.
this it to avoid abusing the primitive to create inverted text
(for secure UI elements only). It does degrade from the aesthetics
of a busy bar but it is a computationally efficient way to patch
around the concern.
This is just the TextView primitive with a "state" variable added
that controls how far the strips should march across the screen.
Users can specify with or without a bounding box.
The exact location of the text within the bar depends on the
BoundingBox option picked.
The primitive computes the total region to animate based upon
the typesetting engine's output. Thus it is not recommended
to "compress" the amount of whitespace allocated to the animation,
because it can cause the animation to have artifacts due to
whitespace overflow of typesetting.
Mark `MemoryRange::as_slice()` and `MemoryRange::as_slice_mut()` as
unsafe.
This is due to the fact that not all representable types can be cast to
an arbitrary value. For example, if Process A sends random values to
Process B, then Process B casts the memory to a slice of `bool`, then
any values that are not 0 or 1 are undefined.
Because these functions can leak UB into the program, they are marked as
unsafe.
This patch adds `unsafe {}` blocks to all instances where this function
is called. Additionally, all instances have been checked to verify that
they do not cast to any invalid types -- most use `u8` or `u32`.
Additionally, the long-deprecated `MemoryRange::from_parts()` call was
removed, since that causes UB without being marked as unsafe.
Signed-off-by: Sean Cross <sean@xobs.io>
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.
Thanks to @samblenny for getting the ball rolling on this.
This commit adds a "tall" font face which is somewhere in betwee
the Regular size (12 pts) and 2x Small size (18 pts). This is
a compromise between text density and readability that has been
missing for some time from the UI.
The 32x32 glyph support is "hacked in", in that an extra flag
has been added to support this special case, rather than either
(a) making the library more generic (e.g. supporting 8x, 16x, 32x, 64x
glyphs) or (b) adding more metadata to the font libraries so that
the bitmap pattern is automatically associated with the font (right
now the parameters are set by hand in blitstr2/fonts.rs).
This is a violation of the "zero, one, many" principle in coding,
but I'm waiving that because (a) 64x glyphs don't make sense on
our system...you're not going to be creating posters and headlines
on this device (ha ha I say this today, tomorrow I will get a PR
for a poster editor app that absolutely needs 64x glyphs) and (b)
the font subsystem is, at least for now, a fairly mature and
well-tested code base so a minor futzing seems more appropriate
than ripping everything out.
The point at which things should be greatly refactored is when
we consider supporting right-to-left scripts or scripts that
require complex ligatures. But I think for now the system as
writ covers 80% of humanity's language needs acceptably
(but not perfectly).
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>
- make the "base" field no longer public. It is accessible, but only
through an `unsafe` method, because, it is unsafe.
- add accessors to offest/mask fields. Because, it's not at all
unsafe to access these, and it can be useful for bit-ops that are
not part of the generic set of UTRA.
- add Arc to AtomicCSR, and require `std` for AtomicCSR types.
This should not break anything, I checked inside @foundation-devices
keyOS and they don't seem to be using AtomicCSR anywhere.
The Arc makes it a bit safer to clone the AtomicCSR base pointer
and share it between threads, but it will have an impact on performance.
The USB stack (which requires AtomicCSR) was regression testing and the
impact seems minimal.
Recall that the main purpose of AtomicCSR is to provide a CSR accessor
that does not require a mutable reference to the base object. This
can make certain Rust idioms a bit cleaner. We wrap the base accessor
in Arc+Atomic to try and improve the safety of throwing the borrow
checker under the bus, but it's still not perfect because hardware
mutable state can have side-effects within hardware itself that cannot
be modeled or checked by Rust's borrow checker.
Fixes crashes on macOS.
Some operating systems and GUI frameworks, in particular Cocoa, don't
allow creating an event loop from a thread other than the main thread
(TID 1) and will abort a program on violation.
I can't test it, but, it basically just takes the code pre #372
and provides it to macos targets.
I think the update() method is ok to just remove, but, if something
doesn't work there that would probably be the root cause.
