From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753682AbbI1Wvv (ORCPT ); Mon, 28 Sep 2015 18:51:51 -0400 Received: from smtp.domeneshop.no ([194.63.252.55]:58542 "EHLO smtp.domeneshop.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752226AbbI1Wvt (ORCPT ); Mon, 28 Sep 2015 18:51:49 -0400 Subject: Re: No more new fbdev drivers, please To: Emil Velikov References: <5603EC15.9090605@ti.com> <5607EA9C.7040909@tronnes.org> Cc: Tomi Valkeinen , Greg Kroah-Hartman , linux-fbdev , DRI Development , Thomas Petazzoni , Teddy Wang , Daniel Vetter , "linux-kernel@vger.kernel.org" , Laurent Pinchart , Dave Airlie , Sudip Mukherjee From: =?UTF-8?Q?Noralf_Tr=c3=b8nnes?= Message-ID: <5609C47A.6030809@tronnes.org> Date: Tue, 29 Sep 2015 00:51:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Den 27.09.2015 18:08, skrev Emil Velikov: > Hi all, > > On 27 September 2015 at 14:09, Noralf Trønnes wrote: >> Den 24.09.2015 14:27, skrev Tomi Valkeinen: >>> 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". >> >> I have done some work [1] to try and make fbtft look more like the rest >> of the kernel (doc [2]), but that work will result in an almost complete >> rewrite of fbtft. > From a very quick skim fbtft looks pretty much like drm/panel. We > presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have > you had a look at these ? Thanks, that was useful. I can use drm_panel to setup the controller (prepare) and do backlight (enable/disable), but I need a way to send framebuffer changes. I could do this: struct tinydrm_panel_funcs { int (*update)(struct drm_framebuffer *fb, struct drm_gem_cma_object *cma_obj, unsigned flags, unsigned color, struct drm_clip_rect *clips, unsigned num_clips); }; struct tinydrm_panel { struct drm_panel panel; u32 width; u32 height; void *dev_private; const struct tinydrm_panel_funcs *funcs; };