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: <s5h1u8w8f82.wl%tiwai@suse.de>
Date:	Fri, 24 May 2013 19:22:53 +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 Fri, 24 May 2013 18:36:14 +0200,
Alex Riesen wrote:
> 
> On Fri, May 24, 2013 at 3:29 PM, Takashi Iwai <tiwai@...e.de> wrote:
> >> On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai <tiwai@...e.de> wrote:
> >> >> 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
> >> >
> >
> > Looking at the outputs above, it seems that turning on/off EAPD on VT
> > codecs triggers the automatic power up/down of the pin, which leads to
> > the unexpected result.
> 
> I may be wrong here, but why the patch touches EAPD handling, but not WID?

Well, I assumed that the EAPD off triggers the pin widget off by the
hardware, too.  But it seems wrong.  By some reason, the hardware
clears the pin automatically.  Hmm.

Could you try to trace the verbs while plugging the headphone?
Check whether you have /sys/kernel/debug/tracing directory.  If not,
make sure that you enabled the kernel tracing capability.

Then, just before plugging the headphone, run below:

  # echo 1 > /sys/kernel/debug/tracing/events/hda/enable

This will start the logging HD-audio verbs.  Then plug the headphone,
and get the trace via

  # cat /sys/kernel/debug/tracing/trace > trace.log

then disable tracing again

  # echo 0 > /sys/kernel/debug/tracing/events/hda/enable

And attach trace.log.  Then we can see whether the driver touches the
pin widget at all.

> > Could you try the patch below?
> 
> I did, it does not work. Transcript and alsa-info before and after
> hda-verb attached.

OK, I'll cook up the new patch later.


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