No sound from speaker, using Realtek ALC269 and snd_hda

[Big Yuuta]

Hi all,

I have an asus eeepc 1001px, on which I installed 9-stable.
I, since day one, never had any sound coming out of the speaker,
but when I plug a headphone in the jack, I have the sound -in the
headphones.

The chipset is a Realtek ALC269 which some people said is supported.

I read, and re-read the man page for snd_hda so many times,
but I just can't make it work.

Here's what I have right now in my device.hints

Code:

hint.hdaa.0.nid20.config="as=1 seq=0 device=Speaker"
hint.hdaa.0.nid26.config="as=1 seq=15 device=Headphones"
hint.hdaa.0.nid18.config="as=2 seq=0"
#hint.hdaa.0.gpio_config="0=set"
hint.hdaa.0.config="forcestereo,ivref50,ivref80,ivref100,ivref,vref"
hint.pcm.0.config="gpio0,gpio1,gpio2,gpio3,gpio4,gpio5,gpio6,gpio7"
hint.pcm.0.vol="100"

This is my n'th attempt, I pretty tried everything I could imagine.

Here's my verbose dmesg http://dpaste.com/818967/plain/

Am I missing something? Is my understanding of pinouts correct?

Thank you for your attention, and help! :)

[Alexander Motin]

On 28.10.2012 17:12, Big Yuuta wrote:
> I have an asus eeepc 1001px, on which I installed 9-stable.
> I, since day one, never had any sound coming out of the speaker,
> but when I plug a headphone in the jack, I have the sound -in the
> headphones.
>
> The chipset is a Realtek ALC269 which some people said is supported.

Now driver support most of CODECs. I don't know cases when specific
CODEC would be a problem, and Realtek CODECs from functional side are
better then many others. But many systems have custom wiring and laptops
are usually more problematic there.

> I read, and re-read the man page for snd_hda so many times,
> but I just can't make it work.
>
> Here's what I have right now in my device.hints
>
> Code:
>
> hint.hdaa.0.nid20.config="as=1 seq=0 device=Speaker"
> hint.hdaa.0.nid26.config="as=1 seq=15 device=Headphones"
> hint.hdaa.0.nid18.config="as=2 seq=0"

As I see, these three hints are replicating existing configuration and
effectively useless.

> #hint.hdaa.0.gpio_config="0=set"
> hint.hdaa.0.config="forcestereo,ivref50,ivref80,ivref100,ivref,vref"
> hint.pcm.0.config="gpio0,gpio1,gpio2,gpio3,gpio4,gpio5,gpio6,gpio7"
> hint.pcm.0.vol="100"
>
> This is my n'th attempt, I pretty tried everything I could imagine.
>
> Here's my verbose dmesg http://dpaste.com/818967/plain/
>
> Am I missing something? Is my understanding of pinouts correct?

CODEC configuration looks good and I see no problems in driver output. I
think most likely problem is in CODEC wiring and power amplifier. Your
CODEC has two GPIO lines and EAPD line. That gives 8 possible
combinations. I would recommend you to try them all. GPIOs, as you tried
could be set with hint.hdaa.0.gpio_config tunable. EAPD line can be
controlled (0 or 100) by the ogain mixer control.

Unluckily with this output I can't completely identify your system to
check what Linux does for it. Could you send me `devinfo -vr` output.

--
Alexander Motin
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[Big Yuuta]

Thank you, Alexander!

On Sun, Oct 28, 2012 at 8:28 PM, Alexander Motin <m...@freebsd.org> wrote:
> On 28.10.2012 17:12, Big Yuuta wrote:
>>
>> hint.hdaa.0.nid20.config="as=1 seq=0 device=Speaker"
>> hint.hdaa.0.nid26.config="as=1 seq=15 device=Headphones"
>> hint.hdaa.0.nid18.config="as=2 seq=0"
>
>
> As I see, these three hints are replicating existing configuration and
> effectively useless.

You're absolutely right! These are the same as the original ones.

