[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5603EC15.9090605@ti.com>
Date: Thu, 24 Sep 2015 15:27:01 +0300
From: Tomi Valkeinen <tomi.valkeinen@...com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-fbdev <linux-fbdev@...r.kernel.org>,
DRI Development <dri-devel@...ts.freedesktop.org>
CC: Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Teddy Wang <teddy.wang@...iconmotion.com>,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
Noralf Trønnes <noralf@...nnes.org>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Dave Airlie <airlied@...hat.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Arnaud Patard <apatard@...driva.com>
Subject: No more new fbdev drivers, please
Hi all,
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".
SM750 hardware seems to support multiple outputs, hardware overlays, 2D
accelerator... I think it's pointless to write an fbdev driver for such
a HW, as it's not possible to use those features with fbdev (without
custom API).
So, without spending too much time looking at those drivers, and without
speaking to the authors, my initial suggestion is to remove them.
Tomi
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists