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
