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

[John Stultz]

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:
>> Hi John,
>>
>> On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote:
>> > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote:
>> > > Hey Noralf, all,
>> > >
>> > >   I've been digging for a bit on the regression that this patch has
>> > >
>> > > tripped on the HiKey board as reported here:
>> > > https://lkml.org/lkml/2018/8/16/81
>> > >
>> > > The first issue was that the kirin driver was setting
>> > > mode_config.max_width/height = 2048, which was causing errors as the
>> > > the requested resolution was 1920x2160 (due to surfaceflinger
>> > > requesting y*2 for page flipping).
>> >
>> > Hey Noralf,
>> >   Sorry, I know your probably sick of me. But I just wanted to circle
>> > around on this little bit. So part of the issue I found earlier, was
>> > that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support
>> > Surfaceflinger's request for page flipping.
>>
>> 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. But in the meantime, keeping the fbdev
method running is important so we have a functioning device for
testing AOSP w/ mainline.

thanks
-john