I found the PIN to switch the dock speakers on - with HDAAnalyzer, it's node 0x1b, from the GUI it's "Widget Control" "Out", or as a number 0x40 in text-mode at Pin-ctls.

With hda-verb dock speaker can be switched on with:

# ./hda-verb /dev/snd/hwC0D0 0x01b SET_PIN_WIDGET_CONTROL 0x40

and off with:

# ./hda-verb /dev/snd/hwC0D0 0x01b SET_PIN_WIDGET_CONTROL 0x20

(not sure of the 0x20 (IN) bit meaning though)

Also GPIO 2 of codec-0 needs to be switched on for dock sound to work.

.. And 0x1b needs also to be unmuted.

Ideally this should work so that dock (has keyboard & displayport) speakers (which are better) will be automatically used when the tablet part is docked to the keyboard, and again when the tablet part is undocked, the table speakers would be used. Not sure of how to sense dock/undock.

When the pin 0x1b is changed and GPIO2 is set, does the sound come from both dock and tablet, or only from the dock?  In non-ideal but a feasible fix is to just enable this pin and GPIO constantly.

Possibly the codec reports the dock connection state via some jack-detection bit.
Try to run hda-verb like
    hda-verb /dev/snd/hwC0D0 0x1b SET_PIN_SENSE 0
    hda-verb /dev/snd/hwC0D0 0x1b GET_PIN_SENSE 0

and see whether the latter command shows the bit 31 on/off per dock/undock.
If 0x1b doesn't show the difference, try other NIDs for pin widgets with the detection capability, e.g. 0x18, 0x19, ... (look for "pincap" with "detect" in the codec proc output).

It comes from both dock and tablet.

One way to silence tablet output I found is to tune output amp dials to 0 in node 0x02 - sound still comes from dock when I do that.

I'll test the detection when I can undock from the HD, that's in use now.

Turning GPIO 0 & 1 off doesn't silence the tablet output.

Node 0x14 mute boxes also mute the tablet speakers while letting sound hear from the dock.

You're correct, GET_PIN_SENSE 0 at node 0x1b can be used to sense dock state - output from looping with the command, first docked, then undocked, then docked again.

hda-verb /dev/snd/hwC0D0 0x1b GET_PIN_SENSE 0

nid = 0x1b, verb = 0xf09, param = 0x0
value = 0x80000000
nid = 0x1b, verb = 0xf09, param = 0x0
value = 0x80000000
nid = 0x1b, verb = 0xf09, param = 0x0
value = 0x80000000
nid = 0x1b, verb = 0xf09, param = 0x0
value = 0x0
nid = 0x1b, verb = 0xf09, param = 0x0
value = 0x0
nid = 0x1b, verb = 0xf09, param = 0x0
value = 0x0
nid = 0x1b, verb = 0xf09, param = 0x0
value = 0x80000000
nid = 0x1b, verb = 0xf09, param = 0x0
value = 0x80000000
nid = 0x1b, verb = 0xf09, param = 0x0
value = 0x80000000

OK, that's good.  Could you give alsa-info.sh output (run with --no-upload option) to this bugzilla, so that I can check via the emulator?

Created attachment 104931 [details]
alsa-info

Here's the alsa.info.sh output.

Thanks.  Could you try the patch attached below?

Created attachment 104961 [details]
Fix patch for ASUS TX300 dock pin and GPIO

One issue with the sound is the external combo jack connector. From a bit of googling, seems like this is either headphone or mic, switchable by software. It works fine as headphone output, but I haven't found a way to use it as mic input with Linux. With node 0x11 mute I can mute the internal microphone(s?), but I can't find how to enable a jack-connected microphone.

3.10 kernel has a few headset support for ALC269 & co, and this might work for this device, too.  Also, for a TRRS type headset, the fix for ASUS X101CH might be usable for this device, too.  For more complicated headset support, the code we took for Dell machines might help, too.

But, in anyway, we need to go step by step.  Did the patch work for the dock output, at least?

Ah, I didn't notice the patch before writing the jack message - I'll test.

Yes, the patch works with 3.10-rc6. Sound comes from both the dock speakers and the tablet speakers.

OK, and are the tablet / dock speakers switched automatically?  Or do both of them sound at the same time if it's docked?

Thanks for the patch and tips wrt headset mic - tested this:

	SND_PCI_QUIRK(0x1043, 0x103f, "ASUS TX300", ALC269_FIXUP_ASUS_X101),

but no input from a mic/headset combo. But my understanding is that the computer has a combo jack which means it takes either headphones or mic but not both at the same time.

From both at the same time when docked.

(In reply to comment #20)
> Thanks for the patch and tips wrt headset mic - tested this:
> 
>     SND_PCI_QUIRK(0x1043, 0x103f, "ASUS TX300", ALC269_FIXUP_ASUS_X101),
> 
> but no input from a mic/headset combo. But my understanding is that the
> computer has a combo jack which means it takes either headphones or mic but
> not
> both at the same time.

Give alsa-info.sh outputs with this change while you're testing from the external mic.  Possibly something was forgotten in the setup.

Also,

(In reply to comment #21)
> From both at the same time when docked.

... give alsa-info.sh outputs before and after dock, too.

The patch assumes that the unsolicited event is generated at docking, which should change the pin NID 0x14 respectively.  If the event isn't generated, a polling would be another option.  For example, pass jackpoll_ms=100 option to snd-hda-intel module.

The report about sound coming from both at the same time was when docked at the time the sound modules were loaded; I didn't test undock/dock but I will.

Starting at docked state, going to undocked, then docking back - in all cases sound comes from tablet internal speakers.

Will attach alsa-info.sh output.

Created attachment 105031 [details]
patched version, computer started at docked state

Created attachment 105041 [details]
After undock

Created attachment 105051 [details]
Docked again after undocked state (patched as the previous one)

Hmm - looking at the patch code, I don't see anything related to NID 0x14 which is the one to silence output in tablet - I wonder if I'm just overlooking it or if you accidentally posted a wrong version of the patch.

Same results with jackpoll_ms=100 option, still sound at tablet side even when docked.

Hm, OK, then please try to take tracepoints for better analysis.

- Build your kernel with trace support
- After boot, you'll have /sys/kernel/debug/tracing/*
- Take alsa-info.sh snapshot at this moment
- Enable the tracing via
     echo 1 > /sys/kernel/debug/tracing/events/hda/enable
- Dock or undock
- Get the tracepoints via
     cat /sys/kernel/debug/tracing/trace > /tmp/trace.log
- Disable the tracing
     echo 0 > /sys/kernel/debug/tracing/events/hda/enable
- Take alsa-info.sh output again

Then attach the two alsa-info.sh outputs and the trace log.
Some more details are found in Documentation/sound/alsa/HD-Audio.txt.

I tried to do that, but no real data at trace file, maybe I'm overlooking something:

# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 0/0   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |

Try to do some more actions, e.g. playing a stream or changing the mixer value.
If there is still no trace, it means that the tracing support isn't built properly in your kernel.  Try to enable relevant kernel configs.

If any events are recorded by the explicit action but nothing from dock/undock, then it means that the codec doesn't get unsolicited events from the dock.

I did play streams (with gnome-control-center audio test), no trace. Nor from mixer settings changes. CONFIG_TRACEPOINTS is on, and below is a grep of TRACE from .config. Can you advise what options should be enabled? Or is there something else besides echo 1 > /sys/kernel/debug/tracing/events/hda_intel/enable which needs to be done to switch tracing on?

CONFIG_STACKTRACE_SUPPORT=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_TRACEPOINTS=y
CONFIG_KPROBES_ON_FTRACE=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_NETFILTER_XT_TARGET_TRACE=m
# CONFIG_SCSI_IPR_TRACE is not set
# CONFIG_VXGE_DEBUG_TRACE_ALL is not set
# CONFIG_ATH5K_TRACER is not set
CONFIG_CAPI_TRACE=y
CONFIG_TRACE_ROUTER=m
CONFIG_TRACE_SINK=m
# CONFIG_PSTORE_FTRACE is not set
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_STACKTRACE=y
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_GENERIC_TRACER=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
# CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
CONFIG_MMIOTRACE=y
# CONFIG_MMIOTRACE_TEST is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y

Here are options containing hda:

grep -i hda /boot/config-3.10.0-rc6 
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_PREALLOC_SIZE=64
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=0
CONFIG_SND_HDA_INPUT_JACK=y
CONFIG_SND_HDA_PATCH_LOADER=y
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_HDMI=y
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CA0132=y
# CONFIG_SND_HDA_CODEC_CA0132_DSP is not set
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SENSORS_HDAPS=m

(In reply to comment #33)
> I did play streams (with gnome-control-center audio test), no trace. Nor from
> mixer settings changes. CONFIG_TRACEPOINTS is on, and below is a grep of
> TRACE
> from .config. Can you advise what options should be enabled? Or is there
> something else besides echo 1 >
> /sys/kernel/debug/tracing/events/hda_intel/enable which needs to be done to
> switch tracing on?

Not /sys/.../hda_intel/enable but /sys/.../hda/enable.

Yes, sorry, cut & pasted the wrong command. "echo 1 > /sys/kernel/debug/tracing/events/hda/enable" is what I did first - tried also hda_intel just in case which came up in the cut&paste, but no trace output with hda/enable or hda_intel/enable.

Hm, then I have no idea what prevents tracing.  Do other trace events work as expected with that kernel?

I'm not familiar with kernel tracing before, but I'd say yes, as after echo 1 >  /sys/kernel/debug/tracing/events/syscalls/sys_enter_umask/enable and trying the umask syscall I get this in trace:

# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 2/2   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
            bash-7152  [002] d... 38541.542337: sys_umask(mask: 12)
            bash-7152  [002] d... 38541.542343: sys_umask(mask: 12)

Then try again whether any specific event comes up by each of /sys/kernel/debug/tracing/hda/*/enable.  It's weird because there is nothing special in the setup.
Other than that, what I can think of is only the filter.  In anyway, check the file contents of enable and filter in each directory after enabling (just do cat).

Every subdir has 1 in enale, and "none" in filter.

cat /sys/kernel/debug/tracing/events/hda/*/enable
1
1
1
1
1
1
1

cat /sys/kernel/debug/tracing/events/hda/*/filter
none
none
none
none
none
none
none

And you really get no events?  Weird...

Nothing in trace; tried even rmmod & modprobe the sound modules.

Hm, then try to put some garbage like #error XXX in sound/pci/hda/hda_trace.h, and check whether the code is really compiled in.  Or check snd-hda-codec.ko via objdump and see whether it has some sections/definitions for ftrace.

:/lib/modules/3.10.0-rc6/kernel/sound/pci/hda# nm snd-hda-codec.ko |grep trace
0000000000000000 t ftrace_define_fields_hda_bus_reset
000000000000022b t ftrace_define_fields_hda_cmd
00000000000001c5 t ftrace_define_fields_hda_power
00000000000000c2 t ftrace_define_fields_hda_power_count
000000000000002f t ftrace_define_fields_hda_unsol_event
                 U ftrace_event_reg
0000000000000a20 d ftrace_event_type_funcs_hda_bus_reset
0000000000000a40 d ftrace_event_type_funcs_hda_cmd
0000000000000a00 d ftrace_event_type_funcs_hda_power
00000000000009e0 d ftrace_event_type_funcs_hda_power_count
00000000000009c0 d ftrace_event_type_funcs_hda_unsol_event
0000000000000c00 t ftrace_raw_event_hda_bus_reset
0000000000000cc0 t ftrace_raw_event_hda_cmd
0000000000000b30 t ftrace_raw_event_hda_power
0000000000000a40 t ftrace_raw_event_hda_power_count
0000000000000970 t ftrace_raw_event_hda_unsol_event
0000000000000680 t ftrace_raw_output_hda_bus_reset
00000000000006d0 t ftrace_raw_output_hda_cmd
0000000000000620 t ftrace_raw_output_hda_power
00000000000005b0 t ftrace_raw_output_hda_power_count
0000000000000550 t ftrace_raw_output_hda_unsol_event
                 U ftrace_raw_output_prep
                 U kmem_cache_alloc_trace
                 U perf_trace_buf_prepare
0000000000003420 t perf_trace_hda_bus_reset
0000000000000880 t perf_trace_hda_cmd
0000000000003340 t perf_trace_hda_power
0000000000003240 t perf_trace_hda_power_count
0000000000003150 t perf_trace_hda_unsol_event
                 U trace_buffer_unlock_commit
                 U trace_define_field
                 U trace_event_buffer_lock_reserve
                 U trace_event_raw_init
0000000000000100 D __tracepoint_hda_bus_reset
0000000000000140 D __tracepoint_hda_get_response
0000000000000040 D __tracepoint_hda_power_count
00000000000000c0 D __tracepoint_hda_power_down
0000000000000080 D __tracepoint_hda_power_up
0000000000000180 D __tracepoint_hda_send_cmd
0000000000000000 D __tracepoint_hda_unsol_event
0000000000000020 r __tracepoint_ptr_hda_bus_reset
0000000000000028 r __tracepoint_ptr_hda_get_response
0000000000000008 r __tracepoint_ptr_hda_power_count
0000000000000018 r __tracepoint_ptr_hda_power_down
0000000000000010 r __tracepoint_ptr_hda_power_up
0000000000000030 r __tracepoint_ptr_hda_send_cmd
0000000000000000 r __tracepoint_ptr_hda_unsol_event
                 U trace_seq_printf

:/lib/modules/3.10.0-rc6/kernel/sound/pci/hda# objdump -t snd-hda-codec.ko |grep tracepoin
0000000000000000 l    d  __tracepoints_ptrs	0000000000000000 __tracepoints_ptrs
0000000000000000 l    d  __tracepoints_strings	0000000000000000 __tracepoints_strings
0000000000000000 l    d  __tracepoints	0000000000000000 __tracepoints
0000000000000000 l     O __tracepoints_ptrs	0000000000000008 __tracepoint_ptr_hda_unsol_event
0000000000000000 l     O __tracepoints_strings	0000000000000010 __tpstrtab_hda_unsol_event
0000000000000008 l     O __tracepoints_ptrs	0000000000000008 __tracepoint_ptr_hda_power_count
0000000000000010 l     O __tracepoints_strings	0000000000000010 __tpstrtab_hda_power_count
0000000000000010 l     O __tracepoints_ptrs	0000000000000008 __tracepoint_ptr_hda_power_up
0000000000000020 l     O __tracepoints_strings	000000000000000d __tpstrtab_hda_power_up
0000000000000018 l     O __tracepoints_ptrs	0000000000000008 __tracepoint_ptr_hda_power_down
000000000000002d l     O __tracepoints_strings	000000000000000f __tpstrtab_hda_power_down
0000000000000020 l     O __tracepoints_ptrs	0000000000000008 __tracepoint_ptr_hda_bus_reset
000000000000003c l     O __tracepoints_strings	000000000000000e __tpstrtab_hda_bus_reset
0000000000000028 l     O __tracepoints_ptrs	0000000000000008 __tracepoint_ptr_hda_get_response
0000000000000050 l     O __tracepoints_strings	0000000000000011 __tpstrtab_hda_get_response
0000000000000030 l     O __tracepoints_ptrs	0000000000000008 __tracepoint_ptr_hda_send_cmd
0000000000000061 l     O __tracepoints_strings	000000000000000d __tpstrtab_hda_send_cmd
0000000000000040 g     O __tracepoints	0000000000000038 __tracepoint_hda_power_count
0000000000000100 g     O __tracepoints	0000000000000038 __tracepoint_hda_bus_reset
00000000000000c0 g     O __tracepoints	0000000000000038 __tracepoint_hda_power_down
0000000000000000 g     O __tracepoints	0000000000000038 __tracepoint_hda_unsol_event
0000000000000140 g     O __tracepoints	0000000000000038 __tracepoint_hda_get_response
0000000000000080 g     O __tracepoints	0000000000000038 __tracepoint_hda_power_up
0000000000000180 g     O __tracepoints	0000000000000038 __tracepoint_hda_send_cmd

Hm, then I have no idea why it doesn't work.

OK, let's forget about the tracepoints but try the traditional printk's.
Apply the patch below temporarily and see the kernel messages at docking/undocking.  Especially whether an unsol event on NID 0x1b is shown.

To check whether it really shows the unsol event, you can try to plug to the headphone jack.  This should issue the unsol event certainly.

Created attachment 105431 [details]
debug patch

OK, getting back to this - I've now compiled 3.11.0-rc6 with the debug patch, and will hopefully get to test it in a while.

OK, the results with 3.11.0-rc6 with the debug patch, no other sound patches:

At bootup, two blocks of debug messages:

Aug 25 18:46:08 assu kernel: [    6.672540] XXX read pin detection 0x21 0x0
Aug 25 18:46:08 assu kernel: [    6.673085] XXX read pin detection 0x5 0x0
Aug 25 18:46:08 assu kernel: [    6.673176] XXX read pin detection 0x6 0x0
Aug 25 18:46:08 assu kernel: [    6.673292] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11
Aug 25 18:46:08 assu kernel: [    6.673404] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12
Aug 25 18:46:08 assu kernel: [    6.673506] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13

and

Aug 25 18:46:19 assu kernel: [   17.574165] XXX read pin detection 0x21 0x0
Aug 25 18:46:19 assu kernel: [   17.604770] XXX read pin detection 0x5 0x0
Aug 25 18:46:19 assu kernel: [   17.604826] XXX read pin detection 0x6 0x0
Aug 25 18:46:35 assu kernel: [   33.658526] XXX read pin detection 0x21 0x0

No XXX debug messages at all at dock & undock.

When plugging in the headphones:


Aug 25 18:58:52 assu kernel: [  770.889224] XXX unsol event 16: 0x4060088
Aug 25 18:58:52 assu kernel: [  770.889328] XXX read pin detection 0x21 0x80000000

Unplugging headphones:

Aug 25 18:59:19 assu kernel: [  797.375524] XXX unsol event 16: 0x4060080
Aug 25 18:59:19 assu kernel: [  797.375597] XXX read pin detection 0x21 0x0

When snd-hda-intel is loaded with jackpoll_ms=100, there's a stream of these both when docked and undocked:

Aug 25 19:05:36 assu kernel: [ 1175.039153] XXX read pin detection 0x21 0x0
Aug 25 19:05:36 assu kernel: [ 1175.039254] XXX read pin detection 0x5 0x0
Aug 25 19:05:36 assu kernel: [ 1175.039335] XXX read pin detection 0x6 0x0

Then the messages with the patch posted in this thred (ALC269_FIXUP_GPIO2_AMP):

After elantech detection:

Aug 25 23:29:08 assu kernel: [    6.783923] XXX read pin detection 0x21 0x0
Aug 25 23:29:08 assu kernel: [    6.784459] XXX read pin detection 0x5 0x40000000
Aug 25 23:29:08 assu kernel: [    6.784486] XXX unsol event 19: 0x8000003
Aug 25 23:29:08 assu kernel: [    6.784548] XXX read pin detection 0x6 0xc0000000
Aug 25 23:29:08 assu kernel: [    6.788057] XXX unsol event 19: 0x8000003
Aug 25 23:29:08 assu kernel: [    6.788112] XXX read pin detection 0x6 0xc0000000
Aug 25 23:29:08 assu kernel: [    6.792205] XXX read pin detection 0x6 0xc0000000

Some more debug, not sure where this comes from, but appeared after plugging in a Samsung Android phone:

Aug 25 23:29:58 assu kernel: [   56.989009] XXX unsol event 19: 0x8000002
Aug 25 23:29:58 assu kernel: [   56.989077] XXX read pin detection 0x6 0x40000000
Aug 25 23:29:58 assu kernel: [   57.049567] XXX unsol event 19: 0x8000003
Aug 25 23:29:58 assu kernel: [   57.049623] XXX read pin detection 0x6 0xc0000000

At undock, still nothing.

Then after dock:

Aug 25 23:36:35 assu kernel: [  454.187589] XXX read pin detection 0x21 0x0

No XXX message after second undock / dock though.

Decided to retest with kernel 3.11.0. This time, it seems there are relevant messages at undock & dock:

After undock:

[ 2559.400753] XXX unsol event 16: 0x8080000
[ 2559.400821] XXX read pin detection 0x1b 0x0

After redock:

[ 2574.976526] XXX unsol event 16: 0x8080080
[ 2574.977354] XXX read pin detection 0x21 0x0
[ 2574.977419] XXX read pin detection 0x1b 0x80000000
[ 2574.978107] XXX read pin detection 0x1b 0x80000000

[ 2579.627465] XXX read pin detection 0x5 0x40000000
[ 2579.627510] XXX read pin detection 0x6 0xc0000000

Still sound simultaneously from both the dock and the tablet part, when docked.

Created attachment 107402 [details]
Patch for automatic tablet mute/unmute & dock sound enable

This is a patch against 3.11.0. In addition to incorporating the earlier code, there's more debug and new code to mute tablet speakers when docking.

The patch is not clean yet, as it appears there's a previous callback which causes the callback not to work with normal hda_jack.c code; for testing, I kludged the code in hda_jack.c to replace the previous callback. Must be debugged what the previous callback is and properly fixed and debug output cleaned before considering for merging.

Takashi, can you look at the patch in attachment 107402 [details], and perhaps see if you can shed some light into the callback issue mentioned above?

Other advise on how best to proceed in getting a fix merged?

You can register the callback at action==HDA_FIXUP_ACT_PRE_PROBE time so that it'll be registered before the generic parser does.

But, another problem in your patch is that you change the amp of NID 0x14 forcibly, and this conflicts with "Speaker Playback Switch" control.  That is, if you mute the output and dock, then the speaker is unmuted although the mixer still shows muted.

Below is a patch with a new approach.  It's for the current Linus tree, but can be applied to 3.11 easily, too.  3.10 might not work with the patch due to missing fixes for automute_via_amp flag.

Created attachment 107429 [details]
Revised fix patch

Thanks, applied with some manual help to 3.11, I'll test.

Test results:

* Dock sound works when docked, tablet is silent
* At docking, there's a click (like with my patch) suggesting the speaker switching works
* No sound when undocked
* Then I start HDAAnalyzer, look at Node 0x14 PIN, notice the Mute boxes are checked
* After unchecking the boxes, sound works when undocked
* Reboot, then Mute boxes are again checked
* Try to see if alsamixer can be used to unmute - can't find any way to do it
* Take away the checks from Node 0x14 PIN Mute boxes, sound works again when undocked
* Dock again; unfortunately, now sound again is heard from both speaker sets (with Mute boxes not checked).

Check whether asus_tx300_automute() is called at each time you dock, undock or headphone plug/unplug.  After calling this, snd_ctl_sync_vmaster() will be called and this will update the mute states of 0x14 and 0x1b.

For invoking alsamixer, run with -c0 option.  The "Speaker" item should have the mute capability, toggled via 'M' button.

asus_tx300_automute is not called at undock/dock. I added similar/same debug lines than in my patch, and one at start of asus_tx300_automute.

At startup:

[   10.954002] XXX tx300 automute called
[   10.954007] XXX tx300 automute jack_detect = true

Unsol event is received at undock:

[  540.620299] XXX unsol event 16: 0x4080000
[  540.620310] XXX running patch for unsol event 16: 0x4080000
[  540.620319] XXX jack->callback called in call_jack_callback, jack=0x1458c800
[  540.620383] XXX read pin detection 0x1b 0x0

Unsol event at dock:

[  545.680576] XXX unsol event 16: 0x4080080
[  545.680587] XXX running patch for unsol event 16: 0x4080080
[  545.680596] XXX jack->callback called in call_jack_callback, jack=0x1458c800
[  545.680659] XXX read pin detection 0x1b 0x80000000

No asus_tx300_automute at either dock or undock.

I also added debug messages to snd_hda_gen_hp_automute() and no output from that, so that's not even called snd_hda_gen_hp_automute().

Ah, it's probably the same issue as I had with the callback, there's a callback already registered:

[    6.703004] XXX snd_hda_jack_detect_enable_callback, jack=0x15f56c38 already registered

By commenting out the "return 0" in snd_hda_jack_detect_enable_callback(), snd_hda_gen_hp_automute() is entered, but it exits before call_update_outputs(codec);

Maybe add

		spec->gen.automute_speaker = 1;

or something like it in the tx300 automute setup?

Adding 

		spec->gen.automute_speaker = 1;

didn't help, snd_hda_gen_hp_automute() still exits before call_update_outputs(codec);

Tried also adding

 		spec->gen.detect_hp = 1;

- didn't help.

However, when I comment out the return at snd_hda_gen_hp_automute(), it works, and tx300 automute gets called.

In other words, your code with two additions, the return at snd_hda_gen_hp_automute() and the return snd_hda_jack_detect_enable_callback() comment out, your code works. These are obviously not the real fixes, but will perhaps help in finding what's wrong with the code.

I guess either the patch was applied wrongly or you changed "Auto-Mute Mode" mixer to off accidentally (and it's taken over via alsactl).  Try the patch below instead.  Apply it cleanly on the top of 3.11.

If it still doesn't work, show alsa-info.sh output.

Created attachment 107452 [details]
Fix patch for 3.11

Your're correct about Auto-Mute Mode being off - wasn't familiar with the setting. Will test your new patch.

Test results:

* Auto-Mute Mode was off by default when the sound modules were unloaded/loaded; alsactl store after enabling Auto-Mute mode fix this. I haven't changed the state on purpose, so I've either changed (and stored? or is it auto-stored?) it accidentally or it's the OS default to have it off.
* With Auto-Mute Mode on, the auto-changing of nid 0x14 works as expected, in other words dock and only the dock speakers are on when docked, and tablet speakers work when not docked

So, basic things seem to be good and well, thanks.

About mixer settings - not sure how this is supposed to work, but from the names and your comments, I would expect "Speaker" to correspond to internal tablet speaker, and "Dock Speaker" to be the dock speaker, and thus would expect things to work like this:

* AlsaMixer (command line) "Speaker" mute would control the tablet internal speaker mute and be "M" (muted) when docked
* AlsaMixer "Dock Speaker" mute would control dock speaker mute and be "M" when undocked

Instead, this is how it behaves, in a way that's unexpected to me:

* When docked, "Speaker" is not muted (not marked with 'M's)
* When undocked, "Dock Speaker" is not muted
* When docked, muting either "Dock Speaker" or "Speaker" mutes the sound.
* Muting "Speaker" adds mutes also to "Master" and "Headphone"

This is as I expect it to be:

* When docked and after using HDAAnalyzer to remove NID 0x14 mutes so sound comes both from dock & tablet speakers, muting Dock Speaker mutes the dock speakers and lets the tablet speakers work

"Auto-Mute Mode" is on as default in the driver level.  It must be alsactl who changed it at module loading time (usually triggered by udev), which also saves the value at shutdown.  The system-default value is found usually in either /var/lib/alsa/asound.state or /etc/asound.state.

The "Speaker" and "Dock Speaker" mixer controls are independent from the dock/undock status.  The mute of the tablet speaker is done at docking no matter whether "Speaker" is muted or not, as long as "Auto-Mute Mode" is set.
Ditto for "Dock Speaker".  If a headphone is plugged, the speaker is muted no matter whether speaker volume mixer controls are muted or not.

The same for undocking.  Since "Speaker" and "Dock Speaker" values are kept untouched by docking/undocking action, the mute state is resumed from the auto-muting.

So, all looks OK to me.

OK, Thanks for the info. Your comment answers two of the things which were unexpected to me, but are these also the way they're supposed to be:

* When docked, muting either "Dock Speaker" or "Speaker" mutes the sound.
* Muting "Speaker" adds mutes also to "Master" and "Headphone"

I would expect

* Muting "Speaker" to mute the internal speaker only, not the dock speaker
* Muting "Speaker" to not mute master & headphone

Could well be that these too are consistent with the way alsa muting normally works, like the automute is, and/or not related to the patch, just wanted to point out in case you think it's a problem.

* When docked, muting either "Dock Speaker" or "Speaker" mutes the sound.

Actually this should've been:

* When docked, muting "Speaker" mutes the sound also from the dock speaker.

Well, "Speaker" controls only the tablet speaker but not the dock speaker.  Ditto for "Dock Speaker".  "Dock Speaker" doesn't control the tablet speaker.
The auto-muting feature is a different story.

"Well, "Speaker" controls only the tablet speaker but not the dock speaker."

That's what I'm expecting. But what I'm telling as the test results is that muting "Speaker" does mute also the dock speaker. And also adds "M"'s to Master & Headphone. Even after I unmute Master & Headphone, dock speaker remains muted.

To be more exact, there's no sound from dock speaker (when there are no "M"'s at dock speaker control but there are "M"'s at "Speaker" control).

This is odd.  How did you achieve it at all?  That is, what is your test procedure?

In other words, does it really happen in the following?
  - amixer -c0 set Master unmute
  - amixer -c0 set Speaker unmute
  - amixer -c0 set "Dock Speaker" unmute

Dock the macchine
  - amixer -c0 set Speaker mute

Then check alsamixer.

Report:

Start state: Everything unmuted, docked.

Undocked.

Geve the following commands in undocked state:

  - amixer -c0 set Master unmute
  - amixer -c0 set Speaker unmute
  - amixer -c0 set "Dock Speaker" unmute

Docked.

Gave the command "amixer -c0 set Speaker mute"

Alsamixer shows:

Master, Headphone, Speaker all are muted ("MM"), Dock speaker unmuted ("OO").

No sound heard when trying sound test.

Give alsa-info.sh outputs before and after running "amixer -c0 set Speaker mute".

Also, try to mute "Speaker" via the command below instead.

  amixer -c0 cset name='PCM Playback Switch' 0,0

Does this cause the same effect?

  amixer -c0 cset name='PCM Playback Switch' 0,0

amixer: Cannot find the given element from control hw:0

Created attachment 107453 [details]
alsa-info.sh before speaker mute (comment 80)

Created attachment 107454 [details]
alsa-info.sh after speaker mute (comment 80)

Doh, of course it must be 'Speaker Playback Switch'
  amixer -c0 cset name='Speaker Playback Switch' 0,0

Take alsa-info.sh outputs before and after running this.

Is a diff sufficient?

# diff -u `ls -tr /tmp/alsa-info.txt.*`
--- /tmp/alsa-info.txt.AGWvrpF02t	2013-09-06 14:59:43.553746377 +0300
+++ /tmp/alsa-info.txt.tfYPZ3lUxn	2013-09-06 15:00:06.233746985 +0300
@@ -3,7 +3,7 @@
 !!ALSA Information Script v 0.4.62
 !!################################
 
-!!Script ran on: Fri Sep  6 11:59:43 UTC 2013
+!!Script ran on: Fri Sep  6 12:00:05 UTC 2013
 
 
 !!Linux Distribution
@@ -335,7 +335,7 @@
   Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0
   Amp-In vals:  [0x00 0x00]
   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
-  Amp-Out vals:  [0x00 0x00]
+  Amp-Out vals:  [0x80 0x80]
   Pincap 0x0000373c: IN OUT HP Detect
     Vref caps: HIZ 50 GRD 80 100
   Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
@@ -378,7 +378,7 @@
     ControlAmp: chs=3, dir=Out, idx=0, ofs=0
   Control: name="Headphone Jack", index=0, device=0
   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
-  Amp-Out vals:  [0x00 0x00]
+  Amp-Out vals:  [0x80 0x80]
   Pincap 0x0000001c: OUT HP Detect
   Pin Default 0x04211020: [Jack] HP Out at Ext Right
     Conn = 1/8, Color = Black
@@ -563,21 +563,21 @@
   Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
   Playback channels: Mono
   Limits: Playback 0 - 87
-  Mono: Playback 87 [100%] [0.00dB] [on]
+  Mono: Playback 87 [100%] [0.00dB] [off]
 Simple mixer control 'Headphone',0
   Capabilities: pvolume pswitch penum
   Playback channels: Front Left - Front Right
   Limits: Playback 0 - 87
   Mono:
-  Front Left: Playback 87 [100%] [0.00dB] [on]
-  Front Right: Playback 87 [100%] [0.00dB] [on]
+  Front Left: Playback 87 [100%] [0.00dB] [off]
+  Front Right: Playback 87 [100%] [0.00dB] [off]
 Simple mixer control 'Speaker',0
   Capabilities: pvolume pswitch penum
   Playback channels: Front Left - Front Right
   Limits: Playback 0 - 87
   Mono:
-  Front Left: Playback 87 [100%] [0.00dB] [on]
-  Front Right: Playback 87 [100%] [0.00dB] [on]
+  Front Left: Playback 87 [100%] [0.00dB] [off]
+  Front Right: Playback 87 [100%] [0.00dB] [off]
 Simple mixer control 'PCM',0
   Capabilities: pvolume penum
   Playback channels: Front Left - Front Right
@@ -642,8 +642,8 @@
 	control.2 {
 		iface MIXER
 		name 'Headphone Playback Switch'
-		value.0 true
-		value.1 true
+		value.0 false
+		value.1 false
 		comment {
 			access 'read write'
 			type BOOLEAN
@@ -680,8 +680,8 @@
 	control.5 {
 		iface MIXER
 		name 'Speaker Playback Switch'
-		value.0 true
-		value.1 true
+		value.0 false
+		value.1 false
 		comment {
 			access 'read write'
 			type BOOLEAN
@@ -760,7 +760,7 @@
 	control.11 {
 		iface MIXER
 		name 'Master Playback Switch'
-		value true
+		value false
 		comment {
 			access 'read write'
 			type BOOLEAN

And yes, it does cause the same effect.

Unmodified 3.11 also mutes master & headphones when muting the speaker.

Could you stop PulseAudio and test without PA?

You nailed it - kill -stop'd pulseaudio, now speaker with unpatched 3.11 works like expected.

To be more exact, muting the speaker works like expected in the way that it doesn't mute master & headphones.

However, using 3.11 patched with your patch, pulseaudio stopped, after unmuting NID14 when docked, muting the Speaker has no effect, sound is heard from speaker anyway.

Because "Speaker" is bound always to the tablet speaker while "Dock Speaker" to the dock speaker.  We can improve the behavior more, but I have no time for that for now...

Though, it's really weird that PulseAudio got so much screwed up.  Since even the unpatched driver shows the behavior, I guess it's a bug of PulseAudio.

By me your patch works well and is ready for inclusion into mainline. Thanks for your work.

Seems to me like there's a small issue with the mute left. I did realize Speaker means the tablet speaker, that's what I was talking about, the tablet speaker is not muted with "Speaker" control when docked. In other words, when docked, muting the Speaker has no effect on the tablet speaker, sound is heard from tablet speaker anyway.

However, muting the tablet speaker with Speaker mute works fine when undocked, and there probably aren't many use cases for the tablet speakers when docked so I don't think the issue has much practical significance. (couple of use cases: if the dock speakers are broken, or if one wants stereo when computer is the shorter side to the user for some reason, but user can probably live without mute in those rare cases..) 

And yes, I agree the mute weirdness looks like a bug of Pulseaudio.

OK, I submitted the patch to ML, and it'll be merged to git tree shortly later if no one objects on ML.

Thanks, appears to be in 3.12-rc1.

I just installed kernel-3.12.5-301.fc20 on Fedora 20, the dock speaker now working. However, the tablet speaker does not work anymore, now the sound is not balanced, left channel is much much louder than right right channel.

As soon as I installed ubuntu 14.04 on my asus TX300 i realized that i have sound only from dock, but when I undock, sound switches to tablet. I found a solution propably for lovetide@gg.com too.

Using hdajackretask I was able to get sound from dock and a tablet simultanly.

2.0 channels 4.0 speakers TO DO :
override Pin ID: 0x21 (on my tx300 named: Black Headphone, Right side) to be a speaker

But I wanted to have 4.0 sound system, to get better than Windows.
As soon as Ubuntu default drivers sees a 4.0 system, but cannot play sound from one "row" speakers I started to experiment and get to work

4.0 channels 4.0 speakers TO DO :
In advanced override mode, override Pin ID: 0x21 as 
Connectivity: Internal (seems to make no diffrence setting it other way, but do not leave blank)
Device: Digital Out (After setting this as Speaker, I only have 2.0 Channels, but sounds from all speakers)
Other settings seems to make no diffrence after all

I also added to /etc/modprobe.d at the end:

"options snd-hda-intel model=asus-mode1"

Don't know if this changes anything

Hope that helps.

options snd-hda-intel model=asus-mode1
Added at the end of /etc/modprobe.d/alsa-base.conf

alc282 is a 4 channels codec, even when you have two nodes in spec->speaker_out does not imply Max channel =4 when the driver assign same audio output nodes to two speaker nodes

spec->channels-max  should be two times the number of unique dac assigned to speaker instead the number of speaker nodes

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_generic.c?id=a07a949be6eb1c9aab06adaadce72dbd27b7d9cb

for multi channel, the driver only check all line out jacks have same default association to support multi channel but don't need headphone and speaker to have same default association

the badness of two speaker nodes to support 4.0 line out type = speaker is higher than that of line out type = headphone, the headphone assign dac first and the remain dac is shared by two speaker nodes

(In reply to Paweł Mikielewicz from comment #96)
> As soon as I installed ubuntu 14.04 on my asus TX300 i realized that i have
> sound only from dock, but when I undock, sound switches to tablet. I found a
> solution propably for lovetide@gg.com too.

you have to post output of alsa-info.sh


> 
> Using hdajackretask I was able to get sound from dock and a tablet
> simultanly.
> 
> 2.0 channels 4.0 speakers TO DO :
> override Pin ID: 0x21 (on my tx300 named: Black Headphone, Right side) to be
> a speaker
> 
> But I wanted to have 4.0 sound system, to get better than Windows.
> As soon as Ubuntu default drivers sees a 4.0 system, but cannot play sound
> from one "row" speakers I started to experiment and get to work

seem driver treat speaker and dock speaker as 2.1 share same DAC but set channels max= 4

requirements of subwoofer and rear surround is sligthly different since subwoofer with low pass filter only need copy of front signal but rear surround need two dac assign to front and rear speaket

> 
> 4.0 channels 4.0 speakers TO DO :
> In advanced override mode, override Pin ID: 0x21 as 
> Connectivity: Internal (seems to make no diffrence setting it other way, but
> do not leave blank)
> Device: Digital Out (After setting this as Speaker, I only have 2.0
> Channels, but sounds from all speakers)
> Other settings seems to make no diffrence after all
> 
> I also added to /etc/modprobe.d at the end:
> 
> "options snd-hda-intel model=asus-mode1"
> 
> Don't know if this changes anything
> 
> Hope that helps.



but your have internal speaker, dock speaker

(In reply to Paweł Mikielewicz from comment #96)
> As soon as I installed ubuntu 14.04 on my asus TX300 i realized that i have
> sound only from dock, but when I undock, sound switches to tablet. I found a
> solution propably for lovetide@gg.com too.
> 
> Using hdajackretask I was able to get sound from dock and a tablet
> simultanly.
> 
> 2.0 channels 4.0 speakers TO DO :
> override Pin ID: 0x21 (on my tx300 named: Black Headphone, Right side) to be
> a speaker
> 
> But I wanted to have 4.0 sound system, to get better than Windows.
> As soon as Ubuntu default drivers sees a 4.0 system, but cannot play sound
> from one "row" speakers 


===> Best configuration: lo_type=2, wired=1, mio=1
multi_outs = 21/0/0/0 : 3/0/0/0 (type HP)
   out path: depth=3 :03:0d:21
spk_outs = 1b/14/0/0 : 2/2/0/0
   spk path: depth=3 :02:0c:1b
   spk path: depth=3 :02:0c:14

as both speakers connected to same DAC , it won't support 4 channels in this config