LinuxFB supports in principle multiple windows, each one with its own backing store.

These backing stores are then composited in onto a per-screen QImage (this member: https://codebrowser.dev/qt5/qtbase/src/platformsupport/fbconvenience/qfbscreen_p.h.html#QFbScreen::mScreenImage ; see also https://codebrowser.dev/qt5/qtbase/src/platformsupport/fbconvenience/qfbscreen.cpp.html#_ZN9QFbScreen8doRedrawEv ).

Then, this per-screen QImage is copied onto the physical framebuffer in https://codebrowser.dev/qt5/qtbase/src/plugins/platforms/linuxfb/qlinuxfbscreen.cpp.html#_ZN14QLinuxFbScreen8doRedrawEv

In the common touchscreen embedded case, there's just one top level window, one screen, no cursor; in this case it would definitely make sense to try and bypass some of these intermediateries. (They cost CPU cycles, which are a very precious resource on low-end GPU-less devices – the ones running linuxfb and software rendering, after all).

[Rumination: this may conflict with screen rotations, as requested by QTBUG-140218. In that report I argue that one could take the screen's image and then draw it rotated on the physical screen, thus costing a copy (and a rather expensive one, as it's cache unfriendly). But in principle one could make QWidgetRepaintManager or Qt Quick's software render apply a global rotation when they paint, thus achieving a rotated screen without paying for a full copy.]