New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Identifying devices through DMI ID? #49
Comments
There is one big flaw that will need to be adressed: those vendor names aren't awesome!
I wouldn't be surprised if they weren't stable across different products, either from capitalization, spacing or even dropping or adding "inc." and similar suffixes/prefixes. There's already two variants for Asus. This is one detail we need to check for: how should this be handled? Strip non-letters, then lowercase and then fuzzymatch in some way to an empirically produced list of vendors? |
Oh, and there are fields in the DMI informations, the OEM Strings, that may be useful depending on the vendor:
DON'T POST THOSE HERE before looking up on google if there are any hits. For at least Asus laptops, these strings define the specific SKU for the model, as their model name and model numbers vary wildly I was able to find the model number |
Going this route, it would make more sense to put effort into Device profiles are inherently problematic: assumption is made that there is next to no hardware configuration can be made. That is not actually the case: many components can be replaced (Wi-Fi card from a different vendor, HDD -> SSD, etc.). It's also not an option for custom-built hardware, like gaming rigs, or most desktop systems, even those that have model numbers, due to generally better customizability. Also, there is rarely anything specific about devices by themselves, except in rare cases. Usually most of the configuration comes down to specific parts. There are exceptions of course: IdeaPad Z510 has some problems with Nouveau that are likely to be motherboard-related:
MacBook Air 6,x (roughly from 2013) needs a special kernel module to maintain brightness levels after lid is closed (or on reboot), which is probably specific to the model's SMC:
These cases will benefit from the approach that you've described. To handle the complexity of identifying hardware better, it's likely that |
Definitely! Detecting the hardware components in the device is 100% better than hoping the device has that hardware. Just think of the Asus example, they use the same model name (TP300LA) for devices with and without NVIDIA GPU, which could wreak havoc when someone with good intentions add a relevant kernel module. The approach udev/systemd seems to use with regards to devices (computers, laptops, tablets) is only to apply quirks to them. E.g. that macbook model is known to need this workaround for problem; that sensors mounted on this model is known to be installed in that orientation. It might still be relevant to implement the configuration of the identified components here though, even if the detection is handled in the configuration generation scripts. There may be some need for leeway into splitting devices and components. The Chuwi Hi10 Pro device has a Cherry Trail Atom CPU, and is built on a common Cherry Trail platform which has some quirks, but those quirks are not specific to that device. In fact, most of the quirks of the GPD 7 with regards to charging, backlight and power use are the same than are present in the Chuwi Hi10 Pro. This would make the "Cherry Trail Platform" a kind of device, but one that may be harder to detect, and might need some creative license for the hardware devices to include. (I don't know if this part all made sense.)
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/best-practice-for-enabling-hardware-support/7424/1 |
The files under
/sys/devices/virtual/dmi/id/
should allow most laptops, and probably brand-name pre-built computers too.This could probably be used to detect available hardware configuration in some way, and the values could be used to help categorize the files in a way that is automatically searchable. Some of that information (modalias) is used in the udev hwdb to detect hardware and apply quirks to them.
I have attached a dump of the data in different classes of machines I own. This will help kickstart discussion and discovery of the helpful attributes.
Acer C720p (with MrChromebox's coreboot-based UEFI)
ASUS TP300LA
Chuwi Hi10 Pro (HQ64) (cheap atom-based tablet)
Custom PC build using a P5N7A-VM motherboard
HP Z420 Workstation
The text was updated successfully, but these errors were encountered: