Peripherals/sensors nightmare under Linux (Mint)

[PDifolco]

Prepping for Win10 EoL by switching to Linux

Dual boot install, system is good, snappy, apps and Steam games work like a charm - didn't even have to reinstall games just mount my game drive !

No graphics driver issue as I have an AMD card

I'm already using Firefox, Thunderbird  and LibreOffice under Windows (f*ck M$ and Google)

 

All is fine ? Well damn no, I can't manage to control my fans and peripherals, nor any RGB

- manage fan speeds (I use FanControl in Windows) : lm-sensors just don't detect anything, then CoolerControl just sees my GPU fans

- control RGB (I use SignalRGB in Windows) : OpenRGB just crashes the system fully at launch (!!) - seems it's because I use an Asus board, but it wasn't fixed since a few years ...

- Also have an Asus KB and Logitech mouse, no way to manage them - but well they work...

 

I'm pretty sure there's no real fix/solution, but that's annoying...

 

 

[NoLeafClover]

1 hour ago, PDifolco said:

lm-sensors just don't detect anything, then CoolerControl just sees my GPU fans

Have you tried running "sensors-detect" and following the prompts?

 

If, following this, you still can't see all the fans and sensors, unfortunately a lot of it has to do with the I/O controller chip on the board that is responsible for interfacing with and exposing the various fans and sensors. Nuvoton controllers are commonly encountered on main boards. The issue often is that, as you might already suspect, 1st party drivers are often proprietary and do not even have proprietary builds for Linux. The implementation of such drivers in the Linux kernel is often written by following technical reference specs for the controllers and effectively "reverse engineering" to some extent.

 

Sometimes there's minor differences between controllers that, if forced manually to use a similar model's driver, it works just fine. This is the case with the Nuvoton NCT6799D sometimes found on X670E boards. If you know the exact chip on your board feel free to share it, or your mainboard make, model, and revision.

 

This is not a Linux problem, rather the nature of proprietary software ...

 

1 hour ago, PDifolco said:

Also have an Asus KB and Logitech mouse, no way to manage them - but well they work...

Have you tried GHub through Wine? It's a long shot but might work.

 

This is again not a Linux problem, but an Asus and Logitech problem. If they had chosen to port their software to Linux, or opened up the specifications for the protocol they use to configure the peripherals, it wouldn't a problem - somebody passionate enough in the community would write the software based on the specs. But, of course, it's all proprietary ...

 

We're starting to see a pattern here. And as frustrating as it may be, hopefully hopefully you can now appreciate even more the benefits of free and open-source software, why there's so many advocates for it, and start to wonder how we, as a society, have allowed it to become this bad.

 

1 hour ago, PDifolco said:

control RGB <snip> OpenRGB just crashes the system

Running OpenRGB shouldn't crash your whole system, especially if not run as root. Have you installed it "natively" from your distro's package manager or via Snap or Flatpak?

 

Not sure how standardised RGB controls are in terms of hardware protocols. LEDs are usually exposed under "/sys/class/leds". Perhaps have a look there and see if there's more than just a handful of files? Presume most will be exposed over SMBus, I2C, or USB but I really don't know if there's other layers to the onion that various manufacturers have added on top. I wouldn't be surprised if some have their own proprietary protocol too...

[1ball]

For managing your Logitech gear, have you checked out Solaar? As far as I know it is offered in most package manager repos, and if it isn't you can manually build it from sources you can obtain thru GitHub.

[PDifolco]

8 minutes ago, NoLeafClover said:

Have you tried running "sensors-detect" and following the prompts?

 

If, following this, you still can't see all the fans and sensors, unfortunately a lot of it has to do with the I/O controller chip on the board that is responsible for interfacing with and exposing the various fans and sensors. Nuvoton controllers are commonly encountered on main boards. The issue often is that, as you might already suspect, 1st party drivers are often proprietary and do not even have proprietary builds for Linux. The implementation of such drivers in the Linux kernel is often written by following technical reference specs for the controllers and effectively "reverse engineering" to some extent.

 

Sometimes there's minor differences between controllers that, if forced manually to use a similar model's driver, it works just fine. This is the case with the Nuvoton NCT6799D sometimes found on X670E boards. If you know the exact chip on your board feel free to share it, or your mainboard make, model, and revision.

 

This is not a Linux problem, rather the nature of proprietary software ...

 

Have you tried GHub through Wine? It's a long shot but might work.

 

This is again not a Linux problem, but an Asus and Logitech problem. If they had chosen to port their software to Linux, or opened up the specifications for the protocol they use to configure the peripherals, it wouldn't a problem - somebody passionate enough in the community would write the software based on the specs. But, of course, it's all proprietary ...

 

We're starting to see a pattern here. And as frustrating as it may be, hopefully hopefully you can now appreciate even more the benefits of free and open-source software, why there's so many advocates for it, and start to wonder how we, as a society, have allowed it to become this bad.

 

Running OpenRGB shouldn't crash your whole system, especially if not run as root. Have you installed it "natively" from your distro's package manager or via Snap or Flatpak?

 

Not sure how standardised RGB controls are in terms of hardware protocols. LEDs are usually exposed under "/sys/class/leds". Perhaps have a look there and see if there's more than just a handful of files? Presume most will be exposed over SMBus, I2C, or USB but I really don't know if there's other layers to the onion that various manufacturers have added on top. I wouldn't be surprised if some have their own proprietary protocol too...

I've asked ChatGPT, and it confirms for sensors it's due to some new Asus chip that isn't compatible with how Linux get them, have to set fan speeds in BIOS...

For the big OpenRGB crash ( I've installed the .deb file normally) same thing, Asus Aura/Armoury crap, and it's been reported by other people on GitHub and Reddit  (google "OpenRGB crash Asus") 

Seems it could work if I disable Aura in BIOS (no big deal, I can't really see the mobo RGB anyway as my PC is on the floor on my left !)

There's a Linux app for Logitech mice tho (logiops), didn't know about it, will try

 

And sure it's not Linux fault if hardware manufacturers do windows-only sh*t, I'd stay clear from Asus from now on , but it's so annoying !

[Nayr438]

For the Logitech Mouse you can try Piper.

I know this is probably what you don't want to hear but Linux kind of decides what you get to use and when it comes to things like RGB and Gaming Peripherals you pretty much rely on community support which isn't guaranteed to exist or last long term.

 

In terms of Keyboard and Mice your best overall options are Razer Keyboards and Razer/Logitech Mice. Razer is well supported by OpenRazer and Logitech Mice as mentioned previously by Piper.
 

Fan speeds not being addressable is fairly common, your overall best option is just to set it in BIOS or obtain a usb controller listed at https://github.com/liquidctl/liquidctl?tab=readme-ov-file#supported-devices, which will work with CoolerControl.

 

For your OpenRGB issue, there is a open Device Request so you will probably just have to wait it out.

 

21 minutes ago, NoLeafClover said:

Have you tried GHub through Wine? It's a long shot but might work.

Wine can't interact directly with USB Devices.

 

21 minutes ago, NoLeafClover said:

Running OpenRGB shouldn't crash your whole system, especially if not run as root.

Not necessarily, it's udev rules grant it full access to the device, send the wrong command and it could cause a hardware error.
There have been known events where OpenRGB has bricked boards due to this which is why they actually put a warning on their GitLab Page.

[NoLeafClover]

On 7/23/2025 at 10:28 PM, Nayr438 said:

Wine can't interact directly with USB Devices.

Ah... Indeed, retrospectively I should have remembered this.

 

On 7/23/2025 at 10:27 PM, PDifolco said:

I've asked ChatGPT, and it confirms for sensors it's due to some new Asus chip that isn't compatible with how Linux get them, have to set fan speeds in BIOS...

ChatGPT is not a reliable source of truth, even if it often gets things right on the merit of probability. I think it is extremely unlikely that ASUS will have their own chip for fan and sensors controller when this is a solved problem that is cheaply and readily available to hardware manufacturers.

 

If your MB is the one in your signature, then it seems it could have the Nuvoton NCT6799D-R chip, which is supported the latest Linux kernel and roughly since kernel v6.5. If "sensors" does not show what you expect, you may need to update to a newer kernel (6.5 or up) or force the driver to recognise the chip. I had the same problem on my X670E board and had to use the latter workaround until the issue was resolved in the upstream kernel and was made available downstream to my distro.

 

The easiest way to know for sure is to look at the chip on the board, as even the same make and model board may have subtle differences between hardware revisions. This will not guarantee that the fans will be addressable but they should at least show up and might save you from having to buy a separate hub. That said, I do agree that setting up the fan curve through the BIOS is the easiest and perhaps most reliable option if you're not looking for a more bespoke fan control, e.g. case fan control based on GPU temps - a scenario often not supported in BIOS.

Edited July 27, 2025 by NoLeafClover
Added a bit more detail, sorry