On Tue, Sep 29, 2020 at 10:29:22PM +0200, Linus Walleij wrote: > On Tue, Sep 29, 2020 at 8:44 PM Daniel Vetter <dan...@ffwll.ch> wrote: > > On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne <p...@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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
