PatrickGHall
commented
2 years ago Also, in case it is relevant, the USB 2.0 header for the H150i is connected to one of the two passthrough ports on the Commander
Closed PatrickGHall closed 2 years ago
PatrickGHall
commented
2 years ago Also, in case it is relevant, the USB 2.0 header for the H150i is connected to one of the two passthrough ports on the Commander
jonasmalacofilho
commented
2 years ago [...] liquidctl can't see the device [...]
I don't see anything wrong in the log you provided:
$ liquidctl initialize all --debug
[...]
[DEBUG] (usb) (find_devices): searching HidapiBus
[DEBUG] (usb) (find_devices): HidapiBus drivers: CommanderCore, CommanderPro, CorsairHidPsu, HydroPlatinum, Kraken2, KrakenX3, KrakenZ3, NzxtEPsu, RgbFusion2, SmartDevice, SmartDevice2, _BaseSmartDevice
[DEBUG] (usb) (find_devices): HID device: 048d:8297 (usage_page=0xff89 usage=0x0010)
[DEBUG] (usb) (find_devices): HID device: 048d:8297 (usage_page=0xff89 usage=0x00cc)
[DEBUG] (usb) (probe): found RgbFusion2: Gigabyte RGB Fusion 2.0 8297 Controller
[DEBUG] (usb) (find_devices): HID device: 1b1c:0c10 (usage_page=0x0084 usage=0x0052)
[DEBUG] (usb) (__init__): has kernel driver: corsair_cpro (/sys/class/hidraw/hidraw1/device/hwmon/hwmon4)
[DEBUG] (usb) (probe): found CommanderPro: Corsair Commander Pro
[...]
[DEBUG] (usb) (find_devices): searching PyUsbBus
[DEBUG] (usb) (find_devices): PyUsbBus drivers: Hydro690Lc, HydroPro, Legacy690Lc, Modern690Lc, _Base690Lc, _ModernBase690Lc
[...]
[DEBUG] (usb) (find_devices): USB device: 1b1c:0c12
[DEBUG] (usb) (probe): found HydroPro: Corsair Hydro H150i Pro <-- HERE IT IS
[...]There it is. Have you tried status and other commands, once initialize is done with it and the other devices?
The device shows the correct vendor and product IDs, but calls itself a "Platinum" rather than a "Pro"
That's expected for this particular model. It seems Corsair throught about releasing it as a "Platinum", but eventually backtracked and left that name for a later (and very different) model. Unfortunately it seems it was too late to fix the USB string descriptors...
jonasmalacofilho
commented
2 years ago Attempting to manually bind the
usbhiddriver gives me an error "No such device"
Oh, forgot to reply to this part.
Yeah, that shouldn't work since this particular model isn't a HID. But that's ok, we can still communicate with it using PyUSB/LibUSB.
jonasmalacofilho
commented
2 years ago On a related note, would
[DEBUG] (usb) (probe): HydroPro recognized: Corsair Hydro H150i Proor
[DEBUG] (usb) (probe): HydroPro identified: Corsair Hydro H150i Promake it more obvious that from that point in the execution onward liquidctl knows about that device and will (try to) handle it appropriately?
(Also pinging @MarshallAsch for his opinion on this).
P.S. Both formats above have the same <driver> <verb>: <description of the specific device model> structure.
MarshallAsch
commented
2 years ago (Also pinging @MarshallAsch for his opinion on this).
I like option 2. [DEBUG] (usb) (probe): HydroPro identified: Corsair Hydro H150i Pro
Ill take a look at the rest of this thread tonight
PatrickGHall
commented
2 years ago I was confused by it not showing up after the call to initialize all and I initially couldn't see it in list but after tinkering with things on the rgb_vengeance stuff I now see it in list and am able to control it. I wish I knew at what point it came alive but there was a reboot in there somewhere. I think it's safe to close this one out as PEBK
While I have you here, can I ask a question about the vengenace RGB (also probably PEBK)?
I have 4 sticks and I assume they correlate to /dev/i2c-{0-3} and given that they appear there, I assume i2c-dev is loaded although I can't see it listed in lsmod even after attempting modprobe i2c-dev which doesn't output any error.
I have myself added to the i2c group and did a reboot:
$ ll /dev/ | grep i2c
crw-rw---- 1 root i2c 89, 0 May 31 13:15 i2c-0
crw-rw---- 1 root i2c 89, 1 May 31 13:15 i2c-1
crw-rw---- 1 root i2c 89, 2 May 31 13:15 i2c-2
crw-rw---- 1 root i2c 89, 3 May 31 13:15 i2c-3$ id `whoami`
uid=1000(patrick) gid=1000(patrick) groups=1000(patrick),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),134(lxd),135(sambashare),137(i2c)My processor is AMD, but I think the SMBus comment is about the spec itself being written by Intel, not that the architecture must be Intel to use it. When executing the commands to set the colors for the vengeance sticks, I keep getting this:
$ liquidctl --match vengeance set led color fixed fa11f2 --unsafe=smbus,vengeance_rgb
ERROR: no device matches available drivers and selection criteria
patrick@cloud2gnd:~$ sudo -E env "PATH=$PATH" liquidctl --match vengeance set led color fixed fa11f2 --unsafe=smbus,vengeance_rgb
[sudo] password for patrick:
ERROR: no device matches available drivers and selection criteriaWhat might I be missing in the setup?
--edit
I found some directions on the OpenRGB page for modifying the kernel params which loaded more I2C devices and got the RAM sticks to show up in OpenRGB, but still getting the same error on liquidctl
I think this one might be too much effort to try and work through for you guys but if you're up for it I can stick around and get you whatever logs you need
PatrickGHall
commented
2 years ago Yet another unrelated thing now that the 150i Pro is listed, when setting the alert colors it seems to not take the values given at least for the "good" state and defaults to green.
$ liquidctl --match hydro set logo color alert fa11f2 ffff00 ff0000 # Still green
$ liquidctl --match hydro set logo color alert fa11f2 fa11f2 ff0000 # Still green
$ liquidctl --match hydro set logo color alert fa11f2 fa11f2 fa11f2 #Still green
$ liquidctl --match hydro set logo color fixed fa11f2 #Hot pink succeeds
$ liquidctl --match hydro set logo color alert fa11f2 ffff00 ff0000 #Goes back to greenAlso I think the weird issue with the device not showing in the list command was because I had previously installed through apt, which was 1.5 and then purged and installed through pip to get the latest. When I rebooted it must have sorted itself
jonasmalacofilho
commented
2 years ago My processor is AMD, but I think the SMBus comment is about the spec itself being written by Intel, not that the architecture must be Intel to use it.
Actually, we really are limited right now to Intel platforms, because of some kernel driver differences. Specifically, we expect to be able to read the both pages of the DDR4 SPD EEPROM through the kernel utilities (to really check that we know how to "talk" to that specific device), but IIRC only the Intel driver sets that up, at least automatically.
I found some directions on the OpenRGB page for modifying the kernel params which loaded more I2C devices and got the RAM sticks to show up in OpenRGB, but still getting the same error on
liquidctl
Can you share those? They could be related to what I just mentioned above.
Yet another unrelated thing now that the 150i Pro is listed, when setting the alert colors it seems to not take the values given at least for the "good" state and defaults to green.
I'm not the author of this driver, but based on what the work I did for the previous generation of Asetek devices, there's a chance that our documentation might be wrong, and that alerts device just don't work that way on the device. Sorry about that...
Any chance you can investigate this a bit further? Maybe see how it works on other software, both first party (CorsairLink and iCue) and third party (OpenRGB, OpenCorsairLink, etc.)?
You can also take a look at our 5-th gen docs and see if how your device responds to the alert settings seems to match that better.
PatrickGHall
commented
2 years ago The OpenRGB kernel parameter instructions are here: https://gitlab.com/CalcProgrammer1/OpenRGB#kernel-parameters
I can take a crack at loading up windows + iCue to see if the alerts are supposed to work for this device
jonasmalacofilho
commented
2 years ago Triage: @PatrickGHall, have you managed to look into the problem with alert mode?
PatrickGHall
commented
2 years ago The device seems to default to an alert mode if I don't apply any other color settings. I wasn't able to change the alert colors with the commands from the asetek page, at least not that I can tell. The PBO pushes the temps up to about 80, so it's possible the alert temperature is higher? Not sure.
I was able to get it passed through to a Windows VM with iCue and there is an alert setting in there, but I only get a dropdown box and my only option is None so I'm starting to think this device maybe doesn't support changing the alert colors, just toggling on/off the mode.
jonasmalacofilho
commented
2 years ago It's possible that there are non-trivial interactions between normal and the alert modes. And without having this feature exposed through iCue, it would require some experimentation, including exhaustively testing all imaginable states/combinations...
Are you interested in working on this, since you have the device?
Otherwise I'm tempted to simply remove the mode, since right now it is neither complete nor functional.
PatrickGHall
commented
2 years ago I can look into it. My pace will undoubtedly be slow. I'll take a look at the repo for the tips on how to get setup for that, I think I remember seeing documentation for it when I was first perusing.
jonasmalacofilho
commented
2 years ago I can look into it.
Great, thanks!
Let me know if you have any questions, either through here, Discord or email.
I think I remember seeing documentation for it when I was first perusing.
Yes, in our internal (but still public) documentation.
MacGyverNL
commented
2 years ago As mentioned in the #484, I think this may be caused by what seems to be a typo in selecting the temperatures from the 3-tuple, leading to a duplicate temperature being passed as mid- and high-point. I get the feeling the software in these devices simply hasn't been built to cope with that situation.
@PatrickGHall You can try if applying that single edit fixes your colours. Since it's Python, if you're careful about it, you can do so on the system-installed package if you remove the corresponding asetek_pro.cpython-3*.pyc cache file.
jonasmalacofilho
commented
2 years ago Closing probably as fixed by PR #484. Please provide feedback in case the issue still remains with the latest code in main.
I have a refurbished Corsair H150i Pro, which I suspect is part of my problem here. In any case, liquidctl can't see the device and it has no driver loaded. Attempting to manually bind the
usbhiddriver gives me an error "No such device"I have also tried adding the following to the provided
71-liquidctl.rulesto try and force the OS to do it:but I haven't had any luck.
Debugging with
lsusbI think I might have a clue as to what is going on, but it might not be relevant. The device shows the correct vendor and product IDs, but calls itself a "Platinum" rather than a "Pro" The relevant output from$ lsusb -v:I also have a Corsair Commander in the system and that is working as expected. I have 7 total fans in the case and 6 of these are connected to the Commander, including the 3 for the AIO.
Additional information about the system:
liquidctl --version: