Re: Dell R440 with Debian 10.7.0 Display Issues
On Tue 06 Apr 2021 at 15:53:43 (+0300), Andrei POPESCU wrote:
> On Ma, 06 apr 21, 12:00:53, Brian wrote:
> > On Mon 05 Apr 2021 at 23:17:09 +0100, Brian wrote:
> > > On Mon 05 Apr 2021 at 22:54:37 +0300, Andrei POPESCU wrote:
> > > > On Sb, 27 mar 21, 10:48:43, Brian wrote:
> > > > >
> > > > > I did previously note the reiteration and acknowledge that video
> > > > > hardware could require non-free firmware. However, does a d-i carrying
> > > > > such firmware ever make any attempt to install it? As I understand it,
> > > > > the installer is designed to probe for and load non-free firmware for
> > > > > network hardware only.
> > > >
> > > > [citation needed]
> > >
> > > I think I asked my question first.
>
> My reply was needlessly harsh, though definitely not intended as such.
>
> I'm still curious where you got the impression that d-i loads firmware
> for network hardware only.
>
> > However, perhaps the hw-detect udeb will shed some light on the matter.
>
> I'd assume that any firmware package present on the unofficial installer
> is meant to be installed by d-i. It also seems much easier to me to just
> install any firmware (package) needed than to specifically filter for
> network devices only.
>
> At the moment I don't have the hardware to test any of this though.
I may do, but I had problems installing buster onto a stick (I think
it's unreliable) so I don't have installer/syslog to check. I believe
the laptop wants i915/kbl_dmc_ver1_04.bin from firmware-misc-nonfree.
However, during installation, AFAICT, firmware-misc-nonfree wasn't
installed. I think the reason is two-fold in this case. I suspect,
without evidence, that the d-i is loading modules in a customised
manner (perhaps AVAIL_MODULES in bin/hw-detect), and that it makes
do with vga16fb rather than anything fancier, like i915.
Secondly, even if i915 were to be loaded, I don't think the
d-i could determine that the desired kbl_dmc_ver1_04.bin is
actually available in firmware-misc-nonfree (which is on the
non-official, firmware-inclusive media).
Here's what I think the d-i actually does (very sketchy).
The kernel finds bits of hardware and either loads the appropriate
modules or hands a list back to the d-i (I'm not sure about that bit).
Whenever modules are loaded, the d-i (bin/check-missing-firmware)
scans dmesg¹, parses the failure messages in check_missing(), looks up
the correct deb in /usr/share/hw-detect/firmware-map (not sure who,
exactly, does that), finds it and "installs"² it.
Here's a fragment of the (sorted) map³:
lib/firmware/i915/bxt_dmc_ver1_07.bin firmware-misc-nonfree non-free
lib/firmware/i915/kbl_dmc_ver1.bin firmware-misc-nonfree non-free
lib/firmware/i915/kbl_dmc_ver1_01.bin firmware-misc-nonfree non-free
lib/firmware/i915/skl_dmc_ver1.bin firmware-misc-nonfree non-free
There's no entry for kbl_dmc_ver1_04.bin, so no firmware blob or .deb
installation could occur.
Sometime I'll get round to installing onto a more reliable device,
so I can look in more detail⁴. Unfortunately, as has happened before,
I have to preserve a Windows installation on the laptop's internal
drive for the time being.
¹ It maintains a record of the timestamps, so it doesn't have to rescan
what it's already read; see get_fresh_dmesg().
² install_firmware_pkg() appears to cache the name of the deb for
installing later, unpacks it, copies the firmware, then deletes
the deb, thereby preventing installation of any dependencies
prematurely.
³ The firmware-map is identical for the official d-i and the non-free
firmware-inclusive buster versions, and the alpha3 version of bullseye.
⁴ I haven't yet checked why bin/check-missing-firmware didn't seem to
be finding/copying loose firmware files in buster as it did in wheezy.
I think the answer should lie in bin/check-missing-firmware.
Cheers,
David.
Reply to: