Proposal for a low-level Linux display framework

[Rob Clark]

On Sat, Sep 17, 2011 at 9:44 AM, Felipe Contreras
<felipe.contreras at gmail.com> wrote:
> On Thu, Sep 15, 2011 at 9:58 PM, Alan Cox <alan at lxorguk.ukuu.org.uk> wrote:
>>> One of my biggest problems with KMS is that it has (naturally) a lot more
>>> complexity than the fb API which leads to instability. Basically it's very
>>
>> It shouldn't do - and a sample of one (your machine) is not a
>> statistically valid set. Fb is pretty much ununsable in contrast on my
>> main box, but that's not a statistically valid sample either.
>>
>> I'm not that convinced by the complexity either. For a simple video card
>> setup such as those that the fb layer can kind of cope with (ie linear
>> buffer, simple mode changes, no client rendering, no vblank flipping,
>> limited mode management, no serious multi-head) a DRM driver is also
>> pretty tiny and simple.
>
> That's not true, many drivers work around the lack of features in the
> fb API by providing custom interfaces. For example, in omapfb it's
> possible to use the overlays from user-space, configure some YUV
> format, do vsink, and multipages just fine:
>
> https://github.com/felipec/gst-omapfb/blob/master/omapfb.c
>
> It's perfect to render video clips. Of course, it would be even better
> if those custom interfaces were merged into the fb API.

fwiw, as was mentioned earlier in the thread, there is already an
effort underway for a standardized overlay interface for KMS:

http://lists.freedesktop.org/archives/dri-devel/2011-April/010559.html

Anyways, it is also possible to extend DRM drivers w/ custom API.. and
even possible extend the fbdev on top of DRM/KMS with custom
interfaces if you *really* wanted to.  I have some patches somewhere
that add support a portion of the omapfb ioctls to the fbdev layer in
omapdrm driver for the benefit of some legacy display test app.  If
someone really wanted to, I guess there is no reason that you couldn't
support all of the omapfb custom ioctls.