WIP: RFC/HACK: limit Android UI size to 1080p

This is more a discution RFC to know if there is a better (more generic ?) solution to handle the following use case:

Amlogic SoCs are low cost Set-Top-Box multimedia oriented, thus they can decode and render 4k60 10bit HDR10+ h264/hevc/vp9 video content by using zero-copy rendering.

But for the general purpose graphics, it can barely handle 4k desktop-like rendering in SW and GPU. Thus Amlogix downscales the UI plane to 1080p max for their Android TV boxes (their HWC2 implementation is at: https://github.com/khadas/android_hardware_amlogic_hwcomposer/tree/khadas-vim3-pie) but they handle the video frame rendering directly, separately from the main framebuffer.

This HACK simply limits the height/width reported to HWC2 for each mode, and then setups the Atomic params for upscaling by using the actual mode width/height.

I was reported Rockchip also uses this trick on their Rk3399 SoCs, seems it's handled at https://github.com/khadas/android_hardware_rockchip_hwcomposer/blob/fd701469b72b549e707e3ee995fefa74389c41ae/hwcomposer.cpp#L342 in their hwcomposer implementation.

This is clearly an hack, but it works fine.

The direct drawback is that Android reports 1920x1080 for the 4k modes, not a big deal but it may collide with actual 1080p modes and hit the issue we had with catastrophic duplicate modes handling in SurfaceFlinger.

The other issue I'm questioning is: how would be composed a 4k video frame when lying about the display width/height ?