DMI mismatch on OEM-rebranded laptops causing driver issues (LAPBC710 / Avell B.On)

--6881311d_1a6e0689_1733
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hey everyone, how=E2=80=99s it going=3F
(=46eel free to correct me if I=E2=80=99m wrong...)

When we install Debian on a computer and Linux is installed, part of the =
process during the kernel build involves checking some DMI information fr=
om your machine.
Some computers (maybe most of them), through a partner or reseller, modif=
y certain information on the motherboard by injecting custom values like:=

Serial key (used for Windows), product name, vendor, etc.

Sometimes, the Linux kernel project doesn=E2=80=99t have those reseller/v=
endor entries listed, so the DMI data doesn=E2=80=99t match any known mod=
el in the kernel database.
In my case, I=E2=80=99m using an Intel NUC LAPBC710 laptop kit, but the r=
eseller in Brazil branded it as =22Avell B.On=22.
Even though the LAPBC710 model is listed in the Linux database (for examp=
le), this mismatch can make it harder to properly install or detect some =
components for correct driver usage.
A classic example for me is SO=46 (the audio driver).

So the question is:
How do you guys deal with DMI info that doesn=E2=80=99t match what=E2=80=99=
s listed in the kernel=3F
Maybe submit some kind of patch to the kernel with a DMI match override=3F=


Since this info is mostly =E2=80=9Cread-only,=E2=80=9D is there any tool =
or installer option in Debian that can help it recognize the correct mode=
l name or DMI string=3F

Best,
--6881311d_1a6e0689_1733
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>Hey everyone, how=E2=80=99s it going=3F</div><div>(=46eel free to co=
rrect me if I=E2=80=99m wrong...)</div><br><div>When we install Debian on=
 a computer and Linux is installed, part of the process during the kernel=
 build involves checking some DMI information from your machine.</div><br=
><div>Some computers (maybe most of them), through a partner or reseller,=
 modify certain information on the motherboard by injecting custom values=
 like:</div><div>Serial key (used for Windows), product name, vendor, etc=
.</div><br><div>Sometimes, the Linux kernel project doesn=E2=80=99t have =
those reseller/vendor entries listed, so the DMI data doesn=E2=80=99t mat=
ch any known model in the kernel database.</div><br><div>In my case, I=E2=
=80=99m using an Intel NUC LAPBC710 laptop kit, but the reseller in Brazi=
l branded it as =22Avell B.On=22.</div><br><div>Even though the LAPBC710 =
model is listed in the Linux database (for example), this mismatch can ma=
ke it harder to properly install or detect some components for correct dr=
iver usage.</div><div>A classic example for me is SO=46 (the audio driver=
).</div><br><div>So the question is:</div><div>How do you guys deal with =
DMI info that doesn=E2=80=99t match what=E2=80=99s listed in the kernel=3F=
</div><div>Maybe submit some kind of patch to the kernel with a DMI match=
 override=3F</div><br><div>Since this info is mostly =E2=80=9Cread-only,=E2=
=80=9D is there any tool or installer option in Debian that can help it r=
ecognize the correct model name or DMI string=3F</div><br><br><br><br><br=
><div>Best,</div>
--6881311d_1a6e0689_1733--