linux-kernel - Re: No more new fbdev drivers, please

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Sep 2015 12:17:04 -0400
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-fbdev <linux-fbdev@...r.kernel.org>,
	DRI Development <dri-devel@...ts.freedesktop.org>,
	Sudip Mukherjee <sudipm.mukherjee@...il.com>,
	Teddy Wang <teddy.wang@...iconmotion.com>,
	Noralf Trønnes <noralf@...nnes.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Dave Airlie <airlied@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arnaud Patard <apatard@...driva.com>
Subject: Re: No more new fbdev drivers, please

On 2015-09-24 11:59, Daniel Vetter wrote:
> On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
>> On 2015-09-24 08:46, Thomas Petazzoni wrote:
>>> Hello,
>>>
>>> On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
>>>
>>>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>>>> new Linux display drivers should be done on DRM.
>>>>
>>>> So let's not add any more new fbdev drivers.
>>>>
>>>> I will continue to maintain the current fbdev drivers, and I don't mind
>>>> adding some new features to those current drivers, as long as the amount
>>>> of code required to add the features stays sensible.
>>>>
>>>> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
>>>> and the question is what to do with those.
>>>>
>>>> xgifb was added in 2010, and is still in staging.
>>>>
>>>> fbtft looks like maybe some kind of framework on top of fbdev, with
>>>> fbtft specific subdrivers... I didn't look at it in detail, but my gut
>>>> says "never".
>>>
>>> fbtft mainly drives some very simple I2C-based or SPI-based displays,
>>> and DRM is I believe overkill for such displays. Last time I talked
>>> with Laurent Pinchart about such drivers, I believe he said that such
>>> simple drivers could probably continue to use the fbdev subsystem.
>> I have to agree, using DRM _really_ doesn't make sense for these, the
>> devices in question are (AFAIK) simple I2C or SPI connected frame-buffer
>> chips that are hooked up to equally simple TFT displays.  There's no 3d
>> acceleration at all from what I can tell, there's _very_ limited 2d
>> acceleration, and most of the stuff that the DRM framework provides
>> call-backs for would have to be done on the CPU anyway.  On top of that,
>> it's targeted at small embedded systems with limited memory, and the DRM
>> framework is by no-means lightweight (TBH, fbdev isn't really either, but
>> it's much more light weight than DRM).
>
> See my other mail, but you can write very simple drm drivers. And if
> there's really a bloat problem for small systems we can add Kconfig knobs
> to throw out everything not needed for simple drivers. The only problem
> really is that everyone with such simple drivers doesn't even consider drm
> "because I don't have a desktop gpu" which is just silly - drm has become
> rather flexible. And that's essentially why writing simple drm drivers
> still has a bit too much boilerplate, since no one yet bothered to add a
> bit of helper support needed.
>
Rather ironically, I got your other mail right after I sent this one.  I 
hadn't realized most of the points you made there (it's been a long time 
since I looked at any drm related code (largely because I've had 
absolutely 0 issues on my systems with it, which is a good thing :))). 
I do think being able to compile out some of the drm stuff that isn't 
used on a given system would be nice, and some good helper functions to 
simplify writing basic drivers would be absolutely wonderful.

As far as not considering it 'because I don't have a desktop GPU' goes, 
I agree, that is silly, although for some people it may be 'because my 
chip doesn't do any "rendering"', which brings up the rather complicated 
discussion of what constitutes a GPU and what 'rendering' means.



Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)