linux-kernel - New driver for Corsair Void headset family

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CALTg27=oxjn6sz7a9H7Jc1z4-ZsoupaEYioWhQPeL1HEKrcRgw@mail.gmail.com>
Date: Sun, 17 Mar 2024 20:45:52 +0000
From: Stuart <stuart.a.hayhurst@...il.com>
To: linux-input@...r.kernel.org
Cc: LKML <linux-kernel@...r.kernel.org>, Jiri Kosina <jikos@...nel.org>, 
	Benjamin Tissoires <benjamin.tissoires@...hat.com>
Subject: New driver for Corsair Void headset family

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