No features supported for G430? about headsetcontrol HOT 12 CLOSED

See #21

from headsetcontrol.

I've tried using that version and I got this error instead:

Headsetcontrol written by Sapd (Denis Arnst)
https://github.com/Sapd

Found Logitech G430!

libusb: error [submit_control_transfer] submiturb failed error -1 errno=16
Failed to set sidetone. Error: -1: LIBUSB_ERROR_IO

from headsetcontrol.

Someone would have to provide support who owns the headset with this problem. But the best would be, to rewrite it (and possible making new captures) for using it in the recent version with hidapi.

Edit: It is also only tested on MacOS in this commit. So it needs further work anyways.

from headsetcontrol.

Okay, thanks very much for looking into it.
I'd like to help fix it if possible so if there's anything I could do to help maybe you could point me in the right direction to learn how?

from headsetcontrol.

So, I'm on Linux and I own this headset, how can I help??

from headsetcontrol.

You need to rewrite the libUSB commands to hidapi. Both are very similar, except that hidapi abstracts some things.

For that I would look into the documentation of boths.
Here for the libusb function which was used: http://libusb.sourceforge.net/api-1.0/group__syncio.html
Here for the enums: http://libusb.sourceforge.net/api-1.0/group__desc.html

What's neat about hidapi, it has a choice of layers, one is actually libusb. So it makes it quite simple. Look into the .c source code of the libusb layer: https://github.com/signal11/hidapi/blob/master/libusb/hid.c
Determine wether you need the hid_write or hid_send_feature_report function, so take a close look at those functions and see how it uses the libusb API. Then do a call to the correct hidapi function with the data ( https://github.com/Sapd/HeadsetControl/blob/master/src/devices/logitech_g430.c ).

You could also simply try sending the data with both functions, if your lucky it works out of the box. The problem I see is, he was using LIBUSB_REQUEST_CLEAR_FEATURE in the old code, which hidapi never uses, so probably it can be replaced by something else (and it was simply not 100% correct). That was also the reason why I couldn't simply convert the function into hidapi, without being sure that it the implementation isn't faulty.

You could also recheck the protocol by doing a new capture (e.g. with usblyzer)

from headsetcontrol.

You need to rewrite the libUSB commands to hidapi. Both are very similar, except that hidapi abstracts some things.

For that I would look into the documentation of boths.
Here for the libusb function which was used: http://libusb.sourceforge.net/api-1.0/group__syncio.html
Here for the enums: http://libusb.sourceforge.net/api-1.0/group__desc.html

What's neat about hidapi, it has a choice of layers, one is actually libusb. So it makes it quite simple. Look into the .c source code of the libusb layer: https://github.com/signal11/hidapi/blob/master/libusb/hid.c
Determine wether you need the hid_write or hid_send_feature_report function, so take a close look at those functions and see how it uses the libusb API. Then do a call to the correct hidapi function with the data ( https://github.com/Sapd/HeadsetControl/blob/master/src/devices/logitech_g430.c ).

You could also simply try sending the data with both functions, if your lucky it works out of the box. The problem I see is, he was using LIBUSB_REQUEST_CLEAR_FEATURE in the old code, which hidapi never uses, so probably it can be replaced by something else (and it was simply not 100% correct). That was also the reason why I couldn't simply convert the function into hidapi, without being sure that it the implementation isn't faulty.

You could also recheck the protocol by doing a new capture (e.g. with usblyzer)

Just so you know my old G430 broke but now I have a new one and I have started working on this. Thanks for the excellent information btw that's a big help

from headsetcontrol.

I see other devices are using LIBUSB_REQUEST_SET_CONFIGURATION which also doesn't seem to be used by hidapi. I've tried just sending the data using hid_write and hid_send_feature_report and neither work.
When using hid_send_feature_report, it prints the error ioctl (SFEATURE): Broken pipe
When I use hid_write, if I set the first byte (report ID) to 2, it appears to write successfully, although I hear no change in the sidetone in my headphones. I'm not really sure if I should be sending that report ID or not.
The data that it was sending already seems to be correct, at least it matches what I found from using usblyzer myself.
I'm not an expert in USB protocols though so maybe there's something that's missing. The G430 protocol looks quite different from the other Logitech headsets supported by this project.

from headsetcontrol.

When I used usbmon and Wireshark in Linux to try and check if the correct data is being sent to the device, it doesn't show any packets being sent except when I disconnect and reconnect the headset.
Wireshark output

from headsetcontrol.

I guess you probably missed something, because if the data matches - it should work. Did you compare your data with the latest working revision? (https://github.com/Sapd/HeadsetControl/blob/master/src/devices/logitech_g430.c the commented code)

The linux output doesn't seem to be correct. (I also had problems using usbmon, so I dumped it in favor of other software on Windows at least.)

from headsetcontrol.

I tried it with the exact same data, yes. There should be a unique 2 bytes sent for a given volume value and the ones that I sniffed in Windows match with what is in the code.
It wasn't working with libusb on Linux before though for whatever reason, and it's probably for the same reason that it won't work now.

I've managed to set up the sniffing with usbmon properly now. I just had to filter by usb.src and usb.dst instead, because when you filter by idVendor/idProduct it will only show the GET DESCRIPTOR requests.

So for a start, one thing I'm seeing is that the packets being sent from HeadsetControl are twice as long as the ones send by the driver in Windows 10.

• In Windows 10, setting the volume once will send 2 packets. The first is 36 bytes, and the second (which contains the actual volume bytes) is of length 30 bytes.
• Using HeadsetControl with either hid_write or hid_send_feature_report, there are also 2 packets, but both are 65 bytes long.

Is this problematic or is it expected for the packets to be larger using hidapi instead of libusb?

The response from the device is always "broken pipe" (except in the case I mentioned earlier when I use hid_write and set the report_id to 0x02). This would make sense to me if the device is receiving a much longer packet than it expects and closes the pipe while we are still writing to it.

EDIT:
Ok, so I've learned from #8 that it actually works fine with libusb if you use the correct interface id, and it is using the correct interface id with hidapi as well, so the only differences I can see are:

• The bRequest value is always 9 (LIBUSB_REQUEST_SET_CONFIGURATION) in hidapi, but the G430's protocol seems to use bRequest=1 (LIBUSB_REQUEST_CLEAR_FEATURE) instead.
• The wValue and wIndex are not the same. I've tested with libusb and changing these and it doesn't seem to work unless they have the exact same values from the USB packet capture in windows.

I could get the wValue to be correct by setting the first byte of the data to be 0x01 (this works because this byte is OR'd with 0x200 to produce the wValue)
However, I don't see any way to set the bRequest or wIndex values to be correct.

I'm not sure how this can be dealt with because hidapi doesn't seem to give enough fine grain control to send the right values according to whatever we might discover from our USB captures.

EDIT 2:
I've now learned from #2 that I can control the sidetone in alsa mixer. From sniffing this with wireshark, I can now see that the 2 bytes sent simply represent a dB gain value. Not that it helps us get further with this.
I'd still like to see it working in this project though if possible, because it would make it easier to script the setting of the sidetone.

from headsetcontrol.

Closing, the sidetone is controlled via an audio channel, which we can't access via HID.

from headsetcontrol.