Help needed: a hardware diagnostics tool for GNOME

I’m interested in creating a hardware diagnostics tool for GNOME. This would show technical details about the system and the available hardware. It would also include information about the firmware for your hardware, and allow blacklisting certain firmware versions.

The main role for this tool would be support or troubleshooting situations, but it could also be more widely useful for anyone who wants to look up information about their hardware.

I want to work on the design for this tool, but need some information to do so: specifically, what hardware information are we able to reliably show at the moment? I know there are a bunch of commands to show hardware information (lscpu, lspci, lsusb, etc): is the information shown there something we can reliably access?

The other thing it would be helpful to have advice on what information is useful to show (or not show)!

15 Likes

Hey @allanday,

I’m very interested in such tool for GNOME! I have purchased an old laptop recently and I had a bunch of hardware issues when I first installed Linux on it that I was able to fix by googling some stuff. The user experience could be improved and we should make it easier for the user to see some important info about the hardware, what does seem to work and what doesn’t seem to work.

I have no idea how feasible it’s to have an “auto fix” issues, but having at least the hardware info that user can search if they are supported or not is a first step in the right direction.

1 Like

Collating the firmware versions of devices (information from fwupd) with the actual devices (building a tree from the sysfs sources lspci/lsusb use) may be impossible since fwupd can represent virtual devices that might not show up on a traditional bus like PCIe, USB, Thunderbolt.

As an example; a dock supported by the fwupd plugin ‘dell-dock’ has an embedded controller that can not be directly access from USB, Thunderbolt, or any other interface. As such I think it would be best to split it up into two separate categories in such a tool:

“Hardware”
“Firmware”

Under Hardware I think the most important things to show:

  • Vendor name
  • Device name
  • Bus information (PCIe, USB, connectivity)
  • Kernel driver in use (or none)
  • Kernel module information (if available)

I think feel any other sysfs attributes available to the device should be tucked away somewhere in an advanced button.

Windows has a concept of “yellow bang” when there is no driver loaded. This concept to me is really interesting for troubleshooting purposes, but I don’t think it truely maps over to Linux because certain ACPI only devices don’t need drivers.

2 Likes

I think you should start by looking at what Hardinfo lists ( without the woefully outdated benchmark tests ).
Then look at CPU-Z for Windows and package all the stats that Hardinfo gives and package it as a Gnome-stastic version of CPU-Z.

There is a poor-man’s version of CPU-Z for Linux called CPU-X. Look at that for some design hints but it’s ugly as heck. There HAD been another Linux CPU-Z clone call I-Nex. It was MUCH closer to CPU-Z and more feature full than CPU-X but it’s now just another dead Linux app.

Or…simply fork Hardinfo and wrap it up in a beautiful Gnome interface according to Gnome HID guidelines.

1 Like

As the author of HardInfo, I believe that there’s not much point in salvaging it. It’s better to write something like that from the scratch. I’ve pondered doing a GTK3 UI refresh by leveraging a lot of the advances in the GNOME HIG over the years, but I unfortunately can’t stand that code base any longer. Of course, I’ll be here to help whoever thinks otherwise, though; I’d be thrilled to have it being part of GNOME.

As far as UI changes, I believe that older versions of HardInfo had some ideas in the UI that could be reused in this new app.

4 Likes

At a UX level it makes a lot of sense to me to combine controls over firmware with other hardware information, since they both fall within diagnostics and troubleshooting. It’s not a long way from “what chipset does my wireless card have?” to “which firmware version does it have?”

That said, I’m also nervous about trying to bridge technical domains that don’t have an existing relationship. It could be a world of pain to try and pretend that they work together. For now the best thing might be to concentrate on the firmware side of things. We can always build out from there, should we feel the need.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.