From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754773AbdBNUKB (ORCPT ); Tue, 14 Feb 2017 15:10:01 -0500 Received: from mail-yb0-f195.google.com ([209.85.213.195]:34520 "EHLO mail-yb0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754181AbdBNUJz (ORCPT ); Tue, 14 Feb 2017 15:09:55 -0500 Date: Tue, 14 Feb 2017 21:09:51 +0100 From: Daniel Vetter To: Daniel Stone Cc: Maxime Ripard , Daniel Vetter , Stefan Christ , Laurent Pinchart , dri-devel , Linux Kernel Mailing List Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Message-ID: <20170214200951.GC22762@dvetter-linux.ger.corp.intel.com> Mail-Followup-To: Daniel Stone , Maxime Ripard , Daniel Vetter , Stefan Christ , Laurent Pinchart , dri-devel , Linux Kernel Mailing List References: <9b4f80f213b50959d168e6f22b21ee784fe26da5.1486031436.git-series.maxime.ripard@free-electrons.com> <2662533.Ps9k37FiVM@avalon> <20170213105422.2cfr7av6ha2vzdlk@lukather> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux dvetter-linux.ger.corp.intel.com 4.8.15-200.fc24.x86_64 User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > Hi Maxime, > > On 13 February 2017 at 10:54, Maxime Ripard > wrote: > > On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >> > This patch add a config to support to create multi buffer for cma fbdev. > >> > Such as double buffer and triple buffer. > >> > > >> > Cma fbdev is convient to add a legency fbdev. And still many Android > >> > devices use fbdev now and at least double buffer is needed for these > >> > Android devices, so that a buffer flip can be operated. It will need > >> > some time for Android device vendors to abondon legency fbdev. So multi > >> > buffer for fbdev is needed. > >> > >> How exactly do we expect Android to move away from fbdev if we add features to > >> the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a > >> thing from the past and that they'd better migrate now. > > > > If your point is that merging this patch will slow down the Android > > move away from fbdev, I disagree with that (obviously). > > > > I don't care at all about Android on my platform of choice, but don't > > see how that merging this patch will change anything. > > > > Let's be honest, Android trees typically have thousands of patches on > > top of mainline. Do you think a simple, 15 LoC, patch will make any > > difference to vendors? If they want to stay on fbdev and have that > > feature, they'll just merge this patch, done. > > So, in that case, why not just let them do that? They'd already have > to add patches to use this, surely; we don't have anything in mainline > kernels which allows people to actually use this larger allocation. > Apart from software mmap() and using panning to do flips, but I'm > taking it as a given that people shipping Android on their devices > aren't using software rendering. I think we need to make a distinction between fbdev the subsystem in the kernel, and fbdev the uabi: - fbdev the subsystem is completely dead in upstream. I think we have full agreement on that. - fbdev the uabi isn't, and if we can get more users from fbdev based drivers to kms/atomic drivers by adding fairly simple stuff like this, I'm all for it. Which means: Yes, I fully plan to merge this, it makes sense. It even _helps_ by making fbdev-the-subsystem even deader. Making live hard for out-of-tree folks or folks with shit userspace doesn't make sense, at least if the only benefit for us is that we'll feel pure about our intentions :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch