Re: Switching fb backend back to default
On Mon, Mar 18, 2019 at 19:48 Oliver Pinter wrote: > > > On Sunday, March 17, 2019, Johannes Lundberg wrote: > >> On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot >> wrote: >> >> > On Sun, 17 Mar 2019 16:32:43 + >> > Johannes Lundberg wrote: >> > >> > > >> > > On 3/17/19 3:34 PM, Greg V wrote: >> > > > >> > > > >> > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg >> > > > 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 :) > > > > As workaround, can't you turn on the display with intel_backlight? > AFAIK, that can only adjust brightness. The display panel is completely shut off. >> >> > >> > > >> > > ___ >> > > 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" >> > >> > >> > -- >> > Emmanuel Vadot >> > >> ___ >> 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 >> " >> > ___ 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"
Re: Switching fb backend back to default
On Mon, Mar 18, 2019 at 19:28 Pete Wright wrote: > > > On 3/17/19 2:50 PM, Johannes Lundberg wrote: > > On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot > wrote: > > > >> On Sun, 17 Mar 2019 16:32:43 + > >> Johannes Lundberg wrote: > >> > >>> On 3/17/19 3:34 PM, Greg V wrote: > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg > 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 You probably have to exit X to unload the driver so I’m not sure it’s that much better than a reboot :) Either way, it will make simple testing a lot easier. > > -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"
Re: Switching fb backend back to default
On Sunday, March 17, 2019, Johannes Lundberg wrote: > On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot > wrote: > > > On Sun, 17 Mar 2019 16:32:43 + > > Johannes Lundberg wrote: > > > > > > > > On 3/17/19 3:34 PM, Greg V wrote: > > > > > > > > > > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg > > > > 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 :) As workaround, can't you turn on the display with intel_backlight? > > > > > > > > > > ___ > > > 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" > > > > > > -- > > Emmanuel Vadot > > > ___ > 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" > ___ 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"
Re: Switching fb backend back to default
On 3/17/19 2:50 PM, Johannes Lundberg wrote: On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot wrote: On Sun, 17 Mar 2019 16:32:43 + Johannes Lundberg wrote: On 3/17/19 3:34 PM, Greg V wrote: On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg 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"
Re: Switching fb backend back to default
On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot wrote: > On Sun, 17 Mar 2019 16:32:43 + > Johannes Lundberg wrote: > > > > > On 3/17/19 3:34 PM, Greg V wrote: > > > > > > > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg > > > 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 :) > > > > > ___ > > 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" > > > -- > Emmanuel Vadot > ___ 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"
Re: Switching fb backend back to default
On Sun, 17 Mar 2019 16:32:43 + Johannes Lundberg wrote: > > On 3/17/19 3:34 PM, Greg V wrote: > > > > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg > > 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Emmanuel Vadot ___ 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"
Re: Switching fb backend back to default
On 3/17/19 3:34 PM, Greg V wrote: > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg > 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). ___ 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"
Re: Switching fb backend back to default
On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg 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. ___ 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"
Switching fb backend back to default
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? Cheers /Johannes ___ 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"
