A disappointing number of hardware platforms ship with the ability to scan out much larger resolutions than their GPU or memory bandwidth can reasonably handle. These platforms are quite common in set-top box markets in particular, e.g. AmLogic/STM chipsets with Mali-450 which can scan out but barely render 4K, and older i.MX chipsets with underpowered Vivante GPUs (plus the requirement to copy buffers around and limited memory bandwidth).
Many of these platforms can display some content at full resolution: media (helped by being YUV), infrequently-updated graphics, etc. But if the compositor is trying to composite at the full resolution, it will fail dismally.
Set-top boxes in particular often get around this by scaling the UI content at an integer multiple, and only displaying media at full size.
This patchset implements a
render-scale configuration parameter for Weston which mimics this behaviour, by creating the renderer output buffer at a smaller scale factor than the output size, downsampling at composition time and upsampling in the DRM backend.
This would actually be a good usecase for the proposed KMS property to configure the scaling algorithm, since text really looks hilariously bad on Intel when rendered at full native size, scaled down by the GPU (probably using linear rather than nearest filtering?) and scaled back up by the display controller (probably also using linear or something even more exotic).
One workaround for the above would be attempting to fiddle with the scale we send to clients, so in the
render_scale == output_scale == 2 case, they don't get downsampled only to later be upsampled. However, this is fraught with danger, and in any case the choice of which applications to scale and when is probably massively usecase-specific, so I'm happy to punt this to a platform problem rather than trying to solve it in generic code.
This marked as WIP for now:
Pixman is currently completely broken WRT damage, and has a hack to always force fullscreen repaints
Screenshots in GL are broken, as they don't scale up to the expected output size
Screencasting is also ???
No support in the headless backend, thus ...
There are no tests