Date: Sun, 17 Mar 2019 16:32:43 +0000 From: Johannes Lundberg <johalun0@gmail.com> To: Greg V <greg@unrelenting.technology> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Switching fb backend back to default Message-ID: <6ea64218-2b6d-fc9a-01b5-ed07bd23c783@gmail.com> In-Reply-To: <1552836887.1930.0@unrelenting.technology> References: <95dfadc9-8341-b2a5-7b58-e94f46b5fa90@gmail.com> <1552836887.1930.0@unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/17/19 3:34 PM, Greg V wrote: > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg > <johalun0@gmail.com> wrote: >> Hi >> >> I'm working on making i915kms unload properly. I've come to what I thi= nk >> 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 t= he >> screen (laptop built in display) stays black. The system seems >> operational otherwise. If I load i915kms again in this state I get bac= k >> 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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6ea64218-2b6d-fc9a-01b5-ed07bd23c783>