At Mon, 6 Mar 2006 15:16:15 +0100,
Takashi Iwai wrote:
> At Sat, 4 Mar 2006 15:51:14 +0100,
> Adrian Bunk wrote:
>>
>> On Sat, Mar 04, 2006 at 02:29:02AM -0300, Otavio Salvador wrote:
>> > Takashi Iwai <[email protected]> writes:
>> >
>> > > Are you sure that your device has PCI SUB-system id 8086:2668 ?
>> >
>> > oh no! Sorry!
>> >
>> > 0000:00:1b.0 0403: 8086:2668 (rev 04)
>> > Subsystem: 152d:0729
>> > ^^^^^^^^^
>>
>> Can you make a patch with the correct id test whether it fixes your
>> problem (without model=basic)?
>
> This one should work for his device.
>
>
> Takashi
> ===
>
> [PATCH] Add default entry for CTL Travel Master U553W
>
> Added the default entry of ALC880 configuration table for
> CTL Travel Master U553W.
>
> Signed-off-by: Takashi Iwai <[email protected]>
>
> ---
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index b767552..d5cd3a1 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -2948,6 +2948,8 @@ static struct hda_board_config alc260_cf
> { .modelname = "basic", .config = ALC260_BASIC },
> { .pci_subvendor = 0x104d, .pci_subdevice = 0x81bb,
> .config = ALC260_BASIC }, /* Sony VAIO */
> + { .pci_subvendor = 0x152d, .pci_subdevice = 0x0729,
> + .config = ALC260_BASIC }, /* CTL Travel Master U553W */
> { .modelname = "hp", .config = ALC260_HP },
> { .pci_subvendor = 0x103c, .pci_subdevice = 0x3010, .config = ALC260_HP },
> { .pci_subvendor = 0x103c, .pci_subdevice = 0x3011, .config = ALC260_HP },
It has been three years since the above patch was posted with a request for
testing. No testing reply ever appeared, and the patch was committed as
submitted. On the relevant hardware, I determined the patch to be incorrect.
For the git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
head, the following patch appears to fix it correctly:
Signed-off-by: Daniel Gimpelevich <[email protected]>
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 6c26afc..87ec806 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5692,7 +5692,7 @@ static struct snd_pci_quirk alc260_cfg_tbl[] = {
SND_PCI_QUIRK(0x104d, 0x81cc, "Sony VAIO", ALC260_BASIC),
SND_PCI_QUIRK(0x104d, 0x81cd, "Sony VAIO", ALC260_BASIC),
SND_PCI_QUIRK(0x10cf, 0x1326, "Fujitsu S702X", ALC260_FUJITSU_S702X),
- SND_PCI_QUIRK(0x152d, 0x0729, "CTL U553W", ALC260_BASIC),
+ SND_PCI_QUIRK(0x152d, 0x0729, "CTL U553W", ALC260_WILL),
SND_PCI_QUIRK(0x161f, 0x2057, "Replacer 672V", ALC260_REPLACER_672V),
SND_PCI_QUIRK(0x1631, 0xc017, "PB V7900", ALC260_WILL),
{}
(adding CCs).
Usually, sending such things to the LKML alone doesn't really work. Please
always send a CC to the relevant subsystem maintainer.
On Saturday 07 March 2009, Daniel Gimpelevich wrote:
> At Mon, 6 Mar 2006 15:16:15 +0100,
> Takashi Iwai wrote:
>
> > At Sat, 4 Mar 2006 15:51:14 +0100,
> > Adrian Bunk wrote:
> >>
> >> On Sat, Mar 04, 2006 at 02:29:02AM -0300, Otavio Salvador wrote:
> >> > Takashi Iwai <[email protected]> writes:
> >> >
> >> > > Are you sure that your device has PCI SUB-system id 8086:2668 ?
> >> >
> >> > oh no! Sorry!
> >> >
> >> > 0000:00:1b.0 0403: 8086:2668 (rev 04)
> >> > Subsystem: 152d:0729
> >> > ^^^^^^^^^
> >>
> >> Can you make a patch with the correct id test whether it fixes your
> >> problem (without model=basic)?
> >
> > This one should work for his device.
> >
> >
> > Takashi
> > ===
> >
> > [PATCH] Add default entry for CTL Travel Master U553W
> >
> > Added the default entry of ALC880 configuration table for
> > CTL Travel Master U553W.
> >
> > Signed-off-by: Takashi Iwai <[email protected]>
> >
> > ---
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index b767552..d5cd3a1 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -2948,6 +2948,8 @@ static struct hda_board_config alc260_cf
> > { .modelname = "basic", .config = ALC260_BASIC },
> > { .pci_subvendor = 0x104d, .pci_subdevice = 0x81bb,
> > .config = ALC260_BASIC }, /* Sony VAIO */
> > + { .pci_subvendor = 0x152d, .pci_subdevice = 0x0729,
> > + .config = ALC260_BASIC }, /* CTL Travel Master U553W */
> > { .modelname = "hp", .config = ALC260_HP },
> > { .pci_subvendor = 0x103c, .pci_subdevice = 0x3010, .config = ALC260_HP },
> > { .pci_subvendor = 0x103c, .pci_subdevice = 0x3011, .config = ALC260_HP },
>
> It has been three years since the above patch was posted with a request for
> testing. No testing reply ever appeared, and the patch was committed as
> submitted. On the relevant hardware, I determined the patch to be incorrect.
> For the git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> head, the following patch appears to fix it correctly:
>
>
> Signed-off-by: Daniel Gimpelevich <[email protected]>
>
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 6c26afc..87ec806 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -5692,7 +5692,7 @@ static struct snd_pci_quirk alc260_cfg_tbl[] = {
> SND_PCI_QUIRK(0x104d, 0x81cc, "Sony VAIO", ALC260_BASIC),
> SND_PCI_QUIRK(0x104d, 0x81cd, "Sony VAIO", ALC260_BASIC),
> SND_PCI_QUIRK(0x10cf, 0x1326, "Fujitsu S702X", ALC260_FUJITSU_S702X),
> - SND_PCI_QUIRK(0x152d, 0x0729, "CTL U553W", ALC260_BASIC),
> + SND_PCI_QUIRK(0x152d, 0x0729, "CTL U553W", ALC260_WILL),
> SND_PCI_QUIRK(0x161f, 0x2057, "Replacer 672V", ALC260_REPLACER_672V),
> SND_PCI_QUIRK(0x1631, 0xc017, "PB V7900", ALC260_WILL),
> {}
>
> --
At Sat, 7 Mar 2009 19:00:44 +0100,
Rafael J. Wysocki wrote:
>
> (adding CCs).
>
> Usually, sending such things to the LKML alone doesn't really work. Please
> always send a CC to the relevant subsystem maintainer.
Yep, thanks.
A comment about this change below...
> On Saturday 07 March 2009, Daniel Gimpelevich wrote:
> > At Mon, 6 Mar 2006 15:16:15 +0100,
> > Takashi Iwai wrote:
> >
> > > At Sat, 4 Mar 2006 15:51:14 +0100,
> > > Adrian Bunk wrote:
> > >>
> > >> On Sat, Mar 04, 2006 at 02:29:02AM -0300, Otavio Salvador wrote:
> > >> > Takashi Iwai <[email protected]> writes:
> > >> >
> > >> > > Are you sure that your device has PCI SUB-system id 8086:2668 ?
> > >> >
> > >> > oh no! Sorry!
> > >> >
> > >> > 0000:00:1b.0 0403: 8086:2668 (rev 04)
> > >> > Subsystem: 152d:0729
> > >> > ^^^^^^^^^
> > >>
> > >> Can you make a patch with the correct id test whether it fixes your
> > >> problem (without model=basic)?
> > >
> > > This one should work for his device.
> > >
> > >
> > > Takashi
> > > ===
> > >
> > > [PATCH] Add default entry for CTL Travel Master U553W
> > >
> > > Added the default entry of ALC880 configuration table for
> > > CTL Travel Master U553W.
> > >
> > > Signed-off-by: Takashi Iwai <[email protected]>
> > >
> > > ---
> > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > > index b767552..d5cd3a1 100644
> > > --- a/sound/pci/hda/patch_realtek.c
> > > +++ b/sound/pci/hda/patch_realtek.c
> > > @@ -2948,6 +2948,8 @@ static struct hda_board_config alc260_cf
> > > { .modelname = "basic", .config = ALC260_BASIC },
> > > { .pci_subvendor = 0x104d, .pci_subdevice = 0x81bb,
> > > .config = ALC260_BASIC }, /* Sony VAIO */
> > > + { .pci_subvendor = 0x152d, .pci_subdevice = 0x0729,
> > > + .config = ALC260_BASIC }, /* CTL Travel Master U553W */
> > > { .modelname = "hp", .config = ALC260_HP },
> > > { .pci_subvendor = 0x103c, .pci_subdevice = 0x3010, .config = ALC260_HP },
> > > { .pci_subvendor = 0x103c, .pci_subdevice = 0x3011, .config = ALC260_HP },
> >
> > It has been three years since the above patch was posted with a request for
> > testing. No testing reply ever appeared, and the patch was committed as
> > submitted. On the relevant hardware, I determined the patch to be incorrect.
Daniel, how "incorrect" do you mean exactly?
As you cited, the above patch was added for the request for the
specific model, so the patch itself is correct per definition. What
wrong could be the choice of the model option by the original poster,
which I cannot judge.
Of course I have no objection to fix the model entry at all, but I
need a more proper justification.
thanks,
Takashi
Takashi Iwai <tiwai <at> suse.de> writes:
> Daniel, how "incorrect" do you mean exactly?
>
> As you cited, the above patch was added for the request for the
> specific model, so the patch itself is correct per definition. What
> wrong could be the choice of the model option by the original poster,
> which I cannot judge.
>
> Of course I have no objection to fix the model entry at all, but I
> need a more proper justification.
The master volume control appeared to be affecting the wrong control line, and
there was no way to turn off IEC958, which appeared to be on by default.
At Sun, 8 Mar 2009 23:21:13 +0000 (UTC),
Daniel Gimpelevich wrote:
>
> Takashi Iwai <tiwai <at> suse.de> writes:
>
> > Daniel, how "incorrect" do you mean exactly?
> >
> > As you cited, the above patch was added for the request for the
> > specific model, so the patch itself is correct per definition. What
> > wrong could be the choice of the model option by the original poster,
> > which I cannot judge.
> >
> > Of course I have no objection to fix the model entry at all, but I
> > need a more proper justification.
>
> The master volume control appeared to be affecting the wrong control line,
Is it so with the latest 2.6.29 kernel?
(Also you aren't accessing pulse plugin, right?)
> and
> there was no way to turn off IEC958, which appeared to be on by default.
This should work.
% amixer -Dhw:0 set IEC958 mute
Takashi
(Re-adding mistakenly snipped CC's…)
On Wed, 2009-03-11 at 09:33 +0100, Takashi Iwai wrote:
> At Sun, 8 Mar 2009 23:21:13 +0000 (UTC),
> Daniel Gimpelevich wrote:
> >
> > Takashi Iwai <tiwai <at> suse.de> writes:
> >
> > > Daniel, how "incorrect" do you mean exactly?
> > >
> > > As you cited, the above patch was added for the request for the
> > > specific model, so the patch itself is correct per definition. What
> > > wrong could be the choice of the model option by the original poster,
> > > which I cannot judge.
> > >
> > > Of course I have no objection to fix the model entry at all, but I
> > > need a more proper justification.
> >
> > The master volume control appeared to be affecting the wrong control line,
>
> Is it so with the latest 2.6.29 kernel?
> (Also you aren't accessing pulse plugin, right?)
Was using alsamixer to test, without pulseaudio running. The underlying
issue is unchanged in three years of commits.
> > and
> > there was no way to turn off IEC958, which appeared to be on by default.
>
> This should work.
>
> % amixer -Dhw:0 set IEC958 mute
It does work, but only after the patch I submitted (or by using the
equivalent module argument).
At Wed, 11 Mar 2009 06:07:20 -0700,
Daniel Gimpelevich wrote:
>
> (Re-adding mistakenly snipped CC's…)
>
> On Wed, 2009-03-11 at 09:33 +0100, Takashi Iwai wrote:
> > At Sun, 8 Mar 2009 23:21:13 +0000 (UTC),
> > Daniel Gimpelevich wrote:
> > >
> > > Takashi Iwai <tiwai <at> suse.de> writes:
> > >
> > > > Daniel, how "incorrect" do you mean exactly?
> > > >
> > > > As you cited, the above patch was added for the request for the
> > > > specific model, so the patch itself is correct per definition. What
> > > > wrong could be the choice of the model option by the original poster,
> > > > which I cannot judge.
> > > >
> > > > Of course I have no objection to fix the model entry at all, but I
> > > > need a more proper justification.
> > >
> > > The master volume control appeared to be affecting the wrong control line,
> >
> > Is it so with the latest 2.6.29 kernel?
> > (Also you aren't accessing pulse plugin, right?)
>
> Was using alsamixer to test, without pulseaudio running. The underlying
> issue is unchanged in three years of commits.
No, the master volume behavior did change recently.
Doesn't it really work with model=basic on 2.6.29?
Its master should change both the widget 0x08 and 0x09, so it should
influence on the volume.
> > > and
> > > there was no way to turn off IEC958, which appeared to be on by default.
> >
> > This should work.
> >
> > % amixer -Dhw:0 set IEC958 mute
>
> It does work, but only after the patch I submitted (or by using the
> equivalent module argument).
Ah, you mean there is no IEC958 mixer as is, right? Then yes, there
is no control with model=basic.
But, I basically wonder whether model=auto works or not.
Choosing an existing model for a device of another vendor is often
wrong in small corner cases.
Anyway, it'd be helpful if you attach the output of alsa-info.sh (with
--no-upload option) on your device. The script is found at
http://www.alsa-project.org/alsa-info.sh
thanks,
Takashi
BTW, Rafael: The reason I originally sent this to the main LKML and not
to Takashi through other channels was that I was replying directly to a
thread already on only this list. I do acknowledge that this list was
not the proper venue for the thread when it was begun, three years ago.
On Wed, 2009-03-11 at 14:27 +0100, Takashi Iwai wrote:
> At Wed, 11 Mar 2009 06:07:20 -0700,
> Daniel Gimpelevich wrote:
> >
> > (Re-adding mistakenly snipped CC's…)
> >
> > On Wed, 2009-03-11 at 09:33 +0100, Takashi Iwai wrote:
> > > At Sun, 8 Mar 2009 23:21:13 +0000 (UTC),
> > > Daniel Gimpelevich wrote:
> > > >
> > > > Takashi Iwai <tiwai <at> suse.de> writes:
> > > >
> > > > > Daniel, how "incorrect" do you mean exactly?
> > > > >
> > > > > As you cited, the above patch was added for the request for the
> > > > > specific model, so the patch itself is correct per definition. What
> > > > > wrong could be the choice of the model option by the original poster,
> > > > > which I cannot judge.
> > > > >
> > > > > Of course I have no objection to fix the model entry at all, but I
> > > > > need a more proper justification.
> > > >
> > > > The master volume control appeared to be affecting the wrong control line,
> > >
> > > Is it so with the latest 2.6.29 kernel?
> > > (Also you aren't accessing pulse plugin, right?)
> >
> > Was using alsamixer to test, without pulseaudio running. The underlying
> > issue is unchanged in three years of commits.
>
> No, the master volume behavior did change recently.
>
> Doesn't it really work with model=basic on 2.6.29?
> Its master should change both the widget 0x08 and 0x09, so it should
> influence on the volume.
Perhaps; I was referring only to the issue of model=basic being chosen
as a lowest common denominator amidst lack of other info. The newest
kernel I have actually tested on that hardware so far is the one on the
Fedora 10 LiveCD.
> > > > and
> > > > there was no way to turn off IEC958, which appeared to be on by default.
> > >
> > > This should work.
> > >
> > > % amixer -Dhw:0 set IEC958 mute
> >
> > It does work, but only after the patch I submitted (or by using the
> > equivalent module argument).
>
> Ah, you mean there is no IEC958 mixer as is, right? Then yes, there
> is no control with model=basic.
>
> But, I basically wonder whether model=auto works or not.
> Choosing an existing model for a device of another vendor is often
> wrong in small corner cases.
As the OP stated, there is no sound output whatsoever with model=auto.
The controls in alsamixer in that case do not exactly match any of the
existing models, and I currently intend to attach a three-way comparison
of them among model=basic, model=will, and model=auto.
> Anyway, it'd be helpful if you attach the output of alsa-info.sh (with
> --no-upload option) on your device. The script is found at
> http://www.alsa-project.org/alsa-info.sh
Unfortunately, the machine has since suffered a hardware failure, which
I will attempt to correct this week. Further testing must wait until
then.