linux-kernel - Re: [alsa-devel] Bugs on aspire one A150

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Nov 2008 19:20:08 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Takashi Iwai <tiwai@...e.de>
CC:	Andreas Mohr <andi@...as.de>, linux-kernel@...r.kernel.org,
	alsa-devel@...a-project.org,
	Kernel Testers List <kernel-testers@...r.kernel.org>
Subject: Re: [alsa-devel] Bugs on aspire one A150

Takashi Iwai wrote:
> At Sun, 9 Nov 2008 21:09:29 +0100,
> Andreas Mohr wrote:
>> On Sun, Nov 09, 2008 at 07:58:17PM +0100, Takashi Iwai wrote:
>>> At Sun, 9 Nov 2008 16:13:23 +0100,
>>> Andreas Mohr wrote:
>>>> OK, _THIS_ time I actually did get the correct model (last time I tried
>>>> modprobe with model=acer-aspire, but apparently it then used the
>>>> /etc/modprobe.d/ model=toshiba setting, since this time gamix showed
>>>> entirely different controls with i-Mic etc.) - all the more reason to
>>>> log the model name chosen/selected by the driver!!
>>> Build with the debug option (why turned off even if you *are*
>>> debugging?).  Then the driver will show you details.
>> Hmm, right, that would have been an (very useful) option, but not for the
>> majority of users OTOH.
> 
> I thought many ditros set this option...
> 
>> Especially since this is a user-visible module parameter which should thus
>> be confirmed in mainstream user code, via logging.
> 
> You can check via /sys/modules/snd_hda_intel/parameters/model whether
> you passed correctly or not, at least :)
> 
>> Admittedly not many modules log their settings during startup,
>> but for snd_hda_intel with its two myriads of codec/machine variants
>> and a resulting quarter myriad of issues that would be very useful.
> 
> Passing the model option is already a kind of debugging work, IMO.
> You shouldn't do it unless you need it, indeed.
> 
>>>> --> I have to admit that usability sucks^Hcould be a lot better.
>>> One would call it rather debuggability than usability.
>>> These are completely different things.
>> See above ;)
>>
>>>> i-Mic on Ekiga with lotsa mixer fiddling didn't work either this time.
>>> OK, then something is missing.  But you should test by arecord first
>>> than any complicated applications as a primary test.
>> Good point, will do.
>>
>> Oh, and is there a way to manually alter codec registers?
> 
> Try hda-verb program.  Build your kernel with CONFIG_SND_HDA_HWDEP=y
> and access via the hwdep device.
> 	ftp://ftp.suse.com/pub/people/tiwai/misc/hda-verb-0.2.tar.bz2
> 
> 
> Takashi


For the reference this this list of nodes on ALC268 (main mobo):

0x01 - params


output streams:
0x02 - DAC1 + volume
0x03 - DAC2 + volume (only headphones)
0x06 - s/pdif-out
0x1D - BEEP


input streams:
0x07 - ADC1
0x23 - ADC1 multiplexer + volume
0x08 - ADC2
0x24 - ADC2 multiplexer + volume


output pins(*):		(***)

0x14 - LINE-OUT		headphones	<- 0x0f - line-out (mixer) <- DAC1 + beep
0x15 - HP-OUT		speakers	<- 0x10 - hp-out  (mixer) <- DAC1 + DAC2 + beep
0x16 - MONO-OUT		N/A		<- 0x0e - mono out (mixer) <- DAC1
0x1E - spdif		


input pins(**):
0x12 - DMIC1/2		N/A
0x13 - DMIC3/4		N/A
0x18 - MIC1		external mic + boost
0x19 - MIC2		internal mic + boost
0x1A - LINE-IN		line-in + boost
0x1C - CD-IN		N/A		


*  Most output pins may be used as input pins
** LINE-IN, MIC1 might be output of DAC1
*** those are pins that are connected on my main mobo.


/proc/asound/card0/codec#0  is attached (also for main computer, I will 
test the 'one' tomorrow 


Best regards,
	Maxim Levitsky

View attachment "codec.txt" of type "text/plain" (7398 bytes)