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]

Message-ID: <CADnq5_OzbGbXP74gPEf+2-2OxTzeXYA2uoLkkH=O198xYXOTrQ@mail.gmail.com>
Date:	Thu, 24 Sep 2015 11:38:29 -0400
From:	Alex Deucher <alexdeucher@...il.com>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>
Cc:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	linux-fbdev <linux-fbdev@...r.kernel.org>,
	Teddy Wang <teddy.wang@...iconmotion.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	DRI Development <dri-devel@...ts.freedesktop.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Arnaud Patard <apatard@...driva.com>,
	Dave Airlie <airlied@...hat.com>,
	Sudip Mukherjee <sudipm.mukherjee@...il.com>
Subject: Re: No more new fbdev drivers, please

On Thu, Sep 24, 2015 at 11:21 AM, Austin S Hemmelgarn
<ahferroin7@...il.com> 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.

Just about all of the acceleration stuff is vendor specific so there's
really nothing you need to provide.  As Daniel noted there are several
drm drivers for simple devices that do not support any kind of 2D or
3D acceleration.  There are no requirements to provide any sort of
acceleration.

Alex
--
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/