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