From: Oleksandr Kovalov <oleksandr.kovalov.work@gmail.com>
To: tiwai@suse.com, perex@perex.cz
Cc: linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
Oleksandr Kovalov <oleksandr.kovalov.work@gmail.com>
Subject: [PATCH v2] ALSA: hda/realtek: Fix cold-boot headset misdetection on Acer Aspire A515-57G
Date: Wed, 2 Sep 2026 20:13:05 +0300 [thread overview]
Message-ID: <20260902171305.3955-1-oleksandr.kovalov.work@gmail.com> (raw)
In-Reply-To: <20260830211038.19528-1-oleksandr.kovalov.work@gmail.com>
On the Acer Aspire A515-57G (PCI SSID 1025:1616), if headphones are
already inserted into the combo jack before the codec powers up (a cold
boot with the plug already seated), the impedance-based headset-type
sensing races and misclassifies the jack. This drives the wrong output
configuration and is audible as missing center-panned content (e.g.
vocals) while panned content plays normally.
A genuine physical unplug/replug after boot reliably fixes this by
forcing a fresh sense transient, which is a strong hint about the
underlying cause: the sensing hardware appears to need a settled,
freshly-triggered read rather than the one-shot classification done
during the normal HDA_FIXUP_ACT_INIT pass.
Add a machine-specific fixup that, on cold boot only (not S3/S4 resume,
which already gets its own re-check), waits briefly after the normal
init-time decision and then forces a fresh headset-mode classification
by resetting the cached mode and re-invoking the existing
alc_fixup_headset_mode() path -- mirroring what a manual replug already
does. The wait+recheck is skipped whenever the first pass already
determined nothing is plugged in, to avoid adding boot latency on the
common case.
Chain into the existing ALC256_FIXUP_ACER_SFG16_MICMUTE_LED fixup so
this quirk-table entry keeps providing mic-mute LED support alongside
the cold-boot headset fix.
Tested on kernel 7.1.9 by building the affected module standalone and
confirming cold boot with headphones pre-inserted plays correctly from
the very first sample, across multiple boots (including a full restart,
and headphones inserted mid-POST rather than before power-on), with no
crashes or warnings and no behavioral difference from a real
post-replug recovery.
Signed-off-by: Oleksandr Kovalov <oleksandr.kovalov.work@gmail.com>
---
v2: Rebase onto sound.git for-linus (2026-09-02, commit f4a23e17d).
Resolve a conflict with the newly-added
ALC256_FIXUP_ACER_SFG16_MICMUTE_LED quirk for the same SSID by
chaining into it instead of overwriting the quirk-table entry, so
both fixes apply to this laptop. No change to the fix logic itself,
which was re-tested and confirmed working after the rebase.
sound/hda/codecs/realtek/alc269.c | 36 ++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index ecc9c6e..95b40a1 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -2379,6 +2379,33 @@ static void alc_fixup_headset_mode_alc255_no_hp_mic(struct hda_codec *codec,
}
}
+/*
+ * On the Acer Aspire A515-57G (and possibly other models sharing this
+ * board), if headphones are already inserted into the combo jack before
+ * the codec powers up (cold boot), the impedance-based headset-type
+ * sensing races and misclassifies the jack, driving the wrong output
+ * configuration (audible as missing center-panned/vocal content). A
+ * genuine physical unplug/replug after boot fixes it by forcing a fresh
+ * sense transient. Mirror that here on cold boot only: give the sense
+ * hardware time to settle, then force a fresh classification.
+ */
+static void alc_fixup_headset_mode_acer_coldboot(struct hda_codec *codec,
+ const struct hda_fixup *fix, int action)
+{
+ struct alc_spec *spec = codec->spec;
+
+ alc_fixup_headset_mode(codec, fix, action);
+
+ if (action == HDA_FIXUP_ACT_INIT &&
+ !is_s3_resume(codec) && !is_s4_resume(codec) &&
+ spec->current_headset_mode != ALC_HEADSET_MODE_UNPLUGGED) {
+ msleep(500);
+ spec->current_headset_mode = ALC_HEADSET_MODE_UNKNOWN;
+ spec->current_headset_type = ALC_HEADSET_TYPE_UNKNOWN;
+ alc_fixup_headset_mode(codec, fix, action);
+ }
+}
+
static void alc288_update_headset_jack_cb(struct hda_codec *codec,
struct hda_jack_callback *jack)
{
@@ -4248,6 +4275,7 @@ enum {
ALC282_FIXUP_ACER_DISABLE_LINEOUT,
ALC255_FIXUP_ACER_LIMIT_INT_MIC_BOOST,
ALC256_FIXUP_ACER_HEADSET_MIC,
+ ALC256_FIXUP_ACER_COLDBOOT,
ALC285_FIXUP_IDEAPAD_S740_COEF,
ALC285_FIXUP_HP_LIMIT_INT_MIC_BOOST,
ALC295_FIXUP_ASUS_DACS,
@@ -6311,6 +6339,12 @@ static const struct hda_fixup alc269_fixups[] = {
.chained = true,
.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
},
+ [ALC256_FIXUP_ACER_COLDBOOT] = {
+ .type = HDA_FIXUP_FUNC,
+ .v.func = alc_fixup_headset_mode_acer_coldboot,
+ .chained = true,
+ .chain_id = ALC256_FIXUP_ACER_SFG16_MICMUTE_LED,
+ },
[ALC285_FIXUP_IDEAPAD_S740_COEF] = {
.type = HDA_FIXUP_FUNC,
.v.func = alc285_fixup_ideapad_s740_coef,
@@ -7148,7 +7182,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x1597, "Acer Nitro 5 AN517-55", ALC2XX_FIXUP_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x159e, "Acer Nitro 5 AN515-46", ALC2XX_FIXUP_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x160e, "Acer PT316-51S", ALC2XX_FIXUP_HEADSET_MIC),
- SND_PCI_QUIRK(0x1025, 0x1616, "Acer Aspire A515-57", ALC256_FIXUP_ACER_SFG16_MICMUTE_LED),
+ SND_PCI_QUIRK(0x1025, 0x1616, "Acer Aspire A515-57", ALC256_FIXUP_ACER_COLDBOOT),
SND_PCI_QUIRK(0x1025, 0x161f, "Acer S40-54", ALC256_FIXUP_ACER_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1025, 0x1640, "Acer Aspire A315-44P", ALC256_FIXUP_ACER_SFG16_MICMUTE_LED),
SND_PCI_QUIRK(0x1025, 0x166c, "Acer Predator PH16-71", ALC2XX_FIXUP_HEADSET_MIC),
--
2.55.0
next prev parent reply other threads:[~2026-09-02 17:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 21:10 [PATCH] ALSA: hda/realtek: Fix cold-boot headset misdetection on Acer Aspire A515-57G Oleksandr Kovalov
2026-09-01 11:47 ` Takashi Iwai
2026-09-02 17:13 ` Oleksandr Kovalov [this message]
2026-09-03 7:34 ` [PATCH v2] " Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260902171305.3955-1-oleksandr.kovalov.work@gmail.com \
--to=oleksandr.kovalov.work@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox