linux-kernel - Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPj87rNAOT-9pZ_A9APSr5ed-zkedwVQiDm_xX05ygVnBzynwQ@mail.gmail.com>
Date:   Mon, 13 Feb 2017 11:20:51 +0000
From:   Daniel Stone <daniel@...ishbar.org>
To:     Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Stefan Christ <s.christ@...tec.de>
Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

Hi Maxime,

On 13 February 2017 at 10:54, Maxime Ripard
<maxime.ripard@...e-electrons.com> 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.

> However, what I do see is that three different people/organisations
> have now expressed interest in that feature, on three different
> SoCs. If that patch needed a significant rework of the fbdev layer,
> then yes, I might agree that it's not worth it. But in this case, it's
> pretty trivial.
>
> The only people you're "punishing" here with that kind of concern are
> the people who actually play fair and want not to have any patches and
> everything upstream.

I would hazard a guess that most users of this have out-of-tree GPU drivers.

> I guess a much better strategy would be to provide an incentive to
> moving to KMS. And I truely think there's one already, so it's just a
> matter of time before people switch over. Fbdev emulation or not.

The concern makes sense, but on the other hand, fbdev is deprecated:
no new drivers, and no new features.

Cheers,
Daniel