Poll for RAUC updates and show notifications #19
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced May 10, 2023
Emantor
approved these changes
May 25, 2023
This usecase comes up often enough that it makes sense to add this. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Multiple cases where topic.modify() is used actually only need this instead. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
The draw_fb is a bit hard to grasp on first sight and also implies that we will keep using the fbdev backend forever (which we hopefully wont). Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
A normal reference is perfectly sufficient. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
We generally want to give exclusive ownership to the display to a single screen at a time. This does however collide with the need to have a second reference for screen capturing. Solve it with an owned Display type that you however still have to lock to do actual drawing on it. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
With the renaming of draw_fb to display this feels natural to do. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
It takes a bit of time to start the tacd, get a hostname and start the screensaver animation. Fill the time using a splash screen. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Having an unmount(&mut self) method that handles the destruction of a screen
that does not _consume_ the screen (e.g. unmount(self)) is a bit unelegant.
This is the first step towards a design where the exclusive access to
resources like the display can be guaranteed by the type system.
E.g. something like this:
let screen = ExampleScreen.new();
let active_screen = screen.activate(display);
...
let display = active_screen.deactivate();
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This change has to major reasons: - The fact that we use RAUC is, at the display level, an implementation detail. The name should reflect what it is and not how it is implemented. - There will soon be another RAUC screen that notifies about updates, making the name ambiguous. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Nearly all screens need to keep track of a list of currently active widgets. Add a convenience type to do this. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This way we can use the type system to ensure that only one screen has access to the display at any point in time and that there are no stray widget redraws across screen transitions. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Having a task to handle button presses in every screen makes maintainance hard. It is also desirable to handle button events the same for all screens from an UX standpoint. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Alerts are screens that have priority over all normal screens and some of the other alerts. This means the display will always show the highest priority alert (if one is active) or one of the normal screens. Having `NormalScreen`s and `AlertScreen`s separate also allows us to centralize the handling of navigation for `NormalScreen`s, as they just transition to the next screen in the list. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Having the locator in every normal screens code has always been a bit of clutter. Having it as an alert screen instead gets rid of that. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Now that we no longer need to reserve space on the display for the locator animation we can start using it for other things. Start with drawing the screen border just a tad further. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Some users have complained about long presses being annoying on the TAC. This is due to them only registering once the user stops pressing the button. Instead send out a long press event as soon as the button was pressed long enough. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
On vanilla TACs we are going to have two official update channels for operating system bundles, Stable and Testing. In addition to that users may also choose to add their own custom channels. Add concept of these channels and a way to poll them to check if a new update is available. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Display a notification on the screen once an update becomes available. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Previously the web interface could not show any kind of out-of-band notifications to the user. Change that. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
The locator feature of the TAC is quite hidden in the web interface. Make it pop out more by using a notification. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
The fact that updates are implemented using RAUC is only an implementation detail once the information is in the web interface. Rename the components to a more generic name. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Once we add the list of update channels the UpdateContainer component will be quite large and the actually interesting information -which slot is active- may flow out of the screen. Buy some more time until that happens by moving the rootfs slots above the (less interesting) bootloader slot. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
While that is not quite decided yet, it is likely that we do not want to enable installing just any bundle via the web interface (as long as the signature works out) outside of setup_mode. Remove the feature from the UI for now and instead rely on update notifications. Installation of any bundle for which the certificates work out is however still possible via the API. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
A bundle installation being in progress is a rather important information. Use a notficication to show it. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This is intened to nag the user into rebooting after installing a new bundle. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This is intended to nag the user into installing updates once they become available. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
|
@hnez has rebased the PR on top of current main. This invalidated the review. But the review is still valid -> force-merging. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds operating system update handling to the tacd.
What this means from an users point of view:
rauc install …call on the commandline:The necessity to display new alerts/notifications on the local screen (Update available, Installing, Please Reboot) kicked up quite some dust in the
src/ui/*part of the code, which is why a lot of commits happened there.With these changes it is now (among other improvements) possible to have multiple active alerts/notifications at the same time and a concept of priorities on which should be shown first between them.
Related Pull Requests