>> #hint.hdaa.0.gpio_config="0=set"
>> hint.hdaa.0.config="forcestereo,ivref50,ivref80,ivref100,ivref,vref"
>> hint.pcm.0.config="gpio0,gpio1,gpio2,gpio3,gpio4,gpio5,gpio6,gpio7"
>> hint.pcm.0.vol="100"
>>
>> This is my n'th attempt, I pretty tried everything I could imagine.
>>
>> Here's my verbose dmesg http://dpaste.com/818967/plain/
>>
>> Am I missing something? Is my understanding of pinouts correct?
>
>
> CODEC configuration looks good and I see no problems in driver output. I
> think most likely problem is in CODEC wiring and power amplifier. Your CODEC
> has two GPIO lines and EAPD line. That gives 8 possible combinations. I
> would recommend you to try them all. GPIOs, as you tried could be set with
> hint.hdaa.0.gpio_config tunable. EAPD line can be controlled (0 or 100) by
> the ogain mixer control.

You mean combinations like:

hint.hdaa.0.gpio_config="0=set 1=set 2=set"

Where the values could be "set" or "keep"? But then again, the man
also cites "clear", "disable", "input". So that'd make more than 8 possible
permutations? Or is it something else? Can you please give me an example?

Also, can I, after booting, just try with:

kenv hint.hdaa.0.gpio_config="0=set 1=set 2=set"
kdunload snd_hda.ko
kdload snd_hda.ko

or should I reboot each time?

> Unluckily with this output I can't completely identify your system to check
> what Linux does for it. Could you send me `devinfo -vr` output.

Sure! I'm attaching it

Again thanks for all your work on the subject, and your help!


P.S. Here's some extra output from dmesg when I set: dev.hdac.0.pindump=1

hdaa0: Dumping AFG pins:
hdaa0: nid 0x as seq device conn jack loc color misc
hdaa0: 18 99a30920 2 0 Mic Fixed ATAPI Onboard Unknown 9
hdaa0: Caps: IN
hdaa0: 20 99130110 1 0 Speaker Fixed ATAPI Onboard Unknown 1
hdaa0: Caps: OUT EAPD Sense: 0x00000000 (disconnected)
hdaa0: 23 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA
hdaa0: Caps: OUT
hdaa0: 24 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA
hdaa0: Caps: IN OUT VREF Sense: 0x00000000 (disconnected)
hdaa0: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA
hdaa0: Caps: IN VREF Sense: 0x00000000 (disconnected)
hdaa0: 26 0121441f 1 15 Headphones Jack 1/8 Rear Green 4
hdaa0: Caps: IN OUT HP Sense: 0x00000000 (disconnected)
hdaa0: 27 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA
hdaa0: Caps: IN OUT Sense: 0x00000000 (disconnected)
hdaa0: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA
hdaa0: Caps: OUT Sense: 0x00000000 (disconnected)
hdaa0: 33 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA
hdaa0: Caps: OUT HP Sense: 0x00000000 (disconnected)
hdaa0: NumGPIO=2 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1
hdaa0: GPIO0: disabled
hdaa0: GPIO1: disabled

[Alexander Motin]

On 28.10.2012 22:09, Big Yuuta wrote:
>> CODEC configuration looks good and I see no problems in driver output. I
>> think most likely problem is in CODEC wiring and power amplifier. Your CODEC
>> has two GPIO lines and EAPD line. That gives 8 possible combinations. I
>> would recommend you to try them all. GPIOs, as you tried could be set with
>> hint.hdaa.0.gpio_config tunable. EAPD line can be controlled (0 or 100) by
>> the ogain mixer control.
>
> You mean combinations like:
>
> hint.hdaa.0.gpio_config="0=set 1=set 2=set"

As I've told, there are only two GPIO pins, so only "0=X 1=Y", plus
ogain mixer control.

> Where the values could be "set" or "keep"? But then again, the man
> also cites "clear", "disable", "input". So that'd make more than 8 possible
> permutations? Or is it something else? Can you please give me an example?

GPIO pins are bidirectional, but I have doubt that input or high
impedance ("disable") state could be used to control something. "keep"
is also useless, as by default these pins are disabled. So you have only
"set" and "clear".

> Also, can I, after booting, just try with:
>
> kenv hint.hdaa.0.gpio_config="0=set 1=set 2=set"
> kdunload snd_hda.ko
> kdload snd_hda.ko

Yes, that should work.

> or should I reboot each time?

I don't think it is required.

[Big Yuuta]

