Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754551Ab0G2I02 (ORCPT ); Thu, 29 Jul 2010 04:26:28 -0400 Received: from cantor2.suse.de ([195.135.220.15]:46711 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754408Ab0G2I0X (ORCPT ); Thu, 29 Jul 2010 04:26:23 -0400 Date: Thu, 29 Jul 2010 10:26:22 +0200 Message-ID: From: Takashi Iwai To: "Mario 'BitKoenig' Holbe" Cc: linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Regression 2.6.35-rc6: ALSA Intel HDA/Realtek: missing Beep In-Reply-To: <20100729080930.GA20619@darkside.kls.lan> References: <20100728144903.GA18170@darkside.kls.lan> <20100728212745.GA15394@darkside.kls.lan> <20100729080930.GA20619@darkside.kls.lan> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2705 Lines: 64 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/