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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
