From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751714AbdBOMve (ORCPT ); Wed, 15 Feb 2017 07:51:34 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:41963 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751067AbdBOMvc (ORCPT ); Wed, 15 Feb 2017 07:51:32 -0500 Date: Wed, 15 Feb 2017 13:51:29 +0100 From: Maxime Ripard To: Laurent Pinchart Cc: Daniel Vetter , Daniel Stone , Daniel Vetter , Stefan Christ , dri-devel , Linux Kernel Mailing List Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Message-ID: <20170215125129.qxbvscwvudcav6j7@lukather> References: <20170214200951.GC22762@dvetter-linux.ger.corp.intel.com> <1826666.9g7KAGLBpO@avalon> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wl4mj2fjdzjteeo6" Content-Disposition: inline In-Reply-To: <1826666.9g7KAGLBpO@avalon> User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --wl4mj2fjdzjteeo6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Feb 14, 2017 at 11:25:08PM +0200, Laurent Pinchart wrote: > Hi Daniel, >=20 > On Tuesday 14 Feb 2017 21:09:51 Daniel Vetter wrote: > > On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > > > 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. > > >>>>=20 > > >>>> Cma fbdev is convient to add a legency fbdev. And still many Andro= id > > >>>> devices use fbdev now and at least double buffer is needed for the= se > > >>>> Android devices, so that a buffer flip can be operated. It will ne= ed > > >>>> some time for Android device vendors to abondon legency fbdev. So > > >>>> multi buffer for fbdev is needed. > > >>>=20 > > >>> 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. > > >>=20 > > >> If your point is that merging this patch will slow down the Android > > >> move away from fbdev, I disagree with that (obviously). > > >>=20 > > >> 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. > > >>=20 > > >> 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. > > >=20 > > > 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. > >=20 > > I think we need to make a distinction between fbdev the subsystem in the > > kernel, and fbdev the uabi: > >=20 > > - fbdev the subsystem is completely dead in upstream. I think we have f= ull > > 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. > > The real question, in my opinion, is how to get more users for the DRM/KM= S=20 > userspace API, to help killing the fbdev API. What's the incentive for=20 > userspace to migrate if we tell them that we're going to support the fbde= v API=20 > forever, and will even go through the trouble of extending the supported= =20 > feature set ? I have a customer who wouldn't have migrated their userspac= e to=20 > DRM/KMS if these two patches had been merged a few years ago. If those patches are not in, then I can see three ways to support old / deficient userspaces: 1) Carry those patches out of tree 2) Write an fbdev driver for the display engine 3) Rewrite the userspace components While 3. would arguably be the best option, this isn't always one, unfortunately. And as a community, I think 1 and 2 are not very good for us. 1. will drive away vendors from our community, undermining the effort we've been doing for a few years. And 2 will result in a driver we really don't want to merge (so useless), and even if it would out of tree, that would make it one less system / board / SoC *with* DRM/KMS APIs, reducing the interest of switching for application developpers. If we really want to make people switch to DRM / KMS, we have to make it ubiquitous. And if we want to make it ubiquitous, we really want to have a transition period where people will have both APIs, supported in a decent enough way. And then, that's a win for everyone, because in the process you get fbdev (booo!) and KMS (yay!), allowing for people to switch over, and eventually kill the emulation entirely. But it's far too early for that. I mean, we don't even have an fbv replacement yet... Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --wl4mj2fjdzjteeo6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYpE7NAAoJEBx+YmzsjxAgAlIP/2hvkJ0VYagy2UJ6F+3powoI mqLLlD++vyT2ubSyVT0CUHNlsOacI9iftWm8Gx2dBKV2jzKJdruALSwBrM7r458X zjSiTTE699YjaI1W/0vuJYgsXSimHp9kcqw6JHgar9k/IasrEoSrCymn+vi1zadA tJhyWzCUJ4hPyWhghskdVZxUA6EF3Pwp+M6jNmByOI6+RUP0yIJcsCLNyiPjGX7s KcTx2BcrUT/6QKs/CCaKUHB7EMOD78SmQ6ZdZvO3jCZjl5lyB0/+TF+y6N8Ps1hW 9qgLJTp41Es1CIuvMCpEzbo3210tqOhomf0ADhLVC6jG/vOx7fKQlPmoeUuh5wr+ nrDJTKeFSC7CqEcOGXY4VQK8+9COonmLUE+i1nBW9B6Cvaxh6A95KQABiMCFJ19r pfashe2P1pgzrkfxAJJtLPNHDrpq8pKFXlzwsAhR6csgxv25+c7YRaDvHTx+cY9k 4qLNxvoCY7tto9OCSASAX27R2VqJvCVlpeJ5txKoUR5WP/+jUdC9Udaq1UFHt0tq PFJlu6pmVAZxIZMDFLD2rrjXbFvYM3nXWGWikFXK8yAyq0eSdp/g+cyaPdEsN+CV zIfym62LR6+0x5Rt1+qXo/rEOJ2UTS2V1fMPBHv1c9ObwUT3PZ3yIL4lyePT2pQw OXZo3g6nmwWfhioG+C9i =a/T4 -----END PGP SIGNATURE----- --wl4mj2fjdzjteeo6--