From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755571AbbI2HCZ (ORCPT ); Tue, 29 Sep 2015 03:02:25 -0400 Received: from mail-wi0-f182.google.com ([209.85.212.182]:37295 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755425AbbI2HCP (ORCPT ); Tue, 29 Sep 2015 03:02:15 -0400 Date: Tue, 29 Sep 2015 09:05:08 +0200 From: Daniel Vetter To: Bernie Thompson Cc: Geert Uytterhoeven , Alex Deucher , Daniel Vetter , Thomas Petazzoni , linux-fbdev , Teddy Wang , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , DRI Development , Tomi Valkeinen , Laurent Pinchart , Arnaud Patard , Dave Airlie , Sudip Mukherjee Subject: Re: No more new fbdev drivers, please Message-ID: <20150929070508.GZ3383@phenom.ffwll.local> Mail-Followup-To: Bernie Thompson , Geert Uytterhoeven , Alex Deucher , Thomas Petazzoni , linux-fbdev , Teddy Wang , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , DRI Development , Tomi Valkeinen , Laurent Pinchart , Arnaud Patard , Dave Airlie , Sudip Mukherjee References: <5603EC15.9090605@ti.com> <20150924144621.40e26f0a@free-electrons.com> <20150924152312.GV3383@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 4.1.0-2-amd64 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 28, 2015 at 01:52:31PM -0700, Bernie Thompson wrote: > On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven > wrote: > > The smallest of these (udl) still counts in at ca. 2800 LoC, > > Note udlfb.c, the original fbdev driver that I helped write and that the > udl DRM driver was based on, is ~1800 LoC ... so we're actually talking in > the ballpark of 2x (rather than 10x) between fbdev and DRM in this case. > That said, the complexity difference is probably higher than the LoC > difference. I know I personally have struggled in the shift from > understanding fbdev to understanding DRM. udl has a bit of room for improvement, we really should push the worker logicy for fbdev emulation into the core drm fbdev helpers using the ->dirtyfb callback. That should rip out quite a few lines. The other thing to consider is that drm/udl supports PRIME buffer sharing for seamlessly extending your desktop by just plugging in an usb dongle. > The fact that there's drivers of both types and USB hardware might make udl > may be a good driver to use as a base for any additional simplification / > helper work. David Airlie and David Herrmann both have this hardware. David > Airlie did the port from fbdev to DRM, so he's made it an exemplary > driver. And if anyone needs any hardware which works with udlfb and udl, > we're happy to send free hardware to any programmers who are willing to > contribute in the form of code or testing: > http://plugable.com/projects/plugable-open-source-hardware-samples-program For example drivers I think it's better to look at the latest drm driver merged - those are up-to-date wrt best practices. udl has already accumulated a bit of cruft (e.g. still using legacy modeset helpers and not the atomic ones). > More simplification and documentation would be great. In particular, the > optimization for the connector+encoder+crtc combination others have > mentioned seems like it would be worthwhile. Atomic helpers already make almost everything optional except for the crtc-level enable/disable callbacks and the per-plane atomic_plane_update (for buffer flips/panning/rotation/...). So a comibined helper would be mostly for cutting down the structure setup/teardown boilerplate. So should be fairly easy to implement even for drm beginners (when using one of the latest drivers as a template for what needs to be done). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch