SUMMARY Hi, If would be great if kinfocenter could show more specific information provided by: dmidecode | grep -A9 '^System Information' I know that with command: dmidecode | grep -A9 '^System Information' we can see the serial number of our computers but kinfocenter is more user friendly that learning the commands.. for beginners and people new to linux. Regards STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE VERSIONS (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Looks like very useful information, yeah.
I wonder, I wonder... maybe we should just dump the dmidecode output in a text KCM. It'd be fairly cheap to do and maintain that way. The other option would be to feed selective data into the about system kcm. BUT that is probably fairly costly from a code POV since we need a whole bunch of heuristics to determine if a given field is indeed useful (e.g. on any device that isn't from one of the big computer OEMs any number of the fields may not be filled which usually means they are filled with placeholder garbage that we need to manually filter out). Smaller ODMs in particular also fail to fill fields properly at times. e.g. my system is custom built so I have System Information Manufacturer: System manufacturer Product Name: System Product Name Version: System Version Serial Number: System Serial Number Wake-up Type: Power Switch SKU Number: SKU Family: To be filled by O.E.M.
Could we just dump the output of `dmidecode | grep -A9 '^System Information'` into the current About This System KCM? I suppose we would need to do some parsing to separate the labels from the data and stick it into a Formlayout properly, yeah.
"Just". That is the "other option" I was talking about. - we need a kauth helper - we need heuristics to filter the bogus data out. nobody will be happy with an entry saying "System Product Name" or "To be filled by O.E.M." dmidecode does sport a --string argument that allows us to query most/all of the interesting fields, so, calling the binary isn't the problem (if we ignore kauth for the moment, cause it is only boilerplate anyway). coming up with the heuristics will be the tricky bit. all those fields are free form. OEM/ODMs can put whatever nonesense in there
Created attachment 141540 [details] proof of concept patch I've attached a proof of concept I made the other night. Someone would need to figure out heuristics to eliminate nonesense values though, which does first need a list of potential nonesense. Looks like this on my system https://i.imgur.com/NRx1gKO.png
At one time or other I have needed most of the info from dmidecode. Wrote a script to produce the following ---------------------------------------------------------------------- System Information Type s ------------------------------------------------------------------------ bios-vendor LENOVO bios-version N1EET91W (1.64 ) bios-release-date 05/12/2021 bios-revision 1.64 firmware-revision 1.18 system-manufacturer LENOVO system-product-name 20ENCTO1WW system-version ThinkPad P50 system-serial-number PC0DTF1L system-uuid 423e074c-20a8-11b2-a85c-b8c832f25d1c system-family ThinkPad P50 baseboard-manufacturer LENOVO baseboard-product-name 20ENCTO1WW baseboard-version SDK0J40697 WIN baseboard-serial-number L1HF661007G baseboard-asset-tag Not Available chassis-manufacturer LENOVO chassis-type Notebook chassis-version None chassis-serial-number PC0DTF1L chassis-asset-tag No Asset Information processor-family Core i7 processor-manufacturer Intel(R) Corporation processor-version Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz processor-frequency 2700 MHz
Harald The image for what it looks on your system shows up as a blank darg image.
In addition to the dmidecode stuff it would be nice to have some basic power supply/battery information
On my system (Fedora 34) the directory " /sys/devices/virtual/dmi/id" contains much of the system information that might be displayed in kinfocenter. Some items like the serial number need authorization. The little script below displays the contents. Some info is probably not useful. Other systems my have the info in different locations. So maybe there is no need to run the dmidecode command. There is a "power" subdirectory but I am not sure of the contents yet. DIR="/sys/devices/virtual/dmi/id/*" for i in ${DIR}; do if ! [ -d $i ]; then echo -ne ${i} "\t"; cat ${i}; fi; done
On my system (Lenovo P50 laptop running Fedora 34) the script below will show whether of not the AC adapter is connected. Not a lot of use if used on a desktop. Would be nice to see if it works on other distros. Another source for battery information can be found in "/sys/class/power_supply/BAT0" if (( $( </sys/class/power_supply/AC/online ) )); then echo "AC Adapter connected "; else echo "AC Adapter not connected "; fi
https://docs.microsoft.com/en-us/windows-hardware/manufacture/iot/license-requirements?view=windows-11#smbios-support
As it turns out microsoft actually made useful values an oem license requirement (and is apparently also showing the System Product Name in their 'about' UI in windows 11). So, long term I suppose we'll see the values getting less crappy. Still, we need a filter list to not show unsuitable values from non-OEM configurations (e.g. purpose built PCs)
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kinfocenter/-/merge_requests/88
Created attachment 147092 [details] attachment-10689-0.html I love this feature.. I requested it around 2 years ago and it is very useful for getting support. Regards *___* *Ezequiel Partida* | Empresario Independiente *BajaPreneur* | www.bajapreneur.com <http://www.digitalio.com/> (664) 522.1896 El jue, 4 nov 2021 a las 14:02, Brian Kaye (<bugzilla_noreply@kde.org>) escribió: > https://bugs.kde.org/show_bug.cgi?id=400079 > > Brian Kaye <bdk@unb.ca> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |bdk@unb.ca > > --- Comment #6 from Brian Kaye <bdk@unb.ca> --- > At one time or other I have needed most of the info from dmidecode. > Wrote a > script to produce the following > ---------------------------------------------------------------------- > System Information Type s > ------------------------------------------------------------------------ > bios-vendor LENOVO > bios-version N1EET91W (1.64 ) > bios-release-date 05/12/2021 > bios-revision 1.64 > firmware-revision 1.18 > system-manufacturer LENOVO > system-product-name 20ENCTO1WW > system-version ThinkPad P50 > system-serial-number PC0DTF1L > system-uuid 423e074c-20a8-11b2-a85c-b8c832f25d1c > system-family ThinkPad P50 > baseboard-manufacturer LENOVO > baseboard-product-name 20ENCTO1WW > baseboard-version SDK0J40697 WIN > baseboard-serial-number L1HF661007G > baseboard-asset-tag Not Available > chassis-manufacturer LENOVO > chassis-type Notebook > chassis-version None > chassis-serial-number PC0DTF1L > chassis-asset-tag No Asset Information > processor-family Core i7 > processor-manufacturer Intel(R) Corporation > processor-version Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz > processor-frequency 2700 MHz > > -- > You are receiving this mail because: > You reported the bug.
(In reply to Nate Graham from comment #3) > Could we just dump the output of `dmidecode | grep -A9 '^System > Information'` into the current About This System KCM? I suppose we would > need to do some parsing to separate the labels from the data and stick it > into a Formlayout properly, yeah.
(In reply to Harald Sitter from comment #2) > I wonder, I wonder... maybe we should just dump the dmidecode output in a > text KCM. It'd be fairly cheap to do and maintain that way. > > The other option would be to feed selective data into the about system kcm. > BUT that is probably fairly costly from a code POV since we need a whole > bunch of heuristics to determine if a given field is indeed useful (e.g. on > any device that isn't from one of the big computer OEMs any number of the > fields may not be filled which usually means they are filled with > placeholder garbage that we need to manually filter out). Smaller ODMs in > particular also fail to fill fields properly at times. > > e.g. my system is custom built so I have > > System Information > Manufacturer: System manufacturer > Product Name: System Product Name > Version: System Version > Serial Number: System Serial Number > Wake-up Type: Power Switch > SKU Number: SKU > Family: To be filled by O.E.M. Harald :In your case where you have a custom build, you probably don't need the smbios information. But it does raise the issue of custom bios where you might like to put your custom info into the bios.
Git commit e5884a1ea6635a35bf8034320fdeecaacb99b5c8 by Nate Graham, on behalf of Harald Sitter. Committed on 03/04/2022 at 14:59. Pushed by ngraham into branch 'master'. Add some DMI data to about-distro Now it shows things like the hardware name, manufacturer, and serial number. Serial number requires an extra click to see so that you don't accidentally reveal it when you take a screenshot of the window. FIXED-IN: 5.25 M +4 -1 Modules/about-distro/src/CMakeLists.txt M +8 -2 Modules/about-distro/src/Entry.cpp M +13 -2 Modules/about-distro/src/Entry.h A +16 -0 Modules/about-distro/src/dmidecode-helper/CMakeLists.txt A +69 -0 Modules/about-distro/src/dmidecode-helper/helper.cpp [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)] A +13 -0 Modules/about-distro/src/dmidecode-helper/helper.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)] A +12 -0 Modules/about-distro/src/dmidecode-helper/org.kde.kinfocenter.dmidecode.actions M +116 -10 Modules/about-distro/src/main.cpp M +38 -5 Modules/about-distro/src/package/contents/ui/main.qml A +10 -0 cmake/Finddmidecode.cmake https://invent.kde.org/plasma/kinfocenter/commit/e5884a1ea6635a35bf8034320fdeecaacb99b5c8