Comments (15)
I have the H115i
Bus 001 Device 003: ID 1b1c:0c0a Corsair
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1b1c Corsair
idProduct 0x0c0a
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
what tools you already use to control it
I currently am not using anything to control it.
how would you be able to help to develop, test and maintain this driver
I can make minor changes to the code for testing and assist with upstreaming(I currently maintain a number of packages in buildroot and am familiar with the kernel development process). I've bisected kernel drivers before such as efifb and tested regression fixes needed such as this.
from liquidtux.
Corsair H115i
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1b1c Corsair
idProduct 0x0c0a
bcdDevice 1.00
iManufacturer 1 Corsair Components, Inc.
iProduct 2 H115i
iSerial 3 7289_2.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
I use liquidctl to control it
from liquidtux.
I'll start...
EVGA CLC 120 (CL12)
# lsusb -v -d2433:b200
Bus 001 Device 005: ID 2433:b200 ASETEK 690LC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x2433
idProduct 0xb200
bcdDevice 1.00
iManufacturer 1 ASETEK
iProduct 2 690LC
iSerial 3 CCVI_1.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
This is just a test device to me, but I routinely power it on to test something with liquidctl. Still, it's not really cooling anything, so there's a chance that a subtle issue might go unnoticed.
I'm willing to develop a large part of the kernel driver, and also help upstream it. After that I can maintain the support for the CLCs (but not the Corsair devices).
from liquidtux.
Ok, it seems that there's some interest for the H115i.
I'll take a first look and try to come with a good structure for the driver. It will probably need to go into the usb subsystem and instantiate both hwmon and led drivers.
While I would normally ignore the LED part, in this case I think it's necessary: for the device to function correctly the configuration command must be used, but that command also controls the LED. And if the user were to use another tool for that, we would need to solve all sorts of conflicts or implement our own pass-through API; probably easier to just implement the LED stuff properly.
from liquidtux.
I think we might have overlooked something when we switched (in liquidctl) the H115i to use the modern driver.
Can you run the following one-line script with liquidctl 1.3.0 and post the results?
for i in {0..20}; do echo "Set pump speed to $((i*5))%"; liquidctl --match H115i set pump speed $((i*5)); sleep 1; liquidctl --match H115i status | grep Pump; done
EDIT: it's important for me to know exactly how much the H115i differs from my CLC 120 test cooler.
from liquidtux.
root@megumi:~# liquidctl --version
liquidctl v1.3.0 (53ddc58a0746)
root@megumi:~# for i in {0..20}; do echo "Set pump speed to $((i*5))%"; liquidctl --match H115i set pump speed $((i*5)); sleep 1; liquidctl --match H115i status | grep Pump; done
Set pump speed to 0%
├── Pump speed 2010 rpm
Set pump speed to 5%
├── Pump speed 2010 rpm
Set pump speed to 10%
├── Pump speed 2040 rpm
Set pump speed to 15%
├── Pump speed 2040 rpm
Set pump speed to 20%
├── Pump speed 2040 rpm
Set pump speed to 25%
├── Pump speed 2040 rpm
Set pump speed to 30%
├── Pump speed 1980 rpm
Set pump speed to 35%
├── Pump speed 2040 rpm
Set pump speed to 40%
├── Pump speed 2040 rpm
Set pump speed to 45%
├── Pump speed 2040 rpm
Set pump speed to 50%
├── Pump speed 2010 rpm
Set pump speed to 55%
├── Pump speed 2160 rpm
Set pump speed to 60%
├── Pump speed 2250 rpm
Set pump speed to 65%
├── Pump speed 2400 rpm
Set pump speed to 70%
├── Pump speed 2520 rpm
Set pump speed to 75%
├── Pump speed 2580 rpm
Set pump speed to 80%
├── Pump speed 2760 rpm
Set pump speed to 85%
├── Pump speed 2880 rpm
Set pump speed to 90%
├── Pump speed 2970 rpm
Set pump speed to 95%
├── Pump speed 3000 rpm
Set pump speed to 100%
├── Pump speed 3120 rpm
root@megumi:~# liquidctl --version
liquidctl v1.3.0 (0e1e12298ec2)
root@megumi:~# for i in {0..20}; do echo "Set pump speed to $((i*5))%"; liquidctl --match H115i set pump speed $((i*5)); sleep 1; liquidctl --match H115i status | grep Pump; done
Set pump speed to 0%
├── Pump speed 2040 rpm
Set pump speed to 5%
├── Pump speed 2040 rpm
Set pump speed to 10%
├── Pump speed 2040 rpm
Set pump speed to 15%
├── Pump speed 2010 rpm
Set pump speed to 20%
├── Pump speed 2040 rpm
Set pump speed to 25%
├── Pump speed 2010 rpm
Set pump speed to 30%
├── Pump speed 2040 rpm
Set pump speed to 35%
├── Pump speed 2010 rpm
Set pump speed to 40%
├── Pump speed 2040 rpm
Set pump speed to 45%
├── Pump speed 2040 rpm
Set pump speed to 50%
├── Pump speed 2040 rpm
Set pump speed to 55%
├── Pump speed 2160 rpm
Set pump speed to 60%
├── Pump speed 2280 rpm
Set pump speed to 65%
├── Pump speed 2340 rpm
Set pump speed to 70%
├── Pump speed 2550 rpm
Set pump speed to 75%
├── Pump speed 2610 rpm
Set pump speed to 80%
├── Pump speed 2760 rpm
Set pump speed to 85%
├── Pump speed 2850 rpm
Set pump speed to 90%
├── Pump speed 3000 rpm
Set pump speed to 95%
├── Pump speed 3030 rpm
Set pump speed to 100%
├── Pump speed 3120 rpm
root@megumi:~# liquidctl --version
liquidctl v1.3.0rc1 (5099594b5bf2)
root@megumi:~# for i in {0..20}; do echo "Set pump speed to $((i*5))%"; liquidctl --match H115i set pump speed $((i*5)); sleep 1; liquidctl --match H115i status | grep Pump; done
Set pump speed to 0%
├── Pump speed 1980 rpm
Set pump speed to 5%
├── Pump speed 2040 rpm
Set pump speed to 10%
├── Pump speed 2010 rpm
Set pump speed to 15%
├── Pump speed 2010 rpm
Set pump speed to 20%
├── Pump speed 2040 rpm
Set pump speed to 25%
├── Pump speed 2010 rpm
Set pump speed to 30%
├── Pump speed 2040 rpm
Set pump speed to 35%
├── Pump speed 2040 rpm
Set pump speed to 40%
├── Pump speed 2010 rpm
Set pump speed to 45%
├── Pump speed 1980 rpm
Set pump speed to 50%
├── Pump speed 2010 rpm
Set pump speed to 55%
├── Pump speed 2130 rpm
Set pump speed to 60%
├── Pump speed 2280 rpm
Set pump speed to 65%
├── Pump speed 2400 rpm
Set pump speed to 70%
├── Pump speed 2550 rpm
Set pump speed to 75%
├── Pump speed 2490 rpm
Set pump speed to 80%
├── Pump speed 2760 rpm
Set pump speed to 85%
├── Pump speed 2850 rpm
Set pump speed to 90%
├── Pump speed 3000 rpm
Set pump speed to 95%
├── Pump speed 3000 rpm
Set pump speed to 100%
├── Pump speed 3060 rpm
from liquidtux.
Interesting, the pump won't react under 50%
from liquidtux.
Interesting, the pump won't react under 50%
In all AIOs I know of the firmware simply ignores pump duties bellow a certain threshold.
The liquidctl driver also enforces this limit, as it has to match what the firmware supports to be able to follow the complicated pump setting routine (in summary: we need to send values between 0x32 and 0x42).
mtype, dmin, dmax = _FIXED_SPEED_CHANNELS[channel]
duty = clamp(duty, dmin, dmax)
total_levels = _MAX_PUMP_SPEED_CODE - _MIN_PUMP_SPEED_CODE + 1
level = round((duty - dmin)/(dmax - dmin)*total_levels)
effective_duty = round(dmin + level*(dmax - dmin)/total_levels)
LOGGER.info('setting %s PWM duty to %i%% (level %i)', channel, effective_duty, level)
self._begin_transaction()
self._write([mtype, _MIN_PUMP_SPEED_CODE + level])
self._end_transaction_and_read()
—liquidctl/driver/asetek.py#L277-L285
(You can see the actual duty value being send to the cooler by passing --verbose
).
In fact, what I'm wondering is precisely if the H115i should share this complicated pump speed setting routine, which was inherited from EVGA CLCs, or use something simpler.
So far the output (with the complicated setting) looks alright to me, but does ~3100 rpm seem reasonable to you as the the maximum pump speed the cooler supports?
from liquidtux.
Hmm, I'm thinking that it IS meant as the pump's max, could the pump have an internal limiter so it doesn't overload itself ?
I'm wouldn't be suprised if there was a limit in the firmware.
from liquidtux.
Hm, okay, it might not be a good idea to have it SET to max at all times, but that's not what it should be anyway.
As far as I can tell, it's only when it hits the thermal target that causes it to ramp up to it that it probably should.
I can't remember if either liquidctl or the original (Windows) LINK sw managed the pump speed depending on the thermals.
But, some ( 1 2 3 4 ) places sime to point to about 2800rpm as a performance (max?) limit.
I wonder if something like 2900-3000 should be better as a MAX upper limit
from liquidtux.
I can't remember if either liquidctl or the original (Windows) LINK sw managed the pump speed depending on the thermals.
As far as I know this would need to happen in software, as it isn't natively supported by the firmware (at least on my test EVGA CLC). The device only supports profiles for fan speeds, based on the liquid temperature.
In the kernel driver this means that we will probably have:
pwm1_auto_point[1-6]_[pwm|temp]
for fan channel, andpwm2
for the pump channel
On the subject of fan control, this should fully expose the hardware capabilities, but I'm not sure how fancontrol
would external sensors (e.g. CPU temperature).
Hmm, I'm thinking that it IS meant as the pump's max,
Sorry, I didn't understand what you meant here.
could the pump have an internal limiter so it doesn't overload itself ?
I'm wouldn't be suprised if there was a limit in the firmware.
Certainly.
Hm, okay, it might not be a good idea to have it SET to max at all times, but that's not what it should be anyway.
As far as I can tell, it's only when it hits the thermal target that causes it to ramp up to it that it probably should.
I wonder if something like 2900-3000 should be better as a MAX upper limit
I'm not sure what you meant regarding what the max is or should be set to.
A hwmon kernel driver should expose what the device supports. I think the only exceptions would be settings/parameters that are unquestionably dangerous.
(liquidctl follows a similar philosophy)
But, some ( 1 2 3 4 ) places sime to point to about 2800rpm as a performance (max?) limit.
Yeah, I've seen some references to different pump "modes" (e.g. "performance"). Any chance one of you can provide a USB traffic capture of these modes being set?
from liquidtux.
A cap in windows ? no, sorry. Anyone else ?
from liquidtux.
I haven't started to work on this new driver for Asetek 690LC variants and, at the current rate, I'm probably not going to get to it before these coolers become irrelevant.
Closing the issue to avoid building up expectations.
Please consider using liquidctl instead.
from liquidtux.
@jonasmalacofilho Is the protocol used by Asetek 690LC variants no longer being used in currently manufactured devices?
from liquidtux.
@jameshilliard the only current sold devices I know of with this protocol are the EVGA CLCs and the Corsair v2s (H80i v2, H100i v2, H115i).
But Corsair seems to have moved on from this design already. So only EGVA stands (AFAIK).
from liquidtux.
Related Issues (19)
- Kernel driver for corsair coolers HOT 6
- nzxt-kraken2: fan/pump control HOT 2
- Grid v3 upstreaming HOT 4
- nzxt-kraken3 upstreaming? HOT 30
- Usage with fancontrol HOT 2
- ci: enable codespell
- Disable squash merges HOT 11
- Match file locations with the kernel tree HOT 1
- nzxt-smart2: maybe error on stale data?
- ci: test CONFIG_DEBUG_FS=y/n
- nzxt-kraken3.c: ‘get_fw_version_cmd’ defined but not used with CONFIG_DEBUG_FS=n
- gitversion.sh (and then dkms) fails on clones without tags HOT 2
- Thanks HOT 1
- Migrate to Rust HOT 2
- NZXT Smartdevice v2 support HOT 5
- Building with W=1? HOT 1
- nzxt-kraken: Incorrect order of failing in probe HOT 1
- X63 support HOT 40
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from liquidtux.