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 14:46:21 +0200
From:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:	Tomi Valkeinen <tomi.valkeinen@...com>
Cc:	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>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Arnaud Patard <apatard@...driva.com>
Subject: Re: No more new fbdev drivers, please

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.

Or are there some plans to make the writing of DRM drivers for very
simple/trivial devices a bit simpler?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/