[Intel-gfx] [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
John Stultz
john.stultz at linaro.org
Thu Aug 23 21:12:46 UTC 2018
On Thu, Aug 23, 2018 at 1:49 PM, Laurent Pinchart
<laurent.pinchart at 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 at 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
More information about the Intel-gfx
mailing list