Headphone jack detection fails on Braswell / Realtek ALC5645

[reynhout]

We're pulling in future mainline code from @plbossart's experimental repo, for the chtrt5650 drivers in 4.9.4-galliumos kernels. Watch for updates.

---

Workaround: This issue appears to be easily fixed by installing acpid and making /etc/acpi/jack.sh executable.

[evan-a-a]

This is likely something gallium/ubuntu specific since I am having no issues with jack detection on Arch with the same kernel.

[reynhout]

Very possibly a kernel config difference -- though I did notice some relevant-sounding changes for chtrt5650 jack detection in @plbossart's updated repo.

@evan-a-a: If you have it, could you pastebin the Arch kernel config for 4.9.x? (probably in /boot/config-4.9.x or similar). Thanks!

[evan-a-a]

@reynhout The config I'm using is available here.

The updated jack detection code was specifically to fix chtrt5645 on an Asus laptop. Jack detection with chtrt5650 on edgar has worked since I first integrated the changes.

[reynhout]

@evan-a-a Got it, thank you. I don't see anything obvious from a quick diff of our configs, but I will dig deeper.

[mint-dewit]

After boot I had audio and volume keys, after multiple sleep wake cycles (divided over 24 hours) I stopped having audio (YouTube would fail playback all together) and after logging out and in I regained audio but lost volume keys.

My description is a bit vague but maybe it'll point someone in the right direction.

On Thu, 19 Jan 2017 17:39 reynhout, notifications@github.com wrote:

@evan-a-a https://github.com/evan-a-a Got it, thank you. I don't see anything obvious from a quick diff of our configs, but I will dig deeper.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/318#issuecomment-273827676, or mute the thread https://github.com/notifications/unsubscribe-auth/AJcKmDlgPH_oB_wEcd7zCxsGOalnNJQLks5rT5HLgaJpZM4LnU92 .

[reynhout]

This should be working in galliumos-braswell version 2.0.5 or later.

Uses an ACPI event handler to run the appropriate amixer commands. No kernel changes necessary.

Tested on TERRA. Please let me know if it WFY.

[mint-dewit]

Not working on EDGAR.

[hmedina0]

Using 2.1, fully updated, not working on TERRA. Have to manually change to headphone output.

[SoulDJ673]

Updated to 2.0.5 from apt, nothing. I then pulled the update from the GitHub repo to see if anything changed, and still nothing. Just an update, but I'm at school rn maybe I could help somehow later though. Btw I have the Samsung Chromebook 3 CELES

==== EDIT ====

After installing acpid and chmoding /etc/acpi/jack.sh there is still no success.

[Ferrantisimo]

Initially was not working for me on EDGAR with a fresh 2.1 dual-boot install using chrx. Speakers worked without issue, and I could switch to headphones by manually switching output source in pavucontrol.

2.1 Braswell did not come with acpid installed by default. chrx didn't give me any options so I'm pretty sure I didn't do anything to cause this. I manually installed the acpid package, but still couldn't automatically switch between headphones and speakers after the plug/unplug event.

Restarting acpid with the -l ("log all events") option revealed that acpid was catching the plug/unplug events, but the /etc/acpi/jack.sh script was exiting with a 126 status. The script looked ok to me, and running the amixer commands inside it would indeed switch between the headphones and speakers. Turns out the /etc/acpi/jack.sh script wasn't executable... One chmod +x later and headphone jack detection and source switching works.

TL;DR: Installing acpid and making /etc/acpi/jack.sh executable fixed this issue for me on EDGAR with a stock chrx install of 2.1

[ghost]

Wow, that's pretty simple. If it works every time that would be fantastic!

[tobeportable]

/etc/api/jack.sh was already executable on my EDGAR so installing acpid solved it for me

[thalesmaoa]

Awesome! acpid worked!

Unfortunately my mic is not working? Any tip?

Braswell Samsung 3

- Thales Alexandre Carvalho Maia

2017-05-19 2:56 GMT-03:00 tobeportable notifications@github.com:

/etc/api/jack.sh was already executable on my EDGAR so installing acpid solved it for me

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/318#issuecomment-302615786, or mute the thread https://github.com/notifications/unsubscribe-auth/ANbCza23TD12fTPTs3LT6P2CNY824kxHks5r7S8lgaJpZM4LnU92 .

[ghost]

@thalesmaoa mic: https://github.com/GalliumOS/galliumos-distro/issues/319

[DefinitelyNotSade]

Can confirm that installing acpid solved this issue for me.

On a Samsung Chromebook 3 - Braswell (XE500C13)

[Aeny202]

Works on SETZER when installing GalliumOS from the Braswell image and manually installing acpid.

[markus-willems]

Doesnt work for me on EDGAR. I installed acpid but when I plug in a headphone jack the output device wont switch from speaker to headphones automatically.

[Aeny202]

Doesnt work for me on EDGAR. I installed acpid but when I plug in a headphone jack the output device wont switch from speaker to headphones automatically.

@markus-willems Could you check if /etc/acpi/jack.sh exists for you and if it's executable?

[symera]

Doesnt work for me on EDGAR. I installed acpid but when I plug in a headphone jack the output device wont switch from speaker to headphones automatically.

@markus-willems I had the same "issue" until I realized that it's just the output device from the UI in Volume Control which won't switch the port after plugging in a headphone, however the sound output did in fact switch automatically.

[markus-willems]

@symera @Aeny202 Oh my, I didnt realize that thats exactly what is happening. I installed it a while ago and could swear it didnt work with an external audio system. I just tried my headphones and they got detected. Thank you.

I will try it again with my external audio system and report back on that.

[markus-willems]

My external audio system is detected, too. However, it wont be detected on start up. I have to plug it out and in when the OS is already booted.

[ghost]

@markus-willems That was a problem (maybe still is) on Bay Trail too.

@reynhout Since the answer seems to be as simple as installing acpid, can we get that installed by default change in the pipeline.

[jklingen92]

I'm using the Acer R11 (CYAN) model and my headphone jack isn't getting detected. Installing acpid doesn't seem to work and the jack.sh file is executable. I assume this is because the audio chip is different.

[vereist]

There's a pretty major issue with this workaround if you're using headphones. What the script is doing is changing the amixer channel stuff, not the actual output sink's port.

So, your output sink port is still technically set to the speakers, routed to the headphone jack, but not through the headphone amplifier. The existing workaround is "fine" if you're plugging into a set of speakers or some other kind of external amplifier, and, in fact, is probably what you want to continue doing.

If you're using headphones or planning to do so, the existing jack.sh isn't the way to do it.

I put together a replacement script here: https://gist.github.com/vereist/f660bbe81002b25f4fd72b466ecb640c

Directions Back up your existing script. Make sure you put the appropriate values in for your user/hardware/ports. Comments are included for people like me who had to look all of these things up. Replace the jack.sh script in /etc/acpi.

What the hell is happening in this script? I noticed in the originally included jack.sh, there were pacmd things commented out. Ostensibly this is because when pulseaudio is set up to run under a user, you can't actually do anything to that process as another user.

So, jack.sh runs as root because of /etc/acpi/events/jack that is listening for plug information from acpid So, the solution is to explicitly run it with your user and uid runtime stuff.

Disclaimers I have no idea if that script will set your cat on fire, summon the devil, or cause some kind of horrible security vulnerability. I just know that it solved my particular problem on an EDGAR model Acer Chromebook 14, and probably will on anything else, assuming you look up the appropriate output from pacmd.

[MageJohn]

@vereist this won't won't work on a multi-user system, unfortunately. We need some way of controlling pulse as root.

[vereist]

Yeah, that's definitely an issue that I wasn't really considering at the time.

I'm not sure that there really is a solution in this instance that isn't some kind of hacky workaround. I mean, I guess you could do something like loop through logged in user IDs or something to set the output device on all of them. I don't know if there is a way to get the ID of users logged into an X session or what.

I'm sure there would be some kind of ramifications of an approach like that too. It just feels like a typical "desktop Linux" problem that comes up because it's all pretty much cobbled together.

On Nov 19, 2017 11:12 AM, "MageJohn" notifications@github.com wrote:

@vereist https://github.com/vereist this won't won't work on a multi-user system, unfortunately. We need some way of controlling pulse as root.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/318#issuecomment-345532900, or mute the thread https://github.com/notifications/unsubscribe-auth/AIgnDmhiNB8AqcC2seH-wjJLUnioc3pvks5s4GGUgaJpZM4LnU92 .

[Shamanon]

@vereist I am noticing no difference in headphone sound between manually switching from speaker to headphone using "volume control" and automatic switching with the original jack.sh script. How are you determining that the original script is not routing audio through the headphone amplifier? The only difference I can see is that when manually switching outputs is that headphone has it's own volume setting (which is nice because I like the speakers at about 75% and the headphones at full)... is that what you are talking about?

[vereist]

@Shamanon pacmd list-sinks will still show it as using the speaker port even though audio is being routed through the headphone port as will the PulseAudio volume control app. Changing the port from speakers to headphones is a dramatic difference. Now, you may not notice on terrible and/or low impedance headphones like ear buds. The effect is still there, it's just less apparent.

Without using the proper port set from pacmd, I can't get any bass out of my 56 Ohm headphones. It just won't drive them. That's how I stumbled upon this entire thing to begin with.

[SoulDJ673]

@vereist 's solution worked for me. Thank you btw

[rusty122]

@vereist @MageJohn I think I found a solution to change the sink port as root:

• Configure PulseAudio to load the module module-native-protocol-tcp
• Set the PULSE_SERVER variable in the jack.sh script
• Instead of using pacmd to change the sink use pactl

PulseAudio clients can connect over Unix socket (in this case the socket is /run/user/$ID/pulse/natvie) or a TCP connection. Loading module-native-protocol-tcp makes the server start listening to port 4713 which is user-agnostic so you can just tell clients to connect to the server over TCP with a special server string environment variable.

For some reason pacmd ignores the PULSE_SERVER value and tries to connect to the server in some default manner while pactl will listen and connects fine over TCP. pactl "only exposes a subset of the available operations" but luckily this includes the set-sink-port command.

Usually the client has to authenticate with a cookie when connecting to the PulseAudio server over TCP but I didn't have to do anything special when connecting from localhost.

You can load the module with pacmd load-module module-native-protocol-tcp. To enable it across startups, uncomment the corresponding line in the /etc/pulse/default.pa configuration.

Here is my modified jack.sh script: https://gist.github.com/rusty122/769650f8ddbc035cad3243c8fa4d97f5

[dsrmatze]

@rusty122 Had to specifically load the module and allow localhost.

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1

(The docs under authentication do to me not clearly state if then the cookies wont be used or if it is specifically required to allow an ip)

Otherwise pulseaudio would yield

Feb 28 17:57:41 ASUSCB root: jackdetect: handling jack/headphone HEADPHONE plug Feb 28 17:57:41 ASUSCB pulseaudio[1235]: [pulseaudio] protocol-native.c: Denied access to client with invalid authentication data.

Other than that it works for me. Thanks for the script.

[rusty122]

@dsrmatze You can try using the /etc/pulse/default.pa configuration instead of the pacmd command. I've uncommented load-module module-native-protocol-tcp there and haven't run into authentication issues.

[dsrmatze]

@rusty122 Thats what i did. I was using exactly your pull request changes. Double checked and still only works with auth-ip-acl=127.0.0.1

$ uname -r
4.14.14-galliumos
$ pulseaudio --version
pulseaudio 8.0

[danilofreire]

Installing acpid worked perfectly on my Lenovo N22. No other configuration was necessary. Thanks!

[nerevar009]

Installing acpid worked for me too on my Acer Chromebook 15, but the speakers were still set as default on boot even with headphones plugged in. I worked around that by logging the headphone plugged/unplugged status to a file in /etc/acpi/jack.sh, commenting out the amixer commands, and using a start script running as a daemon using inotify-tools to set the sink port. It works for both setting the correct sink port on boot and when plugging/unplugging headphones. I couldn't get the PulseAudio TCP connection to work, so I did this instead.

Steps: 1) Run these commands (install inotify-tools, create headphones status file, make it read-only):

sudo apt-get install inotify-tools && sudo touch /var/log/headphones_plugged && sudo chmod +4 /var/log/headphones_plugged

2) Replace /etc/acpi/jack.sh with this one.

3) Add this script as a startup script in Session and Startup's Application Autostart tab.