-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asus ROG Strix LC III 360 #685
Comments
How can I help to integrate this device into liquidctl? I tried reading CONTRIBUTING.md but I don't know how to decode captured data (lack of experiences). Any help will be appreciated. |
Capturing USB traffic is a good tutorial for that. |
And as a complement, there's also Techniques for analyzing USB protocols. |
Hi and thank you for your answer. I read all the two guide and I reached the tshark step where I obtain data like this:
but I don't know how to interpret them. |
It generally also helps to correlate the captured transfers with what was going on with the cooler (e.g. initialization, reporting increasing temperatures or speeds, setting different fan/pump speeds, etc.). |
Hi, |
Oh, sorry, I've been away from the project for a few weeks and missed the context. In that case, my first though is that Many devices also support hardware modes, that is, lighting effects that once set, work independently of software. Figuring them out requires finding a way to make the first-party application set them: some tools, like iCue, have explicit "hardware" modes; others set them automatically when you close the application; and there are some that simply don't support them (even when the actual device firmware does), in which case we can sometimes still find the hardware modes by experimenting with changing arbitrary bytes in the packets (note: this type of experiment carries some risk). |
Hi, and thank you for your answer. I done another test with capture and tried to set color to red (#ff0000). On of the lines is: ec40800004ff0000ff0000ff0000ff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 where: ff0000ff0000ff0000ff0000 is the color setting and the rest: is null, maybe it is space for other features (if I'm not wrong, for this cooler I can change the top and add an LCD screen top, maybe the remaining 000... could be used for that.) I made another test changing the effect (the previous effect was "static"), in this test I set "breath" effect and the code is equal except for color, but I noticed that it appears as (continous) stream of command where in each command there is a different color to make the effect. At this point. how can I try to write on the USB device using dev /dev/bus/usb/001/004 ? There is another way? Thank you in advance. |
I would add I found another command when I change the color: ec40800004000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ec40800004 the first command and the remaining 0. |
That seems reasonable. Since this is a It's possible that something like EDIT: you probably also want to take a look at some basics of the USB protocol, like transfer/endpoint types. PyUSB abstracts some of that stuff way (like interrupt vs bulk reads/writes), but since it's an extra layer, it can sometimes also make things more confusing if the device does weird/unusual things. |
Hi, This could be initialization of the device? This should be the reset before setting any color/effect This is the color/effect settings (from the system when booting) Then I left wireshark capturing and I noticed some request (don't know if sent by the VM kernel or Armoury Crate) with this data: (the previous was sent many times example: 20s after capture starts, 102s, 204s, 326s, 471s.......) During shutdown the VM I don't get any request as the reported but something like this: Setup Data Setup Data Setup Data Setup Data Setup Data Setup Data Setup Data Setup Data Setup Data |
On second thought, the protocol used for the logo doesn't look anything like Asetek's. And from the latter data it seems that only the HID interface is used. In fact, we actually have some code supporting HID-based Aura devices, and looking at it now (admittedly only superficially) it looks quite close to what you've reported. P.S. I appreciate the summarized data, but please also attach the raw Wireshark files in case we need to look at the data in more detail. |
Hi,
|
Hi, Best regards |
Hi, I tried something like this:
but I get Resource Busy and can't find a solution. Any help will be appreciated. |
dev = usb.core.find(idVendor=VENDOR_ID, idProduct=PRODUCT_ID)
# Ensure the device is found
if dev is None:
raise ValueError('Device not found')
# https://elixir.bootlin.com/linux/latest/source/drivers/usb/core/devio.c#L1558
# the usbfs driver in Linux has a limitation that if any interface of the device is claimed by a kernel
# driver no interface can be claimed by a libusb process. So you have to iterate through all of the
# interfaces and detach the kernel driver on all of them
for cfg in dev:
for intf in cfg:
if dev.is_kernel_driver_active(intf.bInterfaceNumber):
print(f"Detaching kernel driver from interface {intf.bInterfaceNumber}")
try:
dev.detach_kernel_driver(intf.bInterfaceNumber)
except usb.core.USBError as e:
print(f"Could not detach kernel driver from interface {intf.bInterfaceNumber}: {str(e)}") try that the commands will be similar to this #677 (comment) If you use wireshark/fiddler and look for If you attach a debugger to armoury crate, in the console output of |
No luck, I get:
|
Well at least it’s not busy any more!
Try pasting the entire usb packet into copilot/chatgpt/gemini and tell it
it is from usbpcap and you want to replay this packet using pyusb, this is
what I did
…On Thu, 11 Jul 2024 at 08:06, sdns575 ***@***.***> wrote:
No luck, I get:
assert ep is not None
—
Reply to this email directly, view it on GitHub
<#685 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB2QMJ4J2S4MM7X75GVS7DZLYVIFAVCNFSM6AAAAABFBT4XSOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRSGE4TENJSG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Device type
AIO Liquid Cooler
Product page
https://rog.asus.com/cooling/cpu-liquid-coolers/rog-strix-lc/rog-strix-lc-iii-360/
First-party software
Armoury Crate
What monitoring functionality does the device support?
No response
What configuration functionality does the device support?
lighting of embedded LEDs
Physical connection
USB Header
Connection protocol
USB/HID
Additional information about the device
Bus 001 Device 004: ID 0b05:1b29 ASUSTek Computer, Inc. AURA LED Controller
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0b05 ASUSTek Computer, Inc.
idProduct 0x1b29
bcdDevice 1.00
iManufacturer 1 AsusTek Computer Inc.
iProduct 2 AURA LED Controller
iSerial 3 9876543210
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x002b
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 16mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 36
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
Device Status: 0x0001
Self Powered
Can you help with implementing or testing the changes needed for liquidctl to support this device?
testing changes on Linux, attempting to capture USB/HID traffic
The text was updated successfully, but these errors were encountered: