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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
