Proposal for a low-level Linux display framework
rob at ti.com
Sat Sep 17 09:50:57 PDT 2011
On Sat, Sep 17, 2011 at 11:11 AM, Florian Tobias Schandinat
<FlorianSchandinat at gmx.de> wrote:
> On 09/17/2011 03:16 PM, Rob Clark wrote:
>>>From userspace perspective, fbdev doesn't go away. It is just a
>> legacy interface provided on top of DRM/KMS driver mostly via helper
>> functions. With this approach, you get the richer KMS API (and all
>> the related plumbing for hotplug, EDID parsing, multi-head support,
>> flipping, etc) for userspace stuff that needs that, but can keep the
>> fbdev userspace interface for legacy apps. It is the best of both
>> worlds. There isn't really any good reason to propagate standalone
>> fbdev driver anymore.
> 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.
Hmm, for simple enough devices, maybe fb is fine.. but if you are
covering a range of devices which include stuff with more
sophisticated userspace (X/wayland), then just doing DRM/KMS and using
the DRM fbdev helpers, vs doing both DRM/KMS and standalone fbdev..
well that seems like a no-brainer.
I still think, if you are starting a new driver, you should just go
ahead and use DRM/KMS.. a simple DRM/KMS driver that doesn't support
all the features is not so complex, and going this route future-proofs
you better when future generations of hardware gain more capabilities
and sw gain more requirements.
> Best regards,
> Florian Tobias Schandinat
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
More information about the dri-devel