On Sun, Oct 28, 2012 at 9:42 PM, Alexander Motin <m...@freebsd.org> wrote:
> On 28.10.2012 22:09, Big Yuuta wrote:
>>>
>>> CODEC configuration looks good and I see no problems in driver output. I
>>> think most likely problem is in CODEC wiring and power amplifier. Your
>>> CODEC
>>> has two GPIO lines and EAPD line. That gives 8 possible combinations. I
>>> would recommend you to try them all. GPIOs, as you tried could be set
>>> with
>>> hint.hdaa.0.gpio_config tunable. EAPD line can be controlled (0 or 100)
>>> by
>>> the ogain mixer control.
>>
>>
>> You mean combinations like:
>>
>> hint.hdaa.0.gpio_config="0=set 1=set 2=set"
>
>
> As I've told, there are only two GPIO pins, so only "0=X 1=Y", plus ogain
> mixer control.

So that would be:

hint.hdaa.0.gpio_config="0=set 1=set"
hint.hdaa.0.gpio_config="0=set 1=clear"
hint.hdaa.0.gpio_config="0=clear 1=set"
hint.hdaa.0.gpio_config="0=clear 1=clear"

which I try with:

mixer ogain 0:0
mixer ogain 100:100

I'm going to check once again, but I think that unfortunately that didn't work.
I hope that I forgot a combination!

Thanks again, Alexander

[Big Yuuta]

Unfortunately, trying with the different combinations didn't work.

I wrote this tiny script just to make sure I'm not forgetting a case:

#!/bin/sh
echo "testing with: $1 - $2";
kenv hint.hdaa.0.gpio_config="0=$1 1=$2";
kldunload snd_hda.ko;
kldload snd_hda.ko;
mplayer song.mp3;

and I run it like this:

./test.sh set set
./test.sh set clear
./test.sh clear set
./test.sh clear clear

And nothing came out of the speaker, alas :(

What's strange is that the speaker actually works with OSS from ports,
but when I use it (OSS) with mplayer it crashes the whole system
whenever I try to skip in a video/audio file

[Alexander Motin]

On 28.10.2012 23:20, Big Yuuta wrote:
> Unfortunately, trying with the different combinations didn't work.
>
> I wrote this tiny script just to make sure I'm not forgetting a case:
>
> #!/bin/sh
> echo "testing with: $1 - $2";
> kenv hint.hdaa.0.gpio_config="0=$1 1=$2";
> kldunload snd_hda.ko;
> kldload snd_hda.ko;
> mplayer song.mp3;
>
> and I run it like this:
>
> ./test.sh set set
> ./test.sh set clear
> ./test.sh clear set
> ./test.sh clear clear
>
> And nothing came out of the speaker, alas :(

Alas. I'll just remind one more time about `mixer ogain`.

Also check that pin sensing is working. Try to plug in/out headphones.
With verbose messages enabled, you should see messages about that on
console and in logs.

--
Alexander Motin

[Big Yuuta]

On Sun, Oct 28, 2012 at 10:34 PM, Alexander Motin <m...@freebsd.org> wrote:
> On 28.10.2012 23:20, Big Yuuta wrote:
>>
>> Unfortunately, trying with the different combinations didn't work.
>>
>> I wrote this tiny script just to make sure I'm not forgetting a case:
>>
>> #!/bin/sh
>> echo "testing with: $1 - $2";
>> kenv hint.hdaa.0.gpio_config="0=$1 1=$2";
>> kldunload snd_hda.ko;
>> kldload snd_hda.ko;
>> mplayer song.mp3;
>>
>> and I run it like this:
>>
>> ./test.sh set set
>> ./test.sh set clear
>> ./test.sh clear set
>> ./test.sh clear clear
>>
>> And nothing came out of the speaker, alas :(
>
>
> Alas. I'll just remind one more time about `mixer ogain`.

My bad, I forgot to tell you that I tried it with
mixer ogain 0:0 and mixer ogain 100:100 for every case.

> Also check that pin sensing is working. Try to plug in/out headphones. With
> verbose messages enabled, you should see messages about that on console and
> in logs.

Ah, yes, I should give this a try!

Thank you so much, Alexander!

I'll keep you informed :)

[Big Yuuta]

Hi, Alexander

On Sun, Oct 28, 2012 at 10:34 PM, Alexander Motin <m...@freebsd.org> wrote:
> Also check that pin sensing is working. Try to plug in/out headphones. With
> verbose messages enabled, you should see messages about that on console and
> in logs.

Pin sensing works fine. I tested it and whenever I plug the headphone in,
I can hear the sound from the headphone, and I have this output
on the console:

hdaa0: Pin sense: nid=26 sence=0x80000000 (connected)
pcm0: Redirect output to: headphones
hdaa0: Pin sense: nid=26 sence=0x00000000 (disconnected)
pcm0: Redirect output to: main

I think the redirection works, but nid20 is not well set? Is "main" here
the 1st nid of the association? i.e. nid20 which has seq=0?

I hope I'm not bothering you with my questions, and again thanks
a lot for all your work, patience, and help!

[Alexander Motin]

On 29.10.2012 17:44, Big Yuuta wrote:
> Hi, Alexander
>
> On Sun, Oct 28, 2012 at 10:34 PM, Alexander Motin <m...@freebsd.org> wrote:
>> Also check that pin sensing is working. Try to plug in/out headphones. With
>> verbose messages enabled, you should see messages about that on console and
>> in logs.
>
> Pin sensing works fine. I tested it and whenever I plug the headphone in,
> I can hear the sound from the headphone, and I have this output
> on the console:
>
> hdaa0: Pin sense: nid=26 sence=0x80000000 (connected)
> pcm0: Redirect output to: headphones
> hdaa0: Pin sense: nid=26 sence=0x00000000 (disconnected)
> pcm0: Redirect output to: main
>
> I think the redirection works, but nid20 is not well set? Is "main" here
> the 1st nid of the association? i.e. nid20 which has seq=0?

Not necessary the seq=0, as it can be multichannel output, but in this
case -- yes.

> I hope I'm not bothering you with my questions, and again thanks
> a lot for all your work, patience, and help!

Unfortunately I am almost run out of ideas. Neither Linux nor audio/oss
seems have specific code for your system. That makes me think that
problem is in some different basic assumptions in the drivers. But that
doesn't give any hint to find it out.

You may try to play with setting different levels of ivref/ovref
voltages via hint.hdaa.0.config tunable. I haven't even seen it
affecting power amplifier, but who knows...

--
Alexander Motin

[Big Yuuta]

Thank you, Alexander! :)

In fact, this netbook works very fine with audio/oss from ports.
My only problem with audio/oss is that whenever I skip (seek) in a
video or an audio file, freebsd crashes and reboots.

I know it's a problem with mplayer + oss, because, mplayer
with snd_hda works (except speaker) and oss + vlc works

But I like mplayer more than vlc ;)

[Alexander Motin]

I don't have plans to support audio/oss, but I would be interested to
diagnose this issue with snd_hda. Unfortunately, I am not sure what else
can I do now without access to the hardware for low-level debugging. If
somebody with the same netbook and the same problem appears at MeetBSD
California or otherwise in San Jose in following days, I would be glad
to look. Other problematic sound hardware is also welcome.

--
Alexander Motin

[Big Yuuta]

Perfect! Thank you so much! And if I ever make it work, I'll tell you.

Thanks again :)

[Big Yuuta]

Hi Alexander,

I got the sound out of that speaker!! :)

I actually started to read your code, and I'm still trying to understand
the stuff in it (I never wrote a device driver)

Anyway, so I did a little hack'ish modification (just to test) in function

hdaa_audio_ctl_amp_set_internal(struct hdaa_devinfo *devinfo, nid_t nid,
int index, int lmute, int rmute,
int left, int right, int dir)
{
uint16_t v = 0;

// Do not mute, even if asked for. Test to be removed of course
lmute = 0;
rmute = 0;


I know, this is absolutely NOT the way to do it, but I wanted to see
if the speaker wasn't muted (or the mixer that controls it)
and it -actually- WAS muted!

Now, I guess I'll have to read the whole code, try to understand its
internals, and I hope to be able to write a patch to add to hdaa_patches.c

I'm just a beginner, but I'll try anyway :)

[Alexander Motin]

