On Mon, 15 Feb 2021 10:07:29 -0800 Roderick Colenbrander <roderick@xxxxxxxxxx> wrote: > On Mon, Feb 15, 2021 at 6:40 AM Marek Behun <marek.behun@xxxxxx> wrote: > > > > On Sun, 14 Feb 2021 16:45:47 -0800 > > Roderick Colenbrander <roderick@xxxxxxxxxx> wrote: > > > > > From: Roderick Colenbrander <roderick.colenbrander@xxxxxxxx> > > > > > > The DualSense controller has a built-in microphone exposed as an > > > audio device over USB (or HID using Bluetooth). A dedicated > > > button on the controller handles mute, but software has to configure > > > the device to mute the audio stream. > > > > > > This patch captures the mute button and schedules an output report > > > to mute/unmute the audio stream as well as toggle the mute LED. > > > > > > Signed-off-by: Roderick Colenbrander <roderick.colenbrander@xxxxxxxx> > > > > Is the microphone supported via Linux? I.e. is there an audio driver > > for it? > > Yes and no. The microphone is supported using USB, not yet using > Bluetooth (uses a custom protocol). Actually there are various other > audio features in the DualSense (headphone jack, speaker, volume > controls,..) and they all work using custom protocols. We were > planning to defer this work through future patches as the features are > very complicated and need a deep analysis on how to realize them. For > example audio controls work through HID, but for USB the audio driver > is a generic hda audio device I think. Bluetooth is a custom protocol > and will be yet a different audio driver somewhere. > > > If it is, look at the audio-micmute LED trigger. > > > > I'm not sure if the expected behavior for the DualSense is similar to > the standard audio mute use cases. My understanding of these triggers > (please correct me if I'm wrong) is for e.g. an audio driver or user > space to send a signal to anything registering for a particular > trigger. In this case a global micmute. Is that, right? > > In our case for PlayStation games, there are often multiple > controllers connected and each user has their own microphone in their > controller. All can function at the same time (different from a > standard PC use case). That's why I'm wondering if this makes sense.I > know we are on Linux, but for Sony we want to properly support such > use cases. If there aren't audio drivers yet for this, simply have this driver also register a private LED trigger (with name "joystick-audiomute" or something similar), and when registering the LED, set the trigger_type member. Look at trigger_type in include/linux/leds.h, and in LED Documentation. When this trigger is enabled for your LED, have your code switch LED state like it does now. When there is no trigger enabled, the userspace will be able to set brightness of this LED via sysfs. Before registering the LED, assign default_trigger member so that this trigger is enabled during registration. This is why we have support for private LED triggers. Marek > > If you can't use the audio-micmute trigger because the microphone isn't > > supported via Linux, I still think the LED should the LED should be > > read-write. You can then register a LED private trigger. The driver should > > change the state of the LED according to the microphone mute state only > > if these trigger is enabled. > > > > Marek > > Roderick
