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: <20170213105422.2cfr7av6ha2vzdlk@lukather>
Date:   Mon, 13 Feb 2017 11:54:22 +0100
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:     dri-devel@...ts.freedesktop.org,
        Daniel Vetter <daniel.vetter@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Sean Paul <seanpaul@...omium.org>,
        Stefan Christ <s.christ@...tec.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma
 fbdev

Hi Laurent,

On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
> Hi Maxime,
> 
> Thank you for the patch.
> 
> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
> > From: Xinliang Liu <xinliang.liu@...aro.org>
> > 
> > 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.

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

Ma

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