Hi,
On 03-11-17 18:40, Mark Brown wrote:
On Fri, Nov 03, 2017 at 01:09:37PM +0100, Hans de Goede wrote:
On 03-11-17 12:24, Mark Brown wrote:
You can make a GPIO input device but obviously can't have anything
reporting through the sound card interface without a sound card.
Ok, so I could make the driver generate evdev events
of type EV_SW with code SW_HEADPHONE_INSERT. Does userspace
do anything useful with this like automatically switching
between headphones and speakers as a headphone-jack which
is part of the sound card would do ?
Depends on your userspace, you can also do an extcon which Android
listens to IIRC.
If not, then is there a way to get a list of registered
soundcards from a driver, then pick one of the cards
based on some heuristics and then do the snd_soc_card_jack_new,
etc. on the picked card?
I assume that the approach from:
https://github.com/me176c-dev/kernel_asus_me176c/commit/498116d7e7b4718fa0655c4879e59a163b1dd85b
Where the struct snd_soc_card byt_rt5640_card is made
non-static and exported is not acceptable ?
Why not have the sound card claim the GPIO and provide the jack?
Yes that would be ideal, but on some devices the ACPI resources
table describing the gpio is not part of the acpi_companion of
the codec, but rather of another ACPI device all together.
It might be best to see if we can somehow search through the list
of ACPI devices from the codec driver and get through the GPIO
that way. I guess we will need a utility function for this to
share between codec drivers, since the same AMCR0F28 ACPI device
is used in DSTDs together with different codecs.
Regards,
Hans
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
