On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > Hi Maxime, > > On 13 February 2017 at 10:54, Maxime Ripard > <maxime.ripard@xxxxxxxxxxxxxxxxxx> 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. 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 :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
