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]
Message-ID: <s5hk3myuoq6.wl%tiwai@suse.de>
Date:	Fri, 17 May 2013 08:04:01 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Alex Riesen <raa.lkml@...il.com>
Cc:	alsa-devel@...a-project.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: regression: from 3.8 to 3.9: headphones output no sound on Intel HDA, codec VIA VT1802

At Thu, 16 May 2013 22:10:47 +0200,
Alex Riesen wrote:
> 
> On Thu, May 16, 2013 at 1:00 PM, Takashi Iwai <tiwai@...e.de> wrote:
> > So, we need to disable the widgets power control in patch_via.c
> > completely as a quick workaround.  Could you check whether the patch
> > below is OK (except for the possible headphone mute issue)?
> 
> Well... It seems that something went unnoticed. This command seems
> to be essential for this (and the revised) patch to get the headphone
> output at all:
> 
>         hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0

Do you mean that the headphone doesn't work without this even after
the patch?  It's weird that the alsa-info.sh output you attached below
already contains it, i.e. 0x25 showing 0xc0.

Or, is the attached output the result after you ran hda-verb like the
above?

> I also used to run the other command after unplugging and re-plugging
> (without it, the headphone is muted after re-plugging):
> 
>         hda-verb /dev/snd/hwC0D0 0x25 SET_EAPD 0x02
> 
> But running
> 
>         hda-verb /dev/snd/hwC0D0 0x24 SET_EAPD 0x03
> 
> also helps to restore the headphone output after re-plugging.
> 
> > Regarding the headphone mute: after confirming the headphone itself
> > is working with the patch, please give alsa-info.sh outputs again
> > with and without the headphone plug.
> 
> Attached.
>
> > Then, at the headphone plugged (and the speaker is still audible
> > wrongly), take a look at /proc/asound/card0/codec#0 file.
> > Look for "Node 0x24", and check whether Pin-ctls item shows 0x00.
> 
> It does. And there is no output from the speakers.

Hmm.  I'm confused.  I thought you mentioned that the speaker is
unmuted?

- Use the patched kernel, play without headphone, confirm that the
  speaker works.  Get alsa-info.sh output at this point.

- Plug the headphone, play, and check whether the headphone works and
  the speaker is muted.
  Again, get alsa-info.sh output at this point, no matter whether the
  headphone works or not.

If something is wrong at this point, try hda-verb things.  Basically,
giving some verbs to 0x25 is to work on the headphone, and 0x24 for
the speaker.  You can check the previous value by the corresponding
GET_* verb.  For example, if you want to change the pin control of
0x25 to 0xc0, check the current value by

	hda-verb /dev/snd/hwC0D0 0x25 GET_PIN_WID 0

(the GET_* takes the last argument 0), then

	hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0

I'm asking it because, in the case above, if the previous value shows
0xc0 and the headphone doesn't work, and if setting the same value
again fixes the headphone output, it must be new behavior I've never
seen.

In anyway, if you make things working, please give exactly what you
did, and take again alsa-info.sh output, too.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