Description of problem:
Installation succeeds on HP Spectre x360 (model 13-4003dx) without issue, except that sound will not work on the internal speakers.
The GNOME sound settings UI will show an empty list of sound devices. When an external device is connected (for example, a Bluetooth speaker), sound works perfectly on the external device and the device indeed becomes listed in the GNOME sound settings UI.
When attempting to adjust the sound volume in GNOME with no external speakers connected, the indicated sound device is "HDMI/DisplayPort". However, no sound is ever produced on the internal speakers.
Version-Release number of selected component (if applicable): Fedora 21, Fedora 22 with latest kernel (4.0.2)
How reproducible: Happens 100% of the time.
Steps to Reproduce:
1. Install Fedora 21 or 22 with any kernel up until the latest (4.0.2)
Sound will not work on internal speakers and no sound interface will be shown in GNOME settings. Sound will work on external Bluetooth speakers or headphones.
Sound is expected to work on internal speakers.
This appears to be a bug that is common across all new laptops shipping with the new Broadwell-U chipset. It has already been reported (and apparently resolved in a kernel update) for the Dell XPS 13 which ships with the same chipset   -- however, the fixes described therein do not aid with the Spectre x360. A bug for the Spectre x360 is also currently open over at Ubuntu's bug tracker .
I can add that this issue remains present when upgrading to the 4.1-rc3 kernel via the rawhide repositories.
I also have a HP Spectre 360, and while collecting info to file bug 1222273, I noticed this recurring message in journalctl:
kernel: broadwell-audio broadwell-audio: ASoC: CODEC DAI rt286-aif1 not registered
Searching for that codec name brought me to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1413446
In my case, the internal speakers are working fine, but the builtin microphone doesn't work (which matches the systems some folks have reported on that Ubuntu bug).
On closer inspection, it appears the audio on my system is actually coming out via the currently attached external monitor's speakers over HDMI, rather than using the internal audio.
Together with bug 1221050, this suggests to me current drivers may have significant compatibility issues with this particular chipset.
It would be pretty neat if someone could help out with this. It seems to be a common issue with Linux distributions and the Broadwell-U chipset...
I was able to get this working on my HP Spectre x360 on Fedora 22 as follows:
1. Update grub config
# vi /etc/default/grub
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora_spectre/swap rd.lvm.lv=fedora_spectre/root rhgb quiet"
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora_spectre/swap rd.lvm.lv=fedora_spectre/root rhgb quiet acpi_backlight=vendor acpi_osi=`!Windows 2013` acpi_osi=`!Windows 2012`"
[root@spectre ~]# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
2. Reboot 2x
FWIW - I did not encounter this on my Lenovo x230. The underlying issue appear to be how Broadwell-based chipsets are recognized.
On the HP forums, folks noted that the backlight parameter was also required. This did appear to be the case for me as well - if I left it out, the sound worked fine but the screen dim/bright control did not.
Hope this helps!
After changing the backticks in Mark's workaround to single quotes, that configuration change did the trick for me - the on-board speakers and microphone in the Spectre 360 are working for me for the first time since I got it.
The two reboots appear to be needed - after the first reboot, the onboard audio still wasn't recognised, but it was there after the second one.
*********** MASS BUG UPDATE **************
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs.
Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23.
If you experience different issues, please open a new bug report for those.
As far as I am currently aware, the workaround Mark listed above is still needed to get audio working on the Spectre 360.
Rechecking that will require removing the workaround, rebooting and seeing if the audio keeps working (so the needinfo flag is still valid).
1) f23 does not have sound
2) went through Mark's steps but changed from backticks to normal apostrophes
3) reboot x2
5) commented out change/re-ran grub2-mkconfig
6) reboot x2
7) no sound!
8) repeat steps 2-4
I can confirm that the following did indeed work for me on a fresh installation of Fedora 23:
1) Fedora 23 has no sound.
2) Appended the following string to the GRUB_CMDLINE_LINUX parameter in /etc/default/grub: acpi_backlight=vendor acpi_osi='!Windows 2013' acpi_osi='!Windows 2012'
3) Note that Mark's string used backticks instead of single quotes and thus did not work.
4) Ran this command as root: grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
5) Rebooted twice.
6) Sound still did not work immediately. I had to open Sound settings and select the newly discovered "Speakers - Built-in Audio" device.
7) Sound works great! Hurray!
Thanks for helping debug this, everyone. I hope this fix will be incorporated into future Fedora updates by default.
Closing this as fixed. Thanks again.
@Nadim - is that a matter of this working by default now, or only with the post-install grub config change?
This problem should be filed against the ACPI component at bugzilla.kernel.org
I'm unclear of the status of this bug - Comment 11, it's been closed current release as of 2016.03.20, which would suggest f23. But sound continues to fail similarly in f24: Bug 1279238
And, re Comment 13, is Redhat refusing this bug against Fedora?
If the former, it should be re-opened re Bug 1279238 and that marked a dup of this.
If the latter, that's a novel position for Redhat to take, could some clarification be given re bug policy - and Bug 1279238 should perhaps be similarly closed?
The reporter chose to close the bug, though the solution referred to is more of a workaround than a fix.
Bastien is saying that this is an upstream bug, so it should be filed (and hence fixed) upstream. There's nothing terribly novel about that, it happens all the time; Fedora has a stated policy that fixes should happen upstream where possible, not by downstream patching.
Note Bug 1350534 reopened
No longer fixed in f28