Kingston HyperX Cloud series gaming headset

[sl1pkn07]

Hi. is possible add support for this headset in this software?

greetings

[hede5562]

Søren Brokær has done some reverse engineering at least for the HyperX Cloud Flight in JavaScript. I'm testing this for mine right now, see Fork hede5562/HeadsetControl. The problem is, there seems to be not only different product IDs but also different values for idUsagePage for different generations of the Cloud Flight: see HeadsetControl/src/devices/hyperx_cflight.c for example - mine has different IDs of Sørens.

It's way from final and definitely not ready for some Pull request, but it's indeed in a state of "works for me".

For having support for all variants from day 0 on, it would help me if you can tell me your Product ID, Usage ID and Usage Page ID? (This question addresses all HyperX Cloud Flight Wireless owners - but not the Wireless S and other HyperX Cloud variants because these are probably different and we need a full usb sniff here - see wiki for creating a dump.)

[hede5562]

PS: It's only battery status for now and I doubt it supports other things at all. Not even the Windows software has options for sidetone or LED control.

[sl1pkn07]

my headset is cloud flight.

with IDs, you mean the product/vendor ID? is: 0951:16C4 (dongle 3500218-001.A02LF) i'm not sure what you mean with usage ID r usage page ID or how obtain it (i see the wiki in https://github.com/Sapd/HeadsetControl/wiki/Development, but is not much clear)

greetings

[hede5562]

That's the point here. Mine is 0951:1723 and as such presumably has other Usage IDs.

I'm not an expert but I try to give an excerpt: Every USB device has several endpoints. For example the headset (an audio sink) has also a microphone (an audio source) and probably some keys (input devices). Those endpoints do need all different drivers. And within the USB world there are known device types, like some kinds of USB audio devices. You do not need a special driver for your headset to work as a headset because usb audio devices do work all (more or less) the same. This also counts for HIDs (human interface devices), like a keyboard, mouse or the volume keys of your headset. Within the HID world there's a table of known device types and sub-functionality, to have generic drivers within operating systems like Linux or Windows. That's the reason for the volume keys to work out of the box. Usage Page IDs are part of the HID scheme to address sub-functionality for HID devices. Some of the "Usage Page ID" are well defined, like volume media keys. But within the Range of those Usage Page IDs there's also a vendor range: Addresses FF00-FFFF. Those usages are not well defined but vendor specific (aka proprietary) and do need a vendor specific driver. And they are subject to change on behalf of the vendor. As such, my device looks for 0xff90 as the Usage Page ID while yours probably expects 0xff53. The Usage ID however seems to be the same (0x0303). As this software (HeadsetControl) currently doesn't support multiple Usage Page IDs for the same device series, yours will most likely not work out of the box with my code changes. You have to change the idUsagePage to 0xff53 and compile it yourself to test it.

But you probably want to confirm your Usage Page ID beforehand.

The wiki describes how to get those Usage Page IDs for Windows with the help of the hidapi testgui. For Linux there are other ways, like described on Stack Overflow here.

[sl1pkn07]

[Sapd]

Note that the usageids are only relevant for Windows. Also Headsetcontrol has a semi-support for them. Because it only solely supports one usageid/usagepage pair. That means if the headset has different features on different usageids, then headsetcontrol can only support one of them.

[hede5562]

Note that the usageids are only relevant for Windows.

indeed - I misinterpreted that. This way it should work for Cloud Flight Variants with both Product IDs, at least on Linux...

[hede5562]

PS: ... for both variants with different Product IDs and different Usage Page IDs.

I can address both Product IDs and leave the Usage Page ID untouched.

[hede5562]

@Sapd Is there a non-blocking variant of the read command? If I switch off the headset but let the USB key plugged in HeadsetControl seems to stall on hid_read() forever.

[Sapd]

@Sapd Is there a non-blocking variant of the read command? If I switch off the headset but let the USB key plugged in HeadsetControl seems to stall on hid_read() forever.

You can set hid_set_nonblocking to true before doing a hid_read. Alternatively you can also use hid_read_timeout

[hede5562]

works.

[hede5562]

Currently I'm using the original translation logic from @srn but I will convert it to a cleaner map()ing if it works.

[hede5562]

It looks promising as HeadsetControl switched the calculated charge from 70% to 65% a second ago which means a "charge state" value from 0x0f to 0x0e with a jump of the "magic value" from nearly 0x00 to nearly 0xff -- but this will probably need one more charge->uncharge->recharge cycle to be sure.

[hede5562]

@sl1pkn07 and others: If you would like to test it, you can use my repository. Feedback will probably speedup the debugging process.

[sl1pkn07]

hi

thanks for the work. when gain time i will test it

greetings

[sl1pkn07]

tested in my linux box and seems works. ive compared the battery level between windows and linux and seems the same (with ngeuty)

so, yea, works!

greetings

[hede5562]

This Headset has some awesome battery lifetime. Mine is some weeks old now and I have charged it only once since then. The thing is, to get meaningful results I need to spent some time and my spare time is a little limited.

However, I progressed a little. I do have a way better understanding of the values now. For example there's no magic in the chargeState and magicValue which i cribbed from Søren. Those are simply two bytes forming the battery voltage in millivolts. ~3600 when low, ~4000 when high and ~4400 when charging...

I'm sniffing to the USB protocol now for myself, maybe I do get some better usable values for the charging state soon.

[hede5562]

What a pitty. I had no time to work on this. I'm currently really busy with my payed job and family and... so on.

Nevertheless I did some work to adapt to upstream(Sapd) code changes and switched to a voltage based battery percentage calculation with my cflight-support ( -> https://github.com/hede5562/HeadsetControl). Still no pull request yet as I have to test the latest changes.

[github-actions[bot]]

This issue is stale because it has been open 300 days with no activity. Remove stale label or comment or this will be closed in 60 days.

[github-actions[bot]]

This issue was closed because it has been stalled with no activity.