Re: [PATCH] drm/fb-helper: Restore first connection behaviour on deferred setup

From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	John Stultz <john.stultz@linaro.org>,
	Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH] drm/fb-helper: Restore first connection behaviour on deferred setup
Date: Fri, 30 Jun 2017 20:13:58 +0200	[thread overview]
Message-ID: <CAKMK7uH4OMjp1vZEXB=0qn4oaOArLBT3eSjS7P5Hm_3APLi_vg@mail.gmail.com> (raw)
In-Reply-To: <20170630165155.8658-1-Liviu.Dudau@arm.com>

On Fri, Jun 30, 2017 at 6:51 PM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
> if no output is connected at framebuffer setup time, we get a default
> 1024x768 mode that is going to be used when we first connect a monitor.
> After the commit, on first connection after deferred setup, we probe
> the monitor and get the preferred resolution, but no mode get set
> because the drm_fb_helper_hotplug_event() function returns early
> when the setup has been deferred. That is different from what happens
> on a second re-connect of the monitor, when the native mode get set.
>
> Create a more consistent behaviour by checking in the
> drm_fb_helper_hotplug_event() function if the deferred setup is still
> active. If not, that means we now have a valid framebuffer that can be
> used for setting the correct mode.
>
> Fixes: b0aa06e9a7fd ("drm/fb-helper: Support deferred setup")
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>

I thought the analysis over irc was that fbcon picked a different
driver as it's console, and that's why nothing shows up on the malidp
output in the deferred case? That's mildly annoying, but iirc fbcon
has always been rather erratic in multi-gpu setups. Although I thought
that it would by default bind all fbdev drivers as consoles (and then
you need to rebind the right console driver, if the right Kconfig is
enabled, through sysfs).

Either way if the register_framebuffer() call in initial_config isn't
good enough, then we need to add the set_par in initial_config
unconditionally, not just in the deferred probe case. Just disable
fbcon entirely for testing, in that case even without deferred probing
nothing will show up.

I'd say if this is still needed in the single gpu case then we need to
investigate more, but for multi-gpu it is what it is (aka fbcon is not
great).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx