Re: [PATCH v6 2/4] HID: playstation: add microphone mute support for DualSense.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 15, 2021 at 10:17 AM Marek Behun <marek.behun@xxxxxx> wrote:
>
> 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.

Sorry for some more questions. I have been trying to understand
triggers all night. The concept is just so strange and foreign to me.
I understand it is in the end just a string and one use case is
in-kernel IPC and you can configure them from user space as well, but
I just don't get it. I understand you can use a trigger to in the end
program your LED in a automatic manner. I just don't understand how
the concepts fit together and how to implement it (maybe I will update
the docs later on... they are a bit sparse for if you don't know this
area).

Regarding registering a private trigger. I see include/linux/leds.h
have a comment about trigger_type and how it should be set for private
triggers on led_classdev. I haven't been able to find any example
usages of this within the kernel. It doesn't seem to be used in the
kernel, maybe it is just around for future use? I also seem to need to
implement my own activate/deactive callbacks for the trigger. These I
would use to program the LED brightness I guess. Though I see various
trigger drivers (drivers/leds/triggers), but not all of them have
activate/deactivate callbacks. Mostly simple drivers, but not sure why
they don't need them. What else is the point of a trigger?

> 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.

Right now I manage the button mute state directly from the input
handler (dualsense_parse_report) when the button is pressed and then
schedule an output report to toggle the LED and program the DualSense
to mute its audio (the PlayStation works very similar). I would need
to use led_trigger_event then here?

If I then understand it right, I need to modify my "brightness_set"
handler and check if there is a trigger (based on
led_classdev->activated??). If there is none, then userspace can
change the LED state. Internally when I change the LED state, I will
also program the hardware to mute as well. (they are tied together)

I am tempted to wait with the trigger code as I really don't understand it.

> 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
>

Roderick



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux