On Thu, Aug 23, 2018 at 1:49 PM, Laurent Pinchart laurent.pinchart@ideasonboard.com 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.
thanks -john