Message-ID: <CAEc3jaDsX8OSVskO6-Rsvn12BbV2-8ZjhV+tPaRpu9Nai3czEg@mail.gmail.com>
Date: Tue, 22 Jul 2025 21:04:45 -0700
From: Roderick Colenbrander <thunderbird2k@...il.com>
To: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
Cc: Roderick Colenbrander <roderick.colenbrander@...y.com>, Jiri Kosina <jikos@...nel.org>, 
	Benjamin Tissoires <bentiss@...nel.org>, Henrik Rydberg <rydberg@...math.org>, kernel@...labora.com, 
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/11] HID: playstation: Add support for audio jack
 handling on DualSense

Hi Cristian,

Thanks for the information on the audio patches in the sound tree. We
weren't familiar with that part.

I talked a bit with my team members as well. In general audio is
getting some bigger attention (will see where that goes). I'm getting
a bit worried that the HID and usb driver need much closer coupling,
the current coupling not being enough.

I don't know the USB audio spec too well, but it is more on the
digital interface and a DAC. I'm not sure on the exact circuitry on
the DualSense, but there is a lot of logic in the console drivers for
volume handling where adjustment of the volume talks to the HID layer
to send a new output report. I suspect they had very good reasons for
it (e.g. for headphone also dealing with different impedances).

So I'm not sure how the volume control is really supposed to work, but
I would think to do it properly it requires some interaction between
the audio and HID drivers. Just letting the audio side do it right
now, is more about leveraging the range of the DAC I guess versus a
proper audio amplification stage.

Just thinking of things from the user perspective, they should have a
unified volume control. I don't know how other devices are doing it,
but I think we need to think a bit further and we need to reconsider
how things work....

Thanks,
Roderick

On Tue, Jul 22, 2025 at 1:03 AM Cristian Ciocaltea
<cristian.ciocaltea@...labora.com> wrote:
>
> Hi Roderick,
>
> On 7/22/25 9:18 AM, Roderick Colenbrander wrote:
> > Hi Cristian and Jiri,
> >
> > One thing I forgot to bring up is whether it is best to have the audio
> > plug logic have its separate input device or have it be part of an
> > existing (e.g. main gamepad). The patch currently creates a separate
> > input device. Originally we added multiple input devices (gamepad,
> > touchpad and sensors) due to axes and button collisions really.
> >
> > For this feature there is no collision. There are not many devices in
> > the kernel, which support these audio EV_SW. I see for example the
> > Switch 2 controller has a mini jack port as well. Some xbox
> > controllers too (though audio not supported in the kernel from a quick
> > glance or at least no HID or xpad driver features for them).
> >
> > I don't have a strong opinion yet. Initial feeling was perhaps have it
> > on the 'main' input device. But on the other hand, I'm not sure what
> > software is normally listening for these kinds of EV_SW events. What
> > would be listening for this like a pipewire?
>
> For now this is going to be used by the usb-audio driver which contains a
> quirk [1] creating the jack controls for headphone and headset mic,
> respectively.  This will further setup an input handler for each of them in
> order to intercept the related hotplug events.
>
> But it can be also used directly from ALSA/pipewire, e.g. for monitoring,
> hence it think it's best to keep it as an audio dedicated input device.
>
> Regards,
> Cristian
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/sound/usb/mixer_quirks.c#n540

Powered by blists - more mailing lists