Recalcitrant input pin on ALC262

Recalcitrant input pin on ALC262

[Tony Vroon]

[-- Attachment #1.1: Type: text/plain, Size: 956 bytes --]

Good evening,

Currently I am implementing full support for the Tyan Thunder n6650W and
have noticed a pin complex that advertises input, but can't seem to be
set to it:
Node 0x1c [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x00:

As you can see the pin capabilities reflect input. However, even after
issuing this in the model-specific verbs:
{0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},

the pin-ctls firmly remains 0x00. Even the python-based hda-analyzer
appears unable to flip the pin-ctls over to 0x20 and reports no error
messages in the GUI or in the terminal.

What am I missing please?

Slightly related, is it considered acceptable to modify pin defaults if
they are blatantly wrong? (Reported colour, N/A vs Fixed, etc)

Regards,
Tony V.

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: 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: Recalcitrant input pin on ALC262

[Takashi Iwai]

At Sun, 01 Feb 2009 20:56:40 +0000,
Tony Vroon wrote:
> 
> Good evening,
> 
> Currently I am implementing full support for the Tyan Thunder n6650W and
> have noticed a pin complex that advertises input, but can't seem to be
> set to it:
> Node 0x1c [Pin Complex] wcaps 0x400001: Stereo
>   Pincap 0x00000020: IN
>   Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
>     Conn = 1/8, Color = Black
>     DefAssociation = 0xf, Sequence = 0x0
>     Misc = NO_PRESENCE
>   Pin-ctls: 0x00:
> 
> As you can see the pin capabilities reflect input. However, even after
> issuing this in the model-specific verbs:
> {0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},
> 
> the pin-ctls firmly remains 0x00. Even the python-based hda-analyzer
> appears unable to flip the pin-ctls over to 0x20 and reports no error
> messages in the GUI or in the terminal.
> 
> What am I missing please?

Try the same procedure to other pin.  If other pins work and this not,
it's no your fault but simply a hardware thing.  The codec information
isn't always right.

> Slightly related, is it considered acceptable to modify pin defaults if
> they are blatantly wrong? (Reported colour, N/A vs Fixed, etc)

Yes, especially if you are using the BIOS auto-parsing.


Takashi