New driver for Corsair Void headset family
From: Stuart
Date: Sun Mar 17 2024 - 16:46:15 EST
Hi, I'm writing a driver for the Corsair Void family of headsets, but
I have a few questions before I submit a patch for v1.
1. I can see there's already a hid-corsair driver, but my driver is
around the same size as it so far, and shares almost nothing in common
with it, as they're completely different devices. Should I still
attempt to merge my corsair-void driver with hid-corsair, or submit it
as a separate driver, such as hid-corsair-void?
2. The headsets can be queried for their firmware versions (separate
versions for the headset and the receiver). However, the wired version
of the headset doesn't have a receiver to report the version for, and
the wireless version isn't always connected to the receiver, so the
version can't always be retrieved. Should I just register and
unregister the attributes as the versions are made available /
unavailable, or always show them and just return something like
-ENODEV if there's no device to return a version for?
3. How should I expose the limits for some of the sysfs attributes?
For example, the headset can play a few alert tones, and I wired that
up by playing the tone whose ID is passed to the send_alert attribute.
If it only supports IDs 0 and 1, should I document this in the docs
for the driver, in the source code, or as another attribute to return
the highest supported ID? I have the same issue for sidetone, where
the headset supports values 0-55, but I'm not sure how to communicate
this.
4. The wireless variant of the headset reports a value for its charge
that's ~54 higher than reality while plugged in. The Windows driver
just conveniently reports 'Charging' instead of a value, I'm not sure
how to communicate that the charge value can't be trusted while
plugged in. Who do I need to ask about this? I'm assuming someone
that's responsible for the power_supply class, but I'm not sure who
that is.
Thanks,
Stuart