Message-ID: <3257247.SMToChRJ8z@avalon>
Date:   Fri, 17 Feb 2017 13:30:40 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     Daniel Vetter <daniel@...ll.ch>,
        Daniel Stone <daniel@...ishbar.org>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Stefan Christ <s.christ@...tec.de>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

Hi Maxime,

On Wednesday 15 Feb 2017 13:51:29 Maxime Ripard wrote:
> On Tue, Feb 14, 2017 at 11:25:08PM +0200, Laurent Pinchart wrote:
> > 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.
> >>>>>> 
> >>>>>> 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.
> > 
> > The real question, in my opinion, is how to get more users for the DRM/KMS
> > userspace API, to help killing the fbdev API. What's the incentive for
> > userspace to migrate if we tell them that we're going to support the fbdev
> > API forever, and will even go through the trouble of extending the
> > supported feature set ? I have a customer who wouldn't have migrated
> > their userspace to 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.

I agree that it's not a solution that can be deployed overnight, but it's 
clearly what we all (as in kernel community and system vendors) need to head 
towards.

> 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.

Haven't we had such a grace period already, until the fbdev subsystem stopped 
accepting new drivers ? It has hardly been an overnight switch.

> 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...

We're talking about http://s-tech.elsat.net.pl/fbv/, whose latest release 
dates from 2011 ? :-)

https://github.com/tomba/kmsxx/blob/master/utils/kmsview.cpp

It won't be hard to add support for BMP, GIF, JPG or PNG.

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists