Closed sistematico closed 3 years ago
@sistematico Can you please connect dongle and provide output of dmesg
and sudo lsusb -v -d 046d:0a66
?
@doctor64
dmesg
[ 9188.245823] usb 1-2: new full-speed USB device number 8 using xhci_hcd
[ 9188.414826] usb 1-2: New USB device found, idVendor=046d, idProduct=0a66
[ 9188.414830] usb 1-2: New USB device strings: Mfr=3, Product=4, SerialNumber=0
[ 9188.414834] usb 1-2: Product: G533 Gaming Headset
[ 9188.414837] usb 1-2: Manufacturer: Logitech
[ 9188.550781] input: Logitech G533 Gaming Headset as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.3/0003:046D:0A66.000C/input/input23
[ 9188.610576] hid-generic 0003:046D:0A66.000C: input,hiddev1,hidraw2: USB HID v1.11 Device [Logitech G533 Gaming Headset] on usb-0000:00:14.0-2/input3
lsusb
``` Bus 001 Device 008: ID 046d:0a66 Logitech, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x046d Logitech, Inc. idProduct 0x0a66 bcdDevice 1.00 iManufacturer 3 Logitech iProduct 4 G533 Gaming Headset iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 269 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 1 G533 Gaming Headset AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 71 bInCollection 2 baInterfaceNr( 0) 1 baInterfaceNr( 1) 2 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 6 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 1 wChannelConfig 0x0000 iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 3 bSourceID 6 bControlSize 1 bmaControls( 0) 0x03 Mute Control Volume Control bmaControls( 1) 0x00 iFeature 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 7 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 3 iTerminal 0 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 2 bSourceID 1 bControlSize 1 bmaControls( 0) 0x03 Mute Control Volume Control bmaControls( 1) 0x00 bmaControls( 2) 0x00 iFeature 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 5 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 2 iTerminal 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 7 bDelay 0 frames wFormatTag 1 PCM AudioStreaming Interface Descriptor: bLength 32 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 1 bSubframeSize 2 bBitResolution 16 bSamFreqType 8 Discrete tSamFreq[ 0] 8000 tSamFreq[ 1] 11025 tSamFreq[ 2] 16000 tSamFreq[ 3] 22050 tSamFreq[ 4] 24000 tSamFreq[ 5] 32000 tSamFreq[ 6] 44100 tSamFreq[ 7] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 13 Transfer Type Isochronous Synch Type Synchronous Usage Type Data wMaxPacketSize 0x0090 1x 144 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioControl Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0 Undefined Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 1 bDelay 0 frames wFormatTag 1 PCM AudioStreaming Interface Descriptor: bLength 32 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 8 Discrete tSamFreq[ 0] 8000 tSamFreq[ 1] 11025 tSamFreq[ 2] 16000 tSamFreq[ 3] 22050 tSamFreq[ 4] 24000 tSamFreq[ 5] 32000 tSamFreq[ 6] 44100 tSamFreq[ 7] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 13 Transfer Type Isochronous Synch Type Synchronous Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioControl Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0 Undefined Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 2 G533 Gaming Headset HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 407 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Device Status: 0x0000 (Bus Powered) ```
@0x4C4A Ah, so at least it detected as hdraw device. This looks promising. I try to get hardware and play with it.
Just got mine and I would love to see support for it!
If anyone with the hardware wants to push this further, you could try to add the receiver to the list of supported receivers in lib/logitech_recceiver/base_usb.py. If you are already running solaar then making small changes to it should be easy.
First clone this repository and try running bin/solaar from your clone. (You may have to install some dependencies - see docs/installation.md.)
Then add the receiver to base_usb.py as a unifying receiver by adding the lines
UNIFYING_RECEIVER_0A66 = _unifying_receiver(0x0a66)
and
UNIFYING_RECEIVER_0A66,
in the obvious places. (That's probably not correct, but should be good enough for now.) Next run Solaar as root, as in
sudo bin/solaar
(You have to run as root because the udev script that changes permissions on hidraw devices doesn't have this receiver in it.)
If you don't see your receiver and device in the Solaar window then support for this device is probably not going to be easy. If you do see something there please respond with the output of sudo bin/solaar show
and sudo bin/solaar probe
(assuming you only have one Logitech receiver attached to your computer, otherwise you will probably need to use the -D option to select the correct receiver).
Adding support for the features of this device that are currently not supported in Solaar may require you to do the programming for them.
Can you install hid-tools and run hid-recorder
on the receiver? You can ctrl+c when it starts recording, I am just interested in the initial information it spits out.
@pfps I'll try that later
@FFY00
``` # Logitech G533 Gaming Headset # 0x05, 0x0c, // Usage Page (Consumer Devices) 0 # 0x09, 0x01, // Usage (Consumer Control) 2 # 0xa1, 0x01, // Collection (Application) 4 # 0x85, 0x01, // Report ID (1) 6 # 0x09, 0xe9, // Usage (Volume Up) 8 # 0x09, 0xea, // Usage (Volume Down) 10 # 0x75, 0x01, // Report Size (1) 12 # 0x95, 0x02, // Report Count (2) 14 # 0x15, 0x00, // Logical Minimum (0) 16 # 0x25, 0x01, // Logical Maximum (1) 18 # 0x81, 0x02, // Input (Data,Var,Abs) 20 # 0x75, 0x06, // Report Size (6) 22 # 0x95, 0x01, // Report Count (1) 24 # 0x81, 0x03, // Input (Cnst,Var,Abs) 26 # 0x75, 0x18, // Report Size (24) 28 # 0x81, 0x03, // Input (Cnst,Var,Abs) 30 # 0xc0, // End Collection 32 # 0x05, 0x0b, // Usage Page (Telephony Devices) 33 # 0x09, 0x01, // Usage (Phone) 35 # 0xa1, 0x01, // Collection (Application) 37 # 0x85, 0x08, // Report ID (8) 39 # 0x09, 0x2f, // Usage (Phone Mute) 41 # 0x75, 0x01, // Report Size (1) 43 # 0x81, 0x06, // Input (Data,Var,Rel) 45 # 0x09, 0x20, // Usage (Hook Switch) 47 # 0x81, 0x06, // Input (Data,Var,Rel) 49 # 0x75, 0x06, // Report Size (6) 51 # 0x81, 0x03, // Input (Cnst,Var,Abs) 53 # 0xc0, // End Collection 55 # 0x06, 0x43, 0xff, // Usage Page (Vendor Usage Page 0xff43) 56 # 0x0a, 0x02, 0x02, // Usage (Vendor Usage 0x202) 59 # 0xa1, 0x01, // Collection (Application) 62 # 0x85, 0x11, // Report ID (17) 64 # 0x95, 0x13, // Report Count (19) 66 # 0x75, 0x08, // Report Size (8) 68 # 0x26, 0xff, 0x00, // Logical Maximum (255) 70 # 0x09, 0x02, // Usage (Vendor Usage 0x02) 73 # 0x81, 0x00, // Input (Data,Arr,Abs) 75 # 0x09, 0x02, // Usage (Vendor Usage 0x02) 77 # 0x91, 0x00, // Output (Data,Arr,Abs) 79 # 0xc0, // End Collection 81 # 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 82 # 0x09, 0x01, // Usage (Vendor Usage 1) 85 # 0xa1, 0x01, // Collection (Application) 87 # 0x09, 0x0a, // Usage (Vendor Usage 0x0a) 89 # 0xa1, 0x02, // Collection (Logical) 91 # 0x85, 0xff, // Report ID (255) 93 # 0x95, 0x01, // Report Count (1) 95 # 0x75, 0x20, // Report Size (32) 97 # 0x09, 0x0b, // Usage (Vendor Usage 0x0b) 99 # 0x17, 0x01, 0x00, 0x00, 0x80, // Logical Minimum (-2147483647) 101 # 0x27, 0xff, 0xff, 0xff, 0x7f, // Logical Maximum (2147483647) 106 # 0x81, 0x02, // Input (Data,Var,Abs) 111 # 0xc0, // End Collection 113 # 0x09, 0x22, // Usage (Vendor Usage 0x22) 114 # 0xa1, 0x02, // Collection (Logical) 116 # 0x85, 0x90, // Report ID (144) 118 # 0x09, 0x33, // Usage (Vendor Usage 0x33) 120 # 0x75, 0x08, // Report Size (8) 122 # 0x15, 0x00, // Logical Minimum (0) 124 # 0x26, 0xff, 0x00, // Logical Maximum (255) 126 # 0x81, 0x02, // Input (Data,Var,Abs) 129 # 0x09, 0x34, // Usage (Vendor Usage 0x34) 131 # 0x81, 0x02, // Input (Data,Var,Abs) 133 # 0x05, 0x01, // Usage Page (Generic Desktop) 135 # 0x09, 0x3b, // Usage (Byte Count) 137 # 0x75, 0x10, // Report Size (16) 139 # 0x27, 0xff, 0xff, 0x00, 0x00, // Logical Maximum (65535) 141 # 0x81, 0x02, // Input (Data,Var,Abs) 146 # 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 148 # 0x09, 0x0a, // Usage (Vendor Usage 0x0a) 151 # 0xa1, 0x02, // Collection (Logical) 153 # 0x05, 0x0a, // Usage Page (Ordinals) 155 # 0x19, 0x01, // Usage Minimum (1) 157 # 0x29, 0x0a, // Usage Maximum (10) 159 # 0x95, 0x0a, // Report Count (10) 161 # 0x75, 0x08, // Report Size (8) 163 # 0x26, 0xff, 0x00, // Logical Maximum (255) 165 # 0x81, 0x02, // Input (Data,Var,Abs) 168 # 0xc0, // End Collection 170 # 0xc0, // End Collection 171 # 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 172 # 0x09, 0x22, // Usage (Vendor Usage 0x22) 175 # 0xa1, 0x02, // Collection (Logical) 177 # 0x85, 0x90, // Report ID (144) 179 # 0x09, 0x33, // Usage (Vendor Usage 0x33) 181 # 0x95, 0x01, // Report Count (1) 183 # 0x91, 0x02, // Output (Data,Var,Abs) 185 # 0x09, 0x34, // Usage (Vendor Usage 0x34) 187 # 0x91, 0x02, // Output (Data,Var,Abs) 189 # 0x05, 0x01, // Usage Page (Generic Desktop) 191 # 0x09, 0x3b, // Usage (Byte Count) 193 # 0x75, 0x10, // Report Size (16) 195 # 0x27, 0xff, 0xff, 0x00, 0x00, // Logical Maximum (65535) 197 # 0x91, 0x02, // Output (Data,Var,Abs) 202 # 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 204 # 0x09, 0x0a, // Usage (Vendor Usage 0x0a) 207 # 0xa1, 0x02, // Collection (Logical) 209 # 0x05, 0x0a, // Usage Page (Ordinals) 211 # 0x19, 0x01, // Usage Minimum (1) 213 # 0x29, 0x0a, // Usage Maximum (10) 215 # 0x95, 0x0a, // Report Count (10) 217 # 0x75, 0x08, // Report Size (8) 219 # 0x26, 0xff, 0x00, // Logical Maximum (255) 221 # 0x91, 0x02, // Output (Data,Var,Abs) 224 # 0xc0, // End Collection 226 # 0xc0, // End Collection 227 # 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 228 # 0x09, 0x22, // Usage (Vendor Usage 0x22) 231 # 0xa1, 0x02, // Collection (Logical) 233 # 0x85, 0xc4, // Report ID (196) 235 # 0x09, 0x33, // Usage (Vendor Usage 0x33) 237 # 0x95, 0x01, // Report Count (1) 239 # 0x81, 0x02, // Input (Data,Var,Abs) 241 # 0x09, 0x34, // Usage (Vendor Usage 0x34) 243 # 0x81, 0x02, // Input (Data,Var,Abs) 245 # 0x05, 0x01, // Usage Page (Generic Desktop) 247 # 0x09, 0x3b, // Usage (Byte Count) 249 # 0x75, 0x10, // Report Size (16) 251 # 0x27, 0xff, 0xff, 0x00, 0x00, // Logical Maximum (65535) 253 # 0x81, 0x02, // Input (Data,Var,Abs) 258 # 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 260 # 0x09, 0x0a, // Usage (Vendor Usage 0x0a) 263 # 0xa1, 0x02, // Collection (Logical) 265 # 0x05, 0x0a, // Usage Page (Ordinals) 267 # 0x19, 0x01, // Usage Minimum (1) 269 # 0x29, 0x3b, // Usage Maximum (59) 271 # 0x95, 0x3b, // Report Count (59) 273 # 0x75, 0x08, // Report Size (8) 275 # 0x26, 0xff, 0x00, // Logical Maximum (255) 277 # 0x81, 0x02, // Input (Data,Var,Abs) 280 # 0xc0, // End Collection 282 # 0xc0, // End Collection 283 # 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 284 # 0x09, 0x22, // Usage (Vendor Usage 0x22) 287 # 0xa1, 0x02, // Collection (Logical) 289 # 0x85, 0xc4, // Report ID (196) 291 # 0x09, 0x33, // Usage (Vendor Usage 0x33) 293 # 0x95, 0x01, // Report Count (1) 295 # 0x91, 0x02, // Output (Data,Var,Abs) 297 # 0x09, 0x34, // Usage (Vendor Usage 0x34) 299 # 0x91, 0x02, // Output (Data,Var,Abs) 301 # 0x05, 0x01, // Usage Page (Generic Desktop) 303 # 0x09, 0x3b, // Usage (Byte Count) 305 # 0x75, 0x10, // Report Size (16) 307 # 0x27, 0xff, 0xff, 0x00, 0x00, // Logical Maximum (65535) 309 # 0x91, 0x02, // Output (Data,Var,Abs) 314 # 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 316 # 0x09, 0x0a, // Usage (Vendor Usage 0x0a) 319 # 0xa1, 0x02, // Collection (Logical) 321 # 0x05, 0x0a, // Usage Page (Ordinals) 323 # 0x19, 0x01, // Usage Minimum (1) 325 # 0x29, 0x3b, // Usage Maximum (59) 327 # 0x95, 0x3b, // Report Count (59) 329 # 0x75, 0x08, // Report Size (8) 331 # 0x26, 0xff, 0x00, // Logical Maximum (255) 333 # 0x91, 0x02, // Output (Data,Var,Abs) 336 # 0xc0, // End Collection 338 # 0xc0, // End Collection 339 # 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 340 # 0x09, 0x0c, // Usage (Vendor Usage 0x0c) 343 # 0xa1, 0x02, // Collection (Logical) 345 # 0x85, 0xff, // Report ID (255) 347 # 0x05, 0x01, // Usage Page (Generic Desktop) 349 # 0x09, 0x3b, // Usage (Byte Count) 351 # 0x95, 0x01, // Report Count (1) 353 # 0xb1, 0x02, // Feature (Data,Var,Abs) 355 # 0x09, 0x3a, // Usage (Counted Buffer) 357 # 0xa1, 0x02, // Collection (Logical) 359 # 0x05, 0x0a, // Usage Page (Ordinals) 361 # 0x19, 0x01, // Usage Minimum (1) 363 # 0x29, 0x3e, // Usage Maximum (62) 365 # 0x95, 0x3e, // Report Count (62) 367 # 0xb1, 0x02, // Feature (Data,Var,Abs) 369 # 0xc0, // End Collection 371 # 0xc0, // End Collection 372 # 0x06, 0x00, 0xff, // Usage Page (Vendor Defined Page 1) 373 # 0x09, 0x0c, // Usage (Vendor Usage 0x0c) 376 # 0xa1, 0x02, // Collection (Logical) 378 # 0x85, 0xe2, // Report ID (226) 380 # 0x05, 0x01, // Usage Page (Generic Desktop) 382 # 0x09, 0x3b, // Usage (Byte Count) 384 # 0x95, 0x01, // Report Count (1) 386 # 0x81, 0x02, // Input (Data,Var,Abs) 388 # 0x09, 0x3a, // Usage (Counted Buffer) 390 # 0xa1, 0x02, // Collection (Logical) 392 # 0x05, 0x0a, // Usage Page (Ordinals) 394 # 0x19, 0x01, // Usage Minimum (1) 396 # 0x29, 0x3e, // Usage Maximum (62) 398 # 0x95, 0x3e, // Report Count (62) 400 # 0x81, 0x02, // Input (Data,Var,Abs) 402 # 0xc0, // End Collection 404 # 0xc0, // End Collection 405 # 0xc0, // End Collection 406 # R: 407 05 0c 09 01 a1 01 85 01 09 e9 09 ea 75 01 95 02 15 00 25 01 81 02 75 06 95 01 81 03 75 18 81 03 c0 05 0b 09 01 a1 01 85 08 09 2f 75 01 81 06 09 20 81 06 75 06 81 03 c0 06 43 ff 0a 02 02 a1 01 85 11 95 13 75 08 26 ff 00 09 02 81 00 09 02 91 00 c0 06 00 ff 09 01 a1 01 09 0a a1 02 85 ff 95 01 75 20 09 0b 17 01 00 00 80 27 ff ff ff 7f 81 02 c0 09 22 a1 02 85 90 09 33 75 08 15 00 26 ff 00 81 02 09 34 81 02 05 01 09 3b 75 10 27 ff ff 00 00 81 02 06 00 ff 09 0a a1 02 05 0a 19 01 29 0a 95 0a 75 08 26 ff 00 81 02 c0 c0 06 00 ff 09 22 a1 02 85 90 09 33 95 01 91 02 09 34 91 02 05 01 09 3b 75 10 27 ff ff 00 00 91 02 06 00 ff 09 0a a1 02 05 0a 19 01 29 0a 95 0a 75 08 26 ff 00 91 02 c0 c0 06 00 ff 09 22 a1 02 85 c4 09 33 95 01 81 02 09 34 81 02 05 01 09 3b 75 10 27 ff ff 00 00 81 02 06 00 ff 09 0a a1 02 05 0a 19 01 29 3b 95 3b 75 08 26 ff 00 81 02 c0 c0 06 00 ff 09 22 a1 02 85 c4 09 33 95 01 91 02 09 34 91 02 05 01 09 3b 75 10 27 ff ff 00 00 91 02 06 00 ff 09 0a a1 02 05 0a 19 01 29 3b 95 3b 75 08 26 ff 00 91 02 c0 c0 06 00 ff 09 0c a1 02 85 ff 05 01 09 3b 95 01 b1 02 09 3a a1 02 05 0a 19 01 29 3e 95 3e b1 02 c0 c0 06 00 ff 09 0c a1 02 85 e2 05 01 09 3b 95 01 81 02 09 3a a1 02 05 0a 19 01 29 3e 95 3e 81 02 c0 c0 c0 N: Logitech G533 Gaming Headset I: 3 046d 0a66 ```
Looks like it should support long HID++ packets, so that's good. But it also looks like there is something else going on, I am not sure how relevant the other vendor usages are, we will need to find out.
Please do what @pfps said and we'll see what we can get from there.
Well, it didn't show up. Installed the udev rules and replugged the device. I don't have the plugdev group to add myself to, but hidraw0 seems to have my user's group. And I'm running it with sudo anyway.
See if I'm missing something:
diff --git a/lib/logitech_receiver/base_usb.py b/lib/logitech_receiver/base_usb.py
index 832024a..5057563 100644
--- a/lib/logitech_receiver/base_usb.py
+++ b/lib/logitech_receiver/base_usb.py
@@ -79,6 +79,7 @@ _lightspeed_receiver = lambda product_id: {
# standard Unifying receivers (marked with the orange Unifying logo)
UNIFYING_RECEIVER_C52B = _unifying_receiver(0xc52b)
UNIFYING_RECEIVER_C532 = _unifying_receiver(0xc532)
+UNIFYING_RECEIVER_0A66 = _unifying_receiver(0x0a66)
# Nano receviers that support the Unifying protocol
NANO_RECEIVER_ADVANCED = _nano_receiver(0xc52f)
@@ -108,6 +109,7 @@ del _DRIVER, _unifying_receiver, _nano_receiver, _lenovo_receiver, _lightspeed_r
ALL = (
UNIFYING_RECEIVER_C52B,
UNIFYING_RECEIVER_C532,
+ UNIFYING_RECEIVER_0A66,
NANO_RECEIVER_ADVANCED,
NANO_RECEIVER_C517,
NANO_RECEIVER_C518,
diff --git a/rules.d/42-logitech-unify-permissions.rules b/rules.d/42-logitech-unify-permissions.rules
index bcd2b4c..30e9014 100644
--- a/rules.d/42-logitech-unify-permissions.rules
+++ b/rules.d/42-logitech-unify-permissions.rules
@@ -10,6 +10,7 @@ SUBSYSTEM != "hidraw", GOTO="solaar_end"
# official Unifying receivers
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", GOTO="solaar_apply"
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c532", GOTO="solaar_apply"
+ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0a66", GOTO="solaar_apply"
# Nano receiver, "Unifying Ready"
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52f", GOTO="solaar_apply"
boris@g1 ~/Solaar (master *%) » sudo hid-recorder
Available devices:
/dev/hidraw0: Logitech G533 Gaming Headset
/dev/hidraw1: Logitech Gaming Mouse G502
/dev/hidraw2: Logitech Gaming Mouse G502
/dev/hidraw3: Ultimate Gadget Laboratories Ultimate Hacking Keyboard
/dev/hidraw4: Ultimate Gadget Laboratories Ultimate Hacking Keyboard
/dev/hidraw5: Ultimate Gadget Laboratories Ultimate Hacking Keyboard
/dev/hidraw6: Ultimate Gadget Laboratories Ultimate Hacking Keyboard
/dev/hidraw7: Ultimate Gadget Laboratories Ultimate Hacking Keyboard
/dev/hidraw8: American Power Conversion Back-UPS XS 950U FW:925.T2 .I USB FW:T2
Select the device event number [0-8]: ^C% boris@g1 ~/Solaar (master *%) » ll /dev/hidraw0
crw-rw----+ 1 root boris 238, 0 Mar 26 16:11 /dev/hidraw0
boris@g1 ~/Solaar (master *%) » sudo bin/solaar
(solaar:13930): libappindicator-WARNING **: 16:13:58.416: Unable to get the session bus: Error spawning command line “dbus-launch --autolaunch=d4c88f517698407e984c821ecae31c7e --binary-syntax --close-stderr”: Child process exited with code 1
(solaar:13930): LIBDBUSMENU-GLIB-WARNING **: 16:13:58.416: Unable to get session bus: Error spawning command line “dbus-launch --autolaunch=d4c88f517698407e984c821ecae31c7e --binary-syntax --close-stderr”: Child process exited with code 1
boris@g1 ~/Solaar (master *%) » sudo bin/solaar show
solaar: error: Logitech receiver not found
That's weird. I wonder why solaar show
isn't picking up the receiver at all. I don't see debugging statements in the part of the code that I think is involved so I don't think debugging output will be helpful, but you could try sudo bin/solaar -dd show
-dd
didn't show anything else.
The receiver probably doesn't respond. This indicates that it maybe doesn't support HID++?
Once you have time try to connect it to a Windows VM, run Logitech's software and sniff the communication with Wireshark. When you do this make sure to capture the initial packets sent by the software, to do this you can pass the receiver to the VM while Windows is starting or alternatively kill the background app, start recording and start the app again.
I was thinking about doing that. I have dual-boot, I'll try to sniff it there. I guess reconnecting the device would cause the driver to send what's necessary.
Here's the capture file, filtered just this device: https://drive.google.com/open?id=1zwBnaTlrNBlw6w_SX_h6eHw9Z_jCJmf0
I tried adding the G533 to the list of detectable devices. Solaar hangs at https://github.com/pwr-Solaar/Solaar/blob/58a1c7ffb0e153159e9482d5683357feff84c7ce/lib/logitech_receiver/receiver.py#L342 because it presumes it's dealing with a unified receiver which understands HID++ 1.0.
G533 comes with a dedicated dongle that cannot be paired to arbitrary devices. lsusb
output:
Bus 003 Device 038: ID 046d:0a66 Logitech, Inc. [G533 Wireless Headset Dongle]
It works out of the box on Linux as a USB audio device, however it talks HID++4.2 in case of my headset (the dongle itself reports that version when queried).
So the first stage would be refactoring the code to conditionally skip the HID++1.0 conversation in Receiver.__init__
and allow treating the dongle as the target device itself. If you look at the HID++ driver in Linux kernel, the very first thing they do is to ask the device which protocol version it supports before they send any more queries to it:
https://github.com/torvalds/linux/blob/v5.6/drivers/hid/hid-logitech-hidpp.c#L877
Yeah, I don't really think such big changes should go into solaar. We are basically just trying to fix the current code and adding minor improvements.
The plan is to write a daemon and drop the backend from Solaar. I have already been working on the daemon but is still very barebones, you can still test it with your device and make sure the daemon can correctly talk to it. You can find the code here, you will need to add your device to __main__.py
. To run the daemon simply invoke python -m logitechd
.
Right now I am working on a DBus library to use in the daemon (see https://github.com/FFY00/jeepney-objects) so don't expect much movement there. All other python dbus libraries are a bit old and with dead or inactive upstreams so I choose to take this route.
IMO the optimal solution long-term would be upstreaming support for all these devices into the hid-logitech-hidpp
kernel driver and then using the kernel's power supply interface, e.g. reading from /sys/class/power_supply/hidpp_battery_X/voltage_now
for matching devices.
That only works for the battery feature. All other features need to be implemented somewhere, and it's not going to be in the kernel driver. We only use the kernel driver for things that require access to kernel internals. Right now, we have two drivers, hid-logitech-dj
which does multiplexing (you can have multiple devices connected to the same receiver and we will export them to userspace as different devices) and hid-logitech-hidpp
which automatically enables high-resolution scrolling and reports battery information. Everything other than that is out of scope.
Closing as out of scope for Solaar at this time.
If someone wants this, they will have to figure out how to add support for the receiver. Either that or wait for a new API for HID++ interactions.
@kdomanski Solaar now supports direct-connected devices that are not receivers. This may mean that your device can easily supported. If you are interested, please respond and reopen this issue.
I'd be interested to assist with this, however would need some pointers as to what to do. (Have a G533 to test with)
@pfps I tried the git checkout pull_968
thing you posted in issue #272 and added a line for G533 as follows:
index e861655..f779b82 100644
--- a/lib/logitech_receiver/descriptors.py
+++ b/lib/logitech_receiver/descriptors.py
@@ -726,3 +726,4 @@ _D('Fujitsu Sonic Mouse', codename='Sonic', protocol=1.0, wpid='1029')
# Headsets (experimental)
_D('G930 Headset Dongle', codename='G930', protocol=4.5, usbid=0x0a1f, kind=_DK.headset, interface=3)
+_D('G533 Headset Dongle', codename='G533', protocol=4.5, usbid=0x0a66, kind=_DK.headset, interface=3)
Unfortunately it didn't work
```$ bin/solaar show
/home/x4c4a/Work/Solaar/lib/solaar/ui/__init__.py:27: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
from gi.repository import GLib, Gtk
[ snipped lines relating to my G900 mouse ]
Wired Devices
solaar: error: Traceback (most recent call last):
File "/home/x4c4a/Work/Solaar/lib/logitech_receiver/base.py", line 209, in write
_hid.write(int(handle), wdata)
File "/home/x4c4a/Work/Solaar/lib/hidapi/udev.py", line 336, in write
raise IOError(_errno.EIO, 'written %d bytes out of expected %d' % (bytes_written, len(data)))
OSError: [Errno 5] written 0 bytes out of expected 7
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/x4c4a/Work/Solaar/lib/solaar/cli/__init__.py", line 199, in run
m.run(c, args, _find_receiver, _find_device)
File "/home/x4c4a/Work/Solaar/lib/solaar/cli/show.py", line 277, in run
_print_device(d, num=dev_num)
File "/home/x4c4a/Work/Solaar/lib/solaar/cli/show.py", line 90, in _print_device
dev.ping()
File "/home/x4c4a/Work/Solaar/lib/logitech_receiver/device.py", line 438, in ping
protocol = _base.ping(self.handle or self.receiver.handle, self.number, long_message=self.bluetooth)
File "/home/x4c4a/Work/Solaar/lib/logitech_receiver/base.py", line 495, in ping
write(ihandle, devnumber, request_data, long_message)
File "/home/x4c4a/Work/Solaar/lib/logitech_receiver/base.py", line 213, in write
raise NoReceiver(reason=reason)
logitech_receiver.base.NoReceiver: {'reason': OSError(5, 'written 0 bytes out of expected 7')}
```
Running `bin/solaar -dd show` yields
```
$ bin/solaar -dd show
/home/x4c4a/Work/Solaar/lib/solaar/ui/__init__.py:27: PyGIWarning: Gtk was imported without specifying a version first. Use gi.require_version('Gtk', '3.0') before import to ensure that the right version gets loaded.
from gi.repository import GLib, Gtk
22:12:24,440 DEBUG [MainThread] solaar.ui.tray: using AppIndicator3
22:12:24,452 DEBUG [MainThread] logitech_receiver.base: (7) <= w[10 FF 83B5 030000]
22:12:24,455 DEBUG [MainThread] logitech_receiver.base: (7) => r[11 FF 83B5 03B52E928B0401080000000000000000]
22:12:24,455 DEBUG [MainThread] logitech_receiver.base: (7) <= w[10 FF 80B2 000000]
22:12:24,457 DEBUG [MainThread] logitech_receiver.base: (7) => r[10 01 410C 325340]
22:12:24,458 DEBUG [MainThread] logitech_receiver.base: (7) => r[10 FF 8002 000000]
22:12:24,490 DEBUG [MainThread] logitech_receiver.base: (7) => r[11 01 0001 00000000000000000000000000000000]
22:12:25,391 WARNING [MainThread] logitech_receiver.base: timeout (0.90/0.90) on device 255 request {80B2} params []
22:12:25,391 DEBUG [MainThread] solaar.cli: [/dev/hidraw5] =>
Any tips on how to proceed?
Thanks for testing. Unfortunately, I forget to say that the Solaar udev rule needs to be installed.
[From installation.md]
You can install this rule by copying, as root,
rules.d/42-logitech-unify-permissions.rules
from Solaar to
/etc/udev/rules.d
.
You will probably also have to tell udev to reload its rule via
sudo udevadm control --reload-rules
.
And then disconnect (unplug) and reconnect (replug) your receiver.
The output of ls -l /dev/hidrawN
(where /dev/hidrawN is the node for your receiver) should have a +
after the permissions once you do this.
If you do have permissions on the device node, then what you are seeing is likely caused by trying to write to an interface that does not accept HID++ messages. See if there are other nodes in /dev/hidraw* that correspond to other interfaces for your receiver. (Use the udevadm command on them and look for 046D:0A66.) If not, you are likely out of luck. If there are other nodes, find their bInterfaceNumber and change the number for interface accordingly.
One way to find out which nodes talk HID++ is to send them an HID++ message using ./tools/hidconsole
. (But you have to redownload the PR first, as there was a bug in hidconsole.)
Here is what I see with two nodes, one that doesn't talk HID++ and one that does:
idefix Solaar> ./tools/hidconsole /dev/hidraw2
.. Opening device /dev/hidraw2
.. Opened handle 3, vendor b'Logitech' product b'G502 LIGHTSPEED Wireless Gaming Mouse' serial '0x330x460x320x330x380x410x460x360x390x420x390x360x350x440x410x42'.
.. Press ^C/^D to exit, or type hex bytes to write to the device.
?? Input: 10000000000000
<< ( 1.792) [10 00 0000 000000] b'\x10\x00\x00\x00\x00\x00\x00'
.. Closing handle 3
Traceback (most recent call last):
File "./tools/hidconsole", line 22, in <module>
hidconsole.main()
File "/home/local/SoftwareDownloads/Solaar/lib/hidapi/hidconsole.py", line 243, in main
_hid.write(handle, data)
File "/home/local/SoftwareDownloads/Solaar/lib/hidapi/udev.py", line 336, in write
raise IOError(_errno.EIO, 'written %d bytes out of expected %d' % (bytes_written, len(data)))
OSError: [Errno 5] written 0 bytes out of expected 7
idefix Solaar> ./tools/hidconsole /dev/hidraw5
.. Opening device /dev/hidraw5
.. Opened handle 3, vendor b'Logitech' product b'G502 LIGHTSPEED Wireless Gaming Mouse' serial '0x330x460x320x330x380x410x460x360x390x420x390x360x350x440x410x42'.
.. Press ^C/^D to exit, or type hex bytes to write to the device.
?? Input: 10000000000000
<< ( 3.744) [10 00 0000 000000] b'\x10\x00\x00\x00\x00\x00\x00'
?? Input: >> ( 3.746) [11 00 0000 00000100000000000000000000000000] b'\x11\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
?? Input:
.. Closing handle 3
idefix Solaar>
Thanks for the tips!
I ran the tests with the udev rules installed, that's all fine.
When performing $ ls -l /dev/hidraw*
, the plus does show up on the Logitech devices and I checked with udevadm info /dev/hidraw*
that the hidraw device with the VID:PID corresponding to the dongle (046D:0A66) has the correct TAGS added.
I did notice that unlike the G900 mouse, there is only one entry, and there's no entry with a sub VID:PID pair (by sub device I mean this - P: /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.2/1-5.1.2:1.2/0003:046D:C539.0008/0003:046D:4053.0009/hidraw/hidraw8
).
There is only one entry with the VID/PID of the G533 (P: /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.1/1-5.1.1:1.3/0003:046D:0A66.0004/hidraw/hidraw4
)
Attempting the hidconsole (I did fetch & checkout your newest edits and I'm on a8adeb0982e31cd540dd2d75974d837ce6eaeace) trick on the G533 device yielded
$ ./tools/hidconsole /dev/hidraw4
.. Opening device /dev/hidraw4
.. Opened handle 3, vendor b'Logitech' product b'G533 Gaming Headset' serial None.
.. Press ^C/^D to exit, or type hex bytes to write to the device.
?? Input: 1000
<< ( 1.400) [10 00 ] b'\x10\x00'
.. Closing handle 3
Traceback (most recent call last):
File "./tools/hidconsole", line 22, in <module>
hidconsole.main()
File "/home/x4c4a/Work/Solaar/lib/hidapi/hidconsole.py", line 243, in main
_hid.write(handle, data)
File "/home/x4c4a/Work/Solaar/lib/hidapi/udev.py", line 336, in write
raise IOError(_errno.EIO, 'written %d bytes out of expected %d' % (bytes_written, len(data)))
OSError: [Errno 5] written 0 bytes out of expected 2
If I try to write it to another of the Logitech hidraw devices (G900 related) I get
$ ./tools/hidconsole /dev/hidraw8
.. Opening device /dev/hidraw8
.. Opened handle 3, vendor b'Logitech' product b'USB Receiver' serial None.
.. Logitech receiver detected, HID++ validation enabled.
.. Press ^C/^D to exit, or type hex bytes to write to the device.
?? Input: 10000000000000
!! Invalid HID++ request: second byte must be 0xFF or one of 0x01..0x06
?? Input: 1000
!! Invalid HID++ request: need at least 4 bytes
?? Input:
.. Closing handle 3
In one of the devices I get a huge dump of data every once in a while (I presume it's the device talking to the computer), so it seems to work.
Does this mean that the G533 doesn't "talk" via HID++? Is there anything else I should read/check out etc. related to this?
Yes, it seems that the G533 does not do HID++. Or, at least, the interface that is exposed in Linux does not do HID++. There might be a different interface that is not exposed in Linux. I don't know how to explore whether this is the case.
Ok, thank you for the assistance! I guess this can be closed as Solaar can't support a device that doesn't communicate with it. :/
Yes, unfortunately. If I get some information to the contrary I'll reopen the issue. There is also Issue #272 about other headesets.
And here is some more information.
I looked at the lsusb output for the G533 and there is definitely an HID interface (#3). So modifying the suggestion in Issue #272 to use the USB PID 0a66 will provide evidence about whether this interface talks HID++.
Running with an adjusted PID yields
$ sudo python3 g933battery.py
Battery:~0% (estimated from:-3/2,6/255) Status: Disconnected
I guess the bitpacking is different. The sound cuts out while I run the command and restarts again after it finished and I need to replug the device for the volume control to start working again.
That's to be expected. The script changes driver settings. The device probably supports different features so their "offset" is different.
The net result is that the G533 can talk HID++ but it is not trivial to set up a driver to send it HID++ commands. I'll see if someone I know can tell me how to get the driver to work.
I just came across this issue in trying to find a linux util to control the RGB lighting on my Logitech peripherals. I have a G635 (wired) headset.
I'm not sure if compatibility for G635 is on topic here, but in any case, if you're not aware, I wanted to let you guys know about the HeadsetControl project, which seems to have figured out how to interface with several Logitech headsets, including G430, G533, G63x and G93x, which all seem to be somewhat similar and use HID++ commands. Relevant files are in the src/devices
subfolder.
In any case, please let me know if this is the best place to request support for G635 or if I would be better off making a new thread. I own the device and am happy to test things and send packet captures as needed.
This is a reasonable place to add a request to support the G635. The problem is that I don't have access to any of these headsets so it is hard to figure out what needs to be done to start support for these devices.
If the headset (or its dongle) works like a USB connected keyboard or mouse then starting support should be easy. All that is needed is to clone Solaar from this repository and install its udev rule file. (See https://pwr-solaar.github.io/Solaar/installation for more information.) You need a very recent udev file because it lets Solaar control all Logitech devices. Then you need to add a line to lib/logitech/descriptors.py with information about the headset or dongle.
This line should look something like:
_D('G635 Headset', codename='G635', usbid=0x????,interface=?)
where the ???? is the USB product ID (from lsusb
) and ? is the interface that talks HID++.
The first problem, of course, is which interface talks HID++. This should be a number between 1 and 4 (or maybe a bit more), and is one of the interfaces that is listed by lsusb -vv
for the device, likely one that does not have audio in its description.
The second problem is which driver is being used for that interface. Maybe Linux isn't setting up any driver for that interface or maybe it isn't a driver that Solaar can use. Getting this fixed would probably require driver or driver-binding updates in Linux. (The fact that HeadsetControl works indicates that there is at least a chance that this all will work.)
So you could try adding the device to descriptors.py and trying the different interfaces, running bin/solaar show
for each of them. That would at least give a good indication that the device can be fairly easily supported in Solaar.
@pfps, ok. I'll give that a go and let you know. I take it it's not safe to just assume the parameters that work for HeadsetControl
will work here?
As far as the keyboard thing goes, the volume and other buttons show up in the output of xinput
and I can monitor them with evtest
so that's not a problem.
These are the interfaces and kernel modules from lsusb
:
|__ Port 3: Dev 86, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 86, If 3, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 86, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 86, If 2, Class=Audio, Driver=snd-usb-audio, 12M
I'll also attach the lsusb -vv
output. Note: the summary line for whatever odd reason shows the product name of my mouse, but this definitely is the output for the headset. I suspect there's some sort of bug in my lsusb
util, but I haven't taken the time to investigate.
Also, HeadsetControl
seems to be just writing the commands to /dev/hidraw0
.
Doing a quick check via sysfs, I can see this, so it's definitely interface 3:
$ cat /sys/class/hidraw/hidraw0/device/uevent
DRIVER=hid-generic
HID_ID=0003:0000046D:00000A89
HID_NAME=Logitech G635 Gaming Headset
HID_PHYS=usb-0000:0a:00.3-1.3/input3
HID_UNIQ=00000000
MODALIAS=hid:b0003g0001v0000046Dp00000A89
Lastly (and this is where I start having no idea what is going on), it looks like there are two input devices associated with the hidraw device. Their udev data is as follows.
cat /sys/class/hidraw/hidraw0/device/input/input100/uevent
PRODUCT=3/46d/a89/111
NAME="Logitech G635 Gaming Headset Consumer Control"
PHYS="usb-0000:0a:00.3-1.3/input3"
UNIQ="00000000"
PROP=0
EV=13
KEY=10000 17800000000 c000000000000 0
MSC=10
MODALIAS=input:b0003v046Dp0A89e0111-e0,1,4,k72,73,A3,A4,A5,A6,A8,D0,ram4,lsfw
$ cat /sys/class/hidraw/hidraw0/device/input/input101/uevent
PRODUCT=3/46d/a89/111
NAME="Logitech G635 Gaming Headset"
PHYS="usb-0000:0a:00.3-1.3/input3"
UNIQ="00000000"
PROP=0
EV=13
KEY=100000000000000 0 0 0
MSC=10
MODALIAS=input:b0003v046Dp0A89e0111-e0,1,4,kF8,ram4,lsfw
The only difference between them is their modalias
and the 'key' property, but I have no idea how to decode what's going on in either (beyond bus, vendor, and product).
Anywho, hopefully some of this is useful. I'll try to modify Solaar
as you suggested and let you know the results.
It looks to me as if the HeadsetControl interface is directly wired to particular devices. Logitech HID++ messages are "indirect" - the device says which command number connects to which command identifier. This is probably common for all devices in a given model, but is not guaranteed. So the HeadsetControl is not guaranteed to work, as it depends on particular number to identifier connections.
From your information it looks as if the interface number is 3 and the product ID is 0a89
Yeah, those numbers are correct. I'm not sure I understand though. I understand what you mean by direct vs indirect, but why does sending a command number vs a command identifier pose an issue?
There are a lot of HID++ 2.0 command, like
HIRES_WHEEL=0x2121,
but only a few possible command numbers (256 I think) in HID++ messages. To send a HIRES_WHEEL command to a device you need to know which number it uses for that command. To do that you use a special command, which is always number 0.
You can see these numbers and identifiers in solaar show
, for example in the output for my mouse
14: HIRES WHEEL {2121}
which shows that this mouse uses command number 14 for the HIRES_WHEEL command.
Different products have different mappings, but it is not even guaranteed that mappings are the same for all devices with the same product id.
Ah, ok. So the mapping from HeadsetControl
can be used in Solaar, but with the caveat that there's no guarantee of universal compatibility?
What would be done in Solaar is to set up code that implements the feature (command group) and use the mechanisms that already exist in Solaar to query the device to find out which command number is used to access the feature. That's what can be done without any cooperation from Logitech. It also might be possible to get information from Logitech on the feature to help with its implementation. But any implementation of the device requires getting the right access to it, which includes the USB interface number to use.
Ok. So is there still any use in trying this out in Solaar as is, or would the more fruitful path be to capture USB traffic so I can send you the raw data sent for each possible command?
The approach is to try to get the device to show up in Solaar so that solaar show
can be used to see which features it supports. That requires adding the device to descriptors.py
Only once that is done would it make sense to capture USB traffic to see what messages the device sends and receives.
I'm getting AssertionError: descriptor for G635 Gaming Headset does not have kind set
Any thoughts as to what to put for that field? (There's no headset or audio option. ) Or is it trial and error?
I don't think kind is used for anything now, so just use kind=_DK.mouse,
Closing again as this needs to be looked at by someone with the hardware and a knowledge of what is needed on the hardware for Solaar to work with it.
Now that https://github.com/pwr-Solaar/Solaar/pull/1582 is merged, my Logitech G533 is showing up in solaar. I can even set the Sidetone value, but the battery status is unavailable. Given the previous comments, would it make sense now to provide captured USB traffic to get the battery status available as well?
Support for the battery of the G533 has been added to Solaar but only in the version in git. You need to clone this project and run solaar as bin/solaar
from the clone directory.
Awesome, thanks a lot!
uname -srmo
): Linux 5.4.11-arch1-1 x86_64 GNU/Linuxsolaar show
:lsusb:
Steps to reproduce the behavior:
pacman -Syu solaar
solaar show