Screen shifting upwards

[tituscmd]

Verification

• [X] I searched for similar bug reports (including closed issues) and found none was relevant.

What happened?

Screen shifts upwards and reveals part of another screen when accessing the notification screen while in the paint app

What should happen instead?

Screen should not shift upwards but remain positioned as it normally is

Reproduction steps

• Open paint app
• Double-click hardware button to pull up notification screen
• Swipe up on the notification screen to close it
• See that the screen has shifted upwards

More details?

Bug is hotfixable/worked-around by simply restarting the watch.

Version

Custom fork based on v1.14.0

Companion app

InfiniLink

[mdmallardi]

Can confirm this on both Pinetimes I own.

[tituscmd]

Interesting. Are you building from main or also from a custom fork?

[FintasticMan]

I can also confirm with basically the latest main.

[mark9064]

Can confirm NOT fixed by spi fixes in #1869 as well - this appears to be a separate issue

[mdmallardi]

Interesting. Are you building from main or also from a custom fork?

I forgot to reply to this. One Pinetime is on 1.14.0, another is on commit 004b2bf from main and was the latest main available at the time I wrote my original reply.

[tituscmd]

Interesting. Are you building from main or also from a custom fork?

I forgot to reply to this. One Pinetime is on 1.14.0, another is on commit 004b2bf from main and was the latest main available at the time I wrote my original reply.

So it seems like this issue does not come from any other commit/PR that isn't already in main. Good to know.

[Xorger23]

Bug is hotfixable/worked-around by simply restarting the watch.

Would also like to note that the screen can be reset back to normal by repeating the procedure until everything shifts back to its original location

[mark9064]

This is a complex one

diff --git a/src/displayapp/screens/Notifications.cpp b/src/displayapp/screens/Notifications.cpp
index 3a3f5f2b..9bf55067 100644
--- a/src/displayapp/screens/Notifications.cpp
+++ b/src/displayapp/screens/Notifications.cpp
@@ -156,6 +156,9 @@ bool Notifications::OnTouchEvent(Pinetime::Applications::TouchEvents event) {
     } else if (event == Pinetime::Applications::TouchEvents::SwipeRight) {
       OnPreviewDismiss();
       return true;
+    } else if (event == Pinetime::Applications::TouchEvents::SwipeUp) {
+      running = false;
+      return true;
     }
     return false;
   }
@@ -216,7 +219,7 @@ bool Notifications::OnTouchEvent(Pinetime::Applications::TouchEvents event) {
 
       if (!nextNotification.valid) {
         running = false;
-        return false;
+        return true;
       }
 
       currentId = nextNotification.id;

This resolves the original issue, but not swiping up on a new notification. And even better, I'm not entirely sure why this resolves the issue yet. Need to keep digging

[mark9064]

From what I can see there are a couple questionable things happening

• Paint receives touch events while the notification->paint transition is occurring (apps probably shouldn't receive touch events until they are fully onscreen)
• Paint bypasses LVGL to draw directly to the display (fine) but in the process updates some states only LVGL should update (not good practice) as it directly calls the internal LVGL display flush function

The combination of the two means that Paint messes with scrolling while it's still happening, and this is possible because it receives touch events earlier than it should