On 3/17/19 2:50 PM, Johannes Lundberg wrote:
On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot <m...@bidouilliste.com> wrote:
On Sun, 17 Mar 2019 16:32:43 +0000
Johannes Lundberg <johal...@gmail.com> wrote:
On 3/17/19 3:34 PM, Greg V wrote:
On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg
<johal...@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).
Yeah a normal user would never unload it. Since I mostly ssh to my test
machines I think I’m fine personally with losing the display while
unloading.
Keyboard input still works though and at least it doesn’t crash anymore :)
that's awesome, so in theory we will be able to upgrade the drm-kmod and
use the new driver without a reboot. i like that as a hacker and
end-user :)
-pete
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
