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

Reply via email to