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>Received on Sun Mar 17 2019 - 20:35:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC