Re: No more new fbdev drivers, please

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3341 bytes --]

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.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]