Fix Inaccurate Window Movement in Linux Framebuffer Backend

[huaxinliao]

Windows would jump to unexpected positions when moving with the mouse on the Linux framebuffer backend. This patch, tested on Raspberry Pi 3B and virtual machines, ensures smoother and more reliable window dragging behavior.

Summary by Bito

This pull request fixes a bug in the Linux framebuffer backend that caused windows to jump during mouse movement. It improves window dragging behavior on Raspberry Pi 3B by modifying screen update conditions, enhancing user experience.

[jserv]

Should the condition tx->fb_base == MAP_FAILED be considered as an early return?

[huaxinliao]

I experimented based on the following code and found that the issue still persists.

--- a/backend/fbdev.c
+++ b/backend/fbdev.c
@@ -190,6 +190,9 @@ static bool twin_fbdev_update_damage(void *closure)
     twin_fbdev_t *tx = PRIV(closure);
     twin_screen_t *screen = SCREEN(closure);
 
+    if (tx->fb_base == MAP_FAILED)
+       return;
+
     if (!tx->vt_active && twin_screen_damaged(screen))
         twin_screen_update(screen);

[weihsinyeh]

I'm curious why adding condition tx->fb_base == MAP_FAILED solves the problem. Can you provide an explanation?

[huaxinliao]

I'm curious why adding condition tx->fb_base == MAP_FAILED solves the problem. Can you provide an explanation?

Based on my current observations and experiments, I consider this PR suppresses the screen update behavior of twin_fbdev_update_damage, which is why the issue appears to go away. I would like to use this PR as a basis for discussion to explore possible solutions to the underlying problem.

[jserv]

Based on my current observations and experiments, I consider this PR suppresses the screen update behavior of twin_fbdev_update_damage, which is why the issue appears to go away. I would like to use this PR as a basis for discussion to explore possible solutions to the underlying problem.

Make git commit messages informative.