Message-ID: <8f7242f0-c217-47e4-ad88-fc1481ca936f@collabora.com>
Date: Wed, 23 Jul 2025 10:17:36 +0300
From: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
To: Roderick Colenbrander <thunderbird2k@...il.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 Roderick,

On 7/23/25 7:04 AM, Roderick Colenbrander wrote:
> Hi Cristian,
> 
> Thanks for the information on the audio patches in the sound tree. We
> weren't familiar with that part.

I've actually mentioned that in the cover letter and changelog of this
revision.  Couldn't do this previously because I submitted the HID series
before the USB audio one.

> 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 think we should keep things simple for now, at least until we land the
basic support, also considering the USB part has been already merged.

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

Indeed, it's not possible to support hardware volume control from
ALSA/usb-audio without involving HID.  This could be done, or at least it's
worth investigating further, but it's not mandatory and definitely beyond
the scope of the current work.

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

There's a bit more complexity in here than initially anticipated, but the
(software) volume control is not really a problem.  It's worth noting I am
going to provide some UCM changes, part of the ALSA project:

  https://github.com/alsa-project/alsa-ucm-conf

This is to ensure proper support for audio profile switching between
headphones/headset and internal speaker/microphone, which also addresses
a few volume control related issues.  Those are mainly caused by the haptic
feedback functionality, which is controlled by a pair of dedicated channels
in a quadraphonic audio stream.  One of the UCM's main jobs is to split the
4.0 PCM stream into 4 mono channels or a pair of stereo (FL+FR) channels,
depending on the active output device/profile.

The only blocker now is this HID series, which prevents us moving further.

Therefore, unless there is anything else remaining which requires urgent
attention, could you please provide an ack for Jiri to be able to pick this
up?

Thanks,
Cristian

> 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