DisplayApp: Go to clock on wakeup if no app loaded

[vkareh]

When waking the screen up, if there is no actual app loaded (i.e. we are still in the QuickSettings, Settings, or Launcher screens) we should just reload the Clock app directly.

[github-actions]

Build size and comparison to main:

Section	Size	Difference
text	378884B	32B
data	948B	0B
bss	63488B	0B

[vkareh]

This supercedes #1436 since that one has conflicts and uses outdated function calls.

[mark9064]

Future compatibility thought: with always on display (#1869), it'd be preferred if the app was loaded on sleep entry rather than on wake. But the whole sleep state might end up being refactored anyway so if this is annoying to implement then don't worry

[vkareh]

@mark9064 - that's a good point. I tried it on sleep and it works even better (the transition is less choppy). Thanks for the suggestion!

Regarding future refactor, I feel that this is a simple enough change and can be moved around as needed without much overhead.

[mark9064]

Great to hear it's working even better. To clarify what I meant originally: "as part of 1869, we might have to refactor some sleep stuff so if it's difficult to change this PR to work on sleep entry at the moment then don't worry". But you've managed to work it out anyway, so it doesn't matter 👍

[JustScott]

Finding this quite nice as I consistently forget to return to the watch face. I'm wondering what thoughts are on having this also apply to the notifications, as that isn't an app that really needs to stay open after you view it once.

[vkareh]

@JustScott at first I assumed that this wouldn't be necessary for the Notifications screen as I usually just dismiss notifications fairly quickly after viewing them, but then realized I use #1716 as part of my daily driver branch, so it's a bit less relevant.

However, after testing it some more, I think it makes sense to add Notifications to the list. It works well with it, so I've pushed a new change.

[mark9064]

Works great, don't find my watch on random screens where it has clicked itself nearly so often as all of the screens one swipe away now return back to the watchface safely. Integrates with AOD perfectly as well.

[JF002]

I noticed a small glitch when the watch wakes up and switches to the clock. Any idea was could be the cause of this?

20240819_182001.mp4

[vkareh]

@JF002 no idea, but I notice it too. With the Always On option this works even better (and no glitch), but I suspect there's something happening in between turning the LCD off and loading the clock screen that keeps the previous screen in some transient store.

I wonder if a delay might help here... 🤔

[mark9064]

Could call the lvgl task handler in a loop until it has no more work to do after loading the clock screen. That way you can be sure it's fully rendered to the display before sleeping

Generally calling the handler until no more work is a bad idea as some apps e.g the timer have so much work in Refresh() that LVGL never finishes (in this case timer should use dirty value for drawing the numbers). But as watchfaces are fast to render it should be done quickly.

[vkareh]

@mark9064 sounds interesting, how do I accomplish that? I'm not sure I fully understand the LVGL task API

[mark9064]

while (!lv_task_handler()) {};
lv_task_handler runs LVGL, it returns the number of ms to wait until running it again. If it returns 0 it would like to be run immediately i.e it still has more things to do

I'm not 100% on LVGL internals but I'm pretty sure it will only return a positive value once done rendering

[vkareh]

Ah excellent, I was on the right track doing

          while (lv_task_handler() == 0) {
            vTaskDelay(100);
          }

Delay seems unnecessary, but things are looking good. A few more tests and I'll push. Thanks!

[mark9064]

Yeah definitely don't block there, DisplayApp is a lowest priority task so anything else that wants to run will already preempt it (and anything else with the same priority will share).
Edit:
I suppose portYIELD would be fine but

1. it should be done quickly
2. yielding probably won't make it finish faster

so I'd just spin in this scenario

[vkareh]

Just pushed the change with the lv_task_handler loop.
It loads the clock app and then waits until it's loaded before it turns off the LCD. The effect is much nicer when turning it back on.

[vkareh]

I've put the clock loading code in between setting the brightness and setting the LCD state. This gets rid of the glitch entirely on both screen off and screen on.

[JF002]

I've put the clock loading code in between setting the brightness and setting the LCD state. This gets rid of the glitch entirely on both screen off and screen on.

Great, I prefer this solution rather than the infinite loop! I confirm that the glitch is not visible anymore 👍