Bug 400079

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