On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote: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.
On 2015-09-24 08:46, Thomas Petazzoni wrote:
Hello,I have to agree, using DRM _really_ doesn't make sense for these, the
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.
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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature