Fix memory region in framebuffer

[a1091150]

Issue #62
The width of screen may be different from the virtual resolution.
In apps/main.c, the default value of WIDTH and HEIGHT are 640 and 480, but the visual resolution are set to 1920 and 1080 on my machine.
The different width will draw three screens on the display as the below screenshot.

Before:

After:

The reason to use xres_virtual line_length as the width and not to use xres in struct fb_var_screeninfo:
On VirtualBox, the visible resolution of virtual terminal, which switched by ctrl+alt+f3, is set to 800x600, but the virtual solution is set to 2048x2048. On my physical machine, Asus latop and Ubuntu system, these are the same values.

The information from sudo fbset -i on my laptop and VirtualBox.
Laptop:

mode "1920x1080"
    geometry 1920 1080 1920 1080 32
    ....
endmode
Frame buffer device information:
    ....
    LineLength  : 7680
    Accelerator : No

VirtualBox:

mode "800x600"
    geometry 800 600 2048 2048 32
endmode

Frame buffer device information:
    ......
    LineLength  : 8192
    Accelerator : No

[jserv]

Improve the git commit message to address the consideration of FBIOPAN_DISPLAY.

[a1091150]

@shengwen-tw, May you test the pull request on you machine to see if it is running correctly?

[shengwen-tw]

@shengwen-tw, May you test the pull request on you machine to see if it is running correctly?

I have ran the modification code and have some observations:

Firstly, I want to point out that I wasn’t able to reproduce the issue you encountered, as we previously discussed. From my side, I can only confirm the functionality remains the same.

However, although the framebuffer output appears correct, I noticed that the rendering update is not smooth, with significant lag when dragging windows or even just moving the cursor.

Could you analyze any potential performance bottlenecks in your code and look into ways to address this issue?

[shengwen-tw]

Please check the video I recorded:
https://www.youtube.com/watch?v=1FK8XkVnP8k

[jserv]

Rebase the latest main branch and resolve the conflicts.

[jserv]

Don't use git merge. Always enforce git rebase.

[a1091150]

Please check the video I recorded: https://www.youtube.com/watch?v=1FK8XkVnP8k

I find out that ioctl(fb_fd, FBIOPAN_DISPLAY, &var); causes your machine lagging, but my laptop and VirtualBox are not. Without it, my laptop can not show the mado's screen.
I see you are using two display, so I plug my laptop another display without the code ioctl(fb_fd, FBIOPAN_DISPLAY, &var);

mado's screen work fine on second display, subtly.

Check the video: https://youtu.be/XvhigZefDfc

The commit bbc35ff removed code ioctl(fb_fd, FBIOPAN_DISPLAY, &var);. I believe this commit is ready to pull (may be?)

[jserv]

Refine the statement "The same setting may not be applied on different hardware" to address the consideration and use scenario.

[jserv]

Read https://cbea.ms/git-commit/ carefully and enforce the rules.

[shengwen-tw]

You mentioned that

I find out that ioctl(fb_fd, FBIOPAN_DISPLAY, &var); causes your machine lagging, but my laptop and VirtualBox are not. Without it, my laptop can not show the mado's screen.

Are you planning to open a new pull request to resolve issue #62?

[a1091150]

Are you planning to open a new pull request to resolve issue #62?

Nope. I notice another drm pull request #69 . The updated may followed and discussed on it.

Issue #62 mentioned some problems:

1. Different screen size causes multiple windwos and weird behavior(will be fixed by this pull request)
2. Update and render after switching back to virtual terminal.
3. ioctl(fb_fd, FBIOPAN_DISPLAY, &var) have different behavior on different machine, mentioned in this pull request before.

For third problem, I suspect it is just my laptop and i915drmfb (Intel DRM) will need this pan display and it is not a bug in Mado but in Intel DRM.

For second problem, I did write some switch code for switching, and I notice the proposed DRM backend (#69). The updated may followed and discussed on it.

[shengwen-tw]

I did various tests and found that the problem might not be caused by ioctl(fb_fd, FBIOPAN_DISPLAY, &var);, as the issue still occurs on my machine even after removing that line of code. (it also happens with the upstream code, though not consistently.)

If ioctl(fb_fd, FBIOPAN_DISPLAY, &var); resolves the issue you encountered, it would be reasonable to adopt the change you proposed earlier. (But could you clarify why the FBIOPAN_DISPLAY operation helps in this case?)

I suspect that the lag might be due to the button events being sent from the Linux input subsystem we recently integrated, as the current implementation does not ensure atomic updates for mouse events. I may open another new issue once I have a clearer understanding of this phenomenon.

[jserv]

If ioctl(fb_fd, FBIOPAN_DISPLAY, &var); resolves the issue you encountered, it would be reasonable to adopt the change you proposed earlier. (But could you clarify why the FBIOPAN_DISPLAY operation helps in this case?)

The advantage of using ioctl FBIOPAN_DISPLAY is potential energy efficiency, meaning that the Linux framebuffer driver does not blindly refresh data (especially static frame data), as data updates are managed by the application.

Since the application knows precisely when to refresh the data, the ideal scenario is for it to call FBIOPAN_DISPLAY immediately after updating the data. However, there are drawbacks: first, the application layer must explicitly call FBIOPAN_DISPLAY for display updates; second, if the screen refresh rate is high, the system call overhead introduced by FBIOPAN_DISPLAY can be significant. For Mado development, it is important to account for the potential unintended system overhead caused by the latter concern.

Reference: Structures used by the frame buffer device API

[jserv]

Thank @a1091150 for contribution!

Check https://cbea.ms/git-commit/ carefully and always enforce the rules, such as Wrap the body at 72 characters. In addition, don't use backtick characters for the sake of terminal compatibility.