Description of problem: Dell XPS13 (2015) laptop can use sound in either HDA or I2S mode. In order to use (revert) to HDA mode due to a firmware problem it is required to use ACPI_REV_OVERRIDE on the kernel command line. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
+ The sound is broken on Dell XPS 13 using linux 4.2+ with F23 userspace.
The proper solution here is to update your firmware to revision A05 or newer, this makes the ACPI override unneccesary.
I have had A05 since the day it came out. Sound doesn't work. Sound worked in HDA mode in 4.0 Sound never worked in any version of fedora 4.1 (because REV was changed but the override was not possible) Sound doesn't work in 4.3RC3 There is some hope that sound will work in 4.3 in I2S mode since the codec was included. It seemed to work briefly in the very first 4.3 but hasn't worked in the newer versions.
Created attachment 1079197 [details] oops for 4.3rc?
The oops appears in all the new 4.3 kernels. It shows use of snd_soc_rt286, so by the time 4.3 rolls out it may actually work. I emailed the realtek maintainers on Sept 13 but never got a reply.
I am on A05 as well. 4.1.x works just fine with ASoC operating in HDA mode. After updating to 4.2.x the ASoC gets switched to the I2S which is rather broken. In particular, there is no sound output AT ALL. The good thing is by toggling things in alsamixer the built-in speakers come alive. Surprise, surprise... even the jack detection works! The bad thing is the headphone output producing (a) some constant noticable noise (that does not scale with the volume) and (b) periodic loud clicks of roughly 1 Hz frequency (is the driver polling for something). The audio plays though. The ugly thing is that built-in microphone just does not work at all! As Darrell already said, the 4.3 is just broken at the moment with the driver not loaded at all due to the oops, so we end up with Dummy Output. Not to mention i915 oops and plenty of other errors I see in dmesg.
*** Bug 1267756 has been marked as a duplicate of this bug. ***
@darrell I did a build of 4.2.2 with CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y and the HDA audio is back. The Copr is now building the public version that you can install once it is done https://copr.fedoraproject.org/coprs/godsic/kernel-acpi-rev-override/ To switch from I2S to HDA please follow this steps: 1. Update to kernel-4.2.2-300.xps13.fc23.x86_64 . 2. Reboot. 3. Go to BIOS and switch off the audio. 4. Boot into new kernel. 5. Reboot. 6. Go to BIOS and switch on the audio. 7. Boot into new kernel. 8. Enjoy the audio
Thanks for that. In 4.3 the codec is in place and sound is close to working in I2S mode. Does adding ACPI_REV_OVERRIDE to the kernel command line revert to I2S mode?
As a part of ACPI_REV_OVERRIDE there is a Dell XPS 13 quirk that forces ACPI _REV to 5, i.e.: ACPI: DMI detected: DELL XPS 13 (2015) (force ACPI _REV to 5) In theory providing the ACPI_REV_OVERRIDE-enabled kernel with 'acpi_rev_override=0' should do ACPI _REV = 2 and trigger I2S mode again, but I have not checked yet. Cannot really check 4.3 as well, since it has to much oops.
updated copr to 4.2.3
*** Bug 1268786 has been marked as a duplicate of this bug. ***
Thank for your Copr ! but, the solution is not to patch kernel to provide firmware instead of disable the function ? Best regards.
(In reply to Guillaume Kulakowski from comment #13) > Thank for your Copr ! > > but, the solution is not to patch kernel to provide firmware instead of > disable the function ? > > Best regards. You are welcome. The patch is quite OK actually. I am not really sure why Justin Forbes is so concerned, since by default (with no kernel parameters provide) the patch only affects Dell XPS 13 machines. Indeed it provides one with the freedom to force _REV=2 or _REV=5, but based on the same logic, fedora kernel team should then disable acpi_osi, queued trim and all the other hardware-specific quirks. The proper solution is to allow upstream kernel developers to mature the i2s audio support and in a mean time use a custom build kernel with 'CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y' (I am committed to sync copr with official fedora kernel, since Dell XPS 13 is my main workhorse and, to my specific needs, i915 and iommu are still not OK on 4.2). BTW, the last time I've checked 4.3 (around rc3 or so), the snd_soc_rt286 oopsed... I would guess we need a few more major kernel release before i2s become production-ready.
snd_soc_rt286 does ooops in today's rawhide RC4. I haven't seen a potential fix for it yet. With CONFIG_ACPI_REV_OVERRIDE_POSSIBLE it looks like the behaviour is to get REV 5 (and thus HDA sound) without any kernel parameters. In the current incarnation the kernel parameter doesn't take any arguments. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-parameters.txt#n296 Given that the HDA sound returns without adding command line parameter I'd guess that the sense of the patch needs to be inverted. If you have POSSIBLE then you get HDA and there is no way to get I2S if you want it.
(In reply to darrell pfeifer from comment #15) Indeed, it does not take any parameters. The DMI quirk will force _REV=5 for Dell XPS 13 automatically with no way to fallback to _REV=2. So there are two possible solutions: a) to add support for acpi_rev_override={0 | 1}; b) or better remove Dell XPS 13 specific quirk at all. What Justin expects (or maybe he has some NDA covered information) is Dell adding "Linux" handler to their DSDT, so that ASoC will be in HDA mode irrespective of the reported _REV.
There is a new BIOS version coming out ... soon http://bartongeorge.net/2015/08/28/recent-fixes-for-xps-13-developer-edition/ It would be odd to force HDA mode when I2S seems so close to working.
Well, Dell will most likely not fix their BIOS. So once i2s mode is properly supported by the kernel you are free to switch to fedora's vanilla package. So logically, this bug should be now closed as 'WONTFIX'.
Here is the deal. The CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is a temporary quirk. I2S support should be working and make it unnecessary soon. With F23 being beta, I was hoping we would get if fixed before hand. What I will do, is turn on CONFIG_ACPI_REV_OVERRIDE_POSSIBLE for 4.2.x in Fedora 22 and 23, but leave it off in Rawhide. If people are willing to test the rawhide kernels periodically to see how things are progressing with 4.3 and 4.4 I would really appreciate it.
That's a decent solution since it allows stock Fedora releases to continue to work. I typically use rawhide (well, koji really) so will let you know. You can close this for F23 if you wish. I can wait until after F23 ship to open another if I2S isn't working then.
@justin Is it reasonable to get rid of the https://github.com/torvalds/linux/blob/master/drivers/acpi/blacklist.c#L334-L349 and https://github.com/torvalds/linux/blob/master/drivers/acpi/blacklist.c#L161-L169 to make CONFIG_ACPI_REV_OVERRIDE_POSSIBLE hardware agnostic and then just leave CONFIG_ACPI_REV_OVERRIDE_POSSIBLE enabled forever?
What are your reasons there? I don't see any clear advantage to it.
I am not aware of any issues that _REV=5 might bring to other hardware components, but it would be nice to have a backup solution in case it does.
I feel like I'm a little late to the party here, I had not seen this bug report before. I have some things I can contribute. Firstly, I am using Fedora 23 on my XPS13 (2015). My sound works fine in I2C mode in Kernel version 4.2.0, 4.2.1, and 4.2.2. The only quirk is that the volume needs to be > 50% in order for it to output any sound, the full volume range seems to be mapped to 51-100%. From what I'm reading here, it seems that most other users cannot get sound working at all in 4.2.x kernels. As mine does work, is there anything I can tribute to help others to get theirs working? Secondly, I got the same kernel oops in the 4.3rc series kernels, I debugged the rt286 code myself and sent my findings to Oder Chiou the maintainer for the rl6347a (rt286) soc driver. He sent me a patch which worked to fix the problem, and my sound is now working correctly in 4.3(rc2,rc3 and rc4). I asked Oder Chiou to submit the patch to get it incorporated into the linux kernel for 4.3 release, but unfortunately the patch was not accepted because it was simply a quick hack, and further work needs to be done on the rt286 driver before it can conform to the requirements of the kernel team. Oder send me one more patch to test which further modifies the driver for kernel 4.3rc4, I am unsure about whether that one will be passed by the kernel team. I could post the 4.3.x patches here if people want them, but I guess I should get permission from Oder Chiou first before I do.
@flubbba86 Could you please confirm that headphone output and built-in microphone are both working for you in i2s mode on 4.2.x?
Proposed as a Freeze Exception for 23-final by Fedora user mjg59 using the blocker tracking app because: Breaks audio on XPS13 out of the box, will leave hardware in a confused state for the first reboot into the new kernel which may break the upgrade experience.
Discussed at 2015-10-19 freeze exception review meeting: https://meetbot.fedoraproject.org/fedora-blocker-review/2015-10-19/f23-blocker-review.2015-10-19-16.00.html . This was rejected as a freeze exception issue: it just isn't the right time to be pulling in new kernels (three days before go/no-go, with lots of other stuff going on). If the release is delayed, this could possibly be re-considered.
Still no sound in 4.3RC6 RT286 still oopses on probe Will update for final 4.3 but unless something changes the override may have to continue into 4.3 too.
The oops has nothing to do with rt286: https://bugzilla.kernel.org/show_bug.cgi?id=105251 The rt286 oops is triggered by hid-multitouch, which leads to then rt286 oops if loaded into the initramfs. If you load hid-multitouch later (not in the initramfs!) it doesn't harm. If you compile your kernel without rt286 but leave hid-multitouch in the initramfs you will still get other random oops. You're probably an arch user and you're probably using the mkinitcpio "keyboard" hook. If you don't use dm-crypt you don't need it, while if you do just add MODULES="atkbd.ko usbhid hid-generic" into /etc/mkinitcpio.conf instead of the keyboard hook. Obviously remember to rebuild your initramfs. P.S. With 4.3-rc7 I get only HDMI outputs in i2S mode (even after two cold boots), if you know to get non-HDMI outputs please let me know.
Still no sound in 4.3RC7 RT286 still oopses on probe
Even after removing hid-multitouch from the initramfs? [niko@arch-laptop ~]$ lsmod | grep rt286 snd_soc_rt286 36864 0 snd_soc_rl6347a 16384 1 snd_soc_rt286 snd_soc_core 155648 1 snd_soc_rt286 snd_pcm 86016 7 snd_soc_core,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_soc_rt286,snd_pcm_dmaengine,snd_hda_core i2c_core 49152 12 drm,i915,i2c_i801,elan_i2c,i2c_hid,i2c_designware_platform,drm_kms_helper,i2c_algo_bit,snd_soc_rl6347a,v4l2_common,snd_soc_rt286,videodev [niko@arch-laptop ~]$ uname -a Linux arch-laptop 4.3.0-rc7-mainline #1 SMP PREEMPT Mon Oct 26 13:51:07 CET 2015 x86_64 GNU/Linux [niko@arch-laptop ~]$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: HDMI [HDA Intel HDMI], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: HDMI [HDA Intel HDMI], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: HDMI [HDA Intel HDMI], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0
Still no sound in 4.3 release RT286 still oopses on probe This may become/remain an issue for F24 if kernel 4.3 is included there. I'll keep posting results for kernel 4.4 as they arrive.
I bought mine in October and BIOS reports an A06 version, had some of these issues and after two cold reboots I get the devices shown in the audio properties just fine. Speakers work. What does not work is the headphones, now, they don't work if what I plug into the jack is a mix/combo cable, the ones that have audio channels and also the mic input, if I use one of those (which are the most common) the audio that comes through the headphones sounds bad (music for instance sounds but voice doesn't as if some channels were missing) What I did was to get a different cable, bought one of those that only has three metal sections on the connector instead of four and then it works, the audio jack plays audio just fine through the headphones. So my guess is that the other type of cable (the one with 4 metal sections which IIRC is called "apple-type connector") activates the mic input in the jack which in turns messes up the audio output through the headphones. Not sure if this is related to this bug but I have read just so many bugzilla reports and blogposts about linux and xps 13 audio issues that I'm feeling it is. Anybody on F23 with stock kernel (4.2.6-300 as of the time of writing this) experiences this as well? TLDR; - Had to do the cold boot thing to get the device available - I get audio from the speakers just fine - Headphones don't work with a cable that includes mic input (4 pin) - Headphones work just fine with a cable that doesn't include mic input (3 pin) - I'm on F23 (4.2.6-300) on the xps 13 (9343)
With kernel 4.4-rc1 I finally get WORKING I2S audio on the XPS 13 9343! Please note that I didn't try headphones nor mic.
Weirdest thing happened. I tried again a live image of ubuntu 15.10 yesterday to try the headphones and it worked. Ubuntu uses 4.2 AFAIK. The weird thing is that, after using ubuntu on the live image I rebooted to fedora and voila!, the headphones worked :S Not sure if the driver in ubuntu did something, does the driver changes something on the soundcard firmware? Because I swear it wasn't working until I used the live image, now it works on both fedora and ubuntu (though I only use ubuntu) Again, I received my xps with BIOS version A06. Maybe relevant. Glad I got it working with the vanilla F23 kernel.
BOIS A06 hasn't been released yet as an update, so I'm still on A05 I still don't get sound on 4.4.0-0.rc1.git3.1.fc24.x86_64. That kernel also has some shm problems that cause grief for chrome browser and pulseaudio, so it isn't usable yet. Even after several cold boots, the output is going to a dummy Nov 21 11:37:00 localhost.localdomain kernel: broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> System Pin mapping ok Nov 21 11:37:00 localhost.localdomain kernel: broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload0 Pin mapping ok Nov 21 11:37:00 localhost.localdomain kernel: broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload1 Pin mapping ok Nov 21 11:37:00 localhost.localdomain kernel: broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Loopback Pin mapping ok Nov 21 11:37:00 localhost.localdomain kernel: broadwell-audio broadwell-audio: rt286-aif1 <-> snd-soc-dummy-dai mapping ok Nov 21 11:37:00 localhost.localdomain kernel: input: broadwell-rt286 Headset as /devices/pci0000:00/INT3438:00/broadwell-audio/sound/card1/input17 The dummy problem happened before, when the codec wasn't available but I'm sure it was added to 4.4 Note I'm using stock rawhide kernel with no kernel command line options.
Then maybe the BIOS version is the difference here, I don't know. I went to dell's website and indeed V A06 isn't released as an update but that is what I got. I purchased mine after skylake model was out so I probably have one of the most updated models (like 3 weeks ago)
I did not have sound working at all after upgrading to F23. After reading a few comments above, I did the following and now computer speakers, microphone and headphones all working normally: 1 Rebooted, went to BIOS and turned sound off 2 Rebooted again and allowed a normal start up 3 Rebooted again, went to BIOS and turned sound on 4 Rebooted again, and now everything is working normally BTW - I have A04 BIOS
(In reply to Jim Whitehurst from comment #38) > I did not have sound working at all after upgrading to F23. After reading a > few comments above, I did the following and now computer speakers, > microphone and headphones all working normally: > I assume that if you turn the machine off completely, wait a couple of seconds and turn it back on again, you won't have sound again. I guess that turning it off and on in the firmware settings is just like booting Windows or an older Fedora kernel (fedora 22) - it will properly initialize the hardware, and it will be kept "warm" if you reboot to a current Fedora kernel and keep working. Similarly, if you boot into a current Fedora kernel and then reboot into an older one in which sound works (or Widnows), sound *won't* work until you do a cold boot into a kernel which initializes the audio device properly. I also know that this information is (probably) well known to all kernel people CC'd here (and they probably have a more accurate description for it than I do, I'm not a kernel person), but I'm making this comment because I see many of the commenters in this bug seem to be confused about this issue.
I really don't understand why the engineers chosed to go that way instead of a simple bios switch (hda/i2s).
BIOS A07 was released today. It is still checking for Linux [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored Still no sound with 4.4RC2 The sound device shows up as "Speakers broadwell RT286", not as the "default". There is oops on probe is gone. When playing sound the sound meter moves, so I'm guessing the BIOS has HDA sound connected as default output but is presenting the I2S device. Yes, it would have been very nice if the BIOS just provided a simple checkbox to switch.
I'm still wondering why some people don't have it working. I do now, did nothing but get the usual updates (and booting in the ubuntu live usb) Darell: Do you have the 9343 model?
Gustavo Sound works in the shipping Fedora kernels. They have the config override turned on so that the sound card runs in HDA mode. In the newer kernels the config option is off. The hope was that I2S mode would work in the newer (4.4) kernels and that the flag would not have to be turned on there. I am updating the bug about the status of the newer kernels only. If you run rawhide kernels (as I do) then sound won't work. (This information is contained somewhere above in the bug but you'd have to do a lot of reading)
Oh, snap! It was confusing to me, now I understand, sound in F23 stock kernel does work in HDA, 4.3+ in I2S is the one that does not work yet. Thanks for the update. And if we (owners of these things) can at least push dell to update the BIOS or something to not report the override (or make it optional) count me in, again, I spent $1,200+ on this thing because of its linux support, somebody needs to push dell somehow, at least us, buyers.
The Dell Linux developer version of the machine ships with Ubuntu, so it works there in HDA mode. I doubt they feel much urgency to get it to work in I2S. Fedora is running with non-working sound as the default. Normally I'd expect to run working mode as the default, then move to another mode when it also starts to work. With this scenario there is a maintenance issue because as long as I2S mode doesn't work the kernel folks have to remember to turn on the flag at the last moment before the kernel ships in a standard Fedora release. So there is a standoff here, where Dell will say "Works in Ubuntu (or with the config option)" and Fedora kernel folks saying "Fix your broken BIOS" At this point I know the codec is in 4.4 and that the driver no longer ooopses on probe. It might be worthwhile talking to the sound folks to see if there is a quirk that needs to be added to the driver.
You are right, though not everyone wants to run Ubuntu, hard to explain to Dell definitely... I bought it without doing research on my own as to whether it worked well or not with Linux (which I usually do) only because I assumed that if it worked with ubuntu out of the box it'd support any distro, how wrong was I, as soon as I got it and saw that the broadcom card needed firmware... and then the sound If I can help with anything else let me know. Thanks!
Good news. With some help from Bard Liao at Realtek, it turns out that the ucm files were not installed on my system. dnf install alsa-ucm After a reboot sound works on 4.4.0-0.rc2.git1.1.fc24.x86_64 with broadwell-rt286 audio.
Continues to work on 4.4 Sound folks may want to ensure that alsa-ucm is installed on machines that need it, but kernel works.
@Mykola I don't know how to install the kernel from godsic's copr, do you have some information on how to do that? I updated from F21 to F22 and to F23 and using the old F21 kernel works for me, but the F23 kernel only shows a 'dummy output' sound device. Thanks!
Try the command listed in comment 47. I suspect it will give you sound in F23 too.
@darrel Thanks for pointing that out, but alsa-ucm is already installed and still only a 'dummy audio' device detected under the F23 kernel, while the F21 kernel works. Any other pointer would be helpful.
The sound works with Fedora 23 stock kernel, once Justin triggered the ACPI workaround in 4.2.4-300. So no need to install kernel from my repo anymore. If it does not work, then follow the Comment 38 routine and it will come alive.
@Justin @darrell The sound does not work for me in I2C mode on 4.4. cat <(dmesg | grep -i i2c) <(dmesg | grep -i audio) [ 3.461989] input: DLL0665:01 06CB:76AD Touchpad as /devices/pci0000:00/INT3433:00/i2c-7/i2c-DLL0665:01/0018:06CB:76AD.0002/input/input10 [ 3.462374] hid-multitouch 0018:06CB:76AD.0002: input,hidraw1: I2C HID v1.00 Mouse [DLL0665:01 06CB:76AD] on i2c-DLL0665:01 [ 3.719651] rt286 i2c-INT343A:00: I2C error -121 [ 3.737629] rt286: probe of i2c-INT343A:00 failed with error -121 [ 3.612531] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 3.781918] haswell-pcm-audio haswell-pcm-audio: Direct firmware load for intel/IntcPP01.bin failed with error -2 [ 3.781922] haswell-pcm-audio haswell-pcm-audio: fw image intel/IntcPP01.bin not available(-2) [ 3.782506] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19 [ 3.800384] broadwell-audio broadwell-audio: ASoC: CODEC DAI rt286-aif1 not registered
@Mykola: Please ensure that you've done two cold boots first (*don't* reboot; shutdown and turn back on again.) This is necessary when switching from HDA to I2S sound. I had the exact same error on 4.4 until I did that, and now it works fine.
(In reply to darrell pfeifer from comment #50) > Try the command listed in comment 47. I suspect it will give you sound in > F23 too. I installed alsa-ucm, powered down and started back up several times. Still only a 'dummy audio' device as shown in Gnome. Any hints on how to debug this would help since I am forced to either: reinstall Fedora from scratch (not an option at the moment), or keep living with the old and probably vulnerable F21 kernel (4.1.13-100). To re-iterate: I upgraded from F21 to F22 and that killed the audio (only a dummy device remaining). I then upgraded from F22 to F23 and still had the same problem. Audio works only with the F21 kernel. I can run basic console commands but I am not skilled in troubleshooting problems like these. Any help would be useful, including other people to bother if possible. Thanks!
Provide some information for a start. At the command line, "uname -r". I'm using 4.4.0-1.fc24.x86_64. In my journalctl I see Feb 14 10:46:48 localhost.localdomain kernel: snd_hda_intel 0000:00:03.0: enabling device (0000 -> 0002) Feb 14 10:46:48 localhost.localdomain kernel: snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [ then Feb 14 10:46:48 localhost.localdomain kernel: input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/sound/card0 Feb 14 10:46:48 localhost.localdomain systemd[1]: Activated swap /dev/mapper/fedora-swap. Feb 14 10:46:48 localhost.localdomain systemd[1]: Reached target Swap. Feb 14 10:46:48 localhost.localdomain kernel: input: HDA Intel HDMI HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:03.0/sound/card0 Feb 14 10:46:48 localhost.localdomain kernel: input: HDA Intel HDMI HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:03.0/sound/card0 Feb 14 10:46:48 localhost.localdomain kernel: sst-acpi INT3438:00: DesignWare DMA Controller, 8 channels then Feb 14 10:46:48 localhost.localdomain kernel: haswell-pcm-audio haswell-pcm-audio: Direct firmware load for intel/IntcPP01.bin fa Feb 14 10:46:48 localhost.localdomain kernel: haswell-pcm-audio haswell-pcm-audio: fw image intel/IntcPP01.bin not available(-2) Feb 14 10:46:48 localhost.localdomain kernel: haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, A bit later... Feb 14 10:46:48 localhost.localdomain kernel: broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> System Pin mapping ok Feb 14 10:46:48 localhost.localdomain kernel: broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload0 Pin mapping ok Feb 14 10:46:48 localhost.localdomain kernel: broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Offload1 Pin mapping ok Feb 14 10:46:48 localhost.localdomain kernel: broadwell-audio broadwell-audio: snd-soc-dummy-dai <-> Loopback Pin mapping ok and finally Feb 14 10:46:48 localhost.localdomain kernel: broadwell-audio broadwell-audio: rt286-aif1 <-> snd-soc-dummy-dai mapping ok Feb 14 10:46:48 localhost.localdomain kernel: input: broadwell-rt286 Headset as /devices/pci0000:00/INT3438:00/broadwell-audio/so Your output should look similar. If you install/run pavucontrol an look at the configuration tab you should see one profile for hdmi and another for broadwell-rt286. The hdmi one is often the default (and always seems to show even if the other driver isn't working) A year ago when the laptop first came out, some people also suggested that turning sound off in the BIOS, booting and then rebooting to turn it back on again would sometimes fix the problem.
@darrel, thanks for the reply I upgraded the kernel, but I also lost the old F21 working kernel (now I absolutely have no sound). the output of my lshw is: https://paste.fedoraproject.org/323501/63431714/raw/ uname output: Linux localhost.localdomain 4.3.5-300.fc23.x86_64+debug #1 SMP pavucontrol only shows the dummy audio output and no audio input at all, no hdmi devices etc.
(In reply to Jobava from comment #57) > @darrel, thanks for the reply > > I upgraded the kernel, but I also lost the old F21 working kernel (now I > absolutely have no sound). > > the output of my lshw is: > https://paste.fedoraproject.org/323501/63431714/raw/ > > uname output: > Linux localhost.localdomain 4.3.5-300.fc23.x86_64+debug #1 SMP > > pavucontrol only shows the dummy audio output and no audio input at all, no > hdmi devices etc. Your lshw output says you have an ASRock 960GC-GS FX desktop motherboard, not a Dell XPS 13. Your mobo has a Realtek ALC662 sound chipset that uses HDA audio, so this bug report is not applicable to you. Please file a new bug report.
Nicholas, Darrel, thanks for your assistance. It was indeed the correct bug, having compiled the latest F23 kernel with the CONFIG_ACPI_REV_OVERRIDE_POSSIBLE option did make sound come back after a cold reboot. It's still a workaround for now since the kernel delivered by the package manager does not enable this option for some reason. Is there a specific reason for that? Thanks! Related bug I created earlier: https://bugzilla.redhat.com/show_bug.cgi?id=1308971 Jobava
(In reply to Jobava from comment #59) > Nicholas, Darrel, thanks for your assistance. > > It was indeed the correct bug, having compiled the latest F23 kernel with > the CONFIG_ACPI_REV_OVERRIDE_POSSIBLE option did make sound come back after > a cold reboot. > > It's still a workaround for now since the kernel delivered by the package > manager does not enable this option for some reason. Is there a specific > reason for that? > > Jobava Well, that is truly bizarre. That config option was added solely for the Dell XPS 13 because of its unique sound chip that switches between HDA and I2S output modes based on the ACPI _REV value. The reason it was added was because reporting the standard _REV value would enable I2S output on the XPS 13, which was still fairly buggy on Linux at the time. It was added in kernel 4.2, and Fedora disabled the option in F23 because I2S works fine on 4.4. If it is true that sound breaks on your motherboard because of this option being disabled, then we can conclude one of two things: either there was a regression in sound support for your board since 4.1, or your BIOS functions in a non-standard way. I'd suggest first compiling a 4.1 kernel to see if there was a regression. Also, it may help if you post a dmesg log.
Nicholas, I followed the instructions here: https://fedoraproject.org/wiki/Building_a_custom_kernel#Building_a_Kernel_from_the_Fedora_source_tree I'll need some detailed instructions on how to compile a 4.1 kernel. I could only install a variant of the latest F23 kernel using 'rpm -ivh ... --nodeps' in a simialar manner as the pastebin below (with version numbers changed). it failed because it failed in the manner described here: https://paste.fedoraproject.org/323759/56573421/raw/ Thanks. Jobava
One thing to note, a Fedora 23 liveDVD does have sound, so kernels past 4.1 do work with my sound chip, it was something that happened during the upgrade from F21 to F22 (I subsequently upgraded to F23). Hope that helps. Jobava
Alright, the system update moved me to a higher kernel version and the audio is still there. Now on the 4.4.2-301.fc23.x86_64 kernel.
A lot of people, including me, report that sound on the XPS 13 9343 is not working anymore after the 4.4 kernel update. Also Arch users are affected (I think no other popular, but stable distributions ship 4.4 yet) My maschine: Manufacturer: Dell Inc. Product Name: XPS 13 9343 Version: A07 WiFi changed to Intel card. Linux dell1175 4.4.2-301.fc23.x86_64 #1 SMP Tue Feb 23 19:00:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Therefore I do not consider this issue closed. Anything I can help with?
@Michael Meschenmoser As I was suggested before (see comment 54), please make two cold reboots of the system (via power off/power on cycle). Anyway from the QA point of view the i2s mode is not on par with hda. In particular, - When headphones are attached there is periodic (~1Hz) click sound in the output. I would speculate something pulls for the jack changes in some inappropriate way. The funny thing is that sometimes the speakers does not get muted when headphones are attached. In this case there is no click sound in the output. - The built-in microphone does not work out-of-the-box. To make it work I use pavucontrol to switch back-and-forth between 'Headset Microphone (Unplugged)'<->'Main microphone' until the later works. - For some reason alsa defaults to rather low 'DAC0' level. So one needs to fix it with alsamixer.
I did 5 cold reboots -> no sound, I disabled sound in BIOS, 2 cold boots, enabled sound, 4 cold boots -> no sound GNOME audio settings shows broadwell-rt286. What do you mean by "on par with hda"? - headphone: no clicking/noises -> no sound at all (headphone plugin correctly shows up in GNOME audio settings) - microphone: not audio input shown in GNOME audio settings since 4.4 update - DAC0: how can I debug this? (I never had sound problems before, so I am not familiar with the alsa/pulse tools) Thanks, Regards, Michael
@Michael Meschenmoser Seems like your ASoC already works in i2s mode, but its outputs are not routed correctly. Do you have alsa-ucm package installed?
I just installed it: alsaucm>> listcards 0: DAISY-I2S Daisy internal card 1: GoogleNyan Nyan internal card 2: PAZ00 PAZ00 alc5632 3: PandaBoard 4: PandaBoardES 5: SDP4430 6: tegraalc5632 -- And for reference: cat /proc/asound/cards 0 [HDMI ]: HDA-Intel - HDA Intel HDMI HDA Intel HDMI at 0xf7218000 irq 49 1 [broadwellrt286 ]: broadwell-rt286 - broadwell-rt286 broadwell-rt286 After connecting the Laptop to my TV sound worked on the TV, but after disconnecting sound is still dead on the internal speakers/headphones.
@Michael Meschenmoser Please 1. Open alsamixer in the terminal 2. Press F6 3. Choose 'broadwell-rt286' 4. Check the 'Master' and 'DAC0' levels.
(In reply to Michael Meschenmoser from comment #64) > Also Arch users are affected (I think no other popular, but stable > distributions ship 4.4 yet) Source? I'm an Arch user and in particularly the one who asked to unset CONFIG_ACPI_REV_OVERRIDE_POSSIBLE (https://bugs.archlinux.org/task/47710): it simply works out of the box here. Also I didn't hear any complaint in the wiki: https://wiki.archlinux.org/index.php/Dell_XPS_13_(2015)
@Niccolò Belli This posts read similar to my problem: - https://bbs.archlinux.org/viewtopic.php?id=208461 - https://bbs.archlinux.org/viewtopic.php?id=208433 + Links in comm. 12 I am starting to get the feeling, that there are different 9343 models out there. On some people's maschines it is working, on other maschines it isn't... @Mykola Dvornik Both levels are "100". Still no sound.
After upgrade to kernel-4.4.2-301.fc23.x86_64 the sounds devices on my Dell XPS 13 disappeared. Powering off and restarting into kernel-4.3.5-300.fc23.x86_64 fixed the issue.
By the way I just tested 4.5-rc6 and i2s regressed: aplay -l does no longer show broadwell-rt286. 4.4.1 works flawlessly.
I started a new bug for 4.4. It has been open for a while. I also tried rc6 and can confirm sound doesn't work there. https://bugzilla.redhat.com/show_bug.cgi?id=1308792
(In reply to Mads Villadsen from comment #72) > After upgrade to kernel-4.4.2-301.fc23.x86_64 the sounds devices on my Dell > XPS 13 disappeared. > > Powering off and restarting into kernel-4.3.5-300.fc23.x86_64 fixed the > issue. Same issue with A07 BIOS.
After upgrading to kernel 4.4.2-301.fc23.x86_64 I also had no sound working. However sound came back after applying the settings for alsamixer mentioned in "http://forthescience.org/blog/tag/xps13.html" (almost at the end of the page).
The alsamixer settings from Comment 76 did the trick. -> Working sound with 4.4.2-301.fc23.x86_64 & broadwell-rt268 (1 sec After sound playback stops the headphones are cracking once, but from quick testing no glitches/noises) Seems I didn't try enough settings after Comment 69 pointed out where to search...
Can those who are seeing issues on F23 comment over on https://bugzilla.redhat.com/show_bug.cgi?id=1313434 about what fixed it for you? This bug here is tracking rawhide so it's harder to get information for F23.
The alsamixer settings from Comment 76 also did the trick for me. Model: 2015 Dell XPS 13 (9343) Kernel: 4.4.3-300.fc23.x86_64 Bios: A07 Alsa packages installed: alsa-lib-1.0.29-2.fc23.x86_64 alsa-plugins-pulseaudio-1.0.29-2.fc23.i686 alsa-plugins-pulseaudio-1.0.29-2.fc23.x86_64 alsa-ucm-1.0.29-2.fc23.x86_64 alsa-utils-1.0.29-2.fc23.x86_64 alsa-lib-1.0.29-2.fc23.i686
This bug should be re-opened: sound is broken again in kernel 4.4.
I am having audio issues as of a few weeks ago.
@justin 4.5-rc7: - no sound, only 'Dummy Output' is present - no kernel module loaded to handle the ASoC - seems like the broadwell-specific kernel module is either missing or got renamed
Bug, kernel 4.4: https://bugzilla.redhat.com/show_bug.cgi?id=1313434
The same here. No audio devices, snd-hda driver not loaded automatically, when loaded manually still gives no sound. Same as comment 82 here. Motherboard is Gigabyte z77n-wifi, old enough, no further comments needed. Sure, the problem is not about alsamixer settings. kernel is 4.4.7-300.fc23.x86_64 on Fedora 23 and not Rawhide.
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE only affects the Broadwell 2015 Dell XPS13. If you have any other system, please file a separate bug.
Sorry, my mistake. There IS another bug, but for some reason it linked here...