From: Daniel Stone <daniel@fooishbar.org> To: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Daniel Vetter <daniel.vetter@intel.com>, Stefan Christ <s.christ@phytec.de> Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Date: Mon, 13 Feb 2017 11:20:51 +0000 [thread overview] Message-ID: <CAPj87rNAOT-9pZ_A9APSr5ed-zkedwVQiDm_xX05ygVnBzynwQ@mail.gmail.com> (raw) In-Reply-To: <20170213105422.2cfr7av6ha2vzdlk@lukather> Hi Maxime, On 13 February 2017 at 10:54, Maxime Ripard <maxime.ripard@free-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
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Stone <daniel@fooishbar.org> To: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Daniel Vetter <daniel.vetter@intel.com>, Stefan Christ <s.christ@phytec.de>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, dri-devel <dri-devel@lists.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Date: Mon, 13 Feb 2017 11:20:51 +0000 [thread overview] Message-ID: <CAPj87rNAOT-9pZ_A9APSr5ed-zkedwVQiDm_xX05ygVnBzynwQ@mail.gmail.com> (raw) In-Reply-To: <20170213105422.2cfr7av6ha2vzdlk@lukather> Hi Maxime, On 13 February 2017 at 10:54, Maxime Ripard <maxime.ripard@free-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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-02-13 11:20 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-02 10:31 [PATCH v2 0/2] drm: Support framebuffer panning Maxime Ripard 2017-02-02 10:31 ` Maxime Ripard 2017-02-02 10:31 ` [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Maxime Ripard 2017-02-02 10:31 ` Maxime Ripard 2017-02-09 17:04 ` Daniel Vetter 2017-02-09 17:04 ` Daniel Vetter 2017-02-10 15:27 ` Maxime Ripard 2017-02-10 15:27 ` Maxime Ripard 2017-02-12 12:28 ` Laurent Pinchart 2017-02-12 12:28 ` Laurent Pinchart 2017-02-13 10:54 ` Maxime Ripard 2017-02-13 10:54 ` Maxime Ripard 2017-02-13 11:20 ` Daniel Stone [this message] 2017-02-13 11:20 ` Daniel Stone 2017-02-14 20:09 ` Daniel Vetter 2017-02-14 20:09 ` Daniel Vetter 2017-02-14 21:25 ` Laurent Pinchart 2017-02-14 21:25 ` Laurent Pinchart 2017-02-15 12:51 ` Maxime Ripard 2017-02-15 12:51 ` Maxime Ripard 2017-02-17 11:30 ` Laurent Pinchart 2017-02-15 12:38 ` Maxime Ripard 2017-02-15 12:38 ` Maxime Ripard 2017-02-17 11:23 ` Laurent Pinchart 2017-02-17 11:23 ` Laurent Pinchart 2017-02-02 10:31 ` [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC Maxime Ripard 2017-02-02 10:31 ` Maxime Ripard 2017-02-09 17:01 ` Daniel Vetter 2017-02-09 17:01 ` Daniel Vetter 2017-02-09 17:38 ` Daniel Stone 2017-02-09 17:38 ` Daniel Stone 2017-02-09 19:06 ` Daniel Vetter 2017-02-09 19:06 ` Daniel Vetter 2017-02-10 14:06 ` Ville Syrjälä 2017-02-10 14:06 ` Ville Syrjälä 2017-02-13 10:35 ` Maxime Ripard 2017-02-13 10:35 ` Maxime Ripard 2017-02-13 14:45 ` Ville Syrjälä 2017-02-13 14:45 ` Ville Syrjälä 2017-02-15 14:06 ` Maxime Ripard 2017-02-15 14:06 ` Maxime Ripard 2017-02-16 12:28 [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Tobias Jakobi 2017-02-16 18:41 ` Maxime Ripard 2017-02-17 12:49 ` Tobias Jakobi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAPj87rNAOT-9pZ_A9APSr5ed-zkedwVQiDm_xX05ygVnBzynwQ@mail.gmail.com \ --to=daniel@fooishbar.org \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-kernel@vger.kernel.org \ --cc=maxime.ripard@free-electrons.com \ --cc=s.christ@phytec.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.