Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: John Stultz <john.stultz@linaro.org>
Cc: "David Lechner" <david@lechnology.com>,
	"Xinliang Liu" <xinliang.liu@linaro.org>,
	"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Noralf Trønnes" <noralf@tronnes.org>
Subject: Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
Date: Fri, 24 Aug 2018 11:57:25 +0300	[thread overview]
Message-ID: <6918283.49Os4COXYy@avalon> (raw)
In-Reply-To: <CALAqxLVR8=ddbKhw-X-yoHpKEzLFTbckzTWdHz_FuTAg7Wr_iQ@mail.gmail.com>

Hi John,

On Friday, 24 August 2018 00:12:46 EEST John Stultz wrote:
> On Thu, Aug 23, 2018 at 1:49 PM, Laurent Pinchart wrote:
> > On Thursday, 23 August 2018 20:48:40 EEST John Stultz wrote:
> >> On Thu, Aug 23, 2018 at 1:09 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >>> On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote:
> >>>> Possibly slightly out of topic, but we're in 2018, is there any plan
> >>>> to make SurfaceFlinger move away from FBDEV ?
> >>> 
> >>> Is surfaceflinger really using direct fbdev still (maybe for boot-up)?
> >>> Or is this just an artifact of the mali blob hwcomposer backend?
> >> 
> >> Mostly its due to the simple fbdev being a legacy solution on android
> >> that works out of the box.
> >> I do suspect the android devs hope to retire it, which is why I'm
> >> working on getting things going w/ the drm_hwcomposer right now so we
> >> can get away from the fbdev.
> > 
> > That would be good news. Are there many Android components other than
> > vendor- specific hwcomposer implementations that still use fbdev ?
> 
> So yea, I can't really speak about what the various vendors are doing,
> as I don't really know, but I'm aware there are still a few (in some
> cases major) vendors who still use fbdev on their shipping devices
> with their custom hwcomposer code.
> 
> Other then that, to my knowledge AOSP only has a default fallback
> hwcomposer that uses fbdev, which is what we've used here as we didn't
> want to take the vendor's proprietary hwcomposer blob.  But again,
> moving to the drm_hwcomposer is the shiny bright future, as soon as a
> few remaining issues are sorted upstream.

Last time I looked (and that was years ago) the init process also used fbdev 
to render the boot splash screen. Is it still the case ? If so is there any 
chance you could add a fix for that to your todo list ? :-)

-- 
Regards,

Laurent Pinchart

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx