Same pci id for different ASUS machine

Same pci id for different ASUS machine

[Jiang zhe]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

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),


[-- Attachment #2: asus_F9s_alc861vd.patch --]
[-- Type: text/x-patch, Size: 746 bytes --]

--- 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),

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Same pci id for different ASUS machine

[Takashi Iwai]

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),

Re: Same pci id for different ASUS machine

[Andy Shevchenko]

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

Re: Same pci id for different ASUS machine

[Takashi Iwai]

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=summary


Takashi

Re: Same pci id for different ASUS machine

[Mark Brown]

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.

Re: Same pci id for different ASUS machine

[Takashi Iwai]

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