On 30.10.2012 09:17, Big Yuuta wrote:
> Hi Alexander,
>
> I got the sound out of that speaker!! :)
>
> I actually started to read your code, and I'm still trying to understand
> the stuff in it (I never wrote a device driver)
>
> Anyway, so I did a little hack'ish modification (just to test) in function
>
> hdaa_audio_ctl_amp_set_internal(struct hdaa_devinfo *devinfo, nid_t nid,
> int index, int lmute, int rmute,
> int left, int right, int dir)
> {
> uint16_t v = 0;
>
> // Do not mute, even if asked for. Test to be removed of course
> lmute = 0;
> rmute = 0;
>
>
> I know, this is absolutely NOT the way to do it, but I wanted to see
> if the speaker wasn't muted (or the mixer that controls it)
> and it -actually- WAS muted!
>
> Now, I guess I'll have to read the whole code, try to understand its
> internals, and I hope to be able to write a patch to add to hdaa_patches.c

Speaker should be muted on headphones connection. That is one of two
ways of handling playback redirection. But it should be unmuted on
disconnection. You may try to set sysctl hw.snd.verbose=4 and
connect/disconnect headphones. It should report which controls are
affected and how.

You may try this hack to use pin controls instead of muters for redirection:
--- hdaa.c (revision 242315)
+++ hdaa.c (working copy)
@@ -260,7 +260,7 @@
/* (Un)Mute headphone pin. */
ctl = hdaa_audio_ctl_amp_get(devinfo,
w->nid, HDAA_CTL_IN, -1, 1);
- if (ctl != NULL && ctl->mute) {
+ if (ctl != NULL && ctl->mute && 0) {
/* If pin has muter - use it. */
val = connected ? 0 : 1;
if (val != ctl->forcemute) {
@@ -290,7 +290,7 @@ hdaa_hpredir_handler(struct hdaa_widget *w)
continue;
ctl = hdaa_audio_ctl_amp_get(devinfo,
as->pins[j], HDAA_CTL_IN, -1, 1);
- if (ctl != NULL && ctl->mute) {
+ if (ctl != NULL && ctl->mute && 0) {
/* If pin has muter - use it. */
val = connected ? 1 : 0;
if (val == ctl->forcemute)


--
Alexander Motin

[Big Yuuta]

Yes, actually I'm using sysctl hw.snd.verbose=4 to understand
what's happening inside.

From my tests, it's not a sense redirection problem. Because, when
I unmute everything, and then I plug a headphone, the sound goes
to the headphone and the internal speaker is mutted, and when I unplug
it, the internal speaker gets the sound, and (nid 26: the headphone)
is mutted.

So, anyway, I'm still debugging it and I found out that I don't have
to "unmute" everything, I just have to make sure that nid=15 is never
mutted.

i.e. the test I wrote in my last email could be more precise like this:

hdaa_audio_ctl_amp_set_internal(struct hdaa_devinfo *devinfo, nid_t nid,
int index, int lmute, int rmute,
int left, int right, int dir)
{
uint16_t v = 0;

if(nid == 15){ //just don't mute nid15, and it works

lmute = 0;
rmute = 0;
}

Strange thing is from my dmesg here: http://dpaste.com/818967/plain/
I thought that nid 15 wasn't used.

hdaa0: nid: 15 [DISABLED]
hdaa0: Name: audio mixer
hdaa0: Widget cap: 0x0020010a
hdaa0: Input amp: 0x80000000
hdaa0: mute=1 step=0 size=0 offset=0
hdaa0: connections: 2
hdaa0: |
hdaa0: + [DISABLED] <- nid=2 [audio output]
hdaa0: + [DISABLED] <- nid=11 [audio mixer]

Maybe it's disabled because others were disabled for other reasons?
I honestly don't grok the whole thing yet.

We, IMVHO, probably just should add a patch inside hdaa_patches.c
for this case:

case HDA_CODEC_ALC269:
if (subid == 0x10438437){ //0x10438437 is my subsystem id.
w = hdaa_widget_get(devinfo, 15);
if(w != NULL)
//some magic to unmute it ?
}
break;

What do you think?

[Alexander Motin]

The driver reports as disabled all parts of the CODEC that are unused in
specific configuration. It is quite usual to have half of CODEC unused.
To avoid unexpected effects driver mutes all disabled controls.
According to information reported by CODEC, this mixer is really unused.
I see no problem from the driver side there.

> We, IMVHO, probably just should add a patch inside hdaa_patches.c
> for this case:
>
> case HDA_CODEC_ALC269:
> if (subid == 0x10438437){ //0x10438437 is my subsystem id.
> w = hdaa_widget_get(devinfo, 15);
> if(w != NULL)
> //some magic to unmute it ?
> }
> break;
>
> What do you think?

I think Realtek engineers got crazy. They not only created several
different CODECs sharing the same ID (my laptop also uses variant of
ALC269, but it has no such problem), but also violated their own specs
and information reported by CODEC. Patch below should hide problematic
muter from the driver. Solution is far from perfect, but that is best I
can propose without having more information. Please test it and report
about results.

--- hdaa_patches.c (revision 242352)
+++ hdaa_patches.c (working copy)
@@ -541,6 +541,21 @@ hdaa_patch(struct hdaa_devinfo *devinfo)
if (w != NULL)
w->connsenable[0] = 0;
break;
+ case HDA_CODEC_ALC269:
+ /*
+ * ASUS EeePC 1001px has strange variant of ALC269 CODEC,
+ * that mutes speaker if unused mixer at NID 15 is muted.
+ * Probably CODEC incorrectly reports internal connections.
+ * Hide that muter from the driver. There are several
CODECs
+ * sharing this ID and I have not enough information about
+ * them to implement more universal solution.
+ */
+ if (subid == 0x10438437) {
+ w = hdaa_widget_get(devinfo, 15);
+ if (w != NULL)
+ w->param.inamp_cap = 0;
+ }
+ break;
case HDA_CODEC_CX20582:
case HDA_CODEC_CX20583:
case HDA_CODEC_CX20584:

[Big Yuuta]

Hi Alexander,

No, that patch didn't do the trick for the simple reason that
my actual subid was 0x84371043 and not 0x1043837 -you spot my mistake? ;-)

So here's the one that finally got me sound with my Asus EeePC 1001px
on the internal speaker:


--- hdaa_patches.c
+++ hdaa_patches.c
@@ -541,6 +541,21 @@

if (w != NULL)
w->connsenable[0] = 0;
break;
+ case HDA_CODEC_ALC269:
+ /*
+ * ASUS EeePC 1001px has strange variant of ALC269 CODEC,
+ * that mutes speaker if unused mixer at NID 15 is muted.
+ * Probably CODEC incorrectly reports internal connections.
+ * Hide that muter from the driver. There are several CODECs
+ * sharing this ID and I have not enough information about
+ * them to implement more universal solution.
+ */

+ if (subid == 0x84371043) {

+ w = hdaa_widget_get(devinfo, 15);
+ if (w != NULL)
+ w->param.inamp_cap = 0;
+ }
+ break;
case HDA_CODEC_CX20582:
case HDA_CODEC_CX20583:
case HDA_CODEC_CX20584:

Now I can have a good nap thinking that somehow I contributed a
tiny little bit to my favorite OS.

Thank you so much, Alexander! Not only you helped me solve this problem that
I had for several months, but you also got me interested in FreeBSD's
internal code!

[Alexander Motin]

On 31.10.2012 18:24, Big Yuuta wrote:
> No, that patch didn't do the trick for the simple reason that
> my actual subid was 0x84371043 and not 0x1043837 -you spot my mistake? ;-)
>
> So here's the one that finally got me sound with my Asus EeePC 1001px
> on the internal speaker:
>

> Now I can have a good nap thinking that somehow I contributed a
> tiny little bit to my favorite OS.
>
> Thank you so much, Alexander! Not only you helped me solve this problem that
> I had for several months, but you also got me interested in FreeBSD's
> internal code!

Thank you for your contribution, it is really valuable, as there is no
other way to handle such kind of hardware issues. I've just committed
the patch to the HEAD branch and will merge it down to 8/9-STABLE in two
weeks.

[Big Yuuta]

On Wed, Oct 31, 2012 at 11:14 PM, Alexander Motin <m...@freebsd.org> wrote:
> On 31.10.2012 18:24, Big Yuuta wrote:
>>
>> No, that patch didn't do the trick for the simple reason that
>> my actual subid was 0x84371043 and not 0x1043837 -you spot my mistake? ;-)
>>
>> So here's the one that finally got me sound with my Asus EeePC 1001px
>> on the internal speaker:
>>
>> Now I can have a good nap thinking that somehow I contributed a
>> tiny little bit to my favorite OS.
>>
>> Thank you so much, Alexander! Not only you helped me solve this problem
>> that
>> I had for several months, but you also got me interested in FreeBSD's
>> internal code!
>
>
> Thank you for your contribution, it is really valuable, as there is no other
> way to handle such kind of hardware issues. I've just committed the patch
> to the HEAD branch and will merge it down to 8/9-STABLE in two weeks.
>
> --
> Alexander Motin

It was *my* pleasure! Thank you!