Re: Switching fb backend back to default

From: Johannes Lundberg <johalun0_at_gmail.com>
Date: Mon, 18 Mar 2019 20:06:33 +0000
On Mon, Mar 18, 2019 at 19:48 Oliver Pinter <oliver.pinter_at_hardenedbsd.org>
wrote:

>
>
> On Sunday, March 17, 2019, Johannes Lundberg <johalun0_at_gmail.com> wrote:
>
>> On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot <manu_at_bidouilliste.com>
>> wrote:
>>
>> > 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).
>>
>>
>> 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_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>
>> >
>> _______________________________________________
>> 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
>> "
>>
>
Received on Mon Mar 18 2019 - 19:06:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC