Switching fb backend back to default

[Emmanuel Vadot]

On Sun, 17 Mar 2019 16:32:43 +0000
Johannes Lundberg <johalun0 at gmail.com> wrote:

> 
> On 3/17/19 3:34 PM, Greg V wrote:
> >
> >
> > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg
> > <johalun0 at gmail.com> wrote:
> >> Hi
> >>
> >> I'm working on making i915kms unload properly. I've come to what I think
> >> is the last issue. The drm driver unloads ok, the "efifb" backend is
> >> restored (according to logs) and vt_efifb_init() is being called but the
> >> screen (laptop built in display) stays black. The system seems
> >> operational otherwise. If I load i915kms again in this state I get back
> >> a visible (i915kms) framebuffer.
> >>
> >> Did we ever have this working so it's known to work?
> >
> > Recently on the linux kernel mailing list:
> >
> > http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html
> >
> > > Of course, once native drivers like i915 or radeon take over, such a
> > framebuffer is toast... [6]
> >
> > > [6] linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb()
> > > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe()
> >
> > So it seems like efifb is not supposed to work after a driver has been
> > loaded at least once.
> >
> >
> Hmm, well the code is there to handle switching back to the boot time
> fb. What I think is happening is that i915 powers off the displays at
> unload and vt doesn't know how to power on (or that it should).
> 

 That and if the display pipeline is de-configured or the resolution
changed you cannot reset it to the original state.
 Unloading drm modules is only useful for testing (and finding leaks).

> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"


-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>