Corsair Link H80i #129
Comments
|
The non-GT/non-v2 H80i ( I would very much welcome a pull request here. If you're willing to work on this, I can you give you directions and help you along the way. |
jonasmalacofilho
changed the title
|
Hello @jonasmalacofilho
Thank you for the offer. I'd love to work on this. |
|
I started by adding the product id: ehaupt@eb6eb86 This gives me: But obviously more is needed: |
|
I'll take a better look at the OCL code and give you some specific pointers. In the mean time, you're mostly on the right track, I just (strongly) suggest you work on a clear/new subclass of UsbHidDriver, instead of reusing CorsairHidPsuDriver. You don't want to send random PSU commands to the cooler. |
|
@ehaupt @jonasmalacofilho I'm available to answer any questions you may have. |
|
Thank you @audiohacked and @jonasmalacofilho |
|
This comment became Porting drivers from OpenCorsairLink. Original commentHi again @ehaupt,In essence, writing a new liquidctl driver means implementing all (suitable) methods of a Note that you shouldn't directly subclass the BaseDriver; instead you'll inherit from a bus-specific base driver like And for the new driver to work out-of-the-box it's sufficient to import its module in Next, in order to port a driver from OCL, the first step is to check the {
.vendor_id = 0x1b1c,
.product_id = 0x0c04,
.device_id = 0x3b,
.name = "H80i",
.read_endpoint = 0x01 | LIBUSB_ENDPOINT_IN,
.write_endpoint = 0x00 | LIBUSB_ENDPOINT_OUT,
.driver = &corsairlink_driver_coolit,
.lowlevel = &corsairlink_lowlevel_coolit,
.led_control_count = 1,
.fan_control_count = 4,
.pump_index = 5,
},The low-level functionsStarting with the low-level functions specified by
This is a HID device, so the liquidctl driver should inherit
Practically, it means that you only need to implement Higher-level functionalityThe remaining Data that is read from the cooler, like the pump speed, will generally go into (You can fetch the firmware version directly in The other three methods are self-explanatory and should be fairly straightforward to implement, apart from the special considerations that I go into next. Protocols with interdependent messagesA big aspect in the design of the liquidctl CLI was not requiring the user to configure different aspects of the cooler in a single command: you should be able to set the pump speed without resetting the fan speed or the LED colors. For most devices there's a clear mapping between the CLI and the implementation: the CLI command There are however "complicated" devices where, at the protocol level, functionality is grouped (all channels must be set at once) or even completely consolidated into a single "state" (everything must be reset when changing a single parameter). Messages can also be required to follow an arbitrary order. So, besides looking at how each individual parameter is configured, you also need to check the "logic" part of OCL, in this case implemented in In fact, in the case of the H80i (or other devices using the same protocol) I think that the different aspects of the cooler can indeed be configured independently, at least for the most part. This is mostly due to the empty implementations of The ordering in Anyway, the main concern I have right now is the I'd start following OCL: initialize a similar variable to 0x81 every time the driver is instantiated, and increment it every time it's used. But if that somehow doesn't work, you can use the internal No matter what, just don't forget to explicitly wrap Advanced driver bindingliquidctl driver don't normally need to check anything super special to know whether or not they are compatible with a particular device. As long as This wont be the case with the H80i: it shares a common vendor and product ID with other devices, and is only differentiated by a "device ID", that has to be explicitly read. Reading of this device ID is implemented in OCL by There are two ways of handling this in liquidctl. One way is to override Because having the driver instance in an undetermined state will cause some issues, both for us and for the user, I think you should try the This is it, at least for now. Let me know if you have any questions. P.S. I tried to be a bit more general than needed here because i want to be able to refer to this comment in case other drivers are ported from OCL. |
|
Thank you @jonasmalacofilho for the detailed instructions. I'll try my luck. |
Taken from #129 (comment),[1] with no additional changes so far. [1] #129 (comment)
|
Merging this with #142, since both should use the exact same driver. Keeping the later issue simply because there's some additional information there. |
I've been successfully using audiohacked/OpenCorsairLink by @audiohacked on FreeBSD for quite some time.
I've just noticed that the project is now archived and retired. Luckily the README.md mentioned this wonderful project so I thought I'd give it a go.
I made sure all the dependencies are installed and I ran
liquidctl listasroot. Unfortunately myCorsair Link H80iis not recognized.I followed the instructions and ran the command with
PYUSB_DEBUGandLIBUSB_DEBUG:Here is the
--debugoutput ofOpenCorsairLinkthat might provide some insight:Here is some info to my system:
Here are the module/python versions:
Operating system:
Please let me know if there is any additional information I can provide.
The text was updated successfully, but these errors were encountered: