From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ondrej Zary Date: Thu, 24 Sep 2015 17:12:27 +0000 Subject: Re: No more new fbdev drivers, please Message-Id: <201509241912.28739.linux@rainbow-software.org> List-Id: References: <5603EC15.9090605@ti.com> <560414EB.508@gmail.com> <20150924155912.GW3383@phenom.ffwll.local> In-Reply-To: <20150924155912.GW3383@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: dri-devel@lists.freedesktop.org Cc: Thomas Petazzoni , linux-fbdev , Teddy Wang , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Austin S Hemmelgarn , Tomi Valkeinen , Laurent Pinchart , Daniel Vetter , Arnaud Patard , Dave Airlie , Sudip Mukherjee On Thursday 24 September 2015 17:59:12 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. Is there a simple way to convert existing fbdev drivers to DRM? Let's say I want to convert tridentfb to DRM, keeping the 2D acceleration (pan, fillrect, copyarea, imageblit) to be usable by the console (and maybe extend it to X11 using some generic 2D driver?) -- Ondrej Zary From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ondrej Zary Subject: Re: No more new fbdev drivers, please Date: Thu, 24 Sep 2015 19:12:27 +0200 Message-ID: <201509241912.28739.linux@rainbow-software.org> References: <5603EC15.9090605@ti.com> <560414EB.508@gmail.com> <20150924155912.GW3383@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from smtp-1b.atlantis.sk (smtp-1b.atlantis.sk [80.94.52.26]) by gabe.freedesktop.org (Postfix) with ESMTPS id DFB2A6EF10 for ; Thu, 24 Sep 2015 10:12:39 -0700 (PDT) In-Reply-To: <20150924155912.GW3383@phenom.ffwll.local> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org Cc: Thomas Petazzoni , linux-fbdev , Teddy Wang , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Austin S Hemmelgarn , Tomi Valkeinen , Laurent Pinchart , Daniel Vetter , Arnaud Patard , Dave Airlie , Sudip Mukherjee List-Id: dri-devel@lists.freedesktop.org T24gVGh1cnNkYXkgMjQgU2VwdGVtYmVyIDIwMTUgMTc6NTk6MTIgRGFuaWVsIFZldHRlciB3cm90 ZToKPiBPbiBUaHUsIFNlcCAyNCwgMjAxNSBhdCAxMToyMToxNUFNIC0wNDAwLCBBdXN0aW4gUyBI ZW1tZWxnYXJuIHdyb3RlOgo+ID4gT24gMjAxNS0wOS0yNCAwODo0NiwgVGhvbWFzIFBldGF6em9u aSB3cm90ZToKPiA+ID5IZWxsbywKPiA+ID4KPiA+ID5PbiBUaHUsIDI0IFNlcCAyMDE1IDE1OjI3 OjAxICswMzAwLCBUb21pIFZhbGtlaW5lbiB3cm90ZToKPiA+ID4+ZmJkZXYgaXMgKG1vcmUgb3Ig bGVzcykgbWFpbnRhaW5lZCwgYnV0IGl0J3MgYSBkZXByZWNhdGVkIGZyYW1ld29yay4KPiA+ID4+ IEFsbCBuZXcgTGludXggZGlzcGxheSBkcml2ZXJzIHNob3VsZCBiZSBkb25lIG9uIERSTS4KPiA+ ID4+Cj4gPiA+PlNvIGxldCdzIG5vdCBhZGQgYW55IG1vcmUgbmV3IGZiZGV2IGRyaXZlcnMuCj4g PiA+Pgo+ID4gPj5JIHdpbGwgY29udGludWUgdG8gbWFpbnRhaW4gdGhlIGN1cnJlbnQgZmJkZXYg ZHJpdmVycywgYW5kIEkgZG9uJ3QgbWluZAo+ID4gPj5hZGRpbmcgc29tZSBuZXcgZmVhdHVyZXMg dG8gdGhvc2UgY3VycmVudCBkcml2ZXJzLCBhcyBsb25nIGFzIHRoZQo+ID4gPj4gYW1vdW50IG9m IGNvZGUgcmVxdWlyZWQgdG8gYWRkIHRoZSBmZWF0dXJlcyBzdGF5cyBzZW5zaWJsZS4KPiA+ID4+ Cj4gPiA+Pkkgc2VlIHdlIGhhdmUgdGhyZWUgZmJkZXYgZHJpdmVycyBpbiBzdGFnaW5nOiB4Z2lm YiwgZmJ0ZnQgYW5kIHNtNzUwZmIsCj4gPiA+PmFuZCB0aGUgcXVlc3Rpb24gaXMgd2hhdCB0byBk byB3aXRoIHRob3NlLgo+ID4gPj4KPiA+ID4+eGdpZmIgd2FzIGFkZGVkIGluIDIwMTAsIGFuZCBp cyBzdGlsbCBpbiBzdGFnaW5nLgo+ID4gPj4KPiA+ID4+ZmJ0ZnQgbG9va3MgbGlrZSBtYXliZSBz b21lIGtpbmQgb2YgZnJhbWV3b3JrIG9uIHRvcCBvZiBmYmRldiwgd2l0aAo+ID4gPj5mYnRmdCBz cGVjaWZpYyBzdWJkcml2ZXJzLi4uIEkgZGlkbid0IGxvb2sgYXQgaXQgaW4gZGV0YWlsLCBidXQg bXkgZ3V0Cj4gPiA+PnNheXMgIm5ldmVyIi4KPiA+ID4KPiA+ID5mYnRmdCBtYWlubHkgZHJpdmVz IHNvbWUgdmVyeSBzaW1wbGUgSTJDLWJhc2VkIG9yIFNQSS1iYXNlZCBkaXNwbGF5cywKPiA+ID5h bmQgRFJNIGlzIEkgYmVsaWV2ZSBvdmVya2lsbCBmb3Igc3VjaCBkaXNwbGF5cy4gTGFzdCB0aW1l IEkgdGFsa2VkCj4gPiA+d2l0aCBMYXVyZW50IFBpbmNoYXJ0IGFib3V0IHN1Y2ggZHJpdmVycywg SSBiZWxpZXZlIGhlIHNhaWQgdGhhdCBzdWNoCj4gPiA+c2ltcGxlIGRyaXZlcnMgY291bGQgcHJv YmFibHkgY29udGludWUgdG8gdXNlIHRoZSBmYmRldiBzdWJzeXN0ZW0uCj4gPgo+ID4gSSBoYXZl IHRvIGFncmVlLCB1c2luZyBEUk0gX3JlYWxseV8gZG9lc24ndCBtYWtlIHNlbnNlIGZvciB0aGVz ZSwgdGhlCj4gPiBkZXZpY2VzIGluIHF1ZXN0aW9uIGFyZSAoQUZBSUspIHNpbXBsZSBJMkMgb3Ig U1BJIGNvbm5lY3RlZCBmcmFtZS1idWZmZXIKPiA+IGNoaXBzIHRoYXQgYXJlIGhvb2tlZCB1cCB0 byBlcXVhbGx5IHNpbXBsZSBURlQgZGlzcGxheXMuICBUaGVyZSdzIG5vIDNkCj4gPiBhY2NlbGVy YXRpb24gYXQgYWxsIGZyb20gd2hhdCBJIGNhbiB0ZWxsLCB0aGVyZSdzIF92ZXJ5XyBsaW1pdGVk IDJkCj4gPiBhY2NlbGVyYXRpb24sIGFuZCBtb3N0IG9mIHRoZSBzdHVmZiB0aGF0IHRoZSBEUk0g ZnJhbWV3b3JrIHByb3ZpZGVzCj4gPiBjYWxsLWJhY2tzIGZvciB3b3VsZCBoYXZlIHRvIGJlIGRv bmUgb24gdGhlIENQVSBhbnl3YXkuICBPbiB0b3Agb2YgdGhhdCwKPiA+IGl0J3MgdGFyZ2V0ZWQg YXQgc21hbGwgZW1iZWRkZWQgc3lzdGVtcyB3aXRoIGxpbWl0ZWQgbWVtb3J5LCBhbmQgdGhlIERS TQo+ID4gZnJhbWV3b3JrIGlzIGJ5IG5vLW1lYW5zIGxpZ2h0d2VpZ2h0IChUQkgsIGZiZGV2IGlz bid0IHJlYWxseSBlaXRoZXIsIGJ1dAo+ID4gaXQncyBtdWNoIG1vcmUgbGlnaHQgd2VpZ2h0IHRo YW4gRFJNKS4KPgo+IFNlZSBteSBvdGhlciBtYWlsLCBidXQgeW91IGNhbiB3cml0ZSB2ZXJ5IHNp bXBsZSBkcm0gZHJpdmVycy4gQW5kIGlmCj4gdGhlcmUncyByZWFsbHkgYSBibG9hdCBwcm9ibGVt IGZvciBzbWFsbCBzeXN0ZW1zIHdlIGNhbiBhZGQgS2NvbmZpZyBrbm9icwo+IHRvIHRocm93IG91 dCBldmVyeXRoaW5nIG5vdCBuZWVkZWQgZm9yIHNpbXBsZSBkcml2ZXJzLiBUaGUgb25seSBwcm9i bGVtCj4gcmVhbGx5IGlzIHRoYXQgZXZlcnlvbmUgd2l0aCBzdWNoIHNpbXBsZSBkcml2ZXJzIGRv ZXNuJ3QgZXZlbiBjb25zaWRlciBkcm0KPiAiYmVjYXVzZSBJIGRvbid0IGhhdmUgYSBkZXNrdG9w IGdwdSIgd2hpY2ggaXMganVzdCBzaWxseSAtIGRybSBoYXMgYmVjb21lCj4gcmF0aGVyIGZsZXhp YmxlLiBBbmQgdGhhdCdzIGVzc2VudGlhbGx5IHdoeSB3cml0aW5nIHNpbXBsZSBkcm0gZHJpdmVy cwo+IHN0aWxsIGhhcyBhIGJpdCB0b28gbXVjaCBib2lsZXJwbGF0ZSwgc2luY2Ugbm8gb25lIHll dCBib3RoZXJlZCB0byBhZGQgYQo+IGJpdCBvZiBoZWxwZXIgc3VwcG9ydCBuZWVkZWQuCgpJcyB0 aGVyZSBhIHNpbXBsZSB3YXkgdG8gY29udmVydCBleGlzdGluZyBmYmRldiBkcml2ZXJzIHRvIERS TT8gTGV0J3Mgc2F5IEkgCndhbnQgdG8gY29udmVydCB0cmlkZW50ZmIgdG8gRFJNLCBrZWVwaW5n IHRoZSAyRCBhY2NlbGVyYXRpb24gKHBhbiwgZmlsbHJlY3QsIApjb3B5YXJlYSwgaW1hZ2VibGl0 KSB0byBiZSB1c2FibGUgYnkgdGhlIGNvbnNvbGUgKGFuZCBtYXliZSBleHRlbmQgaXQgdG8gWDEx IAp1c2luZyBzb21lIGdlbmVyaWMgMkQgZHJpdmVyPykKCi0tIApPbmRyZWogWmFyeQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGlu ZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVk ZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756698AbbIXRMk (ORCPT ); Thu, 24 Sep 2015 13:12:40 -0400 Received: from smtp-1b.atlantis.sk ([80.94.52.26]:58782 "EHLO smtp-1b.atlantis.sk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755204AbbIXRMj (ORCPT ); Thu, 24 Sep 2015 13:12:39 -0400 From: Ondrej Zary To: dri-devel@lists.freedesktop.org Subject: Re: No more new fbdev drivers, please Date: Thu, 24 Sep 2015 19:12:27 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748) Cc: Daniel Vetter , Austin S Hemmelgarn , Thomas Petazzoni , "linux-fbdev" , Teddy Wang , "Greg Kroah-Hartman" , "linux-kernel@vger.kernel.org" , Tomi Valkeinen , Laurent Pinchart , Daniel Vetter , Arnaud Patard , Dave Airlie , Sudip Mukherjee References: <5603EC15.9090605@ti.com> <560414EB.508@gmail.com> <20150924155912.GW3383@phenom.ffwll.local> In-Reply-To: <20150924155912.GW3383@phenom.ffwll.local> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201509241912.28739.linux@rainbow-software.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 24 September 2015 17:59:12 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. Is there a simple way to convert existing fbdev drivers to DRM? Let's say I want to convert tridentfb to DRM, keeping the 2D acceleration (pan, fillrect, copyarea, imageblit) to be usable by the console (and maybe extend it to X11 using some generic 2D driver?) -- Ondrej Zary