lkml.org 
[lkml]   [2011]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Proposal for a low-level Linux display framework
    On 09/15/2011 06:58 PM, Alan Cox wrote:
    >> Well, I rather think that the fb API is more user centric to allow every program
    >> to use it directly in contrast to the KMS/DRM API which aims to support every
    >> feature the hardware has. For this the fb API should not change much, but I
    >> understand some additions were needed for some special users, probably limited
    >> to X and wayland.
    >
    > Wayland needs vblank frame buffer switching and the like. Likewise given
    > you want to composite buffers really any serious accelerated device ends
    > up needing a full memory manager and that ends up needing a buffer
    > manager. Wayland needs clients to be doing their own rendering into
    > objects which means authorisation and management of the render engine
    > which ends up looking much like DRM.

    As you have DRM now and as I'm not interested in wayland I won't discuss this,
    but I guess it might be a good start for Geert's question what would be needed
    to use it on dumb framebuffers.

    >> 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.

    Yes, if you limit DRM to the functionality of the fb API I guess you could reach
    the same stability level. But where can I do this? Where is a option to forbid
    all acceleration or at least limit to the acceleration that can be done without
    any risk?

    >> Well, I think it's too late to really fix this thing. We now have 3 APIs in the
    >> kernel that have to be kept. Probably the best we can do now is figure out how
    >> we can reduce code duplication and do extensions to those APIs in a way that
    >> they are compatible with each other or completely independent and can be used
    >> across the APIs.
    >
    > I think it comes down to 'when nobody is using the old fb drivers they can
    > drop into staging and oblivion'. Right now the fb layer is essentially
    > compatibility glue on most modern x86 platforms.

    That's a really difficult question. Determining the users is difficult and there
    are people that use their hardware very long, for example we are about to get a
    new driver for i740. For the framebuffer infrastructure I guess you have to at
    least wait for my death.


    Regards,

    Florian Tobias Schandinat


    \
     
     \ /
      Last update: 2011-09-15 21:21    [W:0.025 / U:31.556 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site