[alsa-devel] Same pci id for different ASUS machine
Hi, According to the [0003839] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3839 The PCI ID of ASUS F9S is 1043:1339 and "model=lenovo" works for it. But I found that ASUS G1 have the same id and model is 3stack in the alsa driver. Which one is true? --- alsa-driver-hg20080313/alsa-kernel/pci/hda/patch_realtek.c 2008-03-13 09:00:08.000000000 +0800 +++ b/alsa-kernel/pci/hda/patch_realtek.c 2008-03-13 10:38:57.000000000 +0800 @@ -12591,7 +12591,7 @@ static struct snd_pci_quirk alc861vd_cfg SND_PCI_QUIRK(0x1019, 0xa88d, "Realtek ALC660 demo", ALC660VD_3ST), SND_PCI_QUIRK(0x103c, 0x30bf, "HP TX1000", ALC861VD_HP), SND_PCI_QUIRK(0x1043, 0x12e2, "Asus z35m", ALC660VD_3ST), - SND_PCI_QUIRK(0x1043, 0x1339, "Asus G1", ALC660VD_3ST), + SND_PCI_QUIRK(0x1043, 0x1339, "Asus F9S", ALC861VD_LENOVO), SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS", ALC660VD_3ST_DIG), SND_PCI_QUIRK(0x10de, 0x03f0, "Realtek ALC660 demo", ALC660VD_3ST), SND_PCI_QUIRK(0x1179, 0xff00, "Toshiba A135", ALC861VD_LENOVO),
At Thu, 13 Mar 2008 10:48:49 +0800, Jiang zhe wrote:
Hi,
According to the [0003839] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3839
The PCI ID of ASUS F9S is 1043:1339 and "model=lenovo" works for it. But I found that ASUS G1 have the same id and model is 3stack in the alsa driver.
Which one is true?
The question is rather which one is "better". At the time ASUS G1 quirk was added, there was no lenovo model preset. If lenovo preset works better, we should take it, as the devices with the same PCI SSID are supposed to be compatible. Takashi
--- alsa-driver-hg20080313/alsa-kernel/pci/hda/patch_realtek.c 2008-03-13 09:00:08.000000000 +0800 +++ b/alsa-kernel/pci/hda/patch_realtek.c 2008-03-13 10:38:57.000000000 +0800 @@ -12591,7 +12591,7 @@ static struct snd_pci_quirk alc861vd_cfg SND_PCI_QUIRK(0x1019, 0xa88d, "Realtek ALC660 demo", ALC660VD_3ST), SND_PCI_QUIRK(0x103c, 0x30bf, "HP TX1000", ALC861VD_HP), SND_PCI_QUIRK(0x1043, 0x12e2, "Asus z35m", ALC660VD_3ST), - SND_PCI_QUIRK(0x1043, 0x1339, "Asus G1", ALC660VD_3ST), + SND_PCI_QUIRK(0x1043, 0x1339, "Asus F9S", ALC861VD_LENOVO), SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS", ALC660VD_3ST_DIG), SND_PCI_QUIRK(0x10de, 0x03f0, "Realtek ALC660 demo", ALC660VD_3ST), SND_PCI_QUIRK(0x1179, 0xff00, "Toshiba A135", ALC861VD_LENOVO),
[2 asus_F9s_alc861vd.patch <text/x-patch; UTF-8 (7bit)>] --- alsa-driver-hg20080313/alsa-kernel/pci/hda/patch_realtek.c 2008-03-13 09:00:08.000000000 +0800 +++ b/alsa-kernel/pci/hda/patch_realtek.c 2008-03-13 10:38:57.000000000 +0800 @@ -12591,7 +12591,7 @@ static struct snd_pci_quirk alc861vd_cfg SND_PCI_QUIRK(0x1019, 0xa88d, "Realtek ALC660 demo", ALC660VD_3ST), SND_PCI_QUIRK(0x103c, 0x30bf, "HP TX1000", ALC861VD_HP), SND_PCI_QUIRK(0x1043, 0x12e2, "Asus z35m", ALC660VD_3ST), - SND_PCI_QUIRK(0x1043, 0x1339, "Asus G1", ALC660VD_3ST), + SND_PCI_QUIRK(0x1043, 0x1339, "Asus F9S", ALC861VD_LENOVO), SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS", ALC660VD_3ST_DIG), SND_PCI_QUIRK(0x10de, 0x03f0, "Realtek ALC660 demo", ALC660VD_3ST), SND_PCI_QUIRK(0x1179, 0xff00, "Toshiba A135", ALC861VD_LENOVO),
Hi Takashi Iwai! On Thu, Mar 13, 2008 at 08:37:37AM +0100, Takashi Iwai wrote next:
The question is rather which one is "better". At the time ASUS G1 quirk was added, there was no lenovo model preset. The same situation was for some other ALC861 based laptop (uniwill vs. asus?). Due to this I have question how to resolve this under windows for example? Could we make more flex configuration in the ALSA instead of hardcoded model= in the modprobe.conf?
-- With best regards, Andy Shevchenko. mailto: andy@smile.org.ua
At Mon, 17 Mar 2008 22:19:55 +0200, Andy Shevchenko wrote:
Hi Takashi Iwai!
On Thu, Mar 13, 2008 at 08:37:37AM +0100, Takashi Iwai wrote next:
The question is rather which one is "better". At the time ASUS G1 quirk was added, there was no lenovo model preset. The same situation was for some other ALC861 based laptop (uniwill vs. asus?). Due to this I have question how to resolve this under windows for example? Could we make more flex configuration in the ALSA instead of hardcoded model= in the modprobe.conf?
Windows have *.INI files so that they can ignore broken BIOS. Or in other way round - due to this, the hardware vendors never ship the correct BIOS! I have patches to make some stuff dynamically re-configurable, e.g. overriding the default pin-config or additional verbs together with some hints to the parser, which can be set up via udev etc. You can see it on my git tree http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-unstable-2.6.git;a=sum... Takashi
On Tue, Mar 18, 2008 at 06:12:14PM +0100, Takashi Iwai wrote:
Andy Shevchenko wrote:
example? Could we make more flex configuration in the ALSA instead of hardcoded model= in the modprobe.conf?
Windows have *.INI files so that they can ignore broken BIOS. Or in other way round - due to this, the hardware vendors never ship the correct BIOS!
Worse, fixing the BIOS would probably break driver level workarounds :/
I have patches to make some stuff dynamically re-configurable, e.g. overriding the default pin-config or additional verbs together with some hints to the parser, which can be set up via udev etc.
I guess the kernel could do the quirking for most cases by using DMI information to identify the broken BIOSes, though there are obvious advantages to user space workarounds so it may not be worth it for something like sound which is unlikely to be needed to boot.
At Tue, 18 Mar 2008 18:57:41 +0000, Mark Brown wrote:
On Tue, Mar 18, 2008 at 06:12:14PM +0100, Takashi Iwai wrote:
Andy Shevchenko wrote:
example? Could we make more flex configuration in the ALSA instead of hardcoded model= in the modprobe.conf?
Windows have *.INI files so that they can ignore broken BIOS. Or in other way round - due to this, the hardware vendors never ship the correct BIOS!
Worse, fixing the BIOS would probably break driver level workarounds :/
No, in the case HD-audio, it won't normally. The driver level workarounds are simply to override (thus ignore) the BIOS definitions and use the static configuration.
I have patches to make some stuff dynamically re-configurable, e.g. overriding the default pin-config or additional verbs together with some hints to the parser, which can be set up via udev etc.
I guess the kernel could do the quirking for most cases by using DMI information to identify the broken BIOSes, though there are obvious advantages to user space workarounds so it may not be worth it for something like sound which is unlikely to be needed to boot.
The quirks have been already there in HD-audio driver. But the problem is that there are far too many. That's why we need a better, more flexible approach now, adjustable from the user-space after loading the driver. Takashi
participants (4)
-
Andy Shevchenko -
Jiang zhe -
Mark Brown -
Takashi Iwai