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.