linux-kernel - Re: Proposal for a low-level Linux display framework

Open Source and information security mailing list archives

Message-ID: <CAF6AEGuuv4sDJbwHpYGUUsX36gFBcfH_Pa+t57ifvwdON3PP-Q@mail.gmail.com>
Date:	Sat, 17 Sep 2011 11:50:57 -0500
From:	Rob Clark <rob@...com>
To:	Florian Tobias Schandinat <FlorianSchandinat@....de>
Cc:	linux-fbdev@...r.kernel.org, linaro-dev@...ts.linaro.org,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	Archit Taneja <archit@...com>
Subject: Re: Proposal for a low-level Linux display framework

On Sat, Sep 17, 2011 at 11:11 AM, Florian Tobias Schandinat
<FlorianSchandinat@....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.

BR,
-R

>
> Best regards,
>
> Florian Tobias Schandinat
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives