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:
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