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

[Laurent Pinchart]

Hi Daniel,

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. I'd rather 
*reduce* the supported feature set over time until we can finally switch fbdev 
off.

> 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 :-)

-- 
Regards,

Laurent Pinchart