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: >> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
