Date: Sun, 17 Mar 2019 18:34:47 +0300 From: Greg V <greg@unrelenting.technology> To: Johannes Lundberg <johalun0@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Switching fb backend back to default Message-ID: <1552836887.1930.0@unrelenting.technology> In-Reply-To: <95dfadc9-8341-b2a5-7b58-e94f46b5fa90@gmail.com> References: <95dfadc9-8341-b2a5-7b58-e94f46b5fa90@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1552836887.1930.0>