Re: [PATCH] Revert "video: fbdev: amba-clcd: Retire elder CLCD driver"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 29, 2020 at 1:29 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
> On Tue, Sep 29, 2020 at 8:44 PM Daniel Vetter <daniel@xxxxxxxx> wrote:
> > On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne <pcc@xxxxxxxxxx> 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?

This is what the userspace fbdev driver does (or at least tries to
do). If this operation fails (as it does with the old fbdev CLCD
driver) the driver falls back to using a single buffer. The DRM driver
doesn't do anything like that, it allocates multiple buffers. IIRC
that fails on stock kernels but with an increase to the amount of
video RAM declared in the DTS (e.g. [1]) that operation turns out to
succeed.

Peter

[1] https://www.spinics.net/lists/arm-kernel/msg800628.html
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux