linux-kernel - Re: [Bisected regression] Microphone no longer works on Toshiba Satellite A100

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 24 May 2009 14:06:37 -0400
From:	"M. Vefa Bicakci" <bicave@...eronline.com>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [Bisected regression] Microphone no longer works on Toshiba
 Satellite A100

Takashi Iwai wrote:
> At Sun, 24 May 2009 11:51:17 -0400,
> M. Vefa Bicakci wrote:
>> Dear Takashi Iwai,
>>
>> I am sorry for sending this e-mail to you directly. I was going to
>> CC you with linux-kernel@...ordomo.kernel.org but forgot to do so.
> 
> Thanks for report.
> Your post doesn't appear on LKML yet, at least it didn't reach to
> me.  Anyway, could you run alsa-info.sh with --no-upload option and
> attach the generated file?  The script is found at
>     http://www.alsa-project.org/alsa-info.sh

Attached are two outputs from this script. Please read below to learn
why there are two different outputs.

[snip]

>>
>> Judging from the code that was in the tree before the mentioned commit, only
>> ALC /882/ needed the "checking whether pincap has a certain bit set" algorithm.
> 
> No, the pincap check is basically a "must" for all codecs.  The codecs
> that don't give proper capability bits are broken by design.  I need
> to check ALC861 datasheet again, but it's possible ALC861 is a sort of
> such ones.  A workaround would be needed no matter how broken the h/w
> is, though... :)

Oh, I am sorry. To be honest, I don't know much about the Realtek codecs, or
sound card drivers. I just made a guess looking at the working code. Now I
understand that my guess was wrong.

Since we are talking about possibly broken hardware, I would like to mention
to you a problem that I was thinking of reporting but haven't had the chance
to. This problem is also the reason why there are two different outputs
generated by the alsa-info.sh script.

When one first boots this laptop, alsamixer does not show PCM playback and
Digital Input capture channels. However, if I run a ALSA-compatible program
which uses the PCM playback (such as mpg321) or the Digital Input capture
channel (such as arecord), then the respective channels appear in alsamixer.
Does this mean that a new "model=..." quirk needs to be written for this
this laptop? ("model=toshiba" does not work properly.) I am sorry if this
is totally unrelated to the original regression.

The attached file named "before.txt" is the output of alsa-info.sh before
I force the driver to create the PCM and Digital Input channels. The file
named "after.txt" was produced after I ran "play" (sox) and "arecord",
and hence this file contains reference to the mentioned channels.

Please let me know if there is anything I can help with.

Thank you,

M. Vefa Bicakci

View attachment "alsa-before.txt" of type "text/plain" (16622 bytes)

View attachment "alsa-after.txt" of type "text/plain" (17618 bytes)