On Tue, Sep 29, 2020 at 10:29:22PM +0200, Linus Walleij wrote:
On Tue, Sep 29, 2020 at 8:44 PM Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne pcc@google.com wrote:
But aside from all this, why is this blocking the migration from fbdev to drm? With fbdev you don't have buffer allocations, nor dma-buf support, and somehow android can boot.
I do not know how Android does things these days but back in the days it would request a virtual framebuffer twice the height of the physical framebuffer and then pan that up/down between composing frames, thus achieving a type of double-buffering from userspace.
Given the type of bugs Peter is seeing this seems to still be the case, Peter can you confirm?
We have the overallocate option for the fbdev emulation to support this use case of flipping buffers. So this part should work I think, but maybe some other parts of our check_var/set_par implementation don't work in a way to make surface flinger happy. -Daniel