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