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. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3019 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150924/bb15aa49/attachment-0001.bin>
