Good morning, Christophe

Thank you for informing this to us, we will look into it, could you check what the System Information from DMI shows? You can use the dmidecode tool to get the DMI info
System Information should be pretty close to the start of the output, it is handle 0x1

Waiting for your reply,

Regards,

Hi, thanks for looking into this. Here is the DMI System Information block (handle 0x0001, type 1):

Handle 0x0001, DMI type 1, 27 bytes

System Information

    Manufacturer: SLIMBOOK

    Product Name: EXCALIBUR-AMD-AI

    Version: Standard

    Serial Number: EXC-AI-0001024010253

    UUID: [redacted]

    Wake-up Type: Power Switch

    SKU Number: Standard

    Family: Standard

I think this is the root of the problem: the Family field reads "Standard" (as do Version and SKU Number), which is a generic value rather than a product family. This matches what the Slimbook client logs — it resolves model:excalibur-amd-ai and sku:standard correctly, but family:unknown. It looks like libslimbook keys its family detection on the DMI Family field, which here is "Standard" and therefore doesn't map to SLB_MODEL_EXCALIBUR, so the "family == SLB_MODEL_EXCALIBUR" check fails and all model-specific features (in my case the power-profile Fn keys) stop working.

The only field that actually identifies the machine is Product Name: EXCALIBUR-AMD-AI. So a possible software-side fix would be to match on Product Name (or on Product Name + SKU) when the Family field is generic, rather than relying on DMI Family alone. Alternatively, a firmware update that populates Family with the proper product family would fix it at the source.

For reference, firmware is fully up to date: BIOS KPT-W042-FP8-OSLI-0.19, EC 2.5, on kernel 6.17.0-1028-oem (Zorin OS 18.1 / Ubuntu 24.04 base).

Happy to test any patched libslimbook build or provide further logs. Thanks!

Good morning, Christophe
Yea, that SKU Number seems to be bogged, it should not say Standard, populating SKU number should be enough for the issue to go away
We will try to get a BIOS update that fixes this issue

What you can do right now is to map the F1x keys for the power settings to change them system level wide

Sorry for the incovenience
Regards,

Good morning,

Thanks a lot for the quick and clear answer — much appreciated.

Good to know the SKU Number is the culprit and that a BIOS update will populate it correctly. I'll keep an eye out for it.

In the meantime I've already mapped the power-profile F-keys system-wide (hwdb remap to KEY_PROG1/2/3 + GNOME custom shortcuts), so that side is fully covered on my end — no inconvenience at all.

If you'd like a tester for the BIOS update once it's ready, I'm happy to help. Thanks again for the great support.

Regards,

Christophe

One more thing, since you'll be revising the BIOS anyway:

I checked the other DMI tables (baseboard type 2, chassis type 3, onboard devices type 41) and the generic/incorrect-value problem isn't limited to the System SKU — the whole identity chain is unpopulated and still carries the default template strings, and there's also a phantom device declared. It might be worth fixing all of it in the same BIOS pass.

Baseboard (type 2):

    Manufacturer: Standard

    Product Name: Standard

    Version: Standard

    Asset Tag: Base Board Asset Tag

Chassis (type 3):

    Manufacturer: Chassis Manufacturer

    Version: Chassis Version

    Serial Number: Chassis Serial Number

    Asset Tag: Chassis Asset Tag

    SKU Number: Chassis SKU

These "Chassis Manufacturer", "Chassis Serial Number", etc. are the literal default template strings, so those fields were never overwritten at the factory — same root cause as the System SKU reading "Standard".

Onboard device (type 41) — phantom entry:

    Reference Designation: Realtek Ethernet

    Type: Ethernet

    Bus Address: 0000:03:00.0

This machine has no Ethernet at all — no RJ45 port, and nothing on the bus. "lspci | grep -i ethernet" returns nothing, and "ip link" shows only loopback and the Wi-Fi interface (wlp2s0). So this onboard Ethernet entry looks inherited from a fuller board design and should probably be removed for this variant. Beyond cosmetics, a declared-but-absent device can confuse inventory/fleet tooling (fwupd/LVFS, asset management) that goes looking for a controller that isn't there.

For reference, Chassis Type is correctly "Notebook", so it's specifically the identity fields (Manufacturer / Product / Serial / SKU / Asset Tag) plus this phantom Ethernet device.

No urgency on my end — just flagging it while the BIOS is open so it can all be fixed in one go.

Thanks again!

Regards,

Christophe

Good morning,

Unrelated to the SKU issue above, but possibly useful on your side: I'm now running this Excalibur AMD-AI on kernel 7.0.0-28-generic (Ubuntu HWE for 24.04), instead of the 6.17.0-1028-oem branch.

Everything I use works fine so far:

- Wi-Fi 6E on the MT7922 (6 GHz, 160 MHz channels, mt7921e)

- slimbook_keyboard DKMS builds and installs cleanly against 7.0

- GPU: Radeon 890M, radeonsi/gfx1150, no issue

The SKU/family detection problem is unchanged, as expected — it's a firmware matter, not a kernel one.

If it helps, you might want to validate this kernel on your side for the AMD-AI variant. I'm happy to report anything you'd like me to check.

Regards,

Christophe