Hello,
My PC-Speaker Beep control worked in 2.6.34, but is gone in 2.6.35-rc6.
The sound device is an Asus P5E-V HDMI (Intel G35) onboard Intel HDA w/
Realtek ALC883 codec.
The driver does still register a PCBeep input, but the Controls as well
as the sound (:)) are gone.
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
HDA Intel 0000:00:1b.0: irq 47 for MSI/MSI-X
HDA Intel 0000:00:1b.0: setting latency timer to 64
input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input5
$ diff card0-codec#0-2.6.34 card0-codec#0-2.6.35-rc6
111,114d110
< Control: name="Beep Playback Volume", index=0, device=0
< ControlAmp: chs=3, dir=In, idx=5, ofs=0
< Control: name="Beep Playback Switch", index=0, device=0
< ControlAmp: chs=3, dir=In, idx=5, ofs=0
Attached /proc/asound/card0/codec#0 from 2.6.35-rc6.
Thanks for your work & regards
Mario
--
Good, Fast, Cheap: Pick any two (you can't have all three).
-- RFC 1925, 7a
At Wed, 28 Jul 2010 16:49:03 +0200,
Mario 'BitKoenig' Holbe wrote:
>
> Hello,
>
> My PC-Speaker Beep control worked in 2.6.34, but is gone in 2.6.35-rc6.
> The sound device is an Asus P5E-V HDMI (Intel G35) onboard Intel HDA w/
> Realtek ALC883 codec.
>
> The driver does still register a PCBeep input, but the Controls as well
> as the sound (:)) are gone.
>
> HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> HDA Intel 0000:00:1b.0: irq 47 for MSI/MSI-X
> HDA Intel 0000:00:1b.0: setting latency timer to 64
> input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input5
>
> $ diff card0-codec#0-2.6.34 card0-codec#0-2.6.35-rc6
> 111,114d110
> < Control: name="Beep Playback Volume", index=0, device=0
> < ControlAmp: chs=3, dir=In, idx=5, ofs=0
> < Control: name="Beep Playback Switch", index=0, device=0
> < ControlAmp: chs=3, dir=In, idx=5, ofs=0
>
> Attached /proc/asound/card0/codec#0 from 2.6.35-rc6.
It's because now the driver checks the SSID your board sets up.
Realtek codecs suppose SSID containing some useful bits to inform
the h/w setups. The presence of PC beep is one of it.
So, it's actually BIOS that clears it.
In the earlier version, the driver didn't check this.
Actually, the real bug is that it still creates a beep device without
mixers. This should be avoided...
thanks,
Takashi
At Wed, 28 Jul 2010 17:35:10 +0200,
I wrote:
>
> At Wed, 28 Jul 2010 16:49:03 +0200,
> Mario 'BitKoenig' Holbe wrote:
> >
> > Hello,
> >
> > My PC-Speaker Beep control worked in 2.6.34, but is gone in 2.6.35-rc6.
> > The sound device is an Asus P5E-V HDMI (Intel G35) onboard Intel HDA w/
> > Realtek ALC883 codec.
> >
> > The driver does still register a PCBeep input, but the Controls as well
> > as the sound (:)) are gone.
> >
> > HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> > HDA Intel 0000:00:1b.0: irq 47 for MSI/MSI-X
> > HDA Intel 0000:00:1b.0: setting latency timer to 64
> > input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input5
> >
> > $ diff card0-codec#0-2.6.34 card0-codec#0-2.6.35-rc6
> > 111,114d110
> > < Control: name="Beep Playback Volume", index=0, device=0
> > < ControlAmp: chs=3, dir=In, idx=5, ofs=0
> > < Control: name="Beep Playback Switch", index=0, device=0
> > < ControlAmp: chs=3, dir=In, idx=5, ofs=0
> >
> > Attached /proc/asound/card0/codec#0 from 2.6.35-rc6.
>
> It's because now the driver checks the SSID your board sets up.
> Realtek codecs suppose SSID containing some useful bits to inform
> the h/w setups. The presence of PC beep is one of it.
> So, it's actually BIOS that clears it.
>
> In the earlier version, the driver didn't check this.
>
> Actually, the real bug is that it still creates a beep device without
> mixers. This should be avoided...
Or, does the following patch fix? It's already in sound git tree,
Takashi
---
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index d7fd846..9295527 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -1267,11 +1267,11 @@ static int alc_auto_parse_customize_define(struct hda_codec *codec)
unsigned nid = 0;
struct alc_spec *spec = codec->spec;
+ spec->cdefine.enable_pcbeep = 1; /* assume always enabled */
+
ass = codec->subsystem_id & 0xffff;
- if (ass != codec->bus->pci->subsystem_device && (ass & 1)) {
- spec->cdefine.enable_pcbeep = 1; /* assume always enabled */
+ if (ass != codec->bus->pci->subsystem_device && (ass & 1))
goto do_sku;
- }
nid = 0x1d;
if (codec->vendor_id == 0x10ec0260)
--
1.7.2
On Wed, Jul 28, 2010 at 06:03:29PM +0200, Takashi Iwai wrote:
> I wrote:
> > Mario 'BitKoenig' Holbe wrote:
> > > My PC-Speaker Beep control worked in 2.6.34, but is gone in 2.6.35-rc6.
> > It's because now the driver checks the SSID your board sets up.
> > So, it's actually BIOS that clears it.
But the BIOS itself beeps through the sound-card at boot :/
> Or, does the following patch fix? It's already in sound git tree,
Nope, unfortunately it doesn't. Still no Beep controls, no beep through
sound-card.
May I somehow provide any further data?
Or am I somehow able to tweak it? Is there a module parameter to set
this SSID bit? I mean, it did work before... :)
Thanks for you help & regards
Mario
--
Why did the tachyon cross the road?
Because it was on the other side.
At Wed, 28 Jul 2010 23:27:46 +0200,
Mario 'BitKoenig' Holbe wrote:
>
> [1 <text/plain; us-ascii (quoted-printable)>]
> On Wed, Jul 28, 2010 at 06:03:29PM +0200, Takashi Iwai wrote:
> > I wrote:
> > > Mario 'BitKoenig' Holbe wrote:
> > > > My PC-Speaker Beep control worked in 2.6.34, but is gone in 2.6.35-rc6.
> > > It's because now the driver checks the SSID your board sets up.
> > > So, it's actually BIOS that clears it.
>
> But the BIOS itself beeps through the sound-card at boot :/
But BIOS tells that the HD-audio codec shouldn't use, so the driver
follows it.
> > Or, does the following patch fix? It's already in sound git tree,
>
> Nope, unfortunately it doesn't. Still no Beep controls, no beep through
> sound-card.
>
> May I somehow provide any further data?
Please give alsa-info.sh output instead of codec proc file. It's more
comprehensive.
> Or am I somehow able to tweak it? Is there a module parameter to set
> this SSID bit? I mean, it did work before... :)
With the patch below, you'll likely have back the system beep sound.
But it doesn't go through codec, thus no volume control.
thanks,
Takashi
---
>From 8af2591d6342a9e4bb79b4f1236246a79d20ebee Mon Sep 17 00:00:00 2001
From: Takashi Iwai <[email protected]>
Date: Wed, 28 Jul 2010 17:37:16 +0200
Subject: [PATCH] ALSA: hda - Don't register beep input device when no beep is available
We check now the availability of PC beep and skip the build of beep
mixers, but the driver still registers the input device. This should
be checked as well.
Signed-off-by: Takashi Iwai <[email protected]>
---
sound/pci/hda/patch_realtek.c | 32 +++++++++++++++++++-------------
1 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index ff614dd..d7fd846 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -10566,10 +10566,12 @@ static int patch_alc882(struct hda_codec *codec)
}
}
- err = snd_hda_attach_beep_device(codec, 0x1);
- if (err < 0) {
- alc_free(codec);
- return err;
+ if (spec->cdefine.enable_pcbeep) {
+ err = snd_hda_attach_beep_device(codec, 0x1);
+ if (err < 0) {
+ alc_free(codec);
+ return err;
+ }
}
if (board_config != ALC882_AUTO)
@@ -12435,7 +12437,7 @@ static int patch_alc262(struct hda_codec *codec)
}
}
- if (!spec->no_analog) {
+ if (!spec->no_analog && spec->cdefine.enable_pcbeep) {
err = snd_hda_attach_beep_device(codec, 0x1);
if (err < 0) {
alc_free(codec);
@@ -14458,10 +14460,12 @@ static int patch_alc269(struct hda_codec *codec)
}
}
- err = snd_hda_attach_beep_device(codec, 0x1);
- if (err < 0) {
- alc_free(codec);
- return err;
+ if (spec->cdefine.enable_pcbeep) {
+ err = snd_hda_attach_beep_device(codec, 0x1);
+ if (err < 0) {
+ alc_free(codec);
+ return err;
+ }
}
if (board_config != ALC269_AUTO)
@@ -18691,10 +18695,12 @@ static int patch_alc662(struct hda_codec *codec)
}
}
- err = snd_hda_attach_beep_device(codec, 0x1);
- if (err < 0) {
- alc_free(codec);
- return err;
+ if (spec->cdefine.enable_pcbeep) {
+ err = snd_hda_attach_beep_device(codec, 0x1);
+ if (err < 0) {
+ alc_free(codec);
+ return err;
+ }
}
if (board_config != ALC662_AUTO)
--
1.7.2
On Thu, Jul 29, 2010 at 07:44:38AM +0200, Takashi Iwai wrote:
> Mario 'BitKoenig' Holbe wrote:
> > But the BIOS itself beeps through the sound-card at boot :/
> But BIOS tells that the HD-audio codec shouldn't use, so the driver
> follows it.
Even grub's beep (play 480 440 1) goes through the sound-card. So it
seems like the BIOS leaves everything set up working as well.
Please don't get me wrong. I'm not saying the driver does something
wrong, I'm sure it doesn't. I'm just sure that if I could convince it to
behave as if it would have detected the Beep pin everything would work
fine again because it did before...
> Please give alsa-info.sh output instead of codec proc file. It's more
> comprehensive.
Attached.
This is from a kernel with both patches applied you sent me.
> With the patch below, you'll likely have back the system beep sound.
Nope, no sound. But I guess this wasn't the intention of the patch. Now,
no beep input is registered anymore - which was the intention, I guess.
> But it doesn't go through codec, thus no volume control.
If you mean it should go through the 5V PC Speaker (i.e. pcspkr) - I
don't have such a thing connected. I always appreciated having volume-
and mute control over the beep at night when you can't get away from
work but don't like to wake up anybody just because command completion
beeps, because you pasted something in the wrong window, or whatever.
regards
Mario
--
Independence Day: Fortunately, the alien computer operating system works just
fine with the laptop. This proves an important point which Apple enthusiasts
have known for years. While the evil empire of Microsoft may dominate the
computers of Earth people, more advanced life forms clearly prefer Macs.
At Thu, 29 Jul 2010 10:09:30 +0200,
Mario 'BitKoenig' Holbe wrote:
>
> On Thu, Jul 29, 2010 at 07:44:38AM +0200, Takashi Iwai wrote:
> > Mario 'BitKoenig' Holbe wrote:
> > > But the BIOS itself beeps through the sound-card at boot :/
> > But BIOS tells that the HD-audio codec shouldn't use, so the driver
> > follows it.
>
> Even grub's beep (play 480 440 1) goes through the sound-card. So it
> seems like the BIOS leaves everything set up working as well.
Well, my point is that BIOS gives the wrong SSID value. It's bad that
the value is compliant with Realtek codecs specification, but it
clears the PC-beep bit explicitly. In most cases, SSID value isn't
compliant (so BIOS gives a wrong but it's less wrong :), thus the
driver takes a fallback to PC-beep enabled.
> Please don't get me wrong. I'm not saying the driver does something
> wrong, I'm sure it doesn't. I'm just sure that if I could convince it to
> behave as if it would have detected the Beep pin everything would work
> fine again because it did before...
FYI, you can change SSID by writing /sys/class/sound/hwC*D*/subsystem_id
file. Then reconfigure the codec via triggering
/sys/class/sound/hwC*D*/reconfig.
> > Please give alsa-info.sh output instead of codec proc file. It's more
> > comprehensive.
>
> Attached.
>
> This is from a kernel with both patches applied you sent me.
>
> > With the patch below, you'll likely have back the system beep sound.
>
> Nope, no sound. But I guess this wasn't the intention of the patch. Now,
> no beep input is registered anymore - which was the intention, I guess.
It's the intention. If SSID set by BIOS doesn't indicate the presence
of PC-speaker bit *explicitly*, we shouldn't touch beep stuff in codec.
> > But it doesn't go through codec, thus no volume control.
>
> If you mean it should go through the 5V PC Speaker (i.e. pcspkr) - I
> don't have such a thing connected. I always appreciated having volume-
> and mute control over the beep at night when you can't get away from
> work but don't like to wake up anybody just because command completion
> beeps, because you pasted something in the wrong window, or whatever.
For the driver, the outside connection doesn't matter. The
information is given as the spec bit, and just follows it :)
So, the fix is likely to override SSID value, or create a special
quirk rule to enable PC-beep for known white-list, supposing BIOS
won't be fixed in any future...
Takashi
On Thu, Jul 29, 2010 at 10:26:22AM +0200, Takashi Iwai wrote:
> FYI, you can change SSID by writing /sys/class/sound/hwC*D*/subsystem_id
> file. Then reconfigure the codec via triggering
> /sys/class/sound/hwC*D*/reconfig.
Great, that's what I meant with "Or am I somehow able to tweak it? Is
there a module parameter to set this SSID bit?" :)
$ for i in /sys/class/sound/hwC*D*/subsystem_id; do echo "$i: $(cat $i)"; done
/sys/class/sound/hwC0D0/subsystem_id: 0x1043829f
/sys/class/sound/hwC0D1/subsystem_id: 0xffffffff
So, obviously the first check in
if (ass != codec->bus->pci->subsystem_device && (ass & 1))
is false. How can I tweak the subsystem_id least-invasive not to match
codec->bus->pci->subsystem_device (which should be 0x829f then) anymore?
Mario
--
Gib einem Hungrigen einen Fisch, und er ist fuer einen Tag satt.
Zeig ihm, wie man angelt, und er poebelt Dich an, dass er besseres
zu tun haette, als Schnuere ins Wasser haengen zu lassen.
-- David Kastrup in de.comp.text.tex
At Thu, 29 Jul 2010 10:41:38 +0200,
Mario 'BitKoenig' Holbe wrote:
>
> On Thu, Jul 29, 2010 at 10:26:22AM +0200, Takashi Iwai wrote:
> > FYI, you can change SSID by writing /sys/class/sound/hwC*D*/subsystem_id
> > file. Then reconfigure the codec via triggering
> > /sys/class/sound/hwC*D*/reconfig.
>
> Great, that's what I meant with "Or am I somehow able to tweak it? Is
> there a module parameter to set this SSID bit?" :)
>
> $ for i in /sys/class/sound/hwC*D*/subsystem_id; do echo "$i: $(cat $i)"; done
> /sys/class/sound/hwC0D0/subsystem_id: 0x1043829f
> /sys/class/sound/hwC0D1/subsystem_id: 0xffffffff
>
> So, obviously the first check in
> if (ass != codec->bus->pci->subsystem_device && (ass & 1))
> is false. How can I tweak the subsystem_id least-invasive not to match
> codec->bus->pci->subsystem_device (which should be 0x829f then) anymore?
Usually the codec SSID isn't checked in other places, so passing a
bogus value should be OK. Pass a value like 2:
# echo -n 2 > /sys/class/sound/hwC0D0/subsystem_id
then
# echo -n 1 > /sys/class/sound/hwC0D0/reconfig
The latter needs that the all sound device files are closed beforehand.
Takashi
On Thu, Jul 29, 2010 at 10:52:36AM +0200, Takashi Iwai wrote:
> Usually the codec SSID isn't checked in other places, so passing a
> bogus value should be OK. Pass a value like 2:
Mh, 1 probably :)
$ cat /etc/modprobe.d/local-alsa.conf
options snd-hda-intel model=asus-p5q
install snd-hda-intel /sbin/modprobe --ignore-install snd-hda-intel $CMDLINE_OPTS && { cd /sys/class/sound/hwC0D0; echo -n 1 > subsystem_id; echo -n 1 > reconfig; : ; }
Yep, Beep is back :)
Btw...
On Thu, Jul 29, 2010 at 10:26:22AM +0200, Takashi Iwai wrote:
> So, the fix is likely to override SSID value, or create a special
> quirk rule to enable PC-beep for known white-list, supposing BIOS
> won't be fixed in any future...
Well, the Board is from 2007, the last BIOS is from Aug 2009. I don't
think Asus will provide an update just for that :)
Thanks for your help
Mario
--
Unfortunately, the chip vendors have delayed the availability of the
long-promised crystal-ball peripherals yet again, forcing the governor
code to rely on heuristics; once again, software must make up for
deficiencies in the hardware. -- Jonathan Corbet, LWN
At Thu, 29 Jul 2010 11:15:17 +0200,
Mario 'BitKoenig' Holbe wrote:
>
> On Thu, Jul 29, 2010 at 10:52:36AM +0200, Takashi Iwai wrote:
> > Usually the codec SSID isn't checked in other places, so passing a
> > bogus value should be OK. Pass a value like 2:
>
> Mh, 1 probably :)
>
> $ cat /etc/modprobe.d/local-alsa.conf
> options snd-hda-intel model=asus-p5q
> install snd-hda-intel /sbin/modprobe --ignore-install snd-hda-intel $CMDLINE_OPTS && { cd /sys/class/sound/hwC0D0; echo -n 1 > subsystem_id; echo -n 1 > reconfig; : ; }
>
> Yep, Beep is back :)
>
> Btw...
>
> On Thu, Jul 29, 2010 at 10:26:22AM +0200, Takashi Iwai wrote:
> > So, the fix is likely to override SSID value, or create a special
> > quirk rule to enable PC-beep for known white-list, supposing BIOS
> > won't be fixed in any future...
>
> Well, the Board is from 2007, the last BIOS is from Aug 2009. I don't
> think Asus will provide an update just for that :)
OK, then try the patch below (over my previous two patches). It
enables PC-beep for your device forcibly.
Takashi
---
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 1744d4d..439d6e7 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5280,8 +5280,24 @@ static void fillup_priv_adc_nids(struct hda_codec *codec, hda_nid_t *nids,
#ifdef CONFIG_SND_HDA_INPUT_BEEP
#define set_beep_amp(spec, nid, idx, dir) \
((spec)->beep_amp = HDA_COMPOSE_AMP_VAL(nid, 3, idx, dir))
+
+static struct snd_pci_quirk beep_white_list[] = {
+ SND_PCI_QUIRK(0x1043, 0x829f, "ASUS", 1),
+ {}
+};
+
+static inline int has_cdefine_beep(struct hda_codec *codec)
+{
+ struct alc_spec *spec = codec->spec;
+ const struct snd_pci_quirk *q;
+ q = snd_pci_quirk_lookup(codec->bus->pci, beep_white_list);
+ if (q)
+ return q->value;
+ return spec->cdefine.enable_pcbeep;
+}
#else
#define set_beep_amp(spec, nid, idx, dir) /* NOP */
+#define has_cdefine_beep(codec) 0
#endif
/*
@@ -10666,7 +10682,7 @@ static int patch_alc882(struct hda_codec *codec)
}
}
- if (spec->cdefine.enable_pcbeep) {
+ if (has_cdefine_beep(codec)) {
err = snd_hda_attach_beep_device(codec, 0x1);
if (err < 0) {
alc_free(codec);
@@ -10721,7 +10737,7 @@ static int patch_alc882(struct hda_codec *codec)
set_capture_mixer(codec);
- if (spec->cdefine.enable_pcbeep)
+ if (has_cdefine_beep(codec))
set_beep_amp(spec, 0x0b, 0x05, HDA_INPUT);
if (board_config == ALC882_AUTO)
@@ -12537,7 +12553,7 @@ static int patch_alc262(struct hda_codec *codec)
}
}
- if (!spec->no_analog && spec->cdefine.enable_pcbeep) {
+ if (!spec->no_analog && has_cdefine_beep(codec)) {
err = snd_hda_attach_beep_device(codec, 0x1);
if (err < 0) {
alc_free(codec);
@@ -12588,7 +12604,7 @@ static int patch_alc262(struct hda_codec *codec)
}
if (!spec->cap_mixer && !spec->no_analog)
set_capture_mixer(codec);
- if (!spec->no_analog && spec->cdefine.enable_pcbeep)
+ if (!spec->no_analog && has_cdefine_beep(codec))
set_beep_amp(spec, 0x0b, 0x05, HDA_INPUT);
spec->vmaster_nid = 0x0c;
@@ -14593,7 +14609,7 @@ static int patch_alc269(struct hda_codec *codec)
}
}
- if (spec->cdefine.enable_pcbeep) {
+ if (has_cdefine_beep(codec)) {
err = snd_hda_attach_beep_device(codec, 0x1);
if (err < 0) {
alc_free(codec);
@@ -14635,7 +14651,7 @@ static int patch_alc269(struct hda_codec *codec)
if (!spec->cap_mixer)
set_capture_mixer(codec);
- if (spec->cdefine.enable_pcbeep)
+ if (has_cdefine_beep(codec))
set_beep_amp(spec, 0x0b, 0x04, HDA_INPUT);
if (board_config == ALC269_AUTO)
@@ -18832,7 +18848,7 @@ static int patch_alc662(struct hda_codec *codec)
}
}
- if (spec->cdefine.enable_pcbeep) {
+ if (has_cdefine_beep(codec)) {
err = snd_hda_attach_beep_device(codec, 0x1);
if (err < 0) {
alc_free(codec);
@@ -18859,7 +18875,7 @@ static int patch_alc662(struct hda_codec *codec)
if (!spec->cap_mixer)
set_capture_mixer(codec);
- if (spec->cdefine.enable_pcbeep) {
+ if (has_cdefine_beep(codec)) {
switch (codec->vendor_id) {
case 0x10ec0662:
set_beep_amp(spec, 0x0b, 0x05, HDA_INPUT);
On Thu, Jul 29, 2010 at 11:42:44AM +0200, Takashi Iwai wrote:
> OK, then try the patch below (over my previous two patches). It
> enables PC-beep for your device forcibly.
Yes, it does and it works. Thank you very much again.
I just checked 2 more boards - the P5E-VM HDMI (P5E-V HDMI's little
brother) is already covered by the quirk and P5Q-EM (G45) seems to
specify it correctly (subsystem_id = 0x104382fe - seems I got the logic
wrong before - LSB isn't set here and it works).
regards
Mario
--
This project is so important we can't let things that are more important
interfere with it.
-- Advertising/Marketing manager, United Parcel Service
At Thu, 29 Jul 2010 15:25:32 +0200,
Mario 'BitKoenig' Holbe wrote:
>
> On Thu, Jul 29, 2010 at 11:42:44AM +0200, Takashi Iwai wrote:
> > OK, then try the patch below (over my previous two patches). It
> > enables PC-beep for your device forcibly.
>
> Yes, it does and it works. Thank you very much again.
>
> I just checked 2 more boards - the P5E-VM HDMI (P5E-V HDMI's little
> brother) is already covered by the quirk and P5Q-EM (G45) seems to
> specify it correctly (subsystem_id = 0x104382fe - seems I got the logic
> wrong before - LSB isn't set here and it works).
So, it's likely a bad luck about the SSID of P5E-V. I guess this
unexpectedly matches with the value Realtek codec expected, and
unluckily the value had side-effects.
Anyway, I applied the patch now.
thanks,
Takashi