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