On Fri, Jun 30, 2017 at 08:13:58PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 6:51 PM, Liviu Dudau <Liviu.Dudau@xxxxxxx> 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@xxxxxxx>
> > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
>
> 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).
That's right, fbcon picks a different driver and binds to it. But
before the patch, on the first connection with a monitor that happened
after setup (i.e. when the fbdev emulation mode set the default 1024x768
mode), a full atomic modeset was trigger for the driver that had the
connection and the "card" output was enabled. Now with your patch that
does not happen on the first connection, but it does after I turn off and
back on the monitor. I know that is how most computer problems are solved,
but still ... :)
>
> 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.
Actually the un-ballanced call to set_par happens with your patch (it
gets called for all hotplug events that are *not* deferred. I was trying
to balance things and call set_par also for deferred setups where the
__drm_fb_helper_initial_config() call succeeded. And the fact that we do
call set_par in the hotplug path even when the setup is not deferred
tells me that register_framebuffer() is probably not enough.
>
> 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).
I think single gpu case hides the problem because fbcon forces the right
sequence of calls. And I think the old behaviour was correct, as I was
getting output of the second "card" on hotplug, now I have to turn the
monitor off and on again to get some signal sync.
Best regards,
Liviu
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
