Proposal for a low-level Linux display framework

[Dave Airlie]

>
> I disagree. This depends on the functionality the hardware has, the desired
> userspace and the manpower one has to do it. And of course if you just want fb
> having fb via DRM/KMS has some overhead/bloat. It's perfectly okay to have just
> an fb driver for devices that can't do more anyway.
> And fb is no legacy interface but actively developed, just with other goals than
> DRM/KMS is, it aims for stability and to provide a direct interface, not needing
> any X or wayland crap.

Stability is a total misnomer, whats worse is you know it. If you just
want to do software render your whole GUI whether you use KMS or fbdev
doesn't matter. Instability is only to do with GPU hardware
acceleration, whether fb or kms expose accel doesn't matter. So less
attitude please.

fbdev is totally uninteresting for any modern multi-output hardware
with an acceleration engine, you can't even memory manage the GPU
memory in any useful way, try resizing the fb console dynamically when
you've allocated the memory immediately following it in VRAM, you
can't as userspace has it direct mapped, with no way to remove the
mappings or repage them. Even now I'm still thinking we should do
kmscon without exposing the fbdev interface to userspace because the
whole mmap semantics are totally broken, look at the recent fb
handover race fixes.

Dave.

Dave.