I get no sound via the speakers of my Lenovo Legion 7i laptop, which alsamixer tells me is using a Realtek ALC287. I have tried various Linux distros and kernel combinations, including Ubuntu 16.04, 18.04, and 20.04, with both the default and mainline kernels (5.7.x & 5.8.x), and Manjaro with 5.6.x, 5.7.x and 5.8.x kernels. In each case, I made sure to disable Auto-Mute in alsamixer, and turn all volume levels to maximum. In all cases, I get no sounds from the speakers (running speaker-test, playing music, etc.). I *am* able to get sound via headphones and HDMI (though I believe HDMI is via a different sound card). Also, I can see that there is some kind of sound activity occurring when I look at pavucontrol (the reddish-orange bar that indicates a sound is playing), but there is no actual sound produced from the speakers. My alsa-info.sh results (from Manjaro on 5.6.15) are here: http://alsa-project.org/db/?f=ba86fe76a9d9cf1cced56600edf82eb206a36a72 I am happy to run the script again (or any other tool) from a different distro/kernel combination, please just let me know what would be helpful.
Update using more recent kernel: http://alsa-project.org/db/?f=4272343a3590cc08f192f98113dedfc0418afe52 In order to provide better information, I have run alsa-info.sh from Ubuntu 20.04 running the latest mainline kernel 5.7.9-050709-generic. I have also updated the "Kernel Version" field in this bug report to reflect this.
I also tried with kernel 5.8.0-050800rc5-generic. Same result, no sound via speakers.
I can confirm, same thing is happening to me, using manjaro with kernel 5.6.19-2-MANJARO
Can confirm here with Kubuntu 20.04 with kernel 5.4.0-40-generic and kernel 5.7.14... Sound works through head phones (using either bluetooth or a analog 3.5 mm cable). I did notice that playback via bluetooth stopped once... After putting the laptop to sleep then waking it back up, audio via bluetooth resumed. I do not know if I am able to get audio via HDMI, I'm unsure how to use that setting (or is an external HDMI monitor needed for that?).
+1 for this on Manjaro with kernel 5.7.14.
Same issue. I tested Manjaro with kernel 5.8.4. Also tested Mint 20 with kernel 5.4.0-42, Ubuntu 20.04, Fedora 32 and PopOS. Working with 3.5mm audio jack, bluetooth and docking station on USB-C.
Is everyone experiencing this on machines other than the Lenovo Legion 7i? Or is everyone on this same machine so far?
Forgot to mentioned it, Legion 7i for me.
Experiencing this issue (no sound on speakers, but headphones and other outputs work fine) on a Legion 7i too on my side, on Fedora 32, kernel 5.8.4-200.fc32.x86_64.
I have the exact same issue on Linux version 5.4.0-47-generic (buildd@lcy01-amd64-014) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)), with Lenovo Legion 7 81YT. I tried the same things as everybody else and could not get these speakers to work. I am a bit confused because some specs I found online for the the Legion 7 mention ALC 3306 -https://psref.lenovo.com/syspool/Sys/PDF/Legion/Lenovo_Legion_7_15IMHg05/Lenovo_Legion_7_15IMHg05_Spec.pdf (could not find any driver related to it) Vs ALC 287 identified by alsamixer. Speakers work just fine on Windows 10.
(In reply to Cameron from comment #7) > Is everyone experiencing this on machines other than the Lenovo Legion 7i? > Or is everyone on this same machine so far? My issues are also present on Legion 7i (Legion 7-15IMH05 Type 81YT). Here is my alsa-info: http://alsa-project.org/db/?f=f74d2b20683de3bc0daab8c4740f34a66955ba70 A notable thing is that i *DID* have speaker audio for a couple of weeks (headphones have always worked), until it suddenly stopped working again. My guess is that there might have been regression due to some package being updated but I could not find any meaningful culprit. I can paste the hidden BIOS HD audio settings for this configuration if that's of any use. Kernel is 5.4.0-47-generic #51-Ubuntu SMP Fri Sep 4 19:50:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Distributor ID: Ubuntu Description: Ubuntu 20.04.1 LTS
(In reply to kernel.org from comment #11) > (In reply to Cameron from comment #7) > > Is everyone experiencing this on machines other than the Lenovo Legion 7i? > > Or is everyone on this same machine so far? > > My issues are also present on Legion 7i (Legion 7-15IMH05 Type 81YT). > > Here is my alsa-info: > http://alsa-project.org/db/?f=f74d2b20683de3bc0daab8c4740f34a66955ba70 > > A notable thing is that i *DID* have speaker audio for a couple of weeks > (headphones have always worked), until it suddenly stopped working again. > My guess is that there might have been regression due to some package being > updated but I could not find any meaningful culprit. > > I can paste the hidden BIOS HD audio settings for this configuration if > that's of any use. > > Kernel is 5.4.0-47-generic #51-Ubuntu SMP Fri Sep 4 19:50:52 UTC 2020 x86_64 > x86_64 x86_64 GNU/Linux > > Distributor ID: Ubuntu > Description: Ubuntu 20.04.1 LTS Do you have any details for the time period that you did have sound? Was it a fresh install of Ubuntu 20.04.1? Did you allow internet updates during install? If you still have the ISO you used, I'd also like to confirm the hash of the file. If we can reproduce it, we'll be a lot closer to a solution.
Also, regarding the advanced BIOS settings, there are several sound modes you switch the laptop into. I tried a few but didn't get anything to work. I'm not very knowledgeable in this area though. Accessing advanced BIOS is documented here: >Advanced BIOS options can be accessed by going into more settings, hold down >Fn and press each key horizontally from q to p, a to l, then z to m, let go of >Fn and press F10. Click save changes and reboot into BIOS. Advanced settings >will now be available. https://wiki.archlinux.org/index.php/Lenovo_Legion_7i
For convenience, here's how to navigate to the audio settings under the advanced BIOS settings: Advanced -> PCH-IO -> HD Audio Configuration I going to attach pictures showing the top level Audio menu. There's quite a bit more settings under the sub-menus though. It's worth mentioning that in my experience that many settings available under the advance BIOS settings do not seem to work. I haven't tried any of the audio settings yet (and there are quite a few), but in general many settings probably only apply to certain models of laptop aside from the Legion 7i. Presumably at least some of the audio settings should work though.
Created attachment 292497 [details] Top half of top level audio level
Created attachment 292499 [details] bottom half of the top level audio menu
About how long have you had your Legion? I've had mine since August 6th IIRC, and I've always had this problem. Could help narrow down the window. Could this be possibly related to a BIOS update? > A notable thing is that i *DID* have speaker audio for a couple of weeks > (headphones have always worked), until it suddenly stopped working again. > My guess is that there might have been regression due to some package being > updated but I could not find any meaningful culprit.
(In reply to Cameron from comment #17) > About how long have you had your Legion? I've had mine since August 6th > IIRC, and I've always had this problem. Could help narrow down the window. > > Could this be possibly related to a BIOS update? > > > A notable thing is that i *DID* have speaker audio for a couple of weeks > > (headphones have always worked), until it suddenly stopped working again. > > My guess is that there might have been regression due to some package being > > updated but I could not find any meaningful culprit. I got mine in the beginning of August. Updated immediately to 2.02 BIOS. I had already prepared for not having sound as I had read the Arch Wiki page, and was really struck with a surprise as one day after playing with merely the ubuntu sound settings (fiddling with system sound volume) the speakers suddenly started working. I did not make any notes of the occasion as I assumed there might have been a recent kernel or some other package update, and did not expect any regressions to occur. But they did a couple of weeks later and that's when I found this ticket for ALC287. What makes tracking this down a bit trickier than just booting with earlier kernel packages is that I have fiddled with both alsa and pulse on the system (e.g. tried different kernel module options for snd-hda-intel) so my working state was never a vanilla install with some updates. I will nevertheless try to get back to a working configuration with some kernel and report back.
I immediately upgraded to 2.02 as well... But tried reverting to the previous version (2.01 probably?) to test something unrelated. That didn't fix my issues. Anyway, might be worth looking at /var/log/dpkg.log* to see what had been installed/updated around that time frame. I've skimmed through and so far the only thing that stands out are some pulse audio updates on July 23rd. So unless you don't update frequently, that's probably not it. > What makes tracking this down a bit trickier than just booting with earlier > kernel packages is that I have fiddled with both alsa and pulse on the > system (e.g. tried different kernel module options for snd-hda-intel) so my > working state was never a vanilla install with some updates. I will > nevertheless try to get back to a working configuration with some kernel and > report back.
I'm having the same issue on a Lenovo Legion 7-15IMHg05. I just got it this week (22nd september) and installed Arch Linux on it straight away. I tried fiddling with alsamixer and pavucontrol settings, no change. I tried different kernel packages (linux 5.8.10, linux-lts 5.4.66, linux-xanmod 5.8.10/11), no dice. I did not update the BIOS yet and the current version is "E9CN32WW(V2.00)", so this probably rules out a BIOS regression. My alsa-info: http://alsa-project.org/db/?f=60beb004225ca38c49bb6a1495e6cd713a1a4f1e I did not test the laptop with Windows yet, but I will try to do this soon.
Perhaps there is a way to force ALSA to recognize the card as an ALC3306. As Fab mentioned, the specs do seem to indicate that as the sound device.
Did you find this in the documentation? I haven't found any references to ALC3306 on my system Doing a quick search for ALC3306, the only references that come up are for the Lenovo Legion 7 and the Yoga Slim 7. The ALC3306 seems to be pretty uncommon and pretty new. Doing a bit of research, sounds like audio works on the Yoga Slim 7. Possibly a red herring..? On 9/25/20 7:38 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #21 from pyronavi@gmail.com --- > Perhaps there is a way to force ALSA to recognize the card as an ALC3306. As > Fab mentioned, the specs do seem to indicate that as the sound device. >
(In reply to Cameron from comment #22) > Did you find this in the documentation? I haven't found any references > to ALC3306 on my system > > Doing a quick search for ALC3306, the only references that come up are > for the Lenovo Legion 7 and the Yoga Slim 7. The ALC3306 seems to be > pretty uncommon and pretty new. > > Doing a bit of research, sounds like audio works on the Yoga Slim 7. > Possibly a red herring..? > > On 9/25/20 7:38 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #21 from pyronavi@gmail.com --- > > Perhaps there is a way to force ALSA to recognize the card as an ALC3306. > As > > Fab mentioned, the specs do seem to indicate that as the sound device. > > My mistake. I must have seen "Legion 7" and mistaken it for the 7i. Also, I have just sent an email to the members of the ALSA team. Hopefully someone will reply soon.
> I did not test the laptop with Windows yet, but I will try to do this soon. Tested now, it works fine on Windows. I also updated the bios to E9CN58WW(V4.03), still doesn't work on Linux.
I think the 7 and 7i are the same. In the case of the Legion 5/5i, the i differentiates between the AMD and Intel versions. However, I believe there's still no plans to make an AMD version of the Legion 7. My point was that sound seems to work on the Yoga 7 under Linux, which also has the ALC3306 so maybe it's not related to the ALC3306 codec. On 9/26/2020 7:43 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > My mistake. I must have seen "Legion 7" and mistaken it for the 7i.
I am having same issue with Lenovo Legion 7. Another friend that use the same laptop also having that problem too. I hope they can fix this issue.
I am also facing same issue on Ubuntu 20.04 with Legion 7i. Never worked on Linux. Alsa info http://alsa-project.org/db/?f=286348226d62d73c2aa3987794adfde7ef78095e Linux archy-Lenovo-Legion-7-15IMHg05 5.9.2-050902-generic #202010290646 SMP Thu Oct 29 11:11:09 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
have same problem. yoga 7i. have tried numerous kernels and distros.
I can confirm that the same problem is happening on Ubuntu 18.04 with Lenovo Legion 7, I would be really grateful for the fix.
Kubuntu 20.10 still has the same problem. Both with the vendor kernel, 5.8.18, and through 5.9.9.
Tried on Pop_OS! with kernel 5.8.0 with same result. Is there anything we can do to help for this to be prioritized? I really want to get rid of that awful windows partition :/
I'm abount to buy a Legion 7 but this problem worries me a bit. Any chance to have audio on Linux?
(In reply to gorghino from comment #32) > I'm abount to buy a Legion 7 but this problem worries me a bit. Any chance > to have audio on Linux? If Linux is important to you, I would absolutely avoid this laptop. There seems to be zero interest in having this issue fixed I'm afraid.
(In reply to Cameron from comment #33) > (In reply to gorghino from comment #32) > > I'm abount to buy a Legion 7 but this problem worries me a bit. Any chance > > to have audio on Linux? > > If Linux is important to you, I would absolutely avoid this laptop. There > seems to be zero interest in having this issue fixed I'm afraid. Well, the bug has been assigned to Jaroslav Kysela even if it's still not critical (are we too few?). Did you try to contact him for debugging? Here(https://unix.stackexchange.com/questions/611530/how-can-i-get-my-unsupported-sound-card-to-work-with-alsa) and here (https://www.alsa-project.org/wiki/Help_To_Debug_Intel_HDA) there are some hints to start debugging the codec. I'd do it myself but I haven't bought it (yet? :D)
Plus, are you sure that the Legion 7 15IMHg05 works with ALC287? PSREF from Lenovo website reports ALC3306 that is actually missing in sound/pci/hda/patch_realtek.c
I came across this today: https://github.com/alsa-project/alsa-lib/issues/76 The last posts suggests that "amplifier chips for the integrated speakers" might be in use here which need to potentially initialized. That could explain why 3.5mm and bluetooth audio work: They don't need any such initialization.
I guess perexg is Jaroslav Kysela though. (His email is perex[at]perex.cz) :) @perex Any progress so far? I emailed kailang[at]realtek.com who actively commits on the kernel mainline with realtek updates.
Same problem for me on Legion 7i with Manjaro.
Same here. No Audio from the speakers. I've tried multiple distros and upgrading to the latest 5.10 kernel. I'm using Lenovo Yoga Duet 7i
Same here, Ubuntu 18.04, Lenovo Legion 7i, kernel v5.3, sound chip Realtek ACL287
Ubuntu 20.04, Legion 7i, the same issue with no sound from speakers
I left Ubuntu for ArcoLinux and sound works. I installed their LTS Linux kernel and Intel microcode and sound came out of the left speaker only. Then, Lenovo pushed a firmware update this morning and sound works in both speakers. I don't know why an Arch fresh install works but the "easy windows conversion Linux OS" doesn't.
Guys, don't spam me (e-mail). I don't have the detailed information about your hardware and it seems that the hardware vendors are using the amplifier chips for the integrated speakers on recent hardware which must be initialized, too. The linux support depends on the BIOS initialization (if any) at the moment. The HDA codec setup in first comments for Legion 7i looks fine, but Realtek use many hidden (undocumented) registers to set some configuration parameters and may be some other chips (amplifiers) behind. Contact Lenovo, if you can, for help (BIOS - Linux support). They are supporting more the non-gaming hardware in Linux (ThinkPad/ThinkStation series). Also, adding David Ober from Lenovo to Cc.
(In reply to darnellkeithj from comment #42) > I left Ubuntu for ArcoLinux and sound works. I installed their LTS Linux > kernel and Intel microcode and sound came out of the left speaker only. > Then, Lenovo pushed a firmware update this morning and sound works in both > speakers. I don't know why an Arch fresh install works but the "easy windows > conversion Linux OS" doesn't. I downloaded the latest ISO and running it from USB with the latest BIOS update, sound still doesn't work at all for me. But maybe that's because their live image doesn't have the latest LTS kernel, firmware, microcode, etc? With the latest BIOS, sound still doesn't for me under Kubuntu 20.10.
Seems the latest BIOS (E9CN60WW/v4.05) broke sound completely. I couldn't even get audio over my bluetooth speaker. Reverting back fixed it for me, however.
(In reply to Cameron from comment #44) > (In reply to darnellkeithj from comment #42) > > I left Ubuntu for ArcoLinux and sound works. I installed their LTS Linux > > kernel and Intel microcode and sound came out of the left speaker only. > > Then, Lenovo pushed a firmware update this morning and sound works in both > > speakers. I don't know why an Arch fresh install works but the "easy > windows > > conversion Linux OS" doesn't. > > I downloaded the latest ISO and running it from USB with the latest BIOS > update, sound still doesn't work at all for me. But maybe that's because > their live image doesn't have the latest LTS kernel, firmware, microcode, > etc? > > With the latest BIOS, sound still doesn't for me under Kubuntu 20.10. I can confirm that if you "install" or dual boot Arcolinux that sound will work. I just did a reinstall not less than an hour ago. Sound doesn't work from the live USB but will work if you install Arcolinux with the LTS kernel. However, I'm using the Yoga Duet 7i.
(In reply to darnellkeithj from comment #46) > (In reply to Cameron from comment #44) > > (In reply to darnellkeithj from comment #42) > > > I left Ubuntu for ArcoLinux and sound works. I installed their LTS Linux > > > kernel and Intel microcode and sound came out of the left speaker only. > > > Then, Lenovo pushed a firmware update this morning and sound works in > both > > > speakers. I don't know why an Arch fresh install works but the "easy > > windows > > > conversion Linux OS" doesn't. > > > > I downloaded the latest ISO and running it from USB with the latest BIOS > > update, sound still doesn't work at all for me. But maybe that's because > > their live image doesn't have the latest LTS kernel, firmware, microcode, > > etc? > > > > With the latest BIOS, sound still doesn't for me under Kubuntu 20.10. > > I can confirm that if you "install" or dual boot Arcolinux that sound will > work. I just did a reinstall not less than an hour ago to make sure. Sound > doesn't work from the live USB but will work if you install to hardware "with > the LTS kernel". I'm using the Yoga Duet 7i and I don't know what the difference is between the LTS Kernel with Arch and Ubuntu's LTS version - but devs should be able to tell us pretty quickly.
On a related note, can you share the output of "uname -r"? On 12/20/20 5:55 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #47 from darnellkeithj@gmail.com --- > (In reply to darnellkeithj from comment #46) >> (In reply to Cameron from comment #44) >>> (In reply to darnellkeithj from comment #42) >>>> I left Ubuntu for ArcoLinux and sound works. I installed their LTS Linux >>>> kernel and Intel microcode and sound came out of the left speaker only. >>>> Then, Lenovo pushed a firmware update this morning and sound works in >> both >>>> speakers. I don't know why an Arch fresh install works but the "easy >>> windows >>>> conversion Linux OS" doesn't. >>> I downloaded the latest ISO and running it from USB with the latest BIOS >>> update, sound still doesn't work at all for me. But maybe that's because >>> their live image doesn't have the latest LTS kernel, firmware, microcode, >>> etc? >>> >>> With the latest BIOS, sound still doesn't for me under Kubuntu 20.10. >> I can confirm that if you "install" or dual boot Arcolinux that sound will >> work. I just did a reinstall not less than an hour ago to make sure. Sound >> doesn't work from the live USB but will work if you install to hardware >> "with >> the LTS kernel". > I'm using the Yoga Duet 7i and I don't know what the difference is between > the > LTS Kernel with Arch and Ubuntu's LTS version - but devs should be able to > tell > us pretty quickly. >
(In reply to Cameron from comment #48) > On a related note, can you share the output of "uname -r"? > > On 12/20/20 5:55 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #47 from darnellkeithj@gmail.com --- > > (In reply to darnellkeithj from comment #46) > >> (In reply to Cameron from comment #44) > >>> (In reply to darnellkeithj from comment #42) > >>>> I left Ubuntu for ArcoLinux and sound works. I installed their LTS Linux > >>>> kernel and Intel microcode and sound came out of the left speaker only. > >>>> Then, Lenovo pushed a firmware update this morning and sound works in > >> both > >>>> speakers. I don't know why an Arch fresh install works but the "easy > >>> windows > >>>> conversion Linux OS" doesn't. > >>> I downloaded the latest ISO and running it from USB with the latest BIOS > >>> update, sound still doesn't work at all for me. But maybe that's because > >>> their live image doesn't have the latest LTS kernel, firmware, microcode, > >>> etc? > >>> > >>> With the latest BIOS, sound still doesn't for me under Kubuntu 20.10. > >> I can confirm that if you "install" or dual boot Arcolinux that sound will > >> work. I just did a reinstall not less than an hour ago to make sure. Sound > >> doesn't work from the live USB but will work if you install to hardware > >> "with > >> the LTS kernel". > > I'm using the Yoga Duet 7i and I don't know what the difference is between > > the > > LTS Kernel with Arch and Ubuntu's LTS version - but devs should be able to > > tell > > us pretty quickly. > > 5.4.84-1-lts
Same thing here on my 2 yo Legion Y730. Sound-wise everything worked fine for 18 month when i was running ubuntu 18.10, then still good on 20.04.1 for a few weeks and about three weeks ago internal speakers stopped working (but sound works fine on headphones or bluetooth). My kernel is 5.4.0-58 and sound chip Realtek ALC298. Bios version : 8XCN24WW(V1.07)
Created attachment 294325 [details] attachment-14871-0.html I am on Holiday and will be returning on Jan 4 2021
I have had the same problem since I got this laptop in late November. It is a Yoga 7i. I am on Ubuntu 20.10 with kernel 5.8.0.29. I have tried 5.9.10 and 5.9.12 mainline kernels. Everything appears "normal" except the sound just isn't coming out of the speakers. It registers the card, shows up in pavucontrol as expected. The sound output indicator even shows as if audio is playing. I have dabbled with development of kernel modules in the past, but know nothing about audio codecs. Let me know if you need any help from someone with the hardware and kernel experience. It sounds like you may already know the culprit, but that it is not fixable without some specs.
Any updates so far? There are several users who have the laptops with no-speaker-sound and a ready to help with hardware info if needed. Either Lenovo provided laptops for testing or the solution search is stuck Please provide the approximate ETA
Joining the party. Just got Lenovo Legion 7i 15 w/ Realtek ALC287, speakers do not work. Very glad I found this thread -- I have tried so many things at this point. I'm able to use my headphones at least. Do we have any solutions ? Or updates?
Yay so glad I found this after all the stuff I tried before (documented here: https://forums.fedoraforum.org/showthread.php?325363-Lenovo-Thinkbook-no-sound-over-speakers-with-Fedora-33/page1). Mine is a Thinkbook 13s with a Tiger Lake chip and High Definition (HD) Audio, Realtek® ALC3306 codec according to the spec sheet (https://psref.lenovo.com/syspool/Sys/PDF/ThinkBook/ThinkBook_13s_G2_ITL/ThinkBook_13s_G2_ITL_Spec.PDF). Same problem the built in speakers have no sound output even though the headphones and HDMI output sound just fine. I even tried the latest vanilla kernel: 5.11.0-0.rc2.20210108gitf5e6c330254a.119.vanilla.1.fc33.x86_64 but still no sound from the speakers.
Lastest LTS Kernel 5.4.89 breaks ACL287 on Lenovo Yoga Duet 7i. Until now, the only distro and kernel I've found to work with this model is Arch Linux, ArcoLinux to be specific, and 5.4.88-1-lts. I'm assuming this should also work for Legion 7i too.
The same problem with Lenovo Legion 7 15IMH05 (ALC287). Any updates?
Yoga 7i with alc287 audio, Ubuntu 20.04, latest stable kernel 5.10.7, no sound, same problem.
Same issue, 4 users in our company are getting these, tried Ubuntu and Arch with latest kernel. No joy. We can work around for now.
Same issue here. Ubuntu 20.04 on Legion 7i 15IMH05. http://alsa-project.org/db/?f=67c03acf4f5a5f3fd4da996c6955f79f0d4734b8
Also confirmed that yoga 7i 15inch with ubuntu 20.04 lts, 5.8.0 kernel has no sound as well.
Are there any updates? Cause, as I see, the issue appears to be not only 7i Legion notebooks and there are no updates for almost 7 month
(In reply to Max from comment #62) > Are there any updates? Cause, as I see, the issue appears to be not only 7i > Legion notebooks and there are no updates for almost 7 month Hi, I an curious too, as these models don't look like some rare model it seems. And I don't know why hasn't there be any solution nor updates yet, sadly alas.
I want to reiterate my offer from an earlier comment to assist in any way to fix this. Even give me hints at what source file and general changes would be required may be enough. I can check it out and do some trial'n'error.
Created attachment 295069 [details] attachment-20930-0.html I think it was mentioned earlier that the sound chip uses some bits to enable the amplifier section. Bluetooth and the headphone jack are unaffected. You would have to probe the chip to find what bits have been turned on in Windows to make the same changes in the linux driver. On Thu, Feb 4, 2021 at 11:34 AM <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #64 from Brian Long (brian@yateslong.us) --- > I want to reiterate my offer from an earlier comment to assist in any way > to > fix this. Even give me hints at what source file and general changes > would be > required may be enough. I can check it out and do some trial'n'error. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
This link (https://www.kernel.org/doc/html/v5.8/sound/alsa-configuration.html#module-snd-hda-inte) says the following: If the default configuration doesn’t work and one of the above matches with your device, report it together with alsa-info.sh output (with --no-upload option) to kernel bugzilla or alsa-devel ML (see the section Links and Addresses). Has anyone sent this to the alsa-devel mailing list?
There has been some kernel fixes for ALC287 codec and Lenovo in December 2020 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c72b9bfe0f914639cc475585f45722a3eb57a56d). It looks like the author Hui Wang <hui.wang@canonical.com> has experience with HDA codecs: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=Hui+Wang Maybe he's the one to help us out investigating this bug.
(In reply to TT from comment #67) > There has been some kernel fixes for ALC287 codec and Lenovo in December 2020 > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=c72b9bfe0f914639cc475585f45722a3eb57a56d). > > > It looks like the author Hui Wang <hui.wang@canonical.com> has experience > with HDA codecs: > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/ > ?qt=author&q=Hui+Wang > > > Maybe he's the one to help us out investigating this bug. I saw those fixes from Hui back when I was trying out different kernel versions in Dec. I feel he would ultimately fix this issue in time. But time has gone on a bit too long. So I wanted to see if it was more of lacking sample hardware that might be holding it back. I see that the change is probably just a couple lines in this file: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/pci/hda/patch_realtek.c?h=v5.10.13. I just need to know the pins/values to try. There are Thinkpad C940 quirks and the HP ALC287 quirk. This one is different, but they serve as a good template. Now, where do I get those pins? My system is dual boot, so I can go into Windows. Is there a tool I can run to enumerate possible pins/values? Or do I reuse ones I am seeing here with subtle logic guesses?
So which pins are you specifically talking about? What about comparing to the Arch Linux configuration? People mentioned here that the sound works with Arch Linux fresh installation.
(In reply to TT from comment #69) > So which pins are you specifically talking about? > > What about comparing to the Arch Linux configuration? > People mentioned here that the sound works with Arch Linux fresh > installation. I tried Arch Linux fresh installation + Lenovo Legion 7 15IMH05 and speakers don't work.
(In reply to Grigory Malivenko from comment #70) > (In reply to TT from comment #69) > > So which pins are you specifically talking about? > > > > What about comparing to the Arch Linux configuration? > > People mentioned here that the sound works with Arch Linux fresh > > installation. > > I tried Arch Linux fresh installation + Lenovo Legion 7 15IMH05 and speakers > don't work. On my system, the Lenovo Yoga Duet 7i, volume doesn't work out of the box. I've not found any arch systems that have sound working out of the box. You must use earlier an earlier LTS kernel "5.4.88-1-lts". Upgrading to 5.4.89-1-lts and newer will break sound again. I'm not sure why this is such a big deal now since I've mentioned this. Devs could just use whatever works in 5.4.88 LTS and add it to newer kernels. Or tell us how to do it and I'll try myself.
Vanilla 5.4.88 doesn't resolve the issue, at least not for me on Kubuntu 20.10. Earlier 5.4 kernels that I've tested in the past have not fixed the issue. I'm not really familiar with Arch... but if I can find the Arch patchset for 5.4.88, I'll try it out and report back. On 2/7/21 10:31 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #71 from darnellkeithj@gmail.com --- > (In reply to Grigory Malivenko from comment #70) >> (In reply to TT from comment #69) >>> So which pins are you specifically talking about? >>> >>> What about comparing to the Arch Linux configuration? >>> People mentioned here that the sound works with Arch Linux fresh >>> installation. >> I tried Arch Linux fresh installation + Lenovo Legion 7 15IMH05 and speakers >> don't work. > On my system, the Lenovo Yoga Duet 7i, volume doesn't work out of the box. > I've > not found any arch systems that have sound working out of the box. You must > use > earlier an earlier LTS kernel "5.4.88-1-lts". Upgrading to 5.4.89-1-lts and > newer will break sound again. I'm not sure why this is such a big deal now > since I've mentioned this. Devs could just use whatever works in 5.4.88 LTS > and > add it to newer kernels. Or tell us how to do it and I'll try myself. >
(In reply to Cameron from comment #72) > Vanilla 5.4.88 doesn't resolve the issue, at least not for me on Kubuntu > 20.10. Earlier 5.4 kernels that I've tested in the past have not fixed > the issue. > > I'm not really familiar with Arch... but if I can find the Arch patchset > for 5.4.88, I'll try it out and report back. > > On 2/7/21 10:31 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #71 from darnellkeithj@gmail.com --- > > (In reply to Grigory Malivenko from comment #70) > >> (In reply to TT from comment #69) > >>> So which pins are you specifically talking about? > >>> > >>> What about comparing to the Arch Linux configuration? > >>> People mentioned here that the sound works with Arch Linux fresh > >>> installation. > >> I tried Arch Linux fresh installation + Lenovo Legion 7 15IMH05 and > speakers > >> don't work. > > On my system, the Lenovo Yoga Duet 7i, volume doesn't work out of the box. > > I've > > not found any arch systems that have sound working out of the box. You must > > use > > earlier an earlier LTS kernel "5.4.88-1-lts". Upgrading to 5.4.89-1-lts and > > newer will break sound again. I'm not sure why this is such a big deal now > > since I've mentioned this. Devs could just use whatever works in 5.4.88 LTS > > and > > add it to newer kernels. Or tell us how to do it and I'll try myself. > > Then there must be some other differences with sound for the Legion 7i and the Yoga Duet 7i. Try removing sof-firmware and make sure it isn't muted in pavucontrol
I used the arch patches and kernel config to build the exact equivalent of 5.4.88-1-lts. This did not fix anything as expected as the 3 Arch patches were all unrelated to audio/alsa so this is not a surprise (one was to the documentation). Of course, I checked pavucontrol, alsamixer, etc. Made sure nothing was muted, played with the volumes in case it would "unstick" anything. Either there are some differences between Yoga Duet 7i and the Lenovo Legion 7i and/or there's some important userspace differences. I suspect the former. But even if the Duet 7i has its sound issues addressed first, this could potentially go a long way towards helping to figure out what the Legion 7i needs. Can someone with a Duet confirm that vanilla 5.4.88 works and 5.4.89 does not? If so, bisecting should narrow down the issue. On 2/7/21 12:52 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #73 from darnellkeithj@gmail.com --- > (In reply to Cameron from comment #72) >> Vanilla 5.4.88 doesn't resolve the issue, at least not for me on Kubuntu >> 20.10. Earlier 5.4 kernels that I've tested in the past have not fixed >> the issue. >> >> I'm not really familiar with Arch... but if I can find the Arch patchset >> for 5.4.88, I'll try it out and report back. >> >> On 2/7/21 10:31 AM, bugzilla-daemon@bugzilla.kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #71 from darnellkeithj@gmail.com --- >>> (In reply to Grigory Malivenko from comment #70) >>>> (In reply to TT from comment #69) >>>>> So which pins are you specifically talking about? >>>>> >>>>> What about comparing to the Arch Linux configuration? >>>>> People mentioned here that the sound works with Arch Linux fresh >>>>> installation. >>>> I tried Arch Linux fresh installation + Lenovo Legion 7 15IMH05 and >> speakers >>>> don't work. >>> On my system, the Lenovo Yoga Duet 7i, volume doesn't work out of the box. >>> I've >>> not found any arch systems that have sound working out of the box. You must >>> use >>> earlier an earlier LTS kernel "5.4.88-1-lts". Upgrading to 5.4.89-1-lts and >>> newer will break sound again. I'm not sure why this is such a big deal now >>> since I've mentioned this. Devs could just use whatever works in 5.4.88 LTS >>> and >>> add it to newer kernels. Or tell us how to do it and I'll try myself. >>> > Then there must be some other differences with sound for the Legion 7i and > the > Yoga Duet 7i. Try removing sof-firmware and make sure it isn't muted in > pavucontrol >
What is the codec of the yoga duet 7i? Is it also Realtek ALC287? -Thiago > On Feb 7, 2021, at 3:20 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #74 from Cameron (cam@neo-zeon.de) --- > I used the arch patches and kernel config to build the exact equivalent > of 5.4.88-1-lts. This did not fix anything as expected as the 3 Arch > patches were all unrelated to audio/alsa so this is not a surprise (one > was to the documentation). Of course, I checked pavucontrol, alsamixer, > etc. Made sure nothing was muted, played with the volumes in case it > would "unstick" anything. > > Either there are some differences between Yoga Duet 7i and the Lenovo > Legion 7i and/or there's some important userspace differences. I suspect > the former. But even if the Duet 7i has its sound issues addressed > first, this could potentially go a long way towards helping to figure > out what the Legion 7i needs. Can someone with a Duet confirm that > vanilla 5.4.88 works and 5.4.89 does not? If so, bisecting should narrow > down the issue. > >> On 2/7/21 12:52 PM, bugzilla-daemon@bugzilla.kernel.org wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >> >> --- Comment #73 from darnellkeithj@gmail.com --- >> (In reply to Cameron from comment #72) >>> Vanilla 5.4.88 doesn't resolve the issue, at least not for me on Kubuntu >>> 20.10. Earlier 5.4 kernels that I've tested in the past have not fixed >>> the issue. >>> >>> I'm not really familiar with Arch... but if I can find the Arch patchset >>> for 5.4.88, I'll try it out and report back. >>> >>> On 2/7/21 10:31 AM, bugzilla-daemon@bugzilla.kernel.org wrote: >>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>>> >>>> --- Comment #71 from darnellkeithj@gmail.com --- >>>> (In reply to Grigory Malivenko from comment #70) >>>>> (In reply to TT from comment #69) >>>>>> So which pins are you specifically talking about? >>>>>> >>>>>> What about comparing to the Arch Linux configuration? >>>>>> People mentioned here that the sound works with Arch Linux fresh >>>>>> installation. >>>>> I tried Arch Linux fresh installation + Lenovo Legion 7 15IMH05 and >>> speakers >>>>> don't work. >>>> On my system, the Lenovo Yoga Duet 7i, volume doesn't work out of the box. >>>> I've >>>> not found any arch systems that have sound working out of the box. You >>>> must >>>> use >>>> earlier an earlier LTS kernel "5.4.88-1-lts". Upgrading to 5.4.89-1-lts >>>> and >>>> newer will break sound again. I'm not sure why this is such a big deal now >>>> since I've mentioned this. Devs could just use whatever works in 5.4.88 >>>> LTS >>>> and >>>> add it to newer kernels. Or tell us how to do it and I'll try myself. >>>> >> Then there must be some other differences with sound for the Legion 7i and >> the >> Yoga Duet 7i. Try removing sof-firmware and make sure it isn't muted in >> pavucontrol >> > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
Sound works partially with updated fedora 33 on Yoga slim 7i 15 (Yoga Slim 7-15ITL05) https://github.com/alsa-project/alsa-ucm-conf/issues/83
(In reply to Jaroslav Kysela from comment #43) > Contact Lenovo, if you can, for help (BIOS - Linux support). They are > supporting more the non-gaming hardware in Linux (ThinkPad/ThinkStation > series). I don't think there is much help to expect from Lenovo. I contacted support and after a detailed email explaining the issue on my dual boot Win/Linux system I got this: "Thank you for your E-Mail. I will gladly help you. Our devices are all tested to work with only windows, and no other OS. If you have any other questions, I will gladly answer them." Good that he will "gladly help me"... ;-) I have a Legion 7i running Ubuntu 20.04 default kernel. If I would have knew this issue before I would have probably bought another laptop.
(In reply to Jim33 from comment #77) > (In reply to Jaroslav Kysela from comment #43) > > > Contact Lenovo, if you can, for help (BIOS - Linux support). They are > > supporting more the non-gaming hardware in Linux (ThinkPad/ThinkStation > > series). > > I don't think there is much help to expect from Lenovo. I contacted support > and after a detailed email explaining the issue on my dual boot Win/Linux > system I got this: > > "Thank you for your E-Mail. I will gladly help you. > Our devices are all tested to work with only windows, and no other OS. > If you have any other questions, I will gladly answer them." > > Good that he will "gladly help me"... ;-) > > I have a Legion 7i running Ubuntu 20.04 default kernel. > If I would have knew this issue before I would have probably bought another > laptop. There needs to be a push by the linux community and possible litigation to force companies to provide documentation
Alas, I doubt litigation is on the table. I also absolutely would not have purchased this laptop had I known sound support would have been an issue in Linux (or at least returned it within the first 30 days had I known 6 months later this would still be ongoing). I received mine back in August... Now I'm starting to eye new laptops already because I don't have any sound. However, now I'm also concerned that comparatively spec'ed laptops may also have sound issues potentially due to amplifier sound chips that could result in the same problem. At some point in the near future, I may resort to purchasing new laptops and returning them within 30 days if there are any issues under Linux, because I simply can't assume they'll be addressed. Lenovo not wanting to put any developer time into drivers doesn't necessarily mean they're refusing documentation. Perhaps a code bounty could work? I'd be willing to donate to that cause. On 2/14/21 2:20 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #78 from darnellkeithj@gmail.com --- > (In reply to Jim33 from comment #77) >> (In reply to Jaroslav Kysela from comment #43) >> >>> Contact Lenovo, if you can, for help (BIOS - Linux support). They are >>> supporting more the non-gaming hardware in Linux (ThinkPad/ThinkStation >>> series). >> I don't think there is much help to expect from Lenovo. I contacted support >> and after a detailed email explaining the issue on my dual boot Win/Linux >> system I got this: >> >> "Thank you for your E-Mail. I will gladly help you. >> Our devices are all tested to work with only windows, and no other OS. >> If you have any other questions, I will gladly answer them." >> >> Good that he will "gladly help me"... ;-) >> >> I have a Legion 7i running Ubuntu 20.04 default kernel. >> If I would have knew this issue before I would have probably bought another >> laptop. > There needs to be a push by the linux community and possible litigation to > force companies to provide documentation >
(In reply to Cameron from comment #79) > Alas, I doubt litigation is on the table. > > I also absolutely would not have purchased this laptop had I known sound > support would have been an issue in Linux (or at least returned it > within the first 30 days had I known 6 months later this would still be > ongoing). I received mine back in August... Now I'm starting to eye new > laptops already because I don't have any sound. However, now I'm also > concerned that comparatively spec'ed laptops may also have sound issues > potentially due to amplifier sound chips that could result in the same > problem. > > At some point in the near future, I may resort to purchasing new laptops > and returning them within 30 days if there are any issues under Linux, > because I simply can't assume they'll be addressed. > > Lenovo not wanting to put any developer time into drivers doesn't > necessarily mean they're refusing documentation. Perhaps a code bounty > could work? I'd be willing to donate to that cause. > > On 2/14/21 2:20 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #78 from darnellkeithj@gmail.com --- > > (In reply to Jim33 from comment #77) > >> (In reply to Jaroslav Kysela from comment #43) > >> > >>> Contact Lenovo, if you can, for help (BIOS - Linux support). They are > >>> supporting more the non-gaming hardware in Linux (ThinkPad/ThinkStation > >>> series). > >> I don't think there is much help to expect from Lenovo. I contacted > support > >> and after a detailed email explaining the issue on my dual boot Win/Linux > >> system I got this: > >> > >> "Thank you for your E-Mail. I will gladly help you. > >> Our devices are all tested to work with only windows, and no other OS. > >> If you have any other questions, I will gladly answer them." > >> > >> Good that he will "gladly help me"... ;-) > >> > >> I have a Legion 7i running Ubuntu 20.04 default kernel. > >> If I would have knew this issue before I would have probably bought > another > >> laptop. > > There needs to be a push by the linux community and possible litigation to > > force companies to provide documentation > > Do try to install Archlinux and use the kernel https://gitlab.com/manfromva/manfromva/-/tree/master/Kernels I have a Duet 7i with the same sound system and I currently have sound. It didn't work for me on endeavoros but works with Arcolinux and Garuda so far.
(In reply to darnellkeithj from comment #80) > (In reply to Cameron from comment #79) > > Alas, I doubt litigation is on the table. > > > > I also absolutely would not have purchased this laptop had I known sound > > support would have been an issue in Linux (or at least returned it > > within the first 30 days had I known 6 months later this would still be > > ongoing). I received mine back in August... Now I'm starting to eye new > > laptops already because I don't have any sound. However, now I'm also > > concerned that comparatively spec'ed laptops may also have sound issues > > potentially due to amplifier sound chips that could result in the same > > problem. > > > > At some point in the near future, I may resort to purchasing new laptops > > and returning them within 30 days if there are any issues under Linux, > > because I simply can't assume they'll be addressed. > > > > Lenovo not wanting to put any developer time into drivers doesn't > > necessarily mean they're refusing documentation. Perhaps a code bounty > > could work? I'd be willing to donate to that cause. > > > > On 2/14/21 2:20 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > > > --- Comment #78 from darnellkeithj@gmail.com --- > > > (In reply to Jim33 from comment #77) > > >> (In reply to Jaroslav Kysela from comment #43) > > >> > > >>> Contact Lenovo, if you can, for help (BIOS - Linux support). They are > > >>> supporting more the non-gaming hardware in Linux (ThinkPad/ThinkStation > > >>> series). > > >> I don't think there is much help to expect from Lenovo. I contacted > > support > > >> and after a detailed email explaining the issue on my dual boot > Win/Linux > > >> system I got this: > > >> > > >> "Thank you for your E-Mail. I will gladly help you. > > >> Our devices are all tested to work with only windows, and no other OS. > > >> If you have any other questions, I will gladly answer them." > > >> > > >> Good that he will "gladly help me"... ;-) > > >> > > >> I have a Legion 7i running Ubuntu 20.04 default kernel. > > >> If I would have knew this issue before I would have probably bought > > another > > >> laptop. > > > There needs to be a push by the linux community and possible litigation > to > > > force companies to provide documentation > > > > > Do try to install Archlinux and use the kernel > https://gitlab.com/manfromva/manfromva/-/tree/master/Kernels > > I have a Duet 7i with the same sound system and I currently have sound. It > didn't work for me on endeavoros but works with Arcolinux and Garuda so far. Do you mind posting the results of alsa-info? I could not access the kernel link. Is it a private project?
Try now. I had it on private for some reason. That is the official kernel and headers from arch Linux - arcolinux to be exact. I added them on gitlab because it's difficult to get older arch kernels. It Can be used with any Arch distro but I just ran into a bug where my speakers won't work after I connect Bluetooth headphones with Garuda Linux. I'm installing RebornOS Linux now and will try there. Worked just fine with Arcolinux and several other Arch distros.
(In reply to TT from comment #81) > (In reply to darnellkeithj from comment #80) > > (In reply to Cameron from comment #79) > > > Alas, I doubt litigation is on the table. > > > > > > I also absolutely would not have purchased this laptop had I known sound > > > support would have been an issue in Linux (or at least returned it > > > within the first 30 days had I known 6 months later this would still be > > > ongoing). I received mine back in August... Now I'm starting to eye new > > > laptops already because I don't have any sound. However, now I'm also > > > concerned that comparatively spec'ed laptops may also have sound issues > > > potentially due to amplifier sound chips that could result in the same > > > problem. > > > > > > At some point in the near future, I may resort to purchasing new laptops > > > and returning them within 30 days if there are any issues under Linux, > > > because I simply can't assume they'll be addressed. > > > > > > Lenovo not wanting to put any developer time into drivers doesn't > > > necessarily mean they're refusing documentation. Perhaps a code bounty > > > could work? I'd be willing to donate to that cause. > > > > > > On 2/14/21 2:20 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > > > > > --- Comment #78 from darnellkeithj@gmail.com --- > > > > (In reply to Jim33 from comment #77) > > > >> (In reply to Jaroslav Kysela from comment #43) > > > >> > > > >>> Contact Lenovo, if you can, for help (BIOS - Linux support). They are > > > >>> supporting more the non-gaming hardware in Linux > (ThinkPad/ThinkStation > > > >>> series). > > > >> I don't think there is much help to expect from Lenovo. I contacted > > > support > > > >> and after a detailed email explaining the issue on my dual boot > > Win/Linux > > > >> system I got this: > > > >> > > > >> "Thank you for your E-Mail. I will gladly help you. > > > >> Our devices are all tested to work with only windows, and no other OS. > > > >> If you have any other questions, I will gladly answer them." > > > >> > > > >> Good that he will "gladly help me"... ;-) > > > >> > > > >> I have a Legion 7i running Ubuntu 20.04 default kernel. > > > >> If I would have knew this issue before I would have probably bought > > > another > > > >> laptop. > > > > There needs to be a push by the linux community and possible litigation > > to > > > > force companies to provide documentation > > > > > > > > Do try to install Archlinux and use the kernel > > https://gitlab.com/manfromva/manfromva/-/tree/master/Kernels > > > > I have a Duet 7i with the same sound system and I currently have sound. It > > didn't work for me on endeavoros but works with Arcolinux and Garuda so > far. > > Do you mind posting the results of alsa-info? > I could not access the kernel link. Is it a private project? RebornOS didn't work for me but it may be to the lxqt version I installed. Manjaro works fine though. http://alsa-project.org/db/?f=7a8ff2aaf9d780f1c2c68bc129db27a54d9e99d4
I have a lenovo yoga 7i. No sound from the in build speaker in ubuntu 20.10. Is there a solution for this ???
(In reply to gurpreetsinghwalia5 from comment #84) > I have a lenovo yoga 7i. No sound from the in build speaker in ubuntu 20.10. > Is there a solution for this ??? Yes, install fedora 33 and update everything. Then at least the bottom speakers will work.
(In reply to juliusvonkohout from comment #85) > (In reply to gurpreetsinghwalia5 from comment #84) > > I have a lenovo yoga 7i. No sound from the in build speaker in ubuntu > 20.10. > > Is there a solution for this ??? > > Yes, install fedora 33 and update everything. Then at least the bottom > speakers will work. Is there a debian distro that works ??? Need debian for work.
(In reply to gurpreetsinghwalia5 from comment #86) > (In reply to juliusvonkohout from comment #85) > > (In reply to gurpreetsinghwalia5 from comment #84) > > > I have a lenovo yoga 7i. No sound from the in build speaker in ubuntu > > 20.10. > > > Is there a solution for this ??? > > > > Yes, install fedora 33 and update everything. Then at least the bottom > > speakers will work. > > there a debian distro that works ??? Need debian for work. if your using a legion 7 (that's what I have). My understanding is that there is no kernel support (I could be very wrong about this so anyone feel free to correct me). I have used a few distros on my laptop and I use arco linux (its not debian I know) on the latest zen kernel. I still don't have sound out the speakers, but headphones work. So if you are fine with using headphones, any distro will work
Hello, I have same issue on my Lenovo-Legion-7-15IMH05.no sound on my speakers but are my analog headphones working... I have I7 10th gen. Details info: This script visits the following commands/files to collect diagnostic information about your ALSA installation and sound related hardware. dmesg lspci aplay amixer alsactl rpm, dpkg /proc/asound/ /sys/class/sound/ ~/.asoundrc (etc.) See '/usr/sbin/alsa-info --help' for command line options. dmesg: read kernel buffer failed: Operation not permitted Automatically upload ALSA information to www.alsa-project.org? [y/N] : y Uploading information to www.alsa-project.org ... Done! Your ALSA information is located at http://alsa-project.org/db/?f=4bde2ad92ca50dd71b38208c0580a40393503a0f Please inform the person helping you daniel@pop-os:~$ inxi -fxz CPU: Info: 6-Core model: Intel Core i7-10750H bits: 64 type: MT MCP arch: N/A L2 cache: 12.0 MiB bogomips: 62399 Speed: 900 MHz min/max: 800/2600 MHz Core speeds (MHz): 1: 884 2: 866 3: 899 4: 809 5: 888 6: 885 7: 897 8: 878 9: 894 10: 864 11: 892 12: 897 Flags: 3dnowprefetch abm acpi adx aes aperfmperf apic arat arch_capabilities arch_perfmon art avx avx2 bmi1 bmi2 bts clflush clflushopt cmov constant_tsc cpuid cpuid_fault cx16 cx8 de ds_cpl dtes64 dtherm dts epb ept ept_ad erms est f16c flexpriority flush_l1d fma fpu fsgsbase fxsr ht hwp hwp_act_window hwp_epp hwp_notify ibpb ibrs ibrs_enhanced ida intel_pt invpcid invpcid_single lahf_lm lm mca mce md_clear mmx monitor movbe mpx msr mtrr nonstop_tsc nopl nx ospke pae pat pbe pcid pclmulqdq pdcm pdpe1gb pebs pge pku pln pni popcnt pse pse36 pts rdrand rdseed rdtscp rep_good sdbg sep smap smep ss ssbd sse sse2 sse4_1 sse4_2 ssse3 stibp syscall tm tm2 tpr_shadow tsc tsc_adjust tsc_deadline_timer vme vmx vnmi vpid x2apic xgetbv1 xsave xsavec xsaveopt xsaves xtopology xtpr daniel@pop-os:~$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC287 Analog [ALC287 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 10: HDMI 4 [HDMI 4] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 10: HDMI 4 [HDMI 4] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 11: HDMI 5 [HDMI 5] Subdevices: 1/1 Subdevice #0: subdevice #0 daniel@pop-os:~$ **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC287 Analog [ALC287 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 10: HDMI 4 [HDMI 4] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 10: HDMI 4 [HDMI 4] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: NVidia [HDA NVidia], device 11: HDMI 5 [HDMI 5] Subdevices: 1/1 Subdevice #0: subdevice #0 daniel@pop-os:~$ pacmd list-sinks 1 sink(s) available. * index: 4 name: <alsa_output.pci-0000_00_1f.3.analog-stereo> driver: <module-alsa-card.c> flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY state: SUSPENDED suspend cause: IDLE priority: 9039 volume: front-left: 35030 / 53% / -16.32 dB, front-right: 35030 / 53% / -16.32 dB balance 0.00 base volume: 65536 / 100% / 0.00 dB volume steps: 65537 muted: no current latency: 0.00 ms max request: 0 KiB max rewind: 0 KiB monitor source: 5 sample spec: s16le 2ch 48000Hz channel map: front-left,front-right Stereo used by: 0 linked by: 0 configured latency: 0.00 ms; range is 0.50 .. 2000.00 ms card: 1 <alsa_card.pci-0000_00_1f.3> module: 24 properties: alsa.resolution_bits = "16" device.api = "alsa" device.class = "sound" alsa.class = "generic" alsa.subclass = "generic-mix" alsa.name = "ALC287 Analog" alsa.id = "ALC287 Analog" alsa.subdevice = "0" alsa.subdevice_name = "subdevice #0" alsa.device = "0" alsa.card = "0" alsa.card_name = "HDA Intel PCH" alsa.long_card_name = "HDA Intel PCH at 0x6014108000 irq 180" alsa.driver_name = "snd_hda_intel" device.bus_path = "pci-0000:00:1f.3" sysfs.path = "/devices/pci0000:00/0000:00:1f.3/sound/card0" device.bus = "pci" device.vendor.id = "8086" device.vendor.name = "Intel Corporation" device.product.id = "06c8" device.product.name = "Comet Lake PCH cAVS" device.form_factor = "internal" device.string = "front:0" device.buffering.buffer_size = "384000" device.buffering.fragment_size = "192000" device.access_mode = "mmap+timer" device.profile.name = "analog-stereo" device.profile.description = "Analog Stereo" device.description = "Built-in Audio Analog Stereo" module-udev-detect.discovered = "1" device.icon_name = "audio-card-pci" ports: analog-output-speaker: Speakers (priority 10000, latency offset 0 usec, available: no) properties: device.icon_name = "audio-speakers" analog-output-headphones: Headphones (priority 9900, latency offset 0 usec, available: yes) properties: device.icon_name = "audio-headphones" active port: <analog-output-headphones>
Unfortunately I got the same issue. My headphones work on Ubuntu 20.04 but speakers didn't. In Windows 10 everything with sound is perfect. OS: Ubuntu 20.04 description: Notebook product: 82EH (LENOVO_MT_82EH_BU_idea_FM_C7 15IMH05) vendor: LENOVO version: Lenovo C7 15IMH05 *-firmware description: BIOS vendor: LENOVO physical id: 0 version: E9CN62WW(V4.07) date: 01/21/2021 *-cpu description: CPU product: Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz vendor: Intel Corp. physical id: 4 bus info: cpu@0 version: Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz
Created attachment 295777 [details] Me too, but this may help
I also have this issue on (one version of) the Lenovo Yoga Slim 7 --- this model 82A3005RUK to be precise. Happy to provide more details if needed. Is it likely that this will be fixed in the near future? I have to decide whether to wait or try to return the laptop.
You typically have 30 days to return a brand new laptop so keep that in mind. If you do end up returning it, please be clear in your communication that it's due to the lack of working audio in Linux. :) On 3/10/21 9:10 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #91 from Jack S (jack.shotton@gmail.com) --- > I also have this issue on (one version of) the Lenovo Yoga Slim 7 --- this > model 82A3005RUK to be precise. Happy to provide more details if needed. Is > it likely that this will be fixed in the near future? I have to decide > whether > to wait or try to return the laptop. >
(In reply to Cameron from comment #92) > You typically have 30 days to return a brand new laptop so keep that in > mind. > > If you do end up returning it, please be clear in your communication > that it's due to the lack of working audio in Linux. :) > > On 3/10/21 9:10 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #91 from Jack S (jack.shotton@gmail.com) --- > > I also have this issue on (one version of) the Lenovo Yoga Slim 7 --- this > > model 82A3005RUK to be precise. Happy to provide more details if needed. > Is > > it likely that this will be fixed in the near future? I have to decide > > whether > > to wait or try to return the laptop. > > Thank you! The third answer here: https://askubuntu.com/questions/1253498/no-sound-on-headphones-with-sof-hda-dsp-audio-on-ubuntu-and-variants to add the line options snd-hda-intel model=auto to /etc/modprobe.d/alsa-base.conf seems to have fixed it, so perhaps this is not the same bug after all (and I get to keep my laptop!).
(In reply to Jack S from comment #93) > options snd-hda-intel model=auto > seems to have fixed it, so perhaps this is not the same bug after all (and I > get to keep my laptop!). Something seems broken with the autodetection. Could you attach your 'alsa-info.sh --no-upload' output?
(In reply to Jaroslav Kysela from comment #94) > (In reply to Jack S from comment #93) > > > options snd-hda-intel model=auto > > > seems to have fixed it, so perhaps this is not the same bug after all (and > I > > get to keep my laptop!). > > Something seems broken with the autodetection. Could you attach your > 'alsa-info.sh --no-upload' output? Certainly -- here it is! upload=true&script=true&cardinfo= !!################################ !!ALSA Information Script v 0.5.0 !!################################ !!Script ran on: Wed Mar 10 19:14:12 UTC 2021 !!Linux Distribution !!------------------ Ubuntu 20.10 \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu 20.10" NAME="Ubuntu" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.10" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=groovy !!DMI Information !!--------------- Manufacturer: LENOVO Product Name: 82A3 Product Version: Yoga Slim 7 14ITL05 Firmware Version: FBCN19WW System SKU: LENOVO_MT_82A3_BU_idea_FM_Yoga Slim 7 14ITL05 Board Vendor: LENOVO Board Name: LNVNB161216 !!ACPI Device Status Information !!--------------- /sys/bus/acpi/devices/ACPI000C:00/status 15 /sys/bus/acpi/devices/ACPI000E:00/status 15 /sys/bus/acpi/devices/ELAN0000:00/status 15 /sys/bus/acpi/devices/IDEA2002:00/status 15 /sys/bus/acpi/devices/IDEA2004:00/status 15 /sys/bus/acpi/devices/INT33A1:00/status 15 /sys/bus/acpi/devices/INT33D5:00/status 15 /sys/bus/acpi/devices/INT340E:00/status 15 /sys/bus/acpi/devices/INT34C5:00/status 15 /sys/bus/acpi/devices/INT3F0D:00/status 15 /sys/bus/acpi/devices/INTC1040:00/status 15 /sys/bus/acpi/devices/INTC1043:00/status 15 /sys/bus/acpi/devices/INTC1043:01/status 15 /sys/bus/acpi/devices/INTC6000:00/status 15 /sys/bus/acpi/devices/LHK2019:00/status 15 /sys/bus/acpi/devices/LNXPOWER:00/status 1 /sys/bus/acpi/devices/LNXPOWER:01/status 1 /sys/bus/acpi/devices/LNXPOWER:02/status 1 /sys/bus/acpi/devices/LNXPOWER:03/status 1 /sys/bus/acpi/devices/LNXPOWER:05/status 1 /sys/bus/acpi/devices/MSFT0001:00/status 15 /sys/bus/acpi/devices/PNP0103:00/status 15 /sys/bus/acpi/devices/PNP0C02:02/status 11 /sys/bus/acpi/devices/PNP0C02:04/status 11 /sys/bus/acpi/devices/PNP0C09:00/status 15 /sys/bus/acpi/devices/PNP0C0A:00/status 31 /sys/bus/acpi/devices/PRP00001:00/status 11 /sys/bus/acpi/devices/PRP00001:01/status 11 /sys/bus/acpi/devices/USBC000:00/status 15 /sys/bus/acpi/devices/VPC2004:00/status 15 /sys/bus/acpi/devices/device:00/status 15 /sys/bus/acpi/devices/device:17/status 15 /sys/bus/acpi/devices/device:24/status 15 /sys/bus/acpi/devices/device:25/status 15 /sys/bus/acpi/devices/device:26/status 15 /sys/bus/acpi/devices/device:95/status 15 /sys/bus/acpi/devices/device:96/status 15 /sys/bus/acpi/devices/device:97/status 15 /sys/bus/acpi/devices/device:99/status 15 /sys/bus/acpi/devices/device:9a/status 15 /sys/bus/acpi/devices/device:9b/status 15 /sys/bus/acpi/devices/device:a0/status 15 /sys/bus/acpi/devices/device:a8/status 15 /sys/bus/acpi/devices/device:aa/status 15 /sys/bus/acpi/devices/device:ac/status 15 !!Kernel Information !!------------------ Kernel release: 5.8.0-44-generic Operating System: GNU/Linux Architecture: x86_64 Processor: x86_64 SMP Enabled: Yes !!ALSA Version !!------------ Driver version: k5.8.0-44-generic Library version: 1.2.3.2 Utilities version: 1.2.3 !!Loaded ALSA modules !!------------------- snd_soc_skl_hda_dsp (card 0) snd_usb_audio (card 1) !!Sound Servers on this system !!---------------------------- Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - Yes !!Soundcards recognised by ALSA !!----------------------------- 0 [sofhdadsp ]: sof-hda-dsp - sof-hda-dsp LENOVO-82A3-YogaSlim714ITL05-LNVNB161216 1 [Device ]: USB-Audio - USB Advanced Audio Device C-Media Electronics Inc. USB Advanced Audio Device at usb-0000:00:14.0-3, full !!PCI Soundcards installed in the system !!-------------------------------------- 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20) Subsystem: Lenovo Tiger Lake-LP Smart Sound Technology Audio Controller [17aa:3809] !!Modprobe options (Sound related) !!-------------------------------- snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 snd_atiixp_modem: index=-2 snd_intel8x0m: index=-2 snd_via82xx_modem: index=-2 snd_usb_audio: index=-2 snd_usb_caiaq: index=-2 snd_usb_ua101: index=-2 snd_usb_us122l: index=-2 snd_usb_usx2y: index=-2 snd_cmipci: mpu_port=0x330 fm_port=0x388 snd_pcsp: index=-2 snd_usb_audio: index=-2 snd_hda_intel: model=auto !!Loaded sound module options !!--------------------------- !!Module: snd_soc_skl_hda_dsp * : !!Module: snd_usb_audio autoclock : Y delayed_register : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) device_setup : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) ignore_ctl_error : N index : -2,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 pid : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 quirk_alias : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) skip_validation : N use_vmalloc : Y vid : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 !!Sysfs card info !!--------------- !!Card: /sys/class/sound/card0 Driver: /sys/bus/platform/drivers/skl_hda_dsp_generic Tree: /sys/class/sound/card0 |-- controlC0 | |-- dev | |-- device -> ../../card0 | |-- power | |-- subsystem -> ../../../../../../../class/sound | `-- uevent |-- device -> ../../../skl_hda_dsp_generic |-- hwC0D0 | |-- afg | |-- chip_name | |-- clear | |-- dev | |-- device -> ../../card0 | |-- driver_pin_configs | |-- hints | |-- init_pin_configs | |-- init_verbs | |-- mfg | |-- modelname | |-- power | |-- power_off_acct | |-- power_on_acct | |-- reconfig | |-- revision_id | |-- subsystem -> ../../../../../../../class/sound | |-- subsystem_id | |-- uevent | |-- user_pin_configs | |-- vendor_id | `-- vendor_name |-- hwC0D2 | |-- afg | |-- chip_name | |-- clear | |-- dev | |-- device -> ../../card0 | |-- driver_pin_configs | |-- hints | |-- init_pin_configs | |-- init_verbs | |-- mfg | |-- modelname | |-- power | |-- power_off_acct | |-- power_on_acct | |-- reconfig | |-- revision_id | |-- subsystem -> ../../../../../../../class/sound | |-- subsystem_id | |-- uevent | |-- user_pin_configs | |-- vendor_id | `-- vendor_name |-- id |-- input43 | |-- capabilities | |-- device -> ../../card0 | |-- event18 | |-- id | |-- modalias | |-- name | |-- phys | |-- power | |-- properties | |-- subsystem -> ../../../../../../../class/input | |-- uevent | `-- uniq |-- input44 | |-- capabilities | |-- device -> ../../card0 | |-- event19 | |-- id | |-- modalias | |-- name | |-- phys | |-- power | |-- properties | |-- subsystem -> ../../../../../../../class/input | |-- uevent | `-- uniq |-- input45 | |-- capabilities | |-- device -> ../../card0 | |-- event20 | |-- id | |-- modalias | |-- name | |-- phys | |-- power | |-- properties | |-- subsystem -> ../../../../../../../class/input | |-- uevent | `-- uniq |-- input46 | |-- capabilities | |-- device -> ../../card0 | |-- event21 | |-- id | |-- modalias | |-- name | |-- phys | |-- power | |-- properties | |-- subsystem -> ../../../../../../../class/input | |-- uevent | `-- uniq |-- input47 | |-- capabilities | |-- device -> ../../card0 | |-- event22 | |-- id | |-- modalias | |-- name | |-- phys | |-- power | |-- properties | |-- subsystem -> ../../../../../../../class/input | |-- uevent | `-- uniq |-- number |-- pcmC0D0c | |-- dev | |-- device -> ../../card0 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../class/sound | `-- uevent |-- pcmC0D0p | |-- dev | |-- device -> ../../card0 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../class/sound | `-- uevent |-- pcmC0D1c | |-- dev | |-- device -> ../../card0 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../class/sound | `-- uevent |-- pcmC0D1p | |-- dev | |-- device -> ../../card0 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../class/sound | `-- uevent |-- pcmC0D3p | |-- dev | |-- device -> ../../card0 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../class/sound | `-- uevent |-- pcmC0D4p | |-- dev | |-- device -> ../../card0 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../class/sound | `-- uevent |-- pcmC0D5p | |-- dev | |-- device -> ../../card0 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../class/sound | `-- uevent |-- pcmC0D6c | |-- dev | |-- device -> ../../card0 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../class/sound | `-- uevent |-- pcmC0D7c | |-- dev | |-- device -> ../../card0 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../class/sound | `-- uevent |-- power | |-- async | |-- autosuspend_delay_ms | |-- control | |-- runtime_active_kids | |-- runtime_active_time | |-- runtime_enabled | |-- runtime_status | |-- runtime_suspended_time | `-- runtime_usage |-- subsystem -> ../../../../../../class/sound `-- uevent !!Card: /sys/class/sound/card1 Driver: /sys/bus/usb/drivers/snd-usb-audio Tree: /sys/class/sound/card1 |-- controlC1 | |-- dev | |-- device -> ../../card1 | |-- power | |-- subsystem -> ../../../../../../../../../class/sound | `-- uevent |-- device -> ../../../3-3:1.0 |-- id |-- number |-- pcmC1D0c | |-- dev | |-- device -> ../../card1 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../../../class/sound | `-- uevent |-- pcmC1D0p | |-- dev | |-- device -> ../../card1 | |-- pcm_class | |-- power | |-- subsystem -> ../../../../../../../../../class/sound | `-- uevent |-- power | |-- async | |-- autosuspend_delay_ms | |-- control | |-- runtime_active_kids | |-- runtime_active_time | |-- runtime_enabled | |-- runtime_status | |-- runtime_suspended_time | `-- runtime_usage |-- subsystem -> ../../../../../../../../class/sound `-- uevent !!HDA-Intel Codec information !!--------------------------- --startcollapse-- Codec: Realtek ALC287 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0287 Subsystem Id: 0x17aa3809 Revision Id: 0x100002 No Modem Function Group found Default PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D1 D2 D3 D3cold CLKSTOP EPSS Power: setting=D0, actual=D0 GPIO: io=5, o=0, i=0, unsolicited=1, wake=0 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x4f 0x4f] Converter: stream=1, channel=0 PCM: rates [0x40]: 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x57 0x57] Converter: stream=1, channel=0 PCM: rates [0x40]: 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x04 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x05 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x06 [Audio Output] wcaps 0x411: Stereo Converter: stream=0, channel=0 PCM: rates [0x40]: 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x07 [Audio Input] wcaps 0x10051b: Stereo Amp-In Amp-In caps: ofs=0x17, nsteps=0x3f, stepsize=0x02, mute=1 Amp-In vals: [0x97 0x97] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x40]: 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x24 Node 0x08 [Audio Input] wcaps 0x10051b: Stereo Amp-In Control: name="Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x3f, stepsize=0x02, mute=1 Amp-In vals: [0x80 0x80] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x23 Node 0x09 [Audio Input] wcaps 0x10051b: Stereo Amp-In Amp-In caps: ofs=0x17, nsteps=0x3f, stepsize=0x02, mute=1 Amp-In vals: [0x97 0x97] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x22 Node 0x0a [Audio Input] wcaps 0x10051b: Stereo Amp-In Amp-In caps: ofs=0x17, nsteps=0x3f, stepsize=0x02, mute=1 Amp-In vals: [0x97 0x97] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x40]: 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x25 Node 0x0b [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0c [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0d [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0e [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0f [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x10 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x11 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x12 [Pin Complex] wcaps 0x40040b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Pincap 0x00000020: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x13 [Pin Complex] wcaps 0x40040b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Pincap 0x00000020: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00010014: OUT EAPD Detect EAPD 0x2: EAPD Pin Default 0x90170110: [Fixed] Speaker at Int N/A Conn = Analog, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x02 Node 0x15 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x16 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x17 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000001c: OUT HP Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 4 0x02* 0x03 0x06 0x08 Node 0x18 [Pin Complex] wcaps 0x40048b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Pincap 0x00000024: IN Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x19 [Pin Complex] wcaps 0x40048b: Stereo Amp-In Control: name="Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Pincap 0x00003724: IN Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x03a11030: [Jack] Mic at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=02, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x1a [Pin Complex] wcaps 0x40048b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Pincap 0x00003724: IN Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: VREF_HIZ Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00013734: IN OUT EAPD Detect Vref caps: HIZ 50 GRD 80 100 EAPD 0x2: EAPD Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: VREF_HIZ Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x02* 0x03 Node 0x1c [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x1d [Pin Complex] wcaps 0x400400: Mono Pincap 0x00000020: IN Pin Default 0x40471a6d: [N/A] SPDIF Out at Ext N/A Conn = Analog, Color = Black DefAssociation = 0x6, Sequence = 0xd Pin-ctls: 0x20: IN Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x1e [Pin Complex] wcaps 0x400501: Stereo Pincap 0x00000010: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x06 Node 0x1f [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono Processing caps: benign=0, ncoeff=142 Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0001001c: OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x03211020: [Jack] HP Out at Ext Left Conn = 1/8, Color = Black DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x02 0x03* Node 0x22 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 5 0x19 0x1a 0x1b 0x1d 0x13 Node 0x23 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 5 0x19 0x1a 0x1b 0x1d 0x12 Node 0x24 [Audio Selector] wcaps 0x300101: Stereo Connection: 3 0x12* 0x13 0x18 Node 0x25 [Audio Selector] wcaps 0x300101: Stereo Connection: 2 0x12* 0x13 Codec: Intel Tigerlake HDMI Address: 2 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x80862812 Subsystem Id: 0x80860101 Revision Id: 0x100000 No Modem Function Group found Default PCM: rates [0x0]: bits [0x0]: formats [0x0]: Default Amp-In caps: N/A Default Amp-Out caps: N/A State of AFG node 0x01: Power states: D0 D3 CLKSTOP EPSS Power: setting=D0, actual=D0, Clock-stop-OK GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 Node 0x03 [Audio Output] wcaps 0x6611: 8-Channels Digital Converter: stream=0, channel=0 Digital: Enabled KAE Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1a]: 16 24 32 formats [0x5]: PCM AC3 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Node 0x04 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 0 Node 0x05 [Audio Output] wcaps 0x6611: 8-Channels Digital Converter: stream=0, channel=0 Digital: Enabled KAE Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1a]: 16 24 32 formats [0x5]: PCM AC3 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Node 0x06 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 0 Node 0x07 [Audio Output] wcaps 0x6611: 8-Channels Digital Converter: stream=0, channel=0 Digital: Enabled KAE Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1a]: 16 24 32 formats [0x5]: PCM AC3 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Node 0x08 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 0 Node 0x09 [Audio Output] wcaps 0x6611: 8-Channels Digital Converter: stream=0, channel=0 Digital: Enabled KAE Digital category: 0x0 IEC Coding Type: 0x0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1a]: 16 24 32 formats [0x5]: PCM AC3 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Node 0x0a [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 0 Node 0x0b [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 0 Node 0x0c [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 0 Node 0x0d [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 0 Node 0x0e [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 0 Node 0x0f [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x18560010: [Jack] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 0 --endcollapse-- !!USB Descriptors !!--------------- --startcollapse-- Bus 003 Device 002: ID 0d8c:016c C-Media Electronics, Inc. USB Advanced Audio Device Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 16 idVendor 0x0d8c C-Media Electronics, Inc. idProduct 0x016c bcdDevice 1.00 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0103 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 0x006a bInCollection 2 baInterfaceNr(0) 1 baInterfaceNr(1) 2 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 2 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 6 wTerminalType 0x0301 Speaker bAssocTerminal 0 bSourceID 9 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 7 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 8 iTerminal 0 AudioControl Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 5 (SELECTOR_UNIT) bUnitID 8 bNrInPins 1 baSourceID(0) 10 iSelector 0 AudioControl Interface Descriptor: bLength 13 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 9 bSourceID 15 bControlSize 2 bmaControls(0) 0x0001 Mute Control bmaControls(1) 0x0002 Volume Control bmaControls(2) 0x0002 Volume Control iFeature 0 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 10 bSourceID 2 bControlSize 1 bmaControls(0) 0x01 Mute Control bmaControls(1) 0x02 Volume Control bmaControls(2) 0x02 Volume Control iFeature 0 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 13 bSourceID 2 bControlSize 1 bmaControls(0) 0x01 Mute Control bmaControls(1) 0x02 Volume Control bmaControls(2) 0x02 Volume Control iFeature 0 AudioControl Interface Descriptor: bLength 14 bDescriptorType 36 bDescriptorSubtype 4 (MIXER_UNIT) bUnitID 15 bNrInPins 2 baSourceID(0) 1 baSourceID(1) 13 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 bmControls(0) 0x00 iMixer 0 Warning: Junk at end of descriptor (1 bytes): 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 1 bDelay 1 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 14 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 2 Discrete tSamFreq[ 0] 44100 tSamFreq[ 1] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 13 Transfer Type Isochronous Synch Type Synchronous Usage Type Data wMaxPacketSize 0x00c8 1x 200 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0x0000 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 7 bDelay 1 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 14 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 2 Discrete tSamFreq[ 0] 44100 tSamFreq[ 1] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x00c8 1x 200 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0x0000 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.00 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 104 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 2 --endcollapse-- !!USB Stream information !!---------------------- --startcollapse-- C-Media Electronics Inc. USB Advanced Audio Device at usb-0000:00:14.0-3, full : USB Audio Playback: Status: Stop Interface 1 Altset 1 Format: S16_LE Channels: 2 Endpoint: 1 OUT (SYNC) Rates: 44100, 48000 Bits: 16 Channel map: FL FR Capture: Status: Stop Interface 2 Altset 1 Format: S16_LE Channels: 2 Endpoint: 2 IN (ASYNC) Rates: 44100, 48000 Bits: 16 Channel map: FL FR --endcollapse-- !!USB Mixer information !!--------------------- --startcollapse-- USB Mixer: usb_id=0x0d8c016c, ctrlif=0, ctlerr=0 Card: C-Media Electronics Inc. USB Advanced Audio Device at usb-0000:00:14.0-3, full Unit: 9 Control: name="Speaker Playback Volume", index=0 Info: id=9, control=2, cmask=0x3, channels=2, type="S16" Volume: min=-10240, max=0, dBmin=-4000, dBmax=0 Unit: 9 Control: name="Speaker Playback Switch", index=0 Info: id=9, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN" Volume: min=0, max=1, dBmin=0, dBmax=0 Unit: 10 Control: name="Mic Capture Volume", index=0 Info: id=10, control=2, cmask=0x3, channels=2, type="S16" Volume: min=0, max=8704, dBmin=0, dBmax=3400 Unit: 10 Control: name="Mic Capture Switch", index=0 Info: id=10, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN" Volume: min=0, max=1, dBmin=0, dBmax=0 Unit: 13 Control: name="Mic Playback Volume", index=0 Info: id=13, control=2, cmask=0x3, channels=2, type="S16" Volume: min=-2560, max=5632, dBmin=-1000, dBmax=2200 Unit: 13 Control: name="Mic Playback Switch", index=0 Info: id=13, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN" Volume: min=0, max=1, dBmin=0, dBmax=0 --endcollapse-- !!ALSA Device nodes !!----------------- crw-rw----+ 1 root audio 116, 16 Mar 10 17:40 /dev/snd/controlC0 crw-rw----+ 1 root audio 116, 4 Mar 10 17:40 /dev/snd/controlC1 crw-rw----+ 1 root audio 116, 15 Mar 10 17:40 /dev/snd/hwC0D0 crw-rw----+ 1 root audio 116, 14 Mar 10 17:40 /dev/snd/hwC0D2 crw-rw----+ 1 root audio 116, 8 Mar 10 17:40 /dev/snd/pcmC0D0c crw-rw----+ 1 root audio 116, 7 Mar 10 19:14 /dev/snd/pcmC0D0p crw-rw----+ 1 root audio 116, 10 Mar 10 17:40 /dev/snd/pcmC0D1c crw-rw----+ 1 root audio 116, 9 Mar 10 17:40 /dev/snd/pcmC0D1p crw-rw----+ 1 root audio 116, 11 Mar 10 17:41 /dev/snd/pcmC0D3p crw-rw----+ 1 root audio 116, 12 Mar 10 17:40 /dev/snd/pcmC0D4p crw-rw----+ 1 root audio 116, 13 Mar 10 17:40 /dev/snd/pcmC0D5p crw-rw----+ 1 root audio 116, 5 Mar 10 17:40 /dev/snd/pcmC0D6c crw-rw----+ 1 root audio 116, 6 Mar 10 17:40 /dev/snd/pcmC0D7c crw-rw----+ 1 root audio 116, 3 Mar 10 17:41 /dev/snd/pcmC1D0c crw-rw----+ 1 root audio 116, 2 Mar 10 17:41 /dev/snd/pcmC1D0p crw-rw----+ 1 root audio 116, 1 Mar 10 17:40 /dev/snd/seq crw-rw----+ 1 root audio 116, 33 Mar 10 17:40 /dev/snd/timer /dev/snd/by-id: total 0 drwxr-xr-x 2 root root 60 Mar 10 17:40 . drwxr-xr-x 4 root root 420 Mar 10 17:40 .. lrwxrwxrwx 1 root root 12 Mar 10 17:40 usb-C-Media_Electronics_Inc._USB_Advanced_Audio_Device-00 -> ../controlC1 /dev/snd/by-path: total 0 drwxr-xr-x 2 root root 80 Mar 10 17:40 . drwxr-xr-x 4 root root 420 Mar 10 17:40 .. lrwxrwxrwx 1 root root 12 Mar 10 17:40 pci-0000:00:14.0-usb-0:3:1.0 -> ../controlC1 lrwxrwxrwx 1 root root 12 Mar 10 17:40 pci-0000:00:1f.3-platform-skl_hda_dsp_generic -> ../controlC0 !!Aplay/Arecord output !!-------------------- APLAY **** List of PLAYBACK Hardware Devices **** card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: sofhdadsp [sof-hda-dsp], device 1: HDA Digital (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: sofhdadsp [sof-hda-dsp], device 3: HDMI1 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: sofhdadsp [sof-hda-dsp], device 4: HDMI2 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: sofhdadsp [sof-hda-dsp], device 5: HDMI3 (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Device [USB Advanced Audio Device], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 ARECORD **** List of CAPTURE Hardware Devices **** card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: sofhdadsp [sof-hda-dsp], device 1: HDA Digital (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC48kHz (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: sofhdadsp [sof-hda-dsp], device 7: DMIC16kHz (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Device [USB Advanced Audio Device], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 !!Amixer output !!------------- !!-------Mixer controls for card sofhdadsp Card hw:0 'sofhdadsp'/'LENOVO-82A3-YogaSlim714ITL05-LNVNB161216' Mixer name : 'Realtek ALC287' Components : 'HDA:80862812,80860101,00100000 HDA:10ec0287,17aa3809,00100002 cfg-dmics:2' Controls : 46 Simple ctrls : 18 Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 87 Mono: Playback 87 [100%] [0.00dB] [on] Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 87 [100%] [0.00dB] [off] Front Right: Playback 87 [100%] [0.00dB] [off] Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 79 [91%] [-6.00dB] [on] Front Right: Playback 79 [91%] [-6.00dB] [on] Simple mixer control 'Mic Boost',0 Capabilities: volume Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 0 [0%] [0.00dB] Front Right: 0 [0%] [0.00dB] Simple mixer control 'IEC958',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958',1 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'IEC958',2 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 63 Front Left: Capture 0 [0%] [-17.25dB] [off] Front Right: Capture 0 [0%] [-17.25dB] [off] Simple mixer control 'Auto-Mute Mode',0 Capabilities: enum Items: 'Disabled' 'Enabled' Item0: 'Disabled' Simple mixer control 'Dmic0',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 70 Front Left: Capture 50 [71%] [0.00dB] [on] Front Right: Capture 50 [71%] [0.00dB] [on] Simple mixer control 'Dmic1',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 70 Front Left: Capture 50 [71%] [0.00dB] Front Right: Capture 50 [71%] [0.00dB] Simple mixer control 'PGA1.0 1 Master',0 Capabilities: pvolume Playback channels: Front Left - Front Right Limits: Playback 0 - 32 Mono: Front Left: Playback 32 [100%] [0.00dB] Front Right: Playback 32 [100%] [0.00dB] Simple mixer control 'PGA2.0 2 Master',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 80 Front Left: Capture 50 [62%] [0.00dB] Front Right: Capture 50 [62%] [0.00dB] Simple mixer control 'PGA3.0 3 Master',0 Capabilities: pvolume Playback channels: Front Left - Front Right Limits: Playback 0 - 32 Mono: Front Left: Playback 32 [100%] [0.00dB] Front Right: Playback 32 [100%] [0.00dB] Simple mixer control 'PGA4.0 4 Master',0 Capabilities: cvolume Capture channels: Front Left - Front Right Limits: Capture 0 - 80 Front Left: Capture 50 [62%] [0.00dB] Front Right: Capture 50 [62%] [0.00dB] Simple mixer control 'PGA7.0 7 Master',0 Capabilities: pvolume Playback channels: Front Left - Front Right Limits: Playback 0 - 32 Mono: Front Left: Playback 32 [100%] [0.00dB] Front Right: Playback 32 [100%] [0.00dB] Simple mixer control 'PGA8.0 8 Master',0 Capabilities: pvolume Playback channels: Front Left - Front Right Limits: Playback 0 - 32 Mono: Front Left: Playback 32 [100%] [0.00dB] Front Right: Playback 32 [100%] [0.00dB] Simple mixer control 'PGA9.0 9 Master',0 Capabilities: pvolume Playback channels: Front Left - Front Right Limits: Playback 0 - 32 Mono: Front Left: Playback 32 [100%] [0.00dB] Front Right: Playback 32 [100%] [0.00dB] !!-------Mixer controls for card Device Card hw:1 'Device'/'C-Media Electronics Inc. USB Advanced Audio Device at usb-0000:00:14.0-3, full ' Mixer name : 'USB Mixer' Components : 'USB0d8c:016c' Controls : 9 Simple ctrls : 2 Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 40 Mono: Front Left: Playback 20 [50%] [-20.00dB] [on] Front Right: Playback 20 [50%] [-20.00dB] [on] Simple mixer control 'Mic',0 Capabilities: pvolume cvolume pswitch pswitch-joined cswitch cswitch-joined Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: Playback 0 - 32 Capture 0 - 34 Front Left: Playback 10 [31%] [0.00dB] [off] Capture 34 [100%] [34.00dB] [on] Front Right: Playback 10 [31%] [0.00dB] [off] Capture 34 [100%] [34.00dB] [on] !!Alsactl output !!-------------- --startcollapse-- state.sofhdadsp { control.1 { iface MIXER name 'Headphone Playback Volume' value.0 87 value.1 87 comment { access 'read write' type INTEGER count 2 range '0 - 87' dbmin -6525 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.2 { iface MIXER name 'Headphone Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.3 { iface MIXER name 'Speaker Playback Volume' value.0 79 value.1 79 comment { access 'read write' type INTEGER count 2 range '0 - 87' dbmin -6525 dbmax 0 dbvalue.0 -600 dbvalue.1 -600 } } control.4 { iface MIXER name 'Speaker Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.5 { iface MIXER name 'Auto-Mute Mode' value Disabled comment { access 'read write' type ENUMERATED count 1 item.0 Disabled item.1 Enabled } } control.6 { iface MIXER name 'Capture Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 63' dbmin -1725 dbmax 3000 dbvalue.0 -1725 dbvalue.1 -1725 } } control.7 { iface MIXER name 'Capture Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.8 { iface MIXER name 'Mic Boost Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 3' dbmin 0 dbmax 3000 dbvalue.0 0 dbvalue.1 0 } } control.9 { iface MIXER name 'Master Playback Volume' value 87 comment { access 'read write' type INTEGER count 1 range '0 - 87' dbmin -6525 dbmax 0 dbvalue.0 0 } } control.10 { iface MIXER name 'Master Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.11 { iface CARD name 'Mic Jack' value false comment { access read type BOOLEAN count 1 } } control.12 { iface CARD name 'Headphone Jack' value false comment { access read type BOOLEAN count 1 } } control.13 { iface CARD name 'Speaker Phantom Jack' value true comment { access read type BOOLEAN count 1 } } control.14 { iface CARD name 'HDMI/DP,pcm=3 Jack' value false comment { access read type BOOLEAN count 1 } } control.15 { iface MIXER name 'IEC958 Playback Con Mask' value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.16 { iface MIXER name 'IEC958 Playback Pro Mask' value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.17 { iface MIXER name 'IEC958 Playback Default' value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access 'read write' type IEC958 count 1 } } control.18 { iface MIXER name 'IEC958 Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.19 { iface PCM device 3 name ELD value '' comment { access 'read volatile' type BYTES count 0 } } control.20 { iface CARD name 'HDMI/DP,pcm=4 Jack' value false comment { access read type BOOLEAN count 1 } } control.21 { iface MIXER name 'IEC958 Playback Con Mask' index 1 value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.22 { iface MIXER name 'IEC958 Playback Pro Mask' index 1 value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.23 { iface MIXER name 'IEC958 Playback Default' index 1 value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access 'read write' type IEC958 count 1 } } control.24 { iface MIXER name 'IEC958 Playback Switch' index 1 value true comment { access 'read write' type BOOLEAN count 1 } } control.25 { iface PCM device 4 name ELD value '' comment { access 'read volatile' type BYTES count 0 } } control.26 { iface CARD name 'HDMI/DP,pcm=5 Jack' value false comment { access read type BOOLEAN count 1 } } control.27 { iface MIXER name 'IEC958 Playback Con Mask' index 2 value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.28 { iface MIXER name 'IEC958 Playback Pro Mask' index 2 value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access read type IEC958 count 1 } } control.29 { iface MIXER name 'IEC958 Playback Default' index 2 value '0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000' comment { access 'read write' type IEC958 count 1 } } control.30 { iface MIXER name 'IEC958 Playback Switch' index 2 value true comment { access 'read write' type BOOLEAN count 1 } } control.31 { iface PCM device 5 name ELD value '' comment { access 'read volatile' type BYTES count 0 } } control.32 { iface PCM device 3 name 'Playback Channel Map' value.0 0 value.1 0 value.2 0 value.3 0 value.4 0 value.5 0 value.6 0 value.7 0 comment { access 'read write' type INTEGER count 8 range '0 - 36' } } control.33 { iface PCM device 4 name 'Playback Channel Map' value.0 0 value.1 0 value.2 0 value.3 0 value.4 0 value.5 0 value.6 0 value.7 0 comment { access 'read write' type INTEGER count 8 range '0 - 36' } } control.34 { iface PCM device 5 name 'Playback Channel Map' value.0 0 value.1 0 value.2 0 value.3 0 value.4 0 value.5 0 value.6 0 value.7 0 comment { access 'read write' type INTEGER count 8 range '0 - 36' } } control.35 { iface MIXER name 'PGA1.0 1 Master Playback Volume' value.0 32 value.1 32 comment { access 'read write' type INTEGER count 2 range '0 - 32' dbmin -9999999 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.36 { iface MIXER name 'PGA2.0 2 Master Capture Volume' value.0 50 value.1 50 comment { access 'read write' type INTEGER count 2 range '0 - 80' dbmin -9999999 dbmax 3000 dbvalue.0 0 dbvalue.1 0 } } control.37 { iface MIXER name 'PGA3.0 3 Master Playback Volume' value.0 32 value.1 32 comment { access 'read write' type INTEGER count 2 range '0 - 32' dbmin -9999999 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.38 { iface MIXER name 'PGA4.0 4 Master Capture Volume' value.0 50 value.1 50 comment { access 'read write' type INTEGER count 2 range '0 - 80' dbmin -9999999 dbmax 3000 dbvalue.0 0 dbvalue.1 0 } } control.39 { iface MIXER name 'PGA7.0 7 Master Playback Volume' value.0 32 value.1 32 comment { access 'read write' type INTEGER count 2 range '0 - 32' dbmin -9999999 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.40 { iface MIXER name 'PGA8.0 8 Master Playback Volume' value.0 32 value.1 32 comment { access 'read write' type INTEGER count 2 range '0 - 32' dbmin -9999999 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.41 { iface MIXER name 'PGA9.0 9 Master Playback Volume' value.0 32 value.1 32 comment { access 'read write' type INTEGER count 2 range '0 - 32' dbmin -9999999 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.42 { iface MIXER name 'Dmic0 Capture Volume' value.0 50 value.1 50 comment { access 'read write' type INTEGER count 2 range '0 - 70' dbmin -9999999 dbmax 2000 dbvalue.0 0 dbvalue.1 0 } } control.43 { iface MIXER name 'Dmic0 Capture Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.45 { iface MIXER name 'Dmic1 Capture Volume' value.0 50 value.1 50 comment { access 'read write' type INTEGER count 2 range '0 - 70' dbmin -9999999 dbmax 2000 dbvalue.0 0 dbvalue.1 0 } } } state.Device { control.1 { iface PCM name 'Playback Channel Map' value.0 0 value.1 0 comment { access read type INTEGER count 2 range '0 - 36' } } control.2 { iface PCM name 'Capture Channel Map' value.0 0 value.1 0 comment { access read type INTEGER count 2 range '0 - 36' } } control.3 { iface MIXER name 'Mic Playback Switch' value false comment { access 'read write' type BOOLEAN count 1 } } control.4 { iface MIXER name 'Mic Playback Volume' value.0 10 value.1 10 comment { access 'read write' type INTEGER count 2 range '0 - 32' dbmin -1000 dbmax 2200 dbvalue.0 0 dbvalue.1 0 } } control.5 { iface MIXER name 'Speaker Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.6 { iface MIXER name 'Speaker Playback Volume' value.0 20 value.1 20 comment { access 'read write' type INTEGER count 2 range '0 - 40' dbmin -4000 dbmax 0 dbvalue.0 -2000 dbvalue.1 -2000 } } control.7 { iface MIXER name 'Mic Capture Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.8 { iface MIXER name 'Mic Capture Volume' value.0 34 value.1 34 comment { access 'read write' type INTEGER count 2 range '0 - 34' dbmin 0 dbmax 3400 dbvalue.0 3400 dbvalue.1 3400 } } control.9 { iface CARD name 'Keep Interface' value false comment { access 'read write' type BOOLEAN count 1 } } } --endcollapse-- !!All Loaded Modules !!------------------ ac97_bus acpi_pad acpi_tad acpi_thermal_rel aesni_intel af_alg algif_hash algif_skcipher autofs4 bluetooth bnep btbcm btintel btrtl btusb ccm cec cfg80211 cmac coretemp crc32_pclmul crct10dif_pclmul cros_ec cros_ec_ishtp cryptd crypto_simd drm drm_kms_helper ecc ecdh_generic efi_pstore elan_i2c fb_sys_fops ghash_clmulni_intel glue_helper hid hid_generic hid_logitech_dj hid_logitech_hidpp hid_multitouch hid_sensor_als hid_sensor_custom hid_sensor_hub hid_sensor_iio_common hid_sensor_trigger i2c_algo_bit i2c_hid i2c_i801 i2c_smbus i915 ideapad_laptop idma64 industrialio industrialio_triggered_buffer input_leds int3400_thermal int3403_thermal int340x_thermal_zone intel_cstate intel_hid intel_ish_ipc intel_ishtp intel_ishtp_hid intel_ishtp_loader intel_lpss intel_lpss_pci intel_powerclamp intel_rapl_common intel_rapl_msr intel_soc_dts_iosf ip_tables iwlmvm iwlwifi joydev kfifo_buf kvm kvm_intel ledtrig_audio libarc4 lp mac80211 mac_hid mc mei mei_hdcp mei_me nls_iso8859_1 nvme nvme_core parport parport_pc pinctrl_intel pinctrl_tigerlake ppdev processor_thermal_device rc_core rfcomm sch_fq_codel serio_raw snd snd_compress snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_core snd_hda_ext_core snd_hda_intel snd_hwdep snd_intel_dspcfg snd_pcm snd_pcm_dmaengine snd_rawmidi snd_seq snd_seq_device snd_seq_midi snd_seq_midi_event snd_soc_acpi snd_soc_acpi_intel_match snd_soc_core snd_soc_dmic snd_soc_hdac_hda snd_soc_hdac_hdmi snd_soc_skl_hda_dsp snd_sof snd_sof_intel_byt snd_sof_intel_hda snd_sof_intel_hda_common snd_sof_intel_ipc snd_sof_pci snd_sof_xtensa_dsp snd_timer snd_usb_audio snd_usbmidi_lib soundcore sparse_keymap syscopyarea sysfillrect sysimgblt thunderbolt typec typec_ucsi ucsi_acpi usbhid uvcvideo video videobuf2_common videobuf2_memops videobuf2_v4l2 videobuf2_vmalloc videodev virt_dma wacom wmi wmi_bmof x86_pkg_temp_thermal x_tables xhci_pci xhci_pci_renesas !!Sysfs Files !!----------- /sys/class/sound/hwC0D0/init_pin_configs: 0x12 0x411111f0 0x13 0x411111f0 0x14 0x90170110 0x17 0x411111f0 0x18 0x411111f0 0x19 0x03a11030 0x1a 0x411111f0 0x1b 0x411111f0 0x1d 0x40471a6d 0x1e 0x411111f0 0x21 0x03211020 /sys/class/sound/hwC0D0/driver_pin_configs: /sys/class/sound/hwC0D0/user_pin_configs: /sys/class/sound/hwC0D0/init_verbs: /sys/class/sound/hwC0D0/hints: /sys/class/sound/hwC0D2/init_pin_configs: 0x04 0x18560010 0x06 0x18560010 0x08 0x18560010 0x0a 0x18560010 0x0b 0x18560010 0x0c 0x18560010 0x0d 0x18560010 0x0e 0x18560010 0x0f 0x18560010 /sys/class/sound/hwC0D2/driver_pin_configs: /sys/class/sound/hwC0D2/user_pin_configs: /sys/class/sound/hwC0D2/init_verbs: /sys/class/sound/hwC0D2/hints: !!ALSA/HDA dmesg !!-------------- !!Packages installed !!-------------------- ii alsa-topology-conf 1.2.3-1 all ALSA topology configuration files ii alsa-ucm-conf 1.2.2-1ubuntu5 all ALSA Use Case Manager configuration files ii alsa-utils 1.2.3-1ubuntu1 amd64 Utilities for configuring and using ALSA
(In reply to Jack S from comment #95) > (In reply to Jaroslav Kysela from comment #94) > > (In reply to Jack S from comment #93) > > > > > options snd-hda-intel model=auto > > > > > seems to have fixed it, so perhaps this is not the same bug after all > (and > > I > > > get to keep my laptop!). > > > > Something seems broken with the autodetection. Could you attach your > > 'alsa-info.sh --no-upload' output? > > Certainly -- here it is! > PS this is after applying the fix, let me know if you need me to unfix it and do the same.
I'm running Arch (5.11.5-arch1-1) on a Lenovo Yoga 7i and I managed to get audio to work with Realtek ALC287 under certain circumstances. It works only after I suspend to RAM, and it disappears within around 7 seconds of not playing any audio (playing it muted is enough to keep it alive). I also have to start the playback within 7 seconds of resuming from suspend, or alternatively keep it running when suspending. It does not work after suspending to disk, suspending to idle, or rebooting, but hybrid-sleep works. I did not have to blacklist or otherwise configure related kernel modules in /etc/modprobe.d, but I did have to enable S3 sleep by manipulating the DSDT table following https://wiki.archlinux.org/index.php/DSDT. Now I did not really know what I was doing because the patch in the article did not apply to the table on my system; I only changed a line reading "Name (SS3, Zero)" into "Name (SS3, One)", but it worked. Incidentally my brightness keys are only recognized when suspending to RAM or disk, so it seems like there is some necessary initialization going on that are only correctly carried out during certain sleep states. Here is a dmesg log, where I did the following: start playing some audio (no sound) # echo s2idle > /sys/power/mem_sleep # echo mem > /sys/power/state waking up (no sound) # echo deep > /sys/power/mem_sleep # echo mem > /sys/power/state waking up (audio starts playing) pausing and resuming after 7 seconds (no sound) [ 2694.326411] PM: suspend entry (s2idle) [ 2694.327335] Filesystems sync: 0.000 seconds [ 2694.328229] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 2694.330054] OOM killer disabled. [ 2694.330055] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 2694.331250] printk: Suspending console(s) (use no_console_suspend to debug) [ 2695.134660] ACPI: EC: interrupt blocked [ 2697.927155] ACPI: EC: interrupt unblocked [ 2698.778671] pcieport 10000:e0:1d.0: can't derive routing for PCI INT A [ 2698.778677] nvme 10000:e1:00.0: PCI INT A: no GSI [ 2698.784394] nvme nvme0: 8/0/0 default/read/poll queues [ 2699.383146] OOM killer enabled. [ 2699.383149] Restarting tasks ... [ 2699.384141] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915]) [ 2699.385242] done. [ 2699.581393] thermal thermal_zone6: failed to read out thermal zone (-61) [ 2699.582054] PM: suspend exit [ 2716.865106] PM: suspend entry (deep) [ 2716.866184] Filesystems sync: 0.001 seconds [ 2716.866842] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 2716.868785] OOM killer disabled. [ 2716.868786] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 2716.870059] printk: Suspending console(s) (use no_console_suspend to debug) [ 2717.755405] ACPI: EC: interrupt blocked [ 2717.793696] ACPI: Preparing to enter system sleep state S3 [ 2717.807740] ACPI: EC: event blocked [ 2717.807741] ACPI: EC: EC stopped [ 2717.807742] PM: Saving platform NVS memory [ 2717.807869] Disabling non-boot CPUs ... [ 2717.808450] migrate_one_irq: 4 callbacks suppressed [ 2717.808454] IRQ149: set affinity failed(-22). [ 2717.809504] smpboot: CPU 1 is now offline [ 2717.811931] IRQ149: set affinity failed(-22). [ 2717.812998] smpboot: CPU 2 is now offline [ 2717.814258] IRQ149: set affinity failed(-22). [ 2717.815316] smpboot: CPU 3 is now offline [ 2717.817558] IRQ149: set affinity failed(-22). [ 2717.818601] smpboot: CPU 4 is now offline [ 2717.820319] IRQ149: set affinity failed(-22). [ 2717.821351] smpboot: CPU 5 is now offline [ 2717.823171] IRQ149: set affinity failed(-22). [ 2717.824199] smpboot: CPU 6 is now offline [ 2717.824753] IRQ149: set affinity failed(-22). [ 2717.825784] smpboot: CPU 7 is now offline [ 2717.832642] ACPI: Low-level resume complete [ 2717.832773] ACPI: EC: EC started [ 2717.832774] PM: Restoring platform NVS memory [ 2717.833866] Enabling non-boot CPUs ... [ 2717.833920] x86: Booting SMP configuration: [ 2717.833921] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 2717.834897] CPU1 is up [ 2717.834930] smpboot: Booting Node 0 Processor 2 APIC 0x4 [ 2717.836021] CPU2 is up [ 2717.836051] smpboot: Booting Node 0 Processor 3 APIC 0x6 [ 2717.837138] CPU3 is up [ 2717.837169] smpboot: Booting Node 0 Processor 4 APIC 0x1 [ 2717.838265] CPU4 is up [ 2717.838287] smpboot: Booting Node 0 Processor 5 APIC 0x3 [ 2717.839239] CPU5 is up [ 2717.839269] smpboot: Booting Node 0 Processor 6 APIC 0x5 [ 2717.840327] CPU6 is up [ 2717.840348] smpboot: Booting Node 0 Processor 7 APIC 0x7 [ 2717.841434] CPU7 is up [ 2717.843982] ACPI: Waking up from system sleep state S3 [ 2717.847213] ACPI: EC: interrupt unblocked [ 2718.095228] ACPI: EC: event unblocked [ 2718.095906] pcieport 10000:e0:1d.0: can't derive routing for PCI INT A [ 2718.095911] nvme 10000:e1:00.0: PCI INT A: no GSI [ 2718.108513] usb usb1: root hub lost power or was reset [ 2718.108526] usb usb2: root hub lost power or was reset [ 2718.166723] nvme nvme0: 8/0/0 default/read/poll queues [ 2718.348451] usb 3-9: reset high-speed USB device number 3 using xhci_hcd [ 2718.611863] usb 3-10: reset full-speed USB device number 4 using xhci_hcd [ 2718.660745] ish-hid {33AECD58-B679-4E54-9BD9-A04D34F0C226}: [hid-ish]: enum_devices_done OK, num_hid_devices=2 [ 2718.875230] usb 3-8: reset high-speed USB device number 2 using xhci_hcd [ 2719.032790] acpi LNXPOWER:06: Turning OFF [ 2719.034182] OOM killer enabled. [ 2719.034184] Restarting tasks ... done. [ 2719.035966] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915]) [ 2719.036941] thermal thermal_zone6: failed to read out thermal zone (-61) [ 2719.081890] audit: type=1130 audit(1615728121.246:123): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 2719.131666] PM: suspend exit [ 2719.132650] Bluetooth: hci0: Bootloader revision 0.4 build 0 week 30 2018 [ 2719.133690] Bluetooth: hci0: Device revision is 2 [ 2719.133696] Bluetooth: hci0: Secure boot is enabled [ 2719.133698] Bluetooth: hci0: OTP lock is enabled [ 2719.133700] Bluetooth: hci0: API lock is enabled [ 2719.133701] Bluetooth: hci0: Debug lock is disabled [ 2719.133702] Bluetooth: hci0: Minimum firmware build 1 week 10 2014 [ 2719.133986] Bluetooth: hci0: Found device firmware: intel/ibt-19-0-4.sfi [ 2720.728153] Bluetooth: hci0: Waiting for firmware download to complete [ 2720.728635] Bluetooth: hci0: Firmware loaded in 1559382 usecs [ 2720.728662] Bluetooth: hci0: Waiting for device to boot [ 2720.746620] Bluetooth: hci0: Device booted in 17562 usecs [ 2720.746648] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-19-0-4.ddc [ 2720.748628] Bluetooth: hci0: Applying Intel DDC parameters completed [ 2720.751627] Bluetooth: hci0: Firmware revision 0.0 build 26 week 3 2021 [ 2724.086521] audit: type=1131 audit(1615728126.250:124): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 2750.480471] audit: type=1101 audit(1615728152.643:125): pid=66993 uid=1000 auid=1000 ses=1 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="p" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/5 res=success' [ 2750.481116] audit: type=1110 audit(1615728152.643:126): pid=66993 uid=1000 auid=1000 ses=1 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/5 res=success' [ 2750.481311] audit: type=1105 audit(1615728152.646:127): pid=66993 uid=1000 auid=1000 ses=1 msg='op=PAM:session_open grantors=pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/5 res=success' alsa-info.sh: http://alsa-project.org/db/?f=301a28d975ddbb2e2ea6631dcf59a236db05467d
I don't have any sound on my Lenovo Yoga 7i 15" with Fedora 33. Tried Suse, Ubuntu and Mint as well and it is same result.
i would like to attach myself to the problem. New Lenovo Legion 7, no Sound on Manjaro or Ubuntu, not on Live-USB, not on installed OS. Headphones working perfectly, Speakers giving no sound at all. Has there been any kind of solution by now? I am still in my 30-days trial-period, am very happy with this machine, but do all my development for work on linux. if possible, i would love to avoid sending it back and buy another machine.
Did anyone else with the problem try my "workaround" from comment #97? It's actually not too bad, I just suspend whenever I need audio from my speakers and play some music muted in the background in a loop to keep it alive in case playback is interrupted. Not perfect but usable.
This workaround doesn't work with the Legion 7i, unfortunately. On 4/8/21 12:31 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #100 from wave (zanto98@yahoo.de) --- > Did anyone else with the problem try my "workaround" from comment #97? It's > actually not too bad, I just suspend whenever I need audio from my speakers > and > play some music muted in the background in a loop to keep it alive in case > playback is interrupted. Not perfect but usable. >
(In reply to Cameron from comment #101) > This workaround doesn't work with the Legion 7i, unfortunately. > > On 4/8/21 12:31 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #100 from wave (zanto98@yahoo.de) --- > > Did anyone else with the problem try my "workaround" from comment #97? It's > > actually not too bad, I just suspend whenever I need audio from my speakers > > and > > play some music muted in the background in a loop to keep it alive in case > > playback is interrupted. Not perfect but usable. > > But you do get S3 sleep when suspending or managed to activate it?
Yes: [122708.265368] ACPI: Preparing to enter system sleep state S3 [122708.333271] ACPI: Waking up from system sleep state S3
(In reply to wave from comment #100) > Did anyone else with the problem try my "workaround" from comment #97? It's > actually not too bad, I just suspend whenever I need audio from my speakers > and play some music muted in the background in a loop to keep it alive in > case playback is interrupted. Not perfect but usable. I have 14inch yoga 7i, and unfortunately it doesn't work for me. I am running 5.10 kernel
(In reply to chenyh570 from comment #104) > (In reply to wave from comment #100) > > Did anyone else with the problem try my "workaround" from comment #97? It's > > actually not too bad, I just suspend whenever I need audio from my speakers > > and play some music muted in the background in a loop to keep it alive in > > case playback is interrupted. Not perfect but usable. > > I have 14inch yoga 7i, and unfortunately it doesn't work for me. I am > running 5.10 kernel I have the same model and it worked with the same kernel on Arch. Which OS did you try? Unfortunately kernel 5.11.12 broke my S3 sleep again and my previous fix doesn't work, completely breaking speaker audio for me again.
(In reply to wave from comment #105) > (In reply to chenyh570 from comment #104) > > (In reply to wave from comment #100) > > > Did anyone else with the problem try my "workaround" from comment #97? > It's > > > actually not too bad, I just suspend whenever I need audio from my > speakers > > > and play some music muted in the background in a loop to keep it alive in > > > case playback is interrupted. Not perfect but usable. > > > > I have 14inch yoga 7i, and unfortunately it doesn't work for me. I am > > running 5.10 kernel > > I have the same model and it worked with the same kernel on Arch. Which OS > did you try? > Unfortunately kernel 5.11.12 broke my S3 sleep again and my previous fix > doesn't work, completely breaking speaker audio for me again. I am running Ubuntu 20.04.2LTS, and I rolled back to kernel version 5.10.04 recently from 5.11, as the 5.11.12 made my microphone un-usable.
(In reply to chenyh570 from comment #106) > (In reply to wave from comment #105) > > (In reply to chenyh570 from comment #104) > > > (In reply to wave from comment #100) > > > > Did anyone else with the problem try my "workaround" from comment #97? > > It's > > > > actually not too bad, I just suspend whenever I need audio from my > > speakers > > > > and play some music muted in the background in a loop to keep it alive > in > > > > case playback is interrupted. Not perfect but usable. > > > > > > I have 14inch yoga 7i, and unfortunately it doesn't work for me. I am > > > running 5.10 kernel > > > > I have the same model and it worked with the same kernel on Arch. Which OS > > did you try? > > Unfortunately kernel 5.11.12 broke my S3 sleep again and my previous fix > > doesn't work, completely breaking speaker audio for me again. > > I am running Ubuntu 20.04.2LTS, and I rolled back to kernel version 5.10.04 > recently from 5.11, as the 5.11.12 made my microphone un-usable. And what does cat /sys/power/mem_sleep say?
it saids "[s2idle]"
(In reply to chenyh570 from comment #108) > it saids "[s2idle]" In this case S3 sleep is deactivated. You could try to follow the section "Manual method" in https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_X1_Yoga_(Gen_3)#Enabling_S3_(with_BIOS_version_1.33_and_after), but instead of the patch it says there just replace Name (SS3, Zero) with Name (SS3, One) and in a line at the top like DefinitionBlock ("", "DSDT", 2, "LENOVO", "CB-01 ", 0x00000002) you need to increment the last number (change it to 0x00000003 in this case). This is what it took for me to get S3 sleep working, and then right after suspending the speakers work if playback is started within a magical window of a few seconds.
Hi, Same error with Lenovo Yoga 7i 14"intel. Tested with Ubuntu 20.04LTS and Ubuntu 21.04 and no sound from internal speakers, meanwhile the headphones works perfectly.
Created attachment 296485 [details] attachment-29900-0.html I am on Holiday and will be returning on April 29 2021
Hi, I have no idea why or how but internal speakers are working again on my Legion y730. Since i posted here back in december i didn't work on that issue and i realized they were working again only this morning (as my headphones were almost always plugged in) so it might have happened before. Only things i did this past few weeks that might have helped are : upgrade nvidia drivers, install winetricks, upgrade kernel to 5.8.0-50 generic If anyone needs more info on my system, i'm happy to help.
Just throwing it out there, issue exists for me on Legion Y740S OS: Linuxmint 20.1 ulyssa Kernel: x86_64 Linux 5.4.0-72-generic UBUNTU_CODENAME=focal also using ALC287.
Bert I have an error with Lenovo Legion-7 15IM05. I tried with Ubuntu 21.04, Mint 20.1, Manjaro, EndeavourOS. No sound from the internal speakers, the headphones works well. Using ALC287.
It's hard to understand how after almost a year we still don't have support for a high end laptop from a company like lenovo on linux. Especially on something as important as sound.
Just wanted to join in on the bandwagon here and follow any possible progress. Look forward to hearing sound from my laptop speakers someday in Ubuntu. ;) Lenovo Yoga 7-14ITL5 model # 82BH0006US Like others my headphones via 1/8 jack seem to work fine but not a lick of sound from the built in speakers. Lots of trying suggestions noted throughout this thread to no avail. Playing sound while selected on speakers it looks like there is activity just no sound of course. hdaJackRetask seems to not work at all on my unit and hangs quite often where you have to force quit. I was hopeful trying to use it might find some workaround. Anyway not sure if that says anything about the issue.
Same issue occurs on Lenovo Legion 7 16ACHg6 (2021) which is reported to have a Realtek ALC3306 when running Ubuntu 21.04 and upgraded 5.12 kernel. Note that sound does work through the headphones connector.
Thanks for the info! I was considering one of these since I want to replace this laptop, but was concerned that it would have the same issue. On 5/4/21 1:14 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > geoffrey.vl@gmail.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |geoffrey.vl@gmail.com > > --- Comment #117 from geoffrey.vl@gmail.com --- > Same issue occurs on Lenovo Legion 7 16ACHg6 (2021) which is reported to have > a > Realtek ALC3306 when running Ubuntu 21.04 and upgraded 5.12 kernel. > Note that sound does work through the headphones connector. >
Hello! Just want to add the exact same problem occur on my new Lenovo Think Book 13s Gen 2 i7. I also saw on the internet some people having this problem with HP or Dell, seems related also to the Tiger Lake arch... Really weird as everythin is working under Windows... I tried Ubuntu, Ubuntu Studio, Calculate (Gentoo), different kernel... I'm on Pop Os hwinfo --sound 16: PCI 1f.3: 0401 Multimedia audio controller [Created at pci.386] Unique ID: nS1_.Vo0SeQ2FdpF SysFS ID: /devices/pci0000:00/0000:00:1f.3 SysFS BusID: 0000:00:1f.3 Hardware Class: sound Model: "Intel Tiger Lake-LP Smart Sound Technology Audio Controller" Vendor: pci 0x8086 "Intel Corporation" Device: pci 0xa0c8 "Tiger Lake-LP Smart Sound Technology Audio Controller" SubVendor: pci 0x17aa "Lenovo" SubDevice: pci 0x3817 Revision: 0x20 Driver: "sof-audio-pci" Driver Modules: "snd_sof_pci" Memory Range: 0x601d180000-0x601d183fff (rw,non-prefetchable) Memory Range: 0x601d000000-0x601d0fffff (rw,non-prefetchable) IRQ: 165 (2860 events) Module Alias: "pci:v00008086d0000A0C8sv000017AAsd00003817bc04sc01i00" Driver Info #0: Driver Status: snd_hda_intel is active Driver Activation Cmd: "modprobe snd_hda_intel" Driver Info #1: Driver Status: snd_sof_pci is active Driver Activation Cmd: "modprobe snd_sof_pci" Config Status: cfg=new, avail=yes, need=no, active=unknown
Hi ! A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & 14ITL05 & 15ITL05 & 15ITL5 :) Sound from speakers works on Ubuntu 20.04.2LTS !!! (In reply to gurpreetsinghwalia5 from comment #86) > (In reply to juliusvonkohout from comment #85) > > (In reply to gurpreetsinghwalia5 from comment #84) > > > I have a lenovo yoga 7i. No sound from the in build speaker in ubuntu > > 20.10. > > > Is there a solution for this ??? > > > > Yes, install fedora 33 and update everything. Then at least the bottom > > speakers will work. > > Is there a debian distro that works ??? Need debian for work. It work on Ubuntu so will work on Debian. (In reply to Priyaranjan Sharma from comment #98) > I don't have any sound on my Lenovo Yoga 7i 15" with Fedora 33. > Tried Suse, Ubuntu and Mint as well and it is same result. (In reply to esanchez from comment #110) > Hi, > > Same error with Lenovo Yoga 7i 14"intel. > Tested with Ubuntu 20.04LTS and Ubuntu 21.04 and no sound from internal > speakers, meanwhile the headphones works perfectly. (In reply to chenyh570 from comment #104) > (In reply to wave from comment #100) > > Did anyone else with the problem try my "workaround" from comment #97? It's > > actually not too bad, I just suspend whenever I need audio from my speakers > > and play some music muted in the background in a loop to keep it alive in > > case playback is interrupted. Not perfect but usable. > > I have 14inch yoga 7i, and unfortunately it doesn't work for me. I am > running 5.10 kernel (In reply to lazertag from comment #116) > Just wanted to join in on the bandwagon here and follow any possible > progress. Look forward to hearing sound from my laptop speakers someday in > Ubuntu. ;) > > Lenovo Yoga 7-14ITL5 model # 82BH0006US > > Like others my headphones via 1/8 jack seem to work fine but not a lick of > sound from the built in speakers. Lots of trying suggestions noted > throughout this thread to no avail. Playing sound while selected on speakers > it looks like there is activity just no sound of course. > > hdaJackRetask seems to not work at all on my unit and hangs quite often > where you have to force quit. I was hopeful trying to use it might find > some workaround. Anyway not sure if that says anything about the issue. The problem is to enable the S3 : Try : cat /sys/power/mem_sleep You will have : "S2idle [deep]" Try : sudo dmesg |grep ACPI|grep supports You will have : [ 0.195933] ACPI: (supports S0 S3 S4 S5) If not, you will check how to enable S3 : ==== ENABLE S3 ==== We have to patch the DSDT table 1) Install iasl : sudo apt-get install acpica-tools cpio 2) make acpi directory mkdir acpi 3) Get a dump of ACPI DSDT table: sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml 4) Decompile the dump, which will generate a .dsl source based on the .aml ACPI machine language dump : iasl -d dsdt.aml 5) Make the patch file The patch is just for Yoga 7/7i : nano acpi.patch --- dsdt.dsl~ 2018-04-26 09:35:29.501055509 -0600 +++ dsdt.dsl 2018-04-26 09:36:23.769729028 -0600 @@ -18,7 +18,7 @@ * Compiler ID "INTL" * Compiler Version 0x20210105 (539033861) */ -DefinitionBlock ("", "DSDT", 2, "LENOVO", "CB-01 ", 0x00000002) +DefinitionBlock ("", "DSDT", 2, "LENOVO", "CB-01 ", 0x00000003) { External (_GPE.AL6F, MethodObj) // 0 Arguments External (_GPE.P0L6, MethodObj) // 0 Arguments @@ -516,7 +516,7 @@ Name (SS1, Zero) Name (SS2, Zero) - Name (SS3, Zero) + Name (SS3, One) Name (SS4, One) OperationRegion (GNVS, SystemMemory, 0x45AB8018, 0x0A9B) Field (GNVS, AnyAcc, Lock, Preserve) 6) Apply it against dsdt.dsl: patch --verbose < acpi.patch You will have : Hunk #1 succeeded at 18 with fuzz 2. Hunk #2 succeeded at 516. done (not sure because I'm already done it) Could anybody confirm the message, please ? 7) Recompile your patched version of the .dsl source : iasl -ve -tc dsdt.dsl 8) Create a CPIO archive with the correct structure, which GRUB can load on boot. We name the final image acpi_override and copy it into /boot/ : mkdir -p kernel/firmware/acpi cp dsdt.aml kernel/firmware/acpi find kernel | cpio -H newc --create > acpi_override cp acpi_override /boot 9) GRUB needs to boot the kernel with a parameter setting the deep sleep state as default. Edit /etc/default/grub and add the following : GRUB_CMDLINE_LINUX_DEFAULT="mem_sleep_default=deep" GRUB_EARLY_INITRD_LINUX_CUSTOM="/boot/acpi_override" 10) Regenerate the GRUB configuration : sudo update-grub If the second line of the previous step does not generate the grub to make the initrd lines look like "initrd /boot/acpi_override" in the beginning, then follow the next steps as normal. If it does generate those lines, skip to step 12. For me on Ubuntu it's not like this. 11) Tell GRUB to load the new DSDT table on boot in its configuration file usually located in /boot/grub/grub.cfg. Find the relevant GRUB menu entry and add the new image /boot/acpi_override to the initrd lines for the images that you want the s3 sleep to work in : sudo nano /boot/grub/grub.cfg initrd /boot/initrd.img-5.11.5-051105-generic BECOME : initrd /boot/acpi_override /boot/initrd.img-5.11.5-051105-generic Be sure to do it for all kernels ! 12) Reboot and enjoy having a laptop running Linux again... close the lid and the battery does not get drained in a few hours, also the battery no longer stays warm in sleep mode. To verify that things are working : Try : cat /sys/power/mem_sleep You will have : "S2idle [deep]" Try : sudo dmesg |grep ACPI|grep supports You will have : [ 0.195933] ACPI: (supports S0 S3 S4 S5) After we have to enable sound : ==== ENABLE SOUND ==== For me on Ubuntu 20.04, I have to use kernel 5.11.0 to 5.11.5, 5.11.6 don't work, 5.11.16 don't work to. Anybody say why ? So I sugest to try with 5.11.5 : https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11.5/. After could you try with you kernel, and share your kernel version, please ? You will don't have dummy out. For me : aplay -l gives : **** Liste des Périphériques Matériels PLAYBACK **** carte 0: sofhdadsp [sof-hda-dsp], périphérique 0: HDA Analog (*) [] sudo dmesg | grep -i audio gives : sof-audio-pci If it is ok, just have to : - play a song on VLC - suspend to ram - power on - the speakers work :) Like it is say, if you stop for 7 seconds, sound stop working. Work after many reboot. Ubuntu 21.04 live USB have jack/headphone work directly, so I think we have just enable the S3 for it. Working for you ? Original tutorial : https://wiki.archlinux.org/title/Lenovo_Yoga_7i French tutorial on Ubuntu 20.04 : https://doc.ubuntu-fr.org/lenovo_yoga_7_7i
Does your 14ITL05 even have 5 speakers like the 15ITL05? There are thre above the keyboard and 2 below the palm rest. Do you really know that it applies to it? On the 15ITL05 only the bass speakers above the keyboard are not working.
Hi, What is your model please ? For the Lenovo Support, and for the technical information, the Yoga 7i 14" & 15" are the same (the 15" just have 1 USB more), both have Dolby Atmos with 2 Speakers. I Think I have make a mistake with the Yoga Slim 7 14ITL05 & 15ITL05 with 3 speakers ("3 haut-parleurs (3 x 2W), Dolby Atmos"). IdeaPad 5 15ITL05 have the same reference, very strange ... with 2 speakers to like the 15ITL5. This code 14ITL05 or 15ITL05 don't have any result on Lenovo website, but I have see it in my BIOS dump. So I have suppose that is just another reference for the same computer. So sorry, visibly is not the same, and this number is for 2 different computers :( My post is for the Yoga 7i 14ITL5 and 15ITL5, but it seem we have the same, or similar BIOS, so the process to enable the S3 can be the same or really similar. The problem, for me, is to enable the S3, to have sound in any speaker. If you don't have sound in all speaker, is more a drivers problem, in my point of view. So this is not a solution for you, sorry. Or a mixing problem ?
(In reply to DavidLenovo from comment #120) > Hi ! > A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & 14ITL05 & > 15ITL05 & 15ITL5 :) > Sound from speakers works on Ubuntu 20.04.2LTS !!! > > (In reply to gurpreetsinghwalia5 from comment #86) > > (In reply to juliusvonkohout from comment #85) > > > (In reply to gurpreetsinghwalia5 from comment #84) > > > > I have a lenovo yoga 7i. No sound from the in build speaker in ubuntu > > > 20.10. > > > > Is there a solution for this ??? > > > > > > Yes, install fedora 33 and update everything. Then at least the bottom > > > speakers will work. > > > > Is there a debian distro that works ??? Need debian for work. > > It work on Ubuntu so will work on Debian. > > > (In reply to Priyaranjan Sharma from comment #98) > > I don't have any sound on my Lenovo Yoga 7i 15" with Fedora 33. > > Tried Suse, Ubuntu and Mint as well and it is same result. > > > (In reply to esanchez from comment #110) > > Hi, > > > > Same error with Lenovo Yoga 7i 14"intel. > > Tested with Ubuntu 20.04LTS and Ubuntu 21.04 and no sound from internal > > speakers, meanwhile the headphones works perfectly. > > > > (In reply to chenyh570 from comment #104) > > (In reply to wave from comment #100) > > > Did anyone else with the problem try my "workaround" from comment #97? > It's > > > actually not too bad, I just suspend whenever I need audio from my > speakers > > > and play some music muted in the background in a loop to keep it alive in > > > case playback is interrupted. Not perfect but usable. > > > > I have 14inch yoga 7i, and unfortunately it doesn't work for me. I am > > running 5.10 kernel > > > > (In reply to lazertag from comment #116) > > Just wanted to join in on the bandwagon here and follow any possible > > progress. Look forward to hearing sound from my laptop speakers someday in > > Ubuntu. ;) > > > > Lenovo Yoga 7-14ITL5 model # 82BH0006US > > > > Like others my headphones via 1/8 jack seem to work fine but not a lick of > > sound from the built in speakers. Lots of trying suggestions noted > > throughout this thread to no avail. Playing sound while selected on > speakers > > it looks like there is activity just no sound of course. > > > > hdaJackRetask seems to not work at all on my unit and hangs quite often > > where you have to force quit. I was hopeful trying to use it might find > > some workaround. Anyway not sure if that says anything about the issue. > > > > The problem is to enable the S3 : > Try : cat /sys/power/mem_sleep > You will have : "S2idle [deep]" > Try : sudo dmesg |grep ACPI|grep supports > You will have : [ 0.195933] ACPI: (supports S0 S3 S4 S5) > > If not, you will check how to enable S3 : > ==== ENABLE S3 ==== > We have to patch the DSDT table > 1) Install iasl : > sudo apt-get install acpica-tools cpio > > 2) make acpi directory > mkdir acpi > > 3) Get a dump of ACPI DSDT table: > sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml > > 4) Decompile the dump, which will generate a .dsl source based on the .aml > ACPI machine language dump : > iasl -d dsdt.aml > > 5) Make the patch file > The patch is just for Yoga 7/7i : > nano acpi.patch > --- dsdt.dsl~ 2018-04-26 09:35:29.501055509 -0600 > +++ dsdt.dsl 2018-04-26 09:36:23.769729028 -0600 > @@ -18,7 +18,7 @@ > * Compiler ID "INTL" > * Compiler Version 0x20210105 (539033861) > */ > -DefinitionBlock ("", "DSDT", 2, "LENOVO", "CB-01 ", 0x00000002) > +DefinitionBlock ("", "DSDT", 2, "LENOVO", "CB-01 ", 0x00000003) > { > External (_GPE.AL6F, MethodObj) // 0 Arguments > External (_GPE.P0L6, MethodObj) // 0 Arguments > @@ -516,7 +516,7 @@ > > Name (SS1, Zero) > Name (SS2, Zero) > - Name (SS3, Zero) > + Name (SS3, One) > Name (SS4, One) > OperationRegion (GNVS, SystemMemory, 0x45AB8018, 0x0A9B) > Field (GNVS, AnyAcc, Lock, Preserve) > > 6) Apply it against dsdt.dsl: patch --verbose < acpi.patch > You will have : > Hunk #1 succeeded at 18 with fuzz 2. > Hunk #2 succeeded at 516. > done > (not sure because I'm already done it) Could anybody confirm the message, > please ? > > 7) Recompile your patched version of the .dsl source : > iasl -ve -tc dsdt.dsl > > 8) Create a CPIO archive with the correct structure, which GRUB can load on > boot. We name the final image acpi_override and copy it into /boot/ : > mkdir -p kernel/firmware/acpi > cp dsdt.aml kernel/firmware/acpi > find kernel | cpio -H newc --create > acpi_override > cp acpi_override /boot > > 9) GRUB needs to boot the kernel with a parameter setting the deep sleep > state as default. Edit /etc/default/grub and add the following : > GRUB_CMDLINE_LINUX_DEFAULT="mem_sleep_default=deep" > GRUB_EARLY_INITRD_LINUX_CUSTOM="/boot/acpi_override" > > 10) Regenerate the GRUB configuration : > sudo update-grub > > If the second line of the previous step does not generate the grub to make > the initrd lines look like "initrd /boot/acpi_override" in the beginning, > then follow the next steps as normal. If it does generate those lines, skip > to step 12. For me on Ubuntu it's not like this. > > 11) Tell GRUB to load the new DSDT table on boot in its configuration file > usually located in /boot/grub/grub.cfg. Find the relevant GRUB menu entry > and add the new image /boot/acpi_override to the initrd lines for the images > that you want the s3 sleep to work in : > sudo nano /boot/grub/grub.cfg > initrd /boot/initrd.img-5.11.5-051105-generic > BECOME : > initrd /boot/acpi_override /boot/initrd.img-5.11.5-051105-generic > > Be sure to do it for all kernels ! > > 12) Reboot and enjoy having a laptop running Linux again... close the lid > and the battery does not get drained in a few hours, also the battery no > longer stays warm in sleep mode. To verify that things are working : > Try : cat /sys/power/mem_sleep > You will have : "S2idle [deep]" > Try : sudo dmesg |grep ACPI|grep supports > You will have : [ 0.195933] ACPI: (supports S0 S3 S4 S5) > > > After we have to enable sound : > ==== ENABLE SOUND ==== > For me on Ubuntu 20.04, I have to use kernel 5.11.0 to 5.11.5, 5.11.6 don't > work, 5.11.16 don't work to. Anybody say why ? > So I sugest to try with 5.11.5 : > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11.5/. > After could you try with you kernel, and share your kernel version, please ? > > You will don't have dummy out. > For me : > aplay -l > gives : > **** Liste des Périphériques Matériels PLAYBACK **** > carte 0: sofhdadsp [sof-hda-dsp], périphérique 0: HDA Analog (*) [] > > sudo dmesg | grep -i audio > gives : sof-audio-pci > > If it is ok, just have to : > - play a song on VLC > - suspend to ram > - power on > - the speakers work :) > > Like it is say, if you stop for 7 seconds, sound stop working. > > Work after many reboot. > > Ubuntu 21.04 live USB have jack/headphone work directly, so I think we have > just enable the S3 for it. > > Working for you ? > > Original tutorial : https://wiki.archlinux.org/title/Lenovo_Yoga_7i > French tutorial on Ubuntu 20.04 : https://doc.ubuntu-fr.org/lenovo_yoga_7_7i Questions if you don't mind. Step #2 you create this acpi dir but then it doesn't appear to get used? Did you intend for the readers to enter that directory before starting into step 3 so everything is done form it? Step #6 you have us apply the patch to the dsdt.dsl file. Does the 'patch' command just somehow know to apply or use that that file or do we have to identify it as a source/target somehow?
(In reply to lazertag from comment #123) > (In reply to DavidLenovo from comment #120) > > Questions if you don't mind. > > > Step #2 you create this acpi dir but then it doesn't appear to get used? > Did you intend for the readers to enter that directory before starting into > step 3 so everything is done form it? > > Step #6 you have us apply the patch to the dsdt.dsl file. Does the 'patch' > command just somehow know to apply or use that that file or do we have to > identify it as a source/target somehow? I just noted the answer to my second question, it's part of your patch code. sorry, never mind that one.
On the 13S Gen 2, there is only 2 speakers, and S3 is activated...
(In reply to lazertag from comment #123) > (In reply to DavidLenovo from comment #120) > > Hi ! > Questions if you don't mind. > > > Step #2 you create this acpi dir but then it doesn't appear to get used? > Did you intend for the readers to enter that directory before starting into > step 3 so everything is done form it? > > Step #6 you have us apply the patch to the dsdt.dsl file. Does the 'patch' > command just somehow know to apply or use that that file or do we have to > identify it as a source/target somehow? Hi, Sorry, in step #2 after makdir acpi, go in the directory : cd acpi. You can do it in another directory. Yes you have to enter in the acpi directory before the step 3. > I just noted the answer to my second question, it's part of your patch code. > sorry, never mind that one. Step #6 : Yes the patch file have the name of the destination file. I have discover the patch command few day ago, and had the same question !
(In reply to Vincent Morel from comment #125) > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... Hi, I have similar result in hwinfo --sound, but it's not exactly the same card. Your have only 2 speakers working ? Ore no one ? You have try Ubuntu 20.04 with kernel 5.11.5 ?
(In reply to DavidLenovo from comment #120) > Hi ! > A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & 14ITL05 & > 15ITL05 & 15ITL5 :) > Sound from speakers works on Ubuntu 20.04.2LTS !!! > > (In reply to gurpreetsinghwalia5 from comment #86) > > (In reply to juliusvonkohout from comment #85) > > > (In reply to gurpreetsinghwalia5 from comment #84) > > > > I have a lenovo yoga 7i. No sound from the in build speaker in ubuntu > > > 20.10. > > > > Is there a solution for this ??? > > > > > > Yes, install fedora 33 and update everything. Then at least the bottom > > > speakers will work. > > > > Is there a debian distro that works ??? Need debian for work. > > It work on Ubuntu so will work on Debian. > > > (In reply to Priyaranjan Sharma from comment #98) > > I don't have any sound on my Lenovo Yoga 7i 15" with Fedora 33. > > Tried Suse, Ubuntu and Mint as well and it is same result. > > > (In reply to esanchez from comment #110) > > Hi, > > > > Same error with Lenovo Yoga 7i 14"intel. > > Tested with Ubuntu 20.04LTS and Ubuntu 21.04 and no sound from internal > > speakers, meanwhile the headphones works perfectly. > > > > (In reply to chenyh570 from comment #104) > > (In reply to wave from comment #100) > > > Did anyone else with the problem try my "workaround" from comment #97? > It's > > > actually not too bad, I just suspend whenever I need audio from my > speakers > > > and play some music muted in the background in a loop to keep it alive in > > > case playback is interrupted. Not perfect but usable. > > > > I have 14inch yoga 7i, and unfortunately it doesn't work for me. I am > > running 5.10 kernel > > > > (In reply to lazertag from comment #116) > > Just wanted to join in on the bandwagon here and follow any possible > > progress. Look forward to hearing sound from my laptop speakers someday in > > Ubuntu. ;) > > > > Lenovo Yoga 7-14ITL5 model # 82BH0006US > > > > Like others my headphones via 1/8 jack seem to work fine but not a lick of > > sound from the built in speakers. Lots of trying suggestions noted > > throughout this thread to no avail. Playing sound while selected on > speakers > > it looks like there is activity just no sound of course. > > > > hdaJackRetask seems to not work at all on my unit and hangs quite often > > where you have to force quit. I was hopeful trying to use it might find > > some workaround. Anyway not sure if that says anything about the issue. > > > > The problem is to enable the S3 : > Try : cat /sys/power/mem_sleep > You will have : "S2idle [deep]" > Try : sudo dmesg |grep ACPI|grep supports > You will have : [ 0.195933] ACPI: (supports S0 S3 S4 S5) > > If not, you will check how to enable S3 : > ==== ENABLE S3 ==== > We have to patch the DSDT table > 1) Install iasl : > sudo apt-get install acpica-tools cpio > > 2) make acpi directory > mkdir acpi > > 3) Get a dump of ACPI DSDT table: > sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml > > 4) Decompile the dump, which will generate a .dsl source based on the .aml > ACPI machine language dump : > iasl -d dsdt.aml > > 5) Make the patch file > The patch is just for Yoga 7/7i : > nano acpi.patch > --- dsdt.dsl~ 2018-04-26 09:35:29.501055509 -0600 > +++ dsdt.dsl 2018-04-26 09:36:23.769729028 -0600 > @@ -18,7 +18,7 @@ > * Compiler ID "INTL" > * Compiler Version 0x20210105 (539033861) > */ > -DefinitionBlock ("", "DSDT", 2, "LENOVO", "CB-01 ", 0x00000002) > +DefinitionBlock ("", "DSDT", 2, "LENOVO", "CB-01 ", 0x00000003) > { > External (_GPE.AL6F, MethodObj) // 0 Arguments > External (_GPE.P0L6, MethodObj) // 0 Arguments > @@ -516,7 +516,7 @@ > > Name (SS1, Zero) > Name (SS2, Zero) > - Name (SS3, Zero) > + Name (SS3, One) > Name (SS4, One) > OperationRegion (GNVS, SystemMemory, 0x45AB8018, 0x0A9B) > Field (GNVS, AnyAcc, Lock, Preserve) > > 6) Apply it against dsdt.dsl: patch --verbose < acpi.patch > You will have : > Hunk #1 succeeded at 18 with fuzz 2. > Hunk #2 succeeded at 516. > done > (not sure because I'm already done it) Could anybody confirm the message, > please ? > > 7) Recompile your patched version of the .dsl source : > iasl -ve -tc dsdt.dsl > > 8) Create a CPIO archive with the correct structure, which GRUB can load on > boot. We name the final image acpi_override and copy it into /boot/ : > mkdir -p kernel/firmware/acpi > cp dsdt.aml kernel/firmware/acpi > find kernel | cpio -H newc --create > acpi_override > cp acpi_override /boot > > 9) GRUB needs to boot the kernel with a parameter setting the deep sleep > state as default. Edit /etc/default/grub and add the following : > GRUB_CMDLINE_LINUX_DEFAULT="mem_sleep_default=deep" > GRUB_EARLY_INITRD_LINUX_CUSTOM="/boot/acpi_override" > > 10) Regenerate the GRUB configuration : > sudo update-grub > > If the second line of the previous step does not generate the grub to make > the initrd lines look like "initrd /boot/acpi_override" in the beginning, > then follow the next steps as normal. If it does generate those lines, skip > to step 12. For me on Ubuntu it's not like this. > > 11) Tell GRUB to load the new DSDT table on boot in its configuration file > usually located in /boot/grub/grub.cfg. Find the relevant GRUB menu entry > and add the new image /boot/acpi_override to the initrd lines for the images > that you want the s3 sleep to work in : > sudo nano /boot/grub/grub.cfg > initrd /boot/initrd.img-5.11.5-051105-generic > BECOME : > initrd /boot/acpi_override /boot/initrd.img-5.11.5-051105-generic > > Be sure to do it for all kernels ! > > 12) Reboot and enjoy having a laptop running Linux again... close the lid > and the battery does not get drained in a few hours, also the battery no > longer stays warm in sleep mode. To verify that things are working : > Try : cat /sys/power/mem_sleep > You will have : "S2idle [deep]" > Try : sudo dmesg |grep ACPI|grep supports > You will have : [ 0.195933] ACPI: (supports S0 S3 S4 S5) > > > After we have to enable sound : > ==== ENABLE SOUND ==== > For me on Ubuntu 20.04, I have to use kernel 5.11.0 to 5.11.5, 5.11.6 don't > work, 5.11.16 don't work to. Anybody say why ? > So I sugest to try with 5.11.5 : > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11.5/. > After could you try with you kernel, and share your kernel version, please ? > > You will don't have dummy out. > For me : > aplay -l > gives : > **** Liste des Périphériques Matériels PLAYBACK **** > carte 0: sofhdadsp [sof-hda-dsp], périphérique 0: HDA Analog (*) [] > > sudo dmesg | grep -i audio > gives : sof-audio-pci > > If it is ok, just have to : > - play a song on VLC > - suspend to ram > - power on > - the speakers work :) > > Like it is say, if you stop for 7 seconds, sound stop working. > > Work after many reboot. > > Ubuntu 21.04 live USB have jack/headphone work directly, so I think we have > just enable the S3 for it. > > Working for you ? > > Original tutorial : https://wiki.archlinux.org/title/Lenovo_Yoga_7i > French tutorial on Ubuntu 20.04 : https://doc.ubuntu-fr.org/lenovo_yoga_7_7i Wondeful news to me, basically it works. Yet, I was trying to make this as automatic as possible, so I was trying the bash script as descipt in the tutorial. Hower it keeps throwing: tee: /dev/audio: Connection refused to me. Do you know what is this about? Cheers!
(In reply to DavidLenovo from comment #127) > (In reply to Vincent Morel from comment #125) > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > Hi, I have similar result in hwinfo --sound, but it's not exactly the same > card. > > Your have only 2 speakers working ? Ore no one ? > > You have try Ubuntu 20.04 with kernel 5.11.5 ? No speaker working (but headphone, hdmi... are working). I did not try kernel 5.11.5 (My Pop Os is in 5.11.0 but I remember trying Ubuntu 21.04 and there was no sound also).
(In reply to chenyh570 from comment #129) > (In reply to DavidLenovo from comment #120) > > Hi ! > > A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & 14ITL05 & > > 15ITL05 & 15ITL5 :) > > Sound from speakers works on Ubuntu 20.04.2LTS !!! > > > > (In reply to gurpreetsinghwalia5 from comment #86) > > > (In reply to juliusvonkohout from comment #85) > > > > (In reply to gurpreetsinghwalia5 from comment #84) > > > > > I have a lenovo yoga 7i. No sound from the in build speaker in ubuntu > > > > 20.10. > > > > > Is there a solution for this ??? > > > > > > > > Yes, install fedora 33 and update everything. Then at least the bottom > > > > speakers will work. > > > > > > Is there a debian distro that works ??? Need debian for work. > > > > It work on Ubuntu so will work on Debian. > > > > > > (In reply to Priyaranjan Sharma from comment #98) > > > I don't have any sound on my Lenovo Yoga 7i 15" with Fedora 33. > > > Tried Suse, Ubuntu and Mint as well and it is same result. > > > > > > (In reply to esanchez from comment #110) > > > Hi, > > > > > > Same error with Lenovo Yoga 7i 14"intel. > > > Tested with Ubuntu 20.04LTS and Ubuntu 21.04 and no sound from internal > > > speakers, meanwhile the headphones works perfectly. > > > > > > > > (In reply to chenyh570 from comment #104) > > > (In reply to wave from comment #100) > > > > Did anyone else with the problem try my "workaround" from comment #97? > > It's > > > > actually not too bad, I just suspend whenever I need audio from my > > speakers > > > > and play some music muted in the background in a loop to keep it alive > in > > > > case playback is interrupted. Not perfect but usable. > > > > > > I have 14inch yoga 7i, and unfortunately it doesn't work for me. I am > > > running 5.10 kernel > > > > > > > > (In reply to lazertag from comment #116) > > > Just wanted to join in on the bandwagon here and follow any possible > > > progress. Look forward to hearing sound from my laptop speakers someday > in > > > Ubuntu. ;) > > > > > > Lenovo Yoga 7-14ITL5 model # 82BH0006US > > > > > > Like others my headphones via 1/8 jack seem to work fine but not a lick > of > > > sound from the built in speakers. Lots of trying suggestions noted > > > throughout this thread to no avail. Playing sound while selected on > > speakers > > > it looks like there is activity just no sound of course. > > > > > > hdaJackRetask seems to not work at all on my unit and hangs quite often > > > where you have to force quit. I was hopeful trying to use it might find > > > some workaround. Anyway not sure if that says anything about the issue. > > > > > > > > The problem is to enable the S3 : > > Try : cat /sys/power/mem_sleep > > You will have : "S2idle [deep]" > > Try : sudo dmesg |grep ACPI|grep supports > > You will have : [ 0.195933] ACPI: (supports S0 S3 S4 S5) > > > > If not, you will check how to enable S3 : > > ==== ENABLE S3 ==== > > We have to patch the DSDT table > > 1) Install iasl : > > sudo apt-get install acpica-tools cpio > > > > 2) make acpi directory > > mkdir acpi > > > > 3) Get a dump of ACPI DSDT table: > > sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml > > > > 4) Decompile the dump, which will generate a .dsl source based on the .aml > > ACPI machine language dump : > > iasl -d dsdt.aml > > > > 5) Make the patch file > > The patch is just for Yoga 7/7i : > > nano acpi.patch > > --- dsdt.dsl~ 2018-04-26 09:35:29.501055509 -0600 > > +++ dsdt.dsl 2018-04-26 09:36:23.769729028 -0600 > > @@ -18,7 +18,7 @@ > > * Compiler ID "INTL" > > * Compiler Version 0x20210105 (539033861) > > */ > > -DefinitionBlock ("", "DSDT", 2, "LENOVO", "CB-01 ", 0x00000002) > > +DefinitionBlock ("", "DSDT", 2, "LENOVO", "CB-01 ", 0x00000003) > > { > > External (_GPE.AL6F, MethodObj) // 0 Arguments > > External (_GPE.P0L6, MethodObj) // 0 Arguments > > @@ -516,7 +516,7 @@ > > > > Name (SS1, Zero) > > Name (SS2, Zero) > > - Name (SS3, Zero) > > + Name (SS3, One) > > Name (SS4, One) > > OperationRegion (GNVS, SystemMemory, 0x45AB8018, 0x0A9B) > > Field (GNVS, AnyAcc, Lock, Preserve) > > > > 6) Apply it against dsdt.dsl: patch --verbose < acpi.patch > > You will have : > > Hunk #1 succeeded at 18 with fuzz 2. > > Hunk #2 succeeded at 516. > > done > > (not sure because I'm already done it) Could anybody confirm the message, > > please ? > > > > 7) Recompile your patched version of the .dsl source : > > iasl -ve -tc dsdt.dsl > > > > 8) Create a CPIO archive with the correct structure, which GRUB can load on > > boot. We name the final image acpi_override and copy it into /boot/ : > > mkdir -p kernel/firmware/acpi > > cp dsdt.aml kernel/firmware/acpi > > find kernel | cpio -H newc --create > acpi_override > > cp acpi_override /boot > > > > 9) GRUB needs to boot the kernel with a parameter setting the deep sleep > > state as default. Edit /etc/default/grub and add the following : > > GRUB_CMDLINE_LINUX_DEFAULT="mem_sleep_default=deep" > > GRUB_EARLY_INITRD_LINUX_CUSTOM="/boot/acpi_override" > > > > 10) Regenerate the GRUB configuration : > > sudo update-grub > > > > If the second line of the previous step does not generate the grub to make > > the initrd lines look like "initrd /boot/acpi_override" in the beginning, > > then follow the next steps as normal. If it does generate those lines, skip > > to step 12. For me on Ubuntu it's not like this. > > > > 11) Tell GRUB to load the new DSDT table on boot in its configuration file > > usually located in /boot/grub/grub.cfg. Find the relevant GRUB menu entry > > and add the new image /boot/acpi_override to the initrd lines for the > images > > that you want the s3 sleep to work in : > > sudo nano /boot/grub/grub.cfg > > initrd /boot/initrd.img-5.11.5-051105-generic > > BECOME : > > initrd /boot/acpi_override /boot/initrd.img-5.11.5-051105-generic > > > > Be sure to do it for all kernels ! > > > > 12) Reboot and enjoy having a laptop running Linux again... close the lid > > and the battery does not get drained in a few hours, also the battery no > > longer stays warm in sleep mode. To verify that things are working : > > Try : cat /sys/power/mem_sleep > > You will have : "S2idle [deep]" > > Try : sudo dmesg |grep ACPI|grep supports > > You will have : [ 0.195933] ACPI: (supports S0 S3 S4 S5) > > > > > > After we have to enable sound : > > ==== ENABLE SOUND ==== > > For me on Ubuntu 20.04, I have to use kernel 5.11.0 to 5.11.5, 5.11.6 don't > > work, 5.11.16 don't work to. Anybody say why ? > > So I sugest to try with 5.11.5 : > > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.11.5/. > > After could you try with you kernel, and share your kernel version, please > ? > > > > You will don't have dummy out. > > For me : > > aplay -l > > gives : > > **** Liste des Périphériques Matériels PLAYBACK **** > > carte 0: sofhdadsp [sof-hda-dsp], périphérique 0: HDA Analog (*) [] > > > > sudo dmesg | grep -i audio > > gives : sof-audio-pci > > > > If it is ok, just have to : > > - play a song on VLC > > - suspend to ram > > - power on > > - the speakers work :) > > > > Like it is say, if you stop for 7 seconds, sound stop working. > > > > Work after many reboot. > > > > Ubuntu 21.04 live USB have jack/headphone work directly, so I think we have > > just enable the S3 for it. > > > > Working for you ? > > > > Original tutorial : https://wiki.archlinux.org/title/Lenovo_Yoga_7i > > French tutorial on Ubuntu 20.04 : > https://doc.ubuntu-fr.org/lenovo_yoga_7_7i > > Wondeful news to me, basically it works. Yet, I was trying to make this as > automatic as possible, so I was trying the bash script as descipt in the > tutorial. Hower it keeps throwing: tee: /dev/audio: Connection refused to > me. Do you know what is this about? Cheers! First of all allow me to remark that this is exactly the solution that I talked about in comment #97 and which I tried to explain to you specifically in more detail in comment #107; in fact I wrote the archwiki article referred to in the comment. Now your problem seems to be related to permissions; perhaps you are running the whole command or padsp as sudo?
(In reply to DavidLenovo from comment #127) > (In reply to Vincent Morel from comment #125) > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > Hi, I have similar result in hwinfo --sound, but it's not exactly the same > card. > > Your have only 2 speakers working ? Ore no one ? > > You have try Ubuntu 20.04 with kernel 5.11.5 ? Just tried with kernel 5.11.5... No luck... How ACL3306 not recognise, can we find some spec or information about it? Seems Realtek codec information is nowhere to be found... :(
(In reply to Vincent Morel from comment #132) > (In reply to DavidLenovo from comment #127) > > (In reply to Vincent Morel from comment #125) > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the same > > card. > > > > Your have only 2 speakers working ? Ore no one ? > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > Just tried with kernel 5.11.5... No luck... > > How ACL3306 not recognise, can we find some spec or information about it? > Seems Realtek codec information is nowhere to be found... :( My unit is the Yoga 7-14ITL5 laptop (Ideapad) - Machine Type Model: 82BH0006US It is only a 2 speaker system, right and left. From a Windows 10 install on my device it is the ALC287. I see no reference in Windows of ALC3306. Lasty, sadly, none of the suggestions, be it using Arch or Ubuntu, have worked for myself to get sound from the speakers at any point.
(In reply to Vincent Morel from comment #130) > (In reply to DavidLenovo from comment #127) > > (In reply to Vincent Morel from comment #125) > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the same > > card. > > > > Your have only 2 speakers working ? Ore no one ? > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > No speaker working (but headphone, hdmi... are working). > > I did not try kernel 5.11.5 (My Pop Os is in 5.11.0 but I remember trying > Ubuntu 21.04 and there was no sound also). (In reply to Vincent Morel from comment #132) > (In reply to DavidLenovo from comment #127) > > (In reply to Vincent Morel from comment #125) > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the same > > card. > > > > Your have only 2 speakers working ? Ore no one ? > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > Just tried with kernel 5.11.5... No luck... > > How ACL3306 not recognise, can we find some spec or information about it? > Seems Realtek codec information is nowhere to be found... :( Could you recheck, please : cat /sys/power/mem_sleep sudo dmesg |grep ACPI|grep supports Do you have try, to play a long sound with VLC, y choose PulseAudio Server if it is available, on another session I just have sof-hda-dsp Speaker + Headphone (it work on both). If your change the sound output, stop and restart the sound. Let the sound playing and put in sleep, put the computer on, and the sound work. It lagging for me at the beginning, and after few seconds it is ok. You have ALC287 or ALC3306 ? You seem to have ALC3306, no ? Not sure Ubuntu is work well for it. I think your problem is to enable S3. It is probably not the same patch for you with you Lenovo Think Book 13s Gen 2. The patch is for Yoga 7i 14" and 15" The user Wave could you help me more I think, my knowledge is limited.
(In reply to wave from comment #131) > (In reply to chenyh570 from comment #129) > > (In reply to DavidLenovo from comment #120) > > > Hi ! > > > A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & 14ITL05 > & > > > 15ITL05 & 15ITL5 :) > > First of all allow me to remark that this is exactly the solution that I > talked about in comment #97 and which I tried to explain to you specifically > in more detail in comment #107; in fact I wrote the archwiki article > referred to in the comment. > > Now your problem seems to be related to permissions; perhaps you are running > the whole command or padsp as sudo? Sorry :( to don't mention you. Thanks a lot :), effectively you see the problem firstly and you try to put all of us in the right way. To be honest my knowledge is to limited to patch me alone. I had need the patch "key in hand", found after (put in my tutorial). I think other people, need the patch "key in hand", with more simple tutorial. I think your have lot of skill, and me (and probably other) just want simple solution (and can't do hard modification). I'm not sure to understand, your are the writer of the tutorial : https://wiki.archlinux.org/title/Lenovo_Yoga_7i ? I think we are lot of people, to don't have lot of knowledge, and need very simple procedure. And for me I see lot of people very skilled, like you, to be documentation not enough easy for us. This is why I make this tutorial, with almost all commands. For example the patch for the Yoga 7i (on Arch Wiki), don't have the beginning of the file : --- dsdt.dsl~ 2018-04-26 09:35:29.501055509 -0600 +++ dsdt.dsl 2018-04-26 09:36:23.769729028 -0600 So it can't work as is. I had to take time to understand, and find why it don't work, I never do it before. Thanks another time :)
(In reply to DavidLenovo from comment #135) > (In reply to wave from comment #131) > > (In reply to chenyh570 from comment #129) > > > (In reply to DavidLenovo from comment #120) > > > > Hi ! > > > > A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & > 14ITL05 > > & > > > > 15ITL05 & 15ITL5 :) > > > > > First of all allow me to remark that this is exactly the solution that I > > talked about in comment #97 and which I tried to explain to you > specifically > > in more detail in comment #107; in fact I wrote the archwiki article > > referred to in the comment. > > > > Now your problem seems to be related to permissions; perhaps you are > running > > the whole command or padsp as sudo? > > Sorry :( to don't mention you. > Thanks a lot :), effectively you see the problem firstly and you try to put > all of us in the right way. > To be honest my knowledge is to limited to patch me alone. I had need the > patch "key in hand", found after (put in my tutorial). > I think other people, need the patch "key in hand", with more simple > tutorial. > > I think your have lot of skill, and me (and probably other) just want simple > solution (and can't do hard modification). > > I'm not sure to understand, your are the writer of the tutorial : > https://wiki.archlinux.org/title/Lenovo_Yoga_7i ? > > I think we are lot of people, to don't have lot of knowledge, and need very > simple procedure. And for me I see lot of people very skilled, like you, to > be documentation not enough easy for us. > This is why I make this tutorial, with almost all commands. > For example the patch for the Yoga 7i (on Arch Wiki), don't have the > beginning of the file : > --- dsdt.dsl~ 2018-04-26 09:35:29.501055509 -0600 > +++ dsdt.dsl 2018-04-26 09:36:23.769729028 -0600 > So it can't work as is. > I had to take time to understand, and find why it don't work, I never do it > before. > > Thanks another time :) Don't worry, I didn't mean to criticize you at all :) Quite the contrary, I know that my instructions were very terse (in that I did not duplicate instructions that are available elsewhere, which would be the wrong thing to do on the archwiki anyway), and I'm happy that you went through it, figured it out, and published your findings in an accessible way. You even cited my tutorial from archwiki so everything is perfect. Thanks also for pointing out that the patch does not quite work with the patch command linked in the article; it works if you put the patch into a file like acpi.patch and then run patch dsdt.dsl acpi.patch (specifying both the file to be patched as well as the patch file). But I'll change that in the article. Nice that you figured it out though!
(In reply to DavidLenovo from comment #134) > (In reply to Vincent Morel from comment #130) > > (In reply to DavidLenovo from comment #127) > > > (In reply to Vincent Morel from comment #125) > > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the > same > > > card. > > > > > > Your have only 2 speakers working ? Ore no one ? > > > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > > > No speaker working (but headphone, hdmi... are working). > > > > I did not try kernel 5.11.5 (My Pop Os is in 5.11.0 but I remember trying > > Ubuntu 21.04 and there was no sound also). > > (In reply to Vincent Morel from comment #132) > > (In reply to DavidLenovo from comment #127) > > > (In reply to Vincent Morel from comment #125) > > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the > same > > > card. > > > > > > Your have only 2 speakers working ? Ore no one ? > > > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > > > Just tried with kernel 5.11.5... No luck... > > > > How ACL3306 not recognise, can we find some spec or information about it? > > Seems Realtek codec information is nowhere to be found... :( > > Could you recheck, please : > cat /sys/power/mem_sleep > > sudo dmesg |grep ACPI|grep supports > > Do you have try, to play a long sound with VLC, y choose PulseAudio Server > if it is available, on another session I just have sof-hda-dsp Speaker + > Headphone (it work on both). If your change the sound output, stop and > restart the sound. > Let the sound playing and put in sleep, put the computer on, and the sound > work. It lagging for me at the beginning, and after few seconds it is ok. > > You have ALC287 or ALC3306 ? You seem to have ALC3306, no ? > Not sure Ubuntu is work well for it. > > I think your problem is to enable S3. > It is probably not the same patch for you with you Lenovo Think Book 13s Gen > 2. The patch is for Yoga 7i 14" and 15" > > The user Wave could you help me more I think, my knowledge is limited. Sure thanks, here is my outputs! :) cat /sys/power/mem_sleep [s2idle] deep sudo dmesg |grep ACPI|grep supports [ 0.242864] ACPI: (supports S0 S3 S4 S5) VLC -> played long song, plugged headphone (sound on headphone works), changing output to speaker, no sound (note that sound meter show sound in preference, but sounds do not output to the speaker). Put computer into sleep while playing. After resume, still no sound in speaker... I have ALC3306. The only "not Ubuntu" I tried was Calculate Linux (Gentoo). I use PopOs, tried Ubuntu 21.04 also. Only informations I found on the web always point back here. Some infos: https://afterhourscoding.wordpress.com/tag/backlight/ And the kernel part: https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c At this point I fear it's becoming little too hard for me, but I can still try to do something. If I understand well this sentence 'According to Jaroslav Kysela Lenovo is using amplifier chips for the integrated speakers on recent hardware which must be initialized too. Much of that is undocumented.' we have to find a way to initialize the amplifier chip...
(In reply to Vincent Morel from comment #137) > (In reply to DavidLenovo from comment #134) > > (In reply to Vincent Morel from comment #130) > > > (In reply to DavidLenovo from comment #127) > > > > (In reply to Vincent Morel from comment #125) > > > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the > > same > > > > card. > > > > > > > > Your have only 2 speakers working ? Ore no one ? > > > > > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > > > > > No speaker working (but headphone, hdmi... are working). > > > > > > I did not try kernel 5.11.5 (My Pop Os is in 5.11.0 but I remember trying > > > Ubuntu 21.04 and there was no sound also). > > > > (In reply to Vincent Morel from comment #132) > > > (In reply to DavidLenovo from comment #127) > > > > (In reply to Vincent Morel from comment #125) > > > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the > > same > > > > card. > > > > > > > > Your have only 2 speakers working ? Ore no one ? > > > > > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > > > > > Just tried with kernel 5.11.5... No luck... > > > > > > How ACL3306 not recognise, can we find some spec or information about it? > > > Seems Realtek codec information is nowhere to be found... :( > > > > Could you recheck, please : > > cat /sys/power/mem_sleep > > > > sudo dmesg |grep ACPI|grep supports > > > > Do you have try, to play a long sound with VLC, y choose PulseAudio Server > > if it is available, on another session I just have sof-hda-dsp Speaker + > > Headphone (it work on both). If your change the sound output, stop and > > restart the sound. > > Let the sound playing and put in sleep, put the computer on, and the sound > > work. It lagging for me at the beginning, and after few seconds it is ok. > > > > You have ALC287 or ALC3306 ? You seem to have ALC3306, no ? > > Not sure Ubuntu is work well for it. > > > > I think your problem is to enable S3. > > It is probably not the same patch for you with you Lenovo Think Book 13s > Gen > > 2. The patch is for Yoga 7i 14" and 15" > > > > The user Wave could you help me more I think, my knowledge is limited. > > Sure thanks, here is my outputs! :) > cat /sys/power/mem_sleep > [s2idle] deep > > sudo dmesg |grep ACPI|grep supports > [ 0.242864] ACPI: (supports S0 S3 S4 S5) > > VLC -> played long song, plugged headphone (sound on headphone works), > changing output to speaker, no sound (note that sound meter show sound in > preference, but sounds do not output to the speaker). > > Put computer into sleep while playing. After resume, still no sound in > speaker... > > I have ALC3306. The only "not Ubuntu" I tried was Calculate Linux (Gentoo). > I use PopOs, tried Ubuntu 21.04 also. > > Only informations I found on the web always point back here. > > Some infos: https://afterhourscoding.wordpress.com/tag/backlight/ > And the kernel part: > https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c > > At this point I fear it's becoming little too hard for me, but I can still > try to do something. > > If I understand well this sentence 'According to Jaroslav Kysela Lenovo is > using amplifier chips for the integrated speakers on recent hardware which > must be initialized too. Much of that is undocumented.' we have to find a > way to initialize the amplifier chip... I think (I had the same error after new installation) this is your S3, it's available but don't activated : [s2idle] deep is available but don't selected. For me in [s2idle], brightness hotkey don't work to even after a suspend to ram. (just with step 9 and deep, it magically work ;) ) You have to check step 9 : > 9) GRUB needs to boot the kernel with a parameter setting the deep sleep > state as default. Edit /etc/default/grub and add the following : sudo nano /etc/default/grub find GRUB_CMDLINE_LINUX_DEFAULT=, normaly it already exist, and replace or complete like this : GRUB_CMDLINE_LINUX_DEFAULT="mem_sleep_default=deep" It is the same for this line : > GRUB_EARLY_INITRD_LINUX_CUSTOM="/boot/acpi_override"" Do you have GRUB_CMDLINE_LINUX_DEFAULT="mem_sleep_default=deep". I think it is this command who force deep instead s2idle. For me, the think to see, is to enable S3 (the patch and step 11, seem to be ok), just check the 9 !
Sorry, I write to quickly. So you have to found the line : GRUB_CMDLINE_LINUX_DEFAULT= Replace or complete with : GRUB_CMDLINE_LINUX_DEFAULT="mem_sleep_default=deep" Put GRUB_EARLY_INITRD_LINUX_CUSTOM="/boot/acpi_override" ERROR in my precedent post juste 1x" not acpi_override"" -> acpi_override", sorry. This line probably don't exist. After you have to regenerate grub : 10) Regenerate the GRUB configuration : sudo update-grub recheck the step 11, it could, it would be erase by Grub : > 11) Tell GRUB to load the new DSDT table on boot in its configuration file > usually located in /boot/grub/grub.cfg. Find the relevant GRUB menu entry > and add the new image /boot/acpi_override to the initrd lines for the > images > that you want the s3 sleep to work in : sudo nano /boot/grub/grub.cfg or sudo gedit /boot/grub/grub.cfg (it could be easier to find initrd part) replace in the kernel part initrd in the part menuentry (and all submenu) of the file /boot/grub/grub.cfg : initrd /boot/initrd.img-5.11.5-051105-generic > BECOME : initrd /boot/acpi_override /boot/initrd.img-5.11.5-051105-generic 5.11.5-051105 is for the 5.11.5 kernel, you will have other number, you just have to do it for 5.11 kernels.
(In reply to Vincent Morel from comment #137) > (In reply to DavidLenovo from comment #134) > > (In reply to Vincent Morel from comment #130) > > > (In reply to DavidLenovo from comment #127) > > > > (In reply to Vincent Morel from comment #125) > > > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the > > same > > > > card. > > > > > > > > Your have only 2 speakers working ? Ore no one ? > > > > > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > > > > > No speaker working (but headphone, hdmi... are working). > > > > > > I did not try kernel 5.11.5 (My Pop Os is in 5.11.0 but I remember trying > > > Ubuntu 21.04 and there was no sound also). > > > > (In reply to Vincent Morel from comment #132) > > > (In reply to DavidLenovo from comment #127) > > > > (In reply to Vincent Morel from comment #125) > > > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the > > same > > > > card. > > > > > > > > Your have only 2 speakers working ? Ore no one ? > > > > > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > > > > > Just tried with kernel 5.11.5... No luck... > > > > > > How ACL3306 not recognise, can we find some spec or information about it? > > > Seems Realtek codec information is nowhere to be found... :( > > > > Could you recheck, please : > > cat /sys/power/mem_sleep > > > > sudo dmesg |grep ACPI|grep supports > > > > Do you have try, to play a long sound with VLC, y choose PulseAudio Server > > if it is available, on another session I just have sof-hda-dsp Speaker + > > Headphone (it work on both). If your change the sound output, stop and > > restart the sound. > > Let the sound playing and put in sleep, put the computer on, and the sound > > work. It lagging for me at the beginning, and after few seconds it is ok. > > > > You have ALC287 or ALC3306 ? You seem to have ALC3306, no ? > > Not sure Ubuntu is work well for it. > > > > I think your problem is to enable S3. > > It is probably not the same patch for you with you Lenovo Think Book 13s > Gen > > 2. The patch is for Yoga 7i 14" and 15" > > > > The user Wave could you help me more I think, my knowledge is limited. > > Sure thanks, here is my outputs! :) > cat /sys/power/mem_sleep > [s2idle] deep > > sudo dmesg |grep ACPI|grep supports > [ 0.242864] ACPI: (supports S0 S3 S4 S5) > > VLC -> played long song, plugged headphone (sound on headphone works), > changing output to speaker, no sound (note that sound meter show sound in > preference, but sounds do not output to the speaker). > > Put computer into sleep while playing. After resume, still no sound in > speaker... > > I have ALC3306. The only "not Ubuntu" I tried was Calculate Linux (Gentoo). > I use PopOs, tried Ubuntu 21.04 also. > > Only informations I found on the web always point back here. > > Some infos: https://afterhourscoding.wordpress.com/tag/backlight/ > And the kernel part: > https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c > > At this point I fear it's becoming little too hard for me, but I can still > try to do something. > > If I understand well this sentence 'According to Jaroslav Kysela Lenovo is > using amplifier chips for the integrated speakers on recent hardware which > must be initialized too. Much of that is undocumented.' we have to find a > way to initialize the amplifier chip... For a quick test without having to change your grub config you can also run echo deep > /sys/power/mem_sleep as root and then try playing sound and hibernating again.
(In reply to wave from comment #140) > (In reply to Vincent Morel from comment #137) > > (In reply to DavidLenovo from comment #134) > > > (In reply to Vincent Morel from comment #130) > > > > (In reply to DavidLenovo from comment #127) > > > > > (In reply to Vincent Morel from comment #125) > > > > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > > > > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the > > > same > > > > > card. > > > > > > > > > > Your have only 2 speakers working ? Ore no one ? > > > > > > > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > > > > > > > No speaker working (but headphone, hdmi... are working). > > > > > > > > I did not try kernel 5.11.5 (My Pop Os is in 5.11.0 but I remember > trying > > > > Ubuntu 21.04 and there was no sound also). > > > > > > (In reply to Vincent Morel from comment #132) > > > > (In reply to DavidLenovo from comment #127) > > > > > (In reply to Vincent Morel from comment #125) > > > > > > On the 13S Gen 2, there is only 2 speakers, and S3 is activated... > > > > > > > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly the > > > same > > > > > card. > > > > > > > > > > Your have only 2 speakers working ? Ore no one ? > > > > > > > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > > > > > > > Just tried with kernel 5.11.5... No luck... > > > > > > > > How ACL3306 not recognise, can we find some spec or information about > it? > > > > Seems Realtek codec information is nowhere to be found... :( > > > > > > Could you recheck, please : > > > cat /sys/power/mem_sleep > > > > > > sudo dmesg |grep ACPI|grep supports > > > > > > Do you have try, to play a long sound with VLC, y choose PulseAudio > Server > > > if it is available, on another session I just have sof-hda-dsp Speaker + > > > Headphone (it work on both). If your change the sound output, stop and > > > restart the sound. > > > Let the sound playing and put in sleep, put the computer on, and the > sound > > > work. It lagging for me at the beginning, and after few seconds it is ok. > > > > > > You have ALC287 or ALC3306 ? You seem to have ALC3306, no ? > > > Not sure Ubuntu is work well for it. > > > > > > I think your problem is to enable S3. > > > It is probably not the same patch for you with you Lenovo Think Book 13s > > Gen > > > 2. The patch is for Yoga 7i 14" and 15" > > > > > > The user Wave could you help me more I think, my knowledge is limited. > > > > Sure thanks, here is my outputs! :) > > cat /sys/power/mem_sleep > > [s2idle] deep > > > > sudo dmesg |grep ACPI|grep supports > > [ 0.242864] ACPI: (supports S0 S3 S4 S5) > > > > VLC -> played long song, plugged headphone (sound on headphone works), > > changing output to speaker, no sound (note that sound meter show sound in > > preference, but sounds do not output to the speaker). > > > > Put computer into sleep while playing. After resume, still no sound in > > speaker... > > > > I have ALC3306. The only "not Ubuntu" I tried was Calculate Linux (Gentoo). > > I use PopOs, tried Ubuntu 21.04 also. > > > > Only informations I found on the web always point back here. > > > > Some infos: https://afterhourscoding.wordpress.com/tag/backlight/ > > And the kernel part: > > https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c > > > > At this point I fear it's becoming little too hard for me, but I can still > > try to do something. > > > > If I understand well this sentence 'According to Jaroslav Kysela Lenovo is > > using amplifier chips for the integrated speakers on recent hardware which > > must be initialized too. Much of that is undocumented.' we have to find a > > way to initialize the amplifier chip... > > For a quick test without having to change your grub config you can also run > echo deep > /sys/power/mem_sleep > as root and then try playing sound and hibernating again. Thanks for all those precious infos! Just to make things more complicated, PopOs use systemd-boot and not grub. Anyway I was able to activate 'deep' sleep with this command: sudo kernelstub -a "mem_sleep_default=deep" and after reboot I have: cat /sys/power/mem_sleep s2idle [deep] But my computer is not able to exit from sleep now. It goes into deep sleep (I see the led in sleeping mode) but as soon as I press a key the computer turn off. I have to turn it on and it boots... I also try to do it by adding mem_sleep_default=deep in /boot/efi/loader/entries/pop_OS-current.conf (that's where you put option in systemd-boot) Same result... I'll try a totally different distribution when I have time (not ubuntu based) to see if I can do it.
(In reply to Vincent Morel from comment #141) > (In reply to wave from comment #140) > > (In reply to Vincent Morel from comment #137) > > > (In reply to DavidLenovo from comment #134) > > > > (In reply to Vincent Morel from comment #130) > > > > > (In reply to DavidLenovo from comment #127) > > > > > > (In reply to Vincent Morel from comment #125) > > > > > > > On the 13S Gen 2, there is only 2 speakers, and S3 is > activated... > > > > > > > > > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly > the > > > > same > > > > > > card. > > > > > > > > > > > > Your have only 2 speakers working ? Ore no one ? > > > > > > > > > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > > > > > > > > > No speaker working (but headphone, hdmi... are working). > > > > > > > > > > I did not try kernel 5.11.5 (My Pop Os is in 5.11.0 but I remember > > trying > > > > > Ubuntu 21.04 and there was no sound also). > > > > > > > > (In reply to Vincent Morel from comment #132) > > > > > (In reply to DavidLenovo from comment #127) > > > > > > (In reply to Vincent Morel from comment #125) > > > > > > > On the 13S Gen 2, there is only 2 speakers, and S3 is > activated... > > > > > > > > > > > > Hi, I have similar result in hwinfo --sound, but it's not exactly > the > > > > same > > > > > > card. > > > > > > > > > > > > Your have only 2 speakers working ? Ore no one ? > > > > > > > > > > > > You have try Ubuntu 20.04 with kernel 5.11.5 ? > > > > > > > > > > Just tried with kernel 5.11.5... No luck... > > > > > > > > > > How ACL3306 not recognise, can we find some spec or information about > > it? > > > > > Seems Realtek codec information is nowhere to be found... :( > > > > > > > > Could you recheck, please : > > > > cat /sys/power/mem_sleep > > > > > > > > sudo dmesg |grep ACPI|grep supports > > > > > > > > Do you have try, to play a long sound with VLC, y choose PulseAudio > > Server > > > > if it is available, on another session I just have sof-hda-dsp Speaker > + > > > > Headphone (it work on both). If your change the sound output, stop and > > > > restart the sound. > > > > Let the sound playing and put in sleep, put the computer on, and the > > sound > > > > work. It lagging for me at the beginning, and after few seconds it is > ok. > > > > > > > > You have ALC287 or ALC3306 ? You seem to have ALC3306, no ? > > > > Not sure Ubuntu is work well for it. > > > > > > > > I think your problem is to enable S3. > > > > It is probably not the same patch for you with you Lenovo Think Book > 13s > > > Gen > > > > 2. The patch is for Yoga 7i 14" and 15" > > > > > > > > The user Wave could you help me more I think, my knowledge is limited. > > > > > > Sure thanks, here is my outputs! :) > > > cat /sys/power/mem_sleep > > > [s2idle] deep > > > > > > sudo dmesg |grep ACPI|grep supports > > > [ 0.242864] ACPI: (supports S0 S3 S4 S5) > > > > > > VLC -> played long song, plugged headphone (sound on headphone works), > > > changing output to speaker, no sound (note that sound meter show sound in > > > preference, but sounds do not output to the speaker). > > > > > > Put computer into sleep while playing. After resume, still no sound in > > > speaker... > > > > > > I have ALC3306. The only "not Ubuntu" I tried was Calculate Linux > (Gentoo). > > > I use PopOs, tried Ubuntu 21.04 also. > > > > > > Only informations I found on the web always point back here. > > > > > > Some infos: https://afterhourscoding.wordpress.com/tag/backlight/ > > > And the kernel part: > > > > https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c > > > > > > At this point I fear it's becoming little too hard for me, but I can > still > > > try to do something. > > > > > > If I understand well this sentence 'According to Jaroslav Kysela Lenovo > is > > > using amplifier chips for the integrated speakers on recent hardware > which > > > must be initialized too. Much of that is undocumented.' we have to find a > > > way to initialize the amplifier chip... > > > > For a quick test without having to change your grub config you can also run > > echo deep > /sys/power/mem_sleep > > as root and then try playing sound and hibernating again. > > Thanks for all those precious infos! Just to make things more complicated, > PopOs use systemd-boot and not grub. > Anyway I was able to activate 'deep' sleep with this command: > > sudo kernelstub -a "mem_sleep_default=deep" > > and after reboot I have: > cat /sys/power/mem_sleep > s2idle [deep] > > > But my computer is not able to exit from sleep now. It goes into deep sleep > (I see the led in sleeping mode) but as soon as I press a key the computer > turn off. I have to turn it on and it boots... > > I also try to do it by adding mem_sleep_default=deep in > /boot/efi/loader/entries/pop_OS-current.conf (that's where you put option in > systemd-boot) > > Same result... I'll try a totally different distribution when I have time > (not ubuntu based) to see if I can do it. Did you have to patch the DSDT table in order to get S3 sleep and if yes did the patch apply cleanly? Does the problem also occur if you do systemctl hibernate explicitly?
(In reply to wave from comment #136) > (In reply to DavidLenovo from comment #135) > > (In reply to wave from comment #131) > > > (In reply to chenyh570 from comment #129) > > > > (In reply to DavidLenovo from comment #120) > > > > > Hi ! > > > > > A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & > > 14ITL05 > > > & > > > > > 15ITL05 & 15ITL5 :) > > > > > > > > First of all allow me to remark that this is exactly the solution that I > > > talked about in comment #97 and which I tried to explain to you > > specifically > > > in more detail in comment #107; in fact I wrote the archwiki article > > > referred to in the comment. > > > > > > Now your problem seems to be related to permissions; perhaps you are > > running > > > the whole command or padsp as sudo? > > > > Sorry :( to don't mention you. > > Thanks a lot :), effectively you see the problem firstly and you try to put > > all of us in the right way. > > To be honest my knowledge is to limited to patch me alone. I had need the > > patch "key in hand", found after (put in my tutorial). > > I think other people, need the patch "key in hand", with more simple > > tutorial. > > > > I think your have lot of skill, and me (and probably other) just want > simple > > solution (and can't do hard modification). > > > > I'm not sure to understand, your are the writer of the tutorial : > > https://wiki.archlinux.org/title/Lenovo_Yoga_7i ? > > > > I think we are lot of people, to don't have lot of knowledge, and need very > > simple procedure. And for me I see lot of people very skilled, like you, to > > be documentation not enough easy for us. > > This is why I make this tutorial, with almost all commands. > > For example the patch for the Yoga 7i (on Arch Wiki), don't have the > > beginning of the file : > > --- dsdt.dsl~ 2018-04-26 09:35:29.501055509 -0600 > > +++ dsdt.dsl 2018-04-26 09:36:23.769729028 -0600 > > So it can't work as is. > > I had to take time to understand, and find why it don't work, I never do it > > before. > > > > Thanks another time :) > > Don't worry, I didn't mean to criticize you at all :) > Quite the contrary, I know that my instructions were very terse (in that I > did not duplicate instructions that are available elsewhere, which would be > the wrong thing to do on the archwiki anyway), and I'm happy that you went > through it, figured it out, and published your findings in an accessible > way. You even cited my tutorial from archwiki so everything is perfect. > > Thanks also for pointing out that the patch does not quite work with the > patch command linked in the article; it works if you put the patch into a > file like acpi.patch and then run > patch dsdt.dsl acpi.patch > (specifying both the file to be patched as well as the patch file). But I'll > change that in the article. Nice that you figured it out though! Ok :) Thanks for your work, and your wiki page, it's very great to have speakers :) Thanks for the patch info
(In reply to Vincent Morel from comment #141) > Thanks for all those precious infos! Just to make things more complicated, > PopOs use systemd-boot and not grub. > Anyway I was able to activate 'deep' sleep with this command: > > sudo kernelstub -a "mem_sleep_default=deep" > > and after reboot I have: > cat /sys/power/mem_sleep > s2idle [deep] > > > But my computer is not able to exit from sleep now. It goes into deep sleep > (I see the led in sleeping mode) but as soon as I press a key the computer > turn off. I have to turn it on and it boots... > > I also try to do it by adding mem_sleep_default=deep in > /boot/efi/loader/entries/pop_OS-current.conf (that's where you put option in > systemd-boot) > > Same result... I'll try a totally different distribution when I have time > (not ubuntu based) to see if I can do it. (In reply to wave from comment #142) > Did you have to patch the DSDT table in order to get S3 sleep and if yes did > the patch apply cleanly? > > Does the problem also occur if you do > systemctl hibernate > explicitly? Your sure your have to hibernate ? For me in S2 or S3 hibernate (suspend to disk) is the same. But sleeping : suspend to ram, is not the same in S2 and S3. For me I boot, and I make a sleep (suspend to ram) to enable speaker and brightness hotkeys. Your tutorial (Wave) have a script with : rtcwake -m mem -s 1 that it is : suspend to memory. @Vincent Morel : could you try sleep (suspend to ram) (not to disk) ?
(In reply to DavidLenovo from comment #144) > (In reply to Vincent Morel from comment #141) > > Thanks for all those precious infos! Just to make things more complicated, > > PopOs use systemd-boot and not grub. > > Anyway I was able to activate 'deep' sleep with this command: > > > > sudo kernelstub -a "mem_sleep_default=deep" > > > > and after reboot I have: > > cat /sys/power/mem_sleep > > s2idle [deep] > > > > > > But my computer is not able to exit from sleep now. It goes into deep sleep > > (I see the led in sleeping mode) but as soon as I press a key the computer > > turn off. I have to turn it on and it boots... > > > > I also try to do it by adding mem_sleep_default=deep in > > /boot/efi/loader/entries/pop_OS-current.conf (that's where you put option > in > > systemd-boot) > > > > Same result... I'll try a totally different distribution when I have time > > (not ubuntu based) to see if I can do it. > > (In reply to wave from comment #142) > > > Did you have to patch the DSDT table in order to get S3 sleep and if yes > did > > the patch apply cleanly? > > > > Does the problem also occur if you do > > systemctl hibernate > > explicitly? > > Your sure your have to hibernate ? > For me in S2 or S3 hibernate (suspend to disk) is the same. > But sleeping : suspend to ram, is not the same in S2 and S3. > > For me I boot, and I make a sleep (suspend to ram) to enable speaker and > brightness hotkeys. > > Your tutorial (Wave) have a script with : rtcwake -m mem -s 1 that it is : > suspend to memory. > > @Vincent Morel : could you try sleep (suspend to ram) (not to disk) ? You're right, my bad, sorry. Hibernating takes too much time to wake up, I think that's the reason why it doesn't activate sound (my brightness keys do work after suspend to disk/hibernate). Should do systemctl suspend instead, this should trigger S3 sleep.
(In reply to DavidLenovo from comment #144) > (In reply to Vincent Morel from comment #141) > > Thanks for all those precious infos! Just to make things more complicated, > > PopOs use systemd-boot and not grub. > > Anyway I was able to activate 'deep' sleep with this command: > > > > sudo kernelstub -a "mem_sleep_default=deep" > > > > and after reboot I have: > > cat /sys/power/mem_sleep > > s2idle [deep] > > > > > > But my computer is not able to exit from sleep now. It goes into deep sleep > > (I see the led in sleeping mode) but as soon as I press a key the computer > > turn off. I have to turn it on and it boots... > > > > I also try to do it by adding mem_sleep_default=deep in > > /boot/efi/loader/entries/pop_OS-current.conf (that's where you put option > in > > systemd-boot) > > > > Same result... I'll try a totally different distribution when I have time > > (not ubuntu based) to see if I can do it. > > (In reply to wave from comment #142) > > > Did you have to patch the DSDT table in order to get S3 sleep and if yes > did > > the patch apply cleanly? > > > > Does the problem also occur if you do > > systemctl hibernate > > explicitly? > > Your sure your have to hibernate ? > For me in S2 or S3 hibernate (suspend to disk) is the same. > But sleeping : suspend to ram, is not the same in S2 and S3. > > For me I boot, and I make a sleep (suspend to ram) to enable speaker and > brightness hotkeys. > > Your tutorial (Wave) have a script with : rtcwake -m mem -s 1 that it is : > suspend to memory. > > @Vincent Morel : could you try sleep (suspend to ram) (not to disk) ? I tried hibernate and suspend. Hibernate do not allow me to wake the computer, I have to reboot. Suspend works great but no sound at all. For the question regarding DSDT, no, I did not have to patch anything to have "deep" activated. And my Brightness key work out of the box (as all the special keys, volume, mute, mic mute, plane...).
(In reply to Vincent Morel from comment #146) > > I tried hibernate and suspend. Hibernate do not allow me to wake the > computer, I have to reboot. > Suspend works great but no sound at all. > > For the question regarding DSDT, no, I did not have to patch anything to > have "deep" activated. > And my Brightness key work out of the box (as all the special keys, volume, > mute, mic mute, plane...). Ok, thanks. As you say, you have the ACL3306 not ALC287, Is it different ? Do you have try with Windows ? And shutdown totally Windows, I have read a partial shutdown could lock equipment. But I don't know more.
(In reply to Vincent Morel from comment #146) > (In reply to DavidLenovo from comment #144) > > (In reply to Vincent Morel from comment #141) > > > Thanks for all those precious infos! Just to make things more > complicated, > > > PopOs use systemd-boot and not grub. > > > Anyway I was able to activate 'deep' sleep with this command: > > > > > > sudo kernelstub -a "mem_sleep_default=deep" > > > > > > and after reboot I have: > > > cat /sys/power/mem_sleep > > > s2idle [deep] > > > > > > > > > But my computer is not able to exit from sleep now. It goes into deep > sleep > > > (I see the led in sleeping mode) but as soon as I press a key the > computer > > > turn off. I have to turn it on and it boots... > > > > > > I also try to do it by adding mem_sleep_default=deep in > > > /boot/efi/loader/entries/pop_OS-current.conf (that's where you put option > > in > > > systemd-boot) > > > > > > Same result... I'll try a totally different distribution when I have time > > > (not ubuntu based) to see if I can do it. > > > > (In reply to wave from comment #142) > > > > > Did you have to patch the DSDT table in order to get S3 sleep and if yes > > did > > > the patch apply cleanly? > > > > > > Does the problem also occur if you do > > > systemctl hibernate > > > explicitly? > > > > Your sure your have to hibernate ? > > For me in S2 or S3 hibernate (suspend to disk) is the same. > > But sleeping : suspend to ram, is not the same in S2 and S3. > > > > For me I boot, and I make a sleep (suspend to ram) to enable speaker and > > brightness hotkeys. > > > > Your tutorial (Wave) have a script with : rtcwake -m mem -s 1 that it is : > > suspend to memory. > > > > @Vincent Morel : could you try sleep (suspend to ram) (not to disk) ? > > I tried hibernate and suspend. Hibernate do not allow me to wake the > computer, I have to reboot. > Suspend works great but no sound at all. > > For the question regarding DSDT, no, I did not have to patch anything to > have "deep" activated. > And my Brightness key work out of the box (as all the special keys, volume, > mute, mic mute, plane...). Okay, well you do have a different sound card after all, so it might be better to open a separate bug report, and maybe also one for the hibernation issue.
(In reply to wave from comment #148) > (In reply to Vincent Morel from comment #146) > > (In reply to DavidLenovo from comment #144) > > > (In reply to Vincent Morel from comment #141) > > > > Thanks for all those precious infos! Just to make things more > > complicated, > > > > PopOs use systemd-boot and not grub. > > > > Anyway I was able to activate 'deep' sleep with this command: > > > > > > > > sudo kernelstub -a "mem_sleep_default=deep" > > > > > > > > and after reboot I have: > > > > cat /sys/power/mem_sleep > > > > s2idle [deep] > > > > > > > > > > > > But my computer is not able to exit from sleep now. It goes into deep > > sleep > > > > (I see the led in sleeping mode) but as soon as I press a key the > > computer > > > > turn off. I have to turn it on and it boots... > > > > > > > > I also try to do it by adding mem_sleep_default=deep in > > > > /boot/efi/loader/entries/pop_OS-current.conf (that's where you put > option > > > in > > > > systemd-boot) > > > > > > > > Same result... I'll try a totally different distribution when I have > time > > > > (not ubuntu based) to see if I can do it. > > > > > > (In reply to wave from comment #142) > > > > > > > Did you have to patch the DSDT table in order to get S3 sleep and if > yes > > > did > > > > the patch apply cleanly? > > > > > > > > Does the problem also occur if you do > > > > systemctl hibernate > > > > explicitly? > > > > > > Your sure your have to hibernate ? > > > For me in S2 or S3 hibernate (suspend to disk) is the same. > > > But sleeping : suspend to ram, is not the same in S2 and S3. > > > > > > For me I boot, and I make a sleep (suspend to ram) to enable speaker and > > > brightness hotkeys. > > > > > > Your tutorial (Wave) have a script with : rtcwake -m mem -s 1 that it is > : > > > suspend to memory. > > > > > > @Vincent Morel : could you try sleep (suspend to ram) (not to disk) ? > > > > I tried hibernate and suspend. Hibernate do not allow me to wake the > > computer, I have to reboot. > > Suspend works great but no sound at all. > > > > For the question regarding DSDT, no, I did not have to patch anything to > > have "deep" activated. > > And my Brightness key work out of the box (as all the special keys, volume, > > mute, mic mute, plane...). > > Okay, well you do have a different sound card after all, so it might be > better to open a separate bug report, and maybe also one for the hibernation > issue. Yes, thanks for your support, I will open another bug report. :)
(In reply to Vincent Morel from comment #149) > (In reply to wave from comment #148) > > (In reply to Vincent Morel from comment #146) > > > (In reply to DavidLenovo from comment #144) > > > > (In reply to Vincent Morel from comment #141) > > > > > Thanks for all those precious infos! Just to make things more > > > complicated, > > > > > PopOs use systemd-boot and not grub. > > > > > Anyway I was able to activate 'deep' sleep with this command: > > > > > > > > > > sudo kernelstub -a "mem_sleep_default=deep" > > > > > > > > > > and after reboot I have: > > > > > cat /sys/power/mem_sleep > > > > > s2idle [deep] > > > > > > > > > > > > > > > But my computer is not able to exit from sleep now. It goes into deep > > > sleep > > > > > (I see the led in sleeping mode) but as soon as I press a key the > > > computer > > > > > turn off. I have to turn it on and it boots... > > > > > > > > > > I also try to do it by adding mem_sleep_default=deep in > > > > > /boot/efi/loader/entries/pop_OS-current.conf (that's where you put > > option > > > > in > > > > > systemd-boot) > > > > > > > > > > Same result... I'll try a totally different distribution when I have > > time > > > > > (not ubuntu based) to see if I can do it. > > > > > > > > (In reply to wave from comment #142) > > > > > > > > > Did you have to patch the DSDT table in order to get S3 sleep and if > > yes > > > > did > > > > > the patch apply cleanly? > > > > > > > > > > Does the problem also occur if you do > > > > > systemctl hibernate > > > > > explicitly? > > > > > > > > Your sure your have to hibernate ? > > > > For me in S2 or S3 hibernate (suspend to disk) is the same. > > > > But sleeping : suspend to ram, is not the same in S2 and S3. > > > > > > > > For me I boot, and I make a sleep (suspend to ram) to enable speaker > and > > > > brightness hotkeys. > > > > > > > > Your tutorial (Wave) have a script with : rtcwake -m mem -s 1 that it > is > > : > > > > suspend to memory. > > > > > > > > @Vincent Morel : could you try sleep (suspend to ram) (not to disk) ? > > > > > > I tried hibernate and suspend. Hibernate do not allow me to wake the > > > computer, I have to reboot. > > > Suspend works great but no sound at all. > > > > > > For the question regarding DSDT, no, I did not have to patch anything to > > > have "deep" activated. > > > And my Brightness key work out of the box (as all the special keys, > volume, > > > mute, mic mute, plane...). > > > > Okay, well you do have a different sound card after all, so it might be > > better to open a separate bug report, and maybe also one for the > hibernation > > issue. > > Yes, thanks for your support, I will open another bug report. :) I think I have the same issue with the same machine Thinkbook 13s G2 Let me know when you open a new thread I would like to follow it
(In reply to waterproof93 from comment #150) > > I think I have the same issue with the same machine > Thinkbook 13s G2 > > Let me know when you open a new thread I would like to follow it Just opened it :) https://bugzilla.kernel.org/show_bug.cgi?id=213159
I am also going to join the new thread. Despite the alsa-info showing ALC287, I just realized that the Legion 7i 15IMH05 has the Realtek® ALC3306 codec (https://psref.lenovo.com/syspool/Sys/PDF/Legion/Lenovo_Legion_7_15IMH05/Lenovo_Legion_7_15IMH05_Spec.pdf). I have not seen any mention at the kernel source about the ALC3306.
Just confirming that I was able to follow the tutorial by @wave to get my speakers working. S3 sleep enabled without a hitch. I have the Lenovo Yoga 7i 14ITL5. The only issue I ran into was with the login script, but I'm personally OK with that for now (appears I have a permissions issue). I'm currently running Manjaro 21.0.5. I simply have to play some audio, suspend, then wake. Audio then plays through the speakers immediately after waking, even before I unlock the session. Just sharing my experience. Thanks to all who have contributed to the progress being made on this issue!
(In reply to Dre from comment #153) > Just confirming that I was able to follow the tutorial by @wave to get my > speakers working. S3 sleep enabled without a hitch. I have the Lenovo Yoga > 7i 14ITL5. The only issue I ran into was with the login script, but I'm > personally OK with that for now (appears I have a permissions issue). I'm > currently running Manjaro 21.0.5. I simply have to play some audio, > suspend, then wake. Audio then plays through the speakers immediately after > waking, even before I unlock the session. > Just sharing my experience. Thanks to all who have contributed to the > progress being made on this issue! This was on LTS Kernel 5.10.36-2
(In reply to Dre from comment #153) > Just confirming that I was able to follow the tutorial by @wave to get my > speakers working. S3 sleep enabled without a hitch. I have the Lenovo Yoga > 7i 14ITL5. The only issue I ran into was with the login script, but I'm > personally OK with that for now (appears I have a permissions issue). I'm > currently running Manjaro 21.0.5. I simply have to play some audio, > suspend, then wake. Audio then plays through the speakers immediately after > waking, even before I unlock the session. > Just sharing my experience. Thanks to all who have contributed to the > progress being made on this issue! I have the same system and "deep" will not enable.
(In reply to Brian Long from comment #155) > (In reply to Dre from comment #153) > > Just confirming that I was able to follow the tutorial by @wave to get my > > speakers working. S3 sleep enabled without a hitch. I have the Lenovo > Yoga > > 7i 14ITL5. The only issue I ran into was with the login script, but I'm > > personally OK with that for now (appears I have a permissions issue). I'm > > currently running Manjaro 21.0.5. I simply have to play some audio, > > suspend, then wake. Audio then plays through the speakers immediately > after > > waking, even before I unlock the session. > > Just sharing my experience. Thanks to all who have contributed to the > > progress being made on this issue! > > I have the same system and "deep" will not enable. I tried the Arch wiki tutorial on Fedora, Fedora Rawhide, and at least one Ubuntu based distro, but to no avail. It worked only on an Arch based distro for me. I used the latest Manjaro Gnome with the default LTS kernel.
No luck here with making the sleep working. Anyone know if someone is in contact with the manufacturer?
(In reply to Brian Long from comment #155) > (In reply to Dre from comment #153) > > Just confirming that I was able to follow the tutorial by @wave to get my > > speakers working. S3 sleep enabled without a hitch. I have the Lenovo > Yoga > > 7i 14ITL5. The only issue I ran into was with the login script, but I'm > > personally OK with that for now (appears I have a permissions issue). I'm > > currently running Manjaro 21.0.5. I simply have to play some audio, > > suspend, then wake. Audio then plays through the speakers immediately > after > > waking, even before I unlock the session. > > Just sharing my experience. Thanks to all who have contributed to the > > progress being made on this issue! > > I have the same system and "deep" will not enable. Hi, for you and all people without S3, could you try : cat /sys/power/mem_sleep sudo dmesg |grep ACPI|grep supports And find kernel: ACPI: DSDT 0x...(remove by me) ...(remove by me) v02 LENOVO CB-01 00000003 INTL ...) Do you have 00000002 or 00000003 ? I think sudo dmesg |grep ACPI|grep DSDT will work or just sudo dmesg |grep DSDT Thanks (In reply to Niclas from comment #157) > No luck here with making the sleep working. > > Anyone know if someone is in contact with the manufacturer? I contact them, for Lenovo it's not specified it is an Linux laptop, so it is not a problem. The problem is reported by the person answer me, but we don't have tracking or any-else. You can check an alternative BIOS, the problem seem to be created by a deactivation of the S3 in the BIOS. We have a limited bios, but people have found in another model, it's just a switch to enable in the dump. www.bios-mods.com can modify your dump to enable this. Have a good day
(In reply to DavidLenovo from comment #158) > (In reply to Brian Long from comment #155) > > (In reply to Dre from comment #153) > > > Just confirming that I was able to follow the tutorial by @wave to get my > > > speakers working. S3 sleep enabled without a hitch. I have the Lenovo > > Yoga > > > 7i 14ITL5. The only issue I ran into was with the login script, but I'm > > > personally OK with that for now (appears I have a permissions issue). > I'm > > > currently running Manjaro 21.0.5. I simply have to play some audio, > > > suspend, then wake. Audio then plays through the speakers immediately > > after > > > waking, even before I unlock the session. > > > Just sharing my experience. Thanks to all who have contributed to the > > > progress being made on this issue! > > > > I have the same system and "deep" will not enable. > > Hi, for you and all people without S3, could you try : > cat /sys/power/mem_sleep > > sudo dmesg |grep ACPI|grep supports > > And find kernel: ACPI: DSDT 0x...(remove by me) ...(remove by me) v02 > LENOVO CB-01 00000003 INTL ...) > Do you have 00000002 or 00000003 ? > I think sudo dmesg |grep ACPI|grep DSDT will work > or just sudo dmesg |grep DSDT > > Thanks > (In reply to Niclas from comment #157) > > No luck here with making the sleep working. > > > > Anyone know if someone is in contact with the manufacturer? > > I contact them, for Lenovo it's not specified it is an Linux laptop, so it > is not a problem. > The problem is reported by the person answer me, but we don't have tracking > or any-else. > > You can check an alternative BIOS, the problem seem to be created by a > deactivation of the S3 in the BIOS. We have a limited bios, but people have > found in another model, it's just a switch to enable in the dump. > www.bios-mods.com can modify your dump to enable this. > > Have a good day I'm having trouble getting the dmesg command to give me anything, but here is what the cat command returns: s2idle [deep]
(In reply to Dre from comment #159) > I'm having trouble getting the dmesg command to give me anything, but here > is what the cat command returns: s2idle [deep] You have file /var/log/dmesg ? Your cat /sys/power/mem_sleep > is what the cat command returns: s2idle [deep] Is for Arch, or Ubuntu ?
(In reply to DavidLenovo from comment #160) > (In reply to Dre from comment #159) > > I'm having trouble getting the dmesg command to give me anything, but here > > is what the cat command returns: s2idle [deep] > > You have file /var/log/dmesg ? > > Your cat /sys/power/mem_sleep > > is what the cat command returns: s2idle [deep] > Is for Arch, or Ubuntu ? No, I do not have that directory. That cat output is on Arch.
(In reply to Dre from comment #161) > (In reply to DavidLenovo from comment #160) > > (In reply to Dre from comment #159) > > > I'm having trouble getting the dmesg command to give me anything, but > here > > > is what the cat command returns: s2idle [deep] > > > > You have file /var/log/dmesg ? > > > > Your cat /sys/power/mem_sleep > > > is what the cat command returns: s2idle [deep] > > Is for Arch, or Ubuntu ? > > No, I do not have that directory. > > That cat output is on Arch. My fault. I meant "I do not have that file."
(In reply to Dre from comment #161) > (In reply to DavidLenovo from comment #160) > > (In reply to Dre from comment #159) > > > I'm having trouble getting the dmesg command to give me anything, but > here > > > is what the cat command returns: s2idle [deep] > > > > You have file /var/log/dmesg ? > > > > Your cat /sys/power/mem_sleep > > > is what the cat command returns: s2idle [deep] > > Is for Arch, or Ubuntu ? > > No, I do not have that directory. > > That cat output is on Arch. Thanks, ok, and it work on Arch for you, is it ok ? (And just for Arch)
(In reply to DavidLenovo from comment #163) > (In reply to Dre from comment #161) > > (In reply to DavidLenovo from comment #160) > > > (In reply to Dre from comment #159) > > > > I'm having trouble getting the dmesg command to give me anything, but > > here > > > > is what the cat command returns: s2idle [deep] > > > > > > You have file /var/log/dmesg ? > > > > > > Your cat /sys/power/mem_sleep > > > > is what the cat command returns: s2idle [deep] > > > Is for Arch, or Ubuntu ? > > > > No, I do not have that directory. > > > > That cat output is on Arch. > > Thanks, ok, and it work on Arch for you, is it ok ? (And just for Arch) Yes. Just on Arch (and I've tried several distro bases). It's workable. I just have to boot, play audio, suspend, then wake to get speakers working.
I can't believe it's been almost a year without this problem being solved. I tried Ubuntu, PopOs, Fedora, Debian, they all had the same audio problem. I guess I'll just have to get used to headphones now.
(In reply to Jenefer from comment #165) > I can't believe it's been almost a year without this problem being solved. I > tried Ubuntu, PopOs, Fedora, Debian, they all had the same audio problem. I > guess I'll just have to get used to headphones now. Hello, what is your computer model ? The problem is not link to the ALC287, just to enable the S3 in computer.
(In reply to DavidLenovo from comment #120) > Hi ! > A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & 14ITL05 & > 15ITL05 & 15ITL5 :) > Sound from speakers works on Ubuntu 20.04.2LTS !!! This method worked pretty well for me (Lenovo Yoga 7i) with kernal 5.8.0-53-generic #60, After update to 5.8.0-55 the S3 is not visible. > dmesg | grep ACPI | grep supports > [ 0.174047] ACPI: (supports S0 S4 S5) when I'm grepping for ACPI I see that the overwriting of the acpi DST table is done very early in the dmesg log, whereas in 0.55 it's done later, maybe that's an hint. [ 0.000000] BIOS-e820: [mem 0x00000000452ff000-0x0000000045b2efff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x0000000045b2f000-0x0000000045bfefff] ACPI data [ 0.000000] efi: ACPI=0x45bfe000 ACPI 2.0=0x45bfe014 TPMFinalLog=0x45ac5000 SMBIOS=0x439e0000 SMBIOS 3.0=0x439de000 ESRT=0x3f65b018 RNG=0x439e1a18 TPMEventLog=0x3a8a6018 [ 0.006300] ACPI: DSDT ACPI table found in initrd [kernel/firmware/acpi/dsdt.aml][0x3ebe2]
(In reply to DavidLenovo from comment #166) > (In reply to Jenefer from comment #165) > > I can't believe it's been almost a year without this problem being solved. > I > > tried Ubuntu, PopOs, Fedora, Debian, they all had the same audio problem. I > > guess I'll just have to get used to headphones now. > > Hello, what is your computer model ? > The problem is not link to the ALC287, just to enable the S3 in computer. My model is lenovo legion 7i 15IMHg05. I'm using Pop OS for now so It does not use grub boatloader. I don't know if I can change the kernel init. Can you explain how to "to enable the S3 in computer." ?
(In reply to Jenefer from comment #168) > (In reply to DavidLenovo from comment #166) > > (In reply to Jenefer from comment #165) > > > I can't believe it's been almost a year without this problem being > solved. > > I > > > tried Ubuntu, PopOs, Fedora, Debian, they all had the same audio problem. > I > > > guess I'll just have to get used to headphones now. > > > > Hello, what is your computer model ? > > The problem is not link to the ALC287, just to enable the S3 in computer. > > My model is lenovo legion 7i 15IMHg05. I'm using Pop OS for now so It does > not use grub boatloader. I don't know if I can change the kernel init. Can > you explain how to "to enable the S3 in computer." ? Also, your solution seems to work on yoga models, I didn't see anyone with legion model saying it worked for them. Here are my outputs: cat /sys/power/mem_sleep s2idle [deep] sudo dmesg |grep ACPI|grep supports [ 0.410327] ACPI: (supports S0 S3 S4 S5) aplay -l **** List of PLAYBACK Hardware Devices **** card 1: PCH [HDA Intel PCH], device 0: ALC287 Analog [ALC287 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: PCH [HDA Intel PCH], device 10: HDMI 4 [HDMI 4] Subdevices: 1/1 Subdevice #0: subdevice #0 sudo dmesg | grep -i audio [ 0.205536] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) [ 4.131332] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 4.131548] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client [ 4.185009] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker [ 4.185013] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 4.185015] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 4.185016] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 4.185017] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 4.185019] snd_hda_codec_realtek hdaudioC1D0: Mic=0x19 [ 4.185020] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 there is something weird about this last command: the speaker_outs is set to 0 I tried suspending the machine after playing some music but did not get audio after waking
Are you sure the Legion is ALC287 ? Seems Linux report an ACL287 but it's in fact ACL3306 !!! So having the good codec would be a good starting point...
(In reply to Vincent Morel from comment #170) > Are you sure the Legion is ALC287 ? > Seems Linux report an ACL287 but it's in fact ACL3306 !!! > So having the good codec would be a good starting point... Well, that's even more complicated. so even the system is reporting the wrong driver ? Can you guide me to a good solution for this ? I'm just tired of searching the whole web for ACL287 so it turns out to be ACL3306
I believe that Lenovo sells 2 versions of the Legion. We bought a bunch for the company I work at and it is the ALC287. We ended up giving those to Windows users and bought ones that had Ubuntu pre-installed. The behaviour of the audio suggests that there maybe an i/o line controlling the amp to the speakers, imho. Jason Original Message From: bugzilla-daemon@bugzilla.kernel.org Sent: June 11, 2021 10:08 AM To: jason349@gmail.com Subject: [Bug 208555] No sound from speakers using Realtek ALC287 https://bugzilla.kernel.org/show_bug.cgi?id=208555 --- Comment #170 from Vincent Morel (dantahoua@gmail.com) --- Are you sure the Legion is ALC287 ? Seems Linux report an ACL287 but it's in fact ACL3306 !!! So having the good codec would be a good starting point... -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug.
Could someone try this, just copy and paste into a file, make it executable with chmod +x and run it. It worked for me.. https://pastebin.com/raw/zsXp2vz6 //Niclas
The most recent major Manjaro update broke the fix on my system. It upgraded my kernel from 5.10.36-2 to 5.10.41-1. I decided to go ahead and upgrade to 5.13 and follow the tutorial again. The Arch Wiki fix worked on the experimental kernel. Once I play audio > suspend > wake the speakers continue to work until I log off. Even if I stop the audio for any period of time while logged in the speakers still work. @Niclas , what device are you running that on?
(In reply to Niclas from comment #173) > Could someone try this, just copy and paste into a file, make it executable > with chmod +x and run it. It worked for me.. > > https://pastebin.com/raw/zsXp2vz6 > > //Niclas Niclas, are you on a Legion 7i or Yoga?
(In reply to Dre from comment #174) > The most recent major Manjaro update broke the fix on my system. It > upgraded my kernel from 5.10.36-2 to 5.10.41-1. I decided to go ahead and > upgrade to 5.13 and follow the tutorial again. The Arch Wiki fix worked on > the experimental kernel. Once I play audio > suspend > wake the speakers > continue to work until I log off. Even if I stop the audio for any period > of time while logged in the speakers still work. > @Niclas , what device are you running that on? So maybe that's caused by the same changes incorporated in my 5.8.0.53-#60 to 5.8.0.55-#62 which happened between 1. June 21 and 11. June 21 breaking the fix. So hopefully that will disappear onecmore with the next update
(In reply to TT from comment #175) > (In reply to Niclas from comment #173) > > Could someone try this, just copy and paste into a file, make it executable > > with chmod +x and run it. It worked for me.. > > > > https://pastebin.com/raw/zsXp2vz6 > > > > //Niclas > > Niclas, are you on a Legion 7i or Yoga? It works! the script works! on my Samsung Galaxy book pro 360, Unbuntu 21.04
I tried the script on PopOs 21.04 on my Lenovo 13s Gen 2 (ALC3306) but sadly it did not work. The script even removed the working input mic and now I just have dummy output in place of the regular output... :( But it seems we are on the good way! :)
I also tried the script on Ubuntu 20.04 on Legion 7i 15IMH05 and got the same result. It removed the working input mic and just a dummy output showed up. Niclas, how did you generate that script? It looks like it had a dos format.
First off, im sorry for the very minimal post with that pastebin. Very bad form and I have no other excuse then being emerged in another project and I had my head up my butt. So. I have the new Samsung Galaxy Book Pro LTE that just came out and I found this post: https://forum.manjaro.org/t/howto-set-up-the-audio-card-in-samsung-galaxy-book/37090 I tried that script by chance and it works. Although, it has 361 lines (!) and I havent started to disect it yet. Im not sure all of those is needed, when I run it I can hear that it first starts up the left speaker, then the right. I will take that on later. But that post also helps out for those that doesnt know how to make the changes permanent. As for you who found that this works for your specific device, you will have noticed that just closing the browser with youtube or killing vlc/aplay or whatever makes the sound disappear again. Running the script once more, will make it work again and so on. Im still in my other project so im not going to do any work on this one for now for a while yet, but if someone else does, please share here in the thread. //Niclas
I forgot, if you do just blindly use that script and decide to also add the systemd services it will actually work and be permanent after a reboot. //Niclas
tried it on my lenovo 7i and it doesn't work.
(In reply to Dre from comment #174) > The most recent major Manjaro update broke the fix on my system. It > upgraded my kernel from 5.10.36-2 to 5.10.41-1. (In reply to woody64 from comment #167) > (In reply to DavidLenovo from comment #120) > > Hi ! > > A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & 14ITL05 & > > 15ITL05 & 15ITL5 :) > > Sound from speakers works on Ubuntu 20.04.2LTS !!! > > > This method worked pretty well for me (Lenovo Yoga 7i) with kernal > 5.8.0-53-generic #60, > After update to 5.8.0-55 the S3 is not visible. How it work ? Anyone have to open a ticket, to signal it ? It the same for the 5.11.5 work and after 5.11.6 and more stop working Thanks :)
(In reply to Guido from comment #183) > tried it on my lenovo 7i and it doesn't work. On Lenovo Yoga 7i ? Could you try and report : cat /sys/power/mem_sleep sudo dmesg |grep ACPI|grep supports Thanks in advance
(In reply to Jenefer from comment #169) > (In reply to Jenefer from comment #168) > > (In reply to DavidLenovo from comment #166) > > > (In reply to Jenefer from comment #165) > > > > I can't believe it's been almost a year without this problem being > > solved. > > > I > > > > tried Ubuntu, PopOs, Fedora, Debian, they all had the same audio > problem. > > I > > > > guess I'll just have to get used to headphones now. > > > > > > Hello, what is your computer model ? > > > The problem is not link to the ALC287, just to enable the S3 in computer. > > > > My model is lenovo legion 7i 15IMHg05. I'm using Pop OS for now so It does > > not use grub boatloader. I don't know if I can change the kernel init. Can > > you explain how to "to enable the S3 in computer." ? > > Also, your solution seems to work on yoga models, I didn't see anyone with > legion model saying it worked for them. Here are my outputs: > > cat /sys/power/mem_sleep > s2idle [deep] > > sudo dmesg |grep ACPI|grep supports > [ 0.410327] ACPI: (supports S0 S3 S4 S5) > > I tried suspending the machine after playing some music but did not get > audio after waking Your S3 is already activated : you have [deep] and ACPI : S3 :-) It is suspend to ram, not to disk, is it that your have test ? Like Vincent Morel say Are you sure the Legion is ALC287 ? I have the same dmesg as you, but ehdaudio0D0 not hdaudioC1D0 and 2 line more : snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX overwritten snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX overwritten
(In reply to Jason Kukurudziak from comment #172) > I believe that Lenovo sells 2 versions of the Legion. We bought a bunch for > the company I work at and it is the ALC287. We ended up giving those to > Windows users and bought ones that had Ubuntu pre-installed. > > The behaviour of the audio suggests that there maybe an i/o line controlling > the amp to the speakers, imho. > > Jason You don't have to patch acpi DST table for this model ? I'm looking for a permanent solution, now the grub-update erase the solution, and we have to edit the grub.cfg, after each update. Thanks in advance
(In reply to DavidLenovo from comment #186) > (In reply to Jenefer from comment #169) > > (In reply to Jenefer from comment #168) > > > (In reply to DavidLenovo from comment #166) > > > > (In reply to Jenefer from comment #165) > > > > > I can't believe it's been almost a year without this problem being > > > solved. > > > > I > > > > > tried Ubuntu, PopOs, Fedora, Debian, they all had the same audio > > problem. > > > I > > > > > guess I'll just have to get used to headphones now. > > > > > > > > Hello, what is your computer model ? > > > > The problem is not link to the ALC287, just to enable the S3 in > computer. > > > > > > My model is lenovo legion 7i 15IMHg05. I'm using Pop OS for now so It > does > > > not use grub boatloader. I don't know if I can change the kernel init. > Can > > > you explain how to "to enable the S3 in computer." ? > > > > Also, your solution seems to work on yoga models, I didn't see anyone with > > legion model saying it worked for them. Here are my outputs: > > > > cat /sys/power/mem_sleep > > s2idle [deep] > > > > sudo dmesg |grep ACPI|grep supports > > [ 0.410327] ACPI: (supports S0 S3 S4 S5) > > > > > I tried suspending the machine after playing some music but did not get > > audio after waking > > Your S3 is already activated : you have [deep] and ACPI : S3 :-) > > It is suspend to ram, not to disk, is it that your have test ? > > > Like Vincent Morel say Are you sure the Legion is ALC287 ? > > > I have the same dmesg as you, but ehdaudio0D0 not hdaudioC1D0 and 2 line > more : > snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX overwritten > snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX overwritten on the lenovo spec page: https://psref.lenovo.com/Detail/Legion/Lenovo_Legion_7_15IMHg05?M=81YU0006FR it clearly says it is ALC3306. so I have first to correct the audio codec, can you help me with that ?
It seems that I'm expiring the same problem on a brand new Dell Latitude 9420 - Headphones works (starting with kernel 5.13-rc5), but speaker does not. I've tried the S3 patch from comment #120, but iasl failed to rempile it's own decompiled code: > $ sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml > $ iasl -d dsdt.aml > ... no errors or warnings ... Now trying to rempile the file with or without any patched applied: > $ iasl -ve -tc dsdt.aml.dsl > > Intel ACPI Component Architecture > ASL+ Optimizing Compiler/Disassembler version 20200925 > Copyright (c) 2000 - 2020 Intel Corporation > > dsdt.aml.dsl 89: External (_SB_.PC00.LPCB.ECDV.CMFC.DLPN, UnknownObj) > Error 6163 - ^ Object is > created temporarily in another method and cannot be accessed > (_SB_.PC00.LPCB.ECDV.CMFC.DLPN) > > dsdt.aml.dsl 90: External (_SB_.PC00.LPCB.ECDV.CMFC.IDMN, UnknownObj) > Error 6163 - ^ Object is > created temporarily in another method and cannot be accessed > (_SB_.PC00.LPCB.ECDV.CMFC.IDMN) > > dsdt.aml.dsl 91: External (_SB_.PC00.LPCB.ECDV.CMFC.IDPC, UnknownObj) > Error 6163 - ^ Object is > created temporarily in another method and cannot be accessed > (_SB_.PC00.LPCB.ECDV.CMFC.IDPC) > > ASL Input: dsdt.aml.dsl - 2613388 bytes 46237 keywords 78191 source > lines > Hex Dump: dsdt.aml.hex - 3421595 bytes > > Compilation failed. 3 Errors, 264 Warnings, 818 Remarks > No AML files were generated due to compiler error(s) Does anyone has an idea what causes this problem and how to get this laptop to enable S3 so I can check if this resolves the issue, too?
(In reply to Jenefer from comment #188) > (In reply to DavidLenovo from comment #186) > on the lenovo spec page: > https://psref.lenovo.com/Detail/Legion/Lenovo_Legion_7_15IMHg05?M=81YU0006FR > it clearly says it is ALC3306. so I have first to correct the audio codec, > can you help me with that ? Hello, I can't sorry, I have the ALC287, but Vincent Morel open a bug for this chipset : https://bugzilla.kernel.org/show_bug.cgi?id=213159 (In reply to Vincent Morel from comment #151) > (In reply to waterproof93 from comment #150) > > > > > I think I have the same issue with the same machine > > Thinkbook 13s G2 > > > > Let me know when you open a new thread I would like to follow it > > Just opened it :) > https://bugzilla.kernel.org/show_bug.cgi?id=213159
(In reply to Roland from comment #189) > It seems that I'm expiring the same problem on a brand new Dell Latitude > 9420 - Headphones works (starting with kernel 5.13-rc5), but speaker does > not. > > I've tried the S3 patch from comment #120, but iasl failed to rempile it's > own decompiled code: > > > $ sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml > > $ iasl -d dsdt.aml > > ... no errors or warnings ... > > Now trying to rempile the file with or without any patched applied: > > > $ iasl -ve -tc dsdt.aml.dsl > > > > Intel ACPI Component Architecture > > ASL+ Optimizing Compiler/Disassembler version 20200925 > > Copyright (c) 2000 - 2020 Intel Corporation > > > > dsdt.aml.dsl 89: External (_SB_.PC00.LPCB.ECDV.CMFC.DLPN, > UnknownObj) > > Error 6163 - ^ Object is > > created temporarily in another method and cannot be accessed > > (_SB_.PC00.LPCB.ECDV.CMFC.DLPN) > > > > dsdt.aml.dsl 90: External (_SB_.PC00.LPCB.ECDV.CMFC.IDMN, > UnknownObj) > > Error 6163 - ^ Object is > > created temporarily in another method and cannot be accessed > > (_SB_.PC00.LPCB.ECDV.CMFC.IDMN) > > > > dsdt.aml.dsl 91: External (_SB_.PC00.LPCB.ECDV.CMFC.IDPC, > UnknownObj) > > Error 6163 - ^ Object is > > created temporarily in another method and cannot be accessed > > (_SB_.PC00.LPCB.ECDV.CMFC.IDPC) > > > > ASL Input: dsdt.aml.dsl - 2613388 bytes 46237 keywords 78191 source > > lines > > Hex Dump: dsdt.aml.hex - 3421595 bytes > > > > Compilation failed. 3 Errors, 264 Warnings, 818 Remarks > > No AML files were generated due to compiler error(s) > > > Does anyone has an idea what causes this problem and how to get this laptop > to enable S3 so I can check if this resolves the issue, too? I think it is normal, this patch is for Lenovo Yoga 7i, and it depend on the hardware, so don't have the same :(. The S3 problem can be resolve by a BIOS option, Lenovo put a locked BIOS so we can't. But if Dell is better on this you could try to find an option S3, or energy, ACPI, it disable for Windows compatibility. I find this : https://downloads.dell.com/manuals/all-products/esuprt_laptop/esuprt_laptop_latitude/latitude-14-9420-2-in-1-laptop_reference-guide_en-us.pdf Not sure to understand :( You have try this 5.11.5 kernel, to be sure, it is not a kernel bug ? We don't know the 5.13.x working, @Dre, do you have more information of you version ? Could you try and report : cat /sys/power/mem_sleep sudo dmesg |grep ACPI|grep supports Thanks in advance
(In reply to DavidLenovo from comment #191) > I think it is normal, this patch is for Lenovo Yoga 7i, and it depend on the > hardware, so don't have the same :(. It's easy to port this patch to Dell, but that's not the point: iasl fails even without applying the patch, which should not happen ;-) But I think I have to ask the iasl people why this fails. > The S3 problem can be resolve by a BIOS option, Lenovo put a locked BIOS so > we can't. But if Dell is better on this you could try to find an option S3, > or energy, ACPI, it disable for Windows compatibility. It's a similar issue on Dell. S3 in BIOS is enabled, but: $ cat /sys/power/mem_sleep [s2idle] $ sudo dmesg |grep ACPI|grep supports [ 0.201665] ACPI: (supports S0 S4 S5) > You have try this 5.11.5 kernel, to be sure, it is not a kernel bug ? Kernel 5.11 is even worse because it doesn't even recognize the sound card. With 5.13rc5 at least the headphone jack and the microphone is working. But basically I think it's either this problem or the problem reported in #213159...
(In reply to DavidLenovo from comment #184) > (In reply to Dre from comment #174) > > The most recent major Manjaro update broke the fix on my system. It > > upgraded my kernel from 5.10.36-2 to 5.10.41-1. > > (In reply to woody64 from comment #167) > > (In reply to DavidLenovo from comment #120) > > > Hi ! > > > A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & 14ITL05 > & > > > 15ITL05 & 15ITL5 :) > > > Sound from speakers works on Ubuntu 20.04.2LTS !!! > > > > > > This method worked pretty well for me (Lenovo Yoga 7i) with kernal > > 5.8.0-53-generic #60, > > After update to 5.8.0-55 the S3 is not visible. > > How it work ? Anyone have to open a ticket, to signal it ? > It the same for the 5.11.5 work and after 5.11.6 and more stop working > > Thanks :) The fix broke each time I updated the system (which updated the kernel). I simply ran through the steps and it restored the fix. I'm currently on 5.13.0-1-MANJARO and have deep sleep again after applying the fix.
It seems someone was able to make progress on a similar issue via PCIE passthrough of their laptop's soundcard: https://bugzilla.kernel.org/show_bug.cgi?id=207423 https://bbs.archlinux.org/viewtopic.php?id=256009 Yesterday, I tried getting this to work on my 2020 Lenovo Legion 7i. The Windows VM seems to see the device in the device manager (and I see the right numeric PCIE ID under Windows), but beyond that Windows doesn't seem to recognize the device properly (although it does know it's a sound card at least but it isn't able to use it even with the proper drivers installed). This was my very first experience with the IOMMU stuff. Maybe someone else would have more luck? Before even attempting this, I set some option in the BIOS (under advanced mode): "Enable VTIO", which I assumed was for VT-d. I haven't confirmed whether or not this was needed, but mentioning it just in case.
Created attachment 297511 [details] Example of soundcard working in win10 VM via passthrough. Comments include steps. Screenshot of example Windows 10 VM working with RealTek sound card passthrough. The exclamation point for the "Intel(R) Smart Sound Technology" (Intel(R) SST) OED device is a red herring and is fine. Here are my notes to get this physical device running under a Windows 10 VM: You need to force the device expanded above to use the RealTek driver. I was able to force it by *extracting* rather than installing the sound driver from the Lenovo site. Selecting update driver on the sound device listed under "Sound, video and game controllers", and from there I did: "Browse my computer for drivers" "Let me pick from a list of available drivers on my computer" "Have Disk" Browse to: C:\Drivers\Audio\201211706.15485923\Realtek\Codec_8975.1\HDXLVSST.inf Press Ok You should see "Realtek High Definition Audio(SST)" as an option. It's the only option for me) Next Yes Restart the VM when prompted
Created attachment 297513 [details] Qemu trace from boot to login screen This is a trace I took via qemu of the soundcard device from boot to the login screen.
Created attachment 297515 [details] Trace of 5 seconds of playing random YouTube video I played a random song on YouTube. This trace starts immediately after the 2020-legion-boot-trace.txt trace. Not sure how helpful it is, but we'll see.
As my previous posts/attachments imply, I managed to get the sound card working in a Windows 10 VM with PCIE passthrough and I've been able to trace the events. I was able to get this process working by following these threads, As well as reading various wikis: https://bugzilla.kernel.org/show_bug.cgi?id=207423 https://bbs.archlinux.org/viewtopic.php?id=256009 If anyone is interested in trying this and needs help, I can probably help you get going into the right direction at the very least. The issue I had previously is that I would say I had to be more "aggressive" in getting Windows to use the correct driver. You'll know it's working when you're able to play audio in your VM and hear it through the laptop's speakers. Might also be helpful if someone does this on a Yoga Slim. Perhaps there are some differences in the verbs that must be sent out to the sound card. From here I guess what needs to be done is figure out what from these traces is needed and maybe try to write a script that that calls hda-verb to send the same verbs to the sound card under Linux (don't forget to re-enable the card for use under Linux again if you had PCIE passthrough setup!). I'll sign up with the ALSA mailing list and give an update on this issue since I suspect there's likely enough here for progress to be made.
> The fix broke each time I updated the system (which updated the kernel). I > simply ran through the steps and it restored the fix. I'm currently on > 5.13.0-1-MANJARO and have deep sleep again after applying the fix. Correct, everytime the grub is updated I need to reconfigure the fix, which works in my case for 5.8.0-53 but not for 5.8.0-55. For the 55 kernel I simply can't enable S3.
(In reply to woody64 from comment #199) > > > The fix broke each time I updated the system (which updated the kernel). I > > simply ran through the steps and it restored the fix. I'm currently on > > 5.13.0-1-MANJARO and have deep sleep again after applying the fix. > > Correct, everytime the grub is updated I need to reconfigure the fix, which > works in my case for 5.8.0-53 but not for 5.8.0-55. For the 55 kernel I > simply can't enable S3. To be more correct, I tried it oncemore and the result is, that with the 55 kernel after applying the patch you can now see: /sys/firmware/acpi/tables/DSDT1 /sys/firmware/acpi/tables/DSDT2 the DSDT1 holds the original values whereas the DSDT2 holds the new values.
(In reply to woody64 from comment #200) > (In reply to woody64 from comment #199) > > > > > The fix broke each time I updated the system (which updated the kernel). > I > > > simply ran through the steps and it restored the fix. I'm currently on > > > 5.13.0-1-MANJARO and have deep sleep again after applying the fix. > > > > Correct, everytime the grub is updated I need to reconfigure the fix, which > > works in my case for 5.8.0-53 but not for 5.8.0-55. For the 55 kernel I > > simply can't enable S3. > > To be more correct, I tried it oncemore and the result is, that with the 55 > kernel after applying the patch you can now see: > > /sys/firmware/acpi/tables/DSDT1 > /sys/firmware/acpi/tables/DSDT2 > > the DSDT1 holds the original values whereas the DSDT2 holds the new values. Might be relevant: https://bugzilla.kernel.org/show_bug.cgi?id=212643. This was a bug introduced by some commit in the ACPI subsystem, but it is fixed in recent versions of the kernel (somewhere around 5.13). Basically it would depend on what kind of distribution you are on, and whether their kernel is recent enough to have incorporated the fix.
(In reply to Roland from comment #192) > (In reply to DavidLenovo from comment #191) > > I think it is normal, this patch is for Lenovo Yoga 7i, and it depend on > the > > hardware, so don't have the same :(. > > It's easy to port this patch to Dell, but that's not the point: iasl fails > even without applying the patch, which should not happen ;-) But I think I > have to ask the iasl people why this fails. > > > The S3 problem can be resolve by a BIOS option, Lenovo put a locked BIOS so > > we can't. But if Dell is better on this you could try to find an option S3, > > or energy, ACPI, it disable for Windows compatibility. > > It's a similar issue on Dell. S3 in BIOS is enabled, but: > > $ cat /sys/power/mem_sleep > [s2idle] > $ sudo dmesg |grep ACPI|grep supports > [ 0.201665] ACPI: (supports S0 S4 S5) > > > You have try this 5.11.5 kernel, to be sure, it is not a kernel bug ? > > Kernel 5.11 is even worse because it doesn't even recognize the sound card. > With 5.13rc5 at least the headphone jack and the microphone is working. But > basically I think it's either this problem or the problem reported in > #213159... Yeah it can happen that the DSDT table is basically broken. If you are willing to invest time and patience, you can dig through the ACPI spec https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf and google the error messages to figure out what you need to do to fix it.
(In reply to Cameron from comment #198) > As my previous posts/attachments imply, I managed to get the sound card > working in a Windows 10 VM with PCIE passthrough and I've been able to trace > the events. > > I was able to get this process working by following these threads, > As well as reading various wikis: > https://bugzilla.kernel.org/show_bug.cgi?id=207423 > https://bbs.archlinux.org/viewtopic.php?id=256009 > > If anyone is interested in trying this and needs help, I can probably help > you get going into the right direction at the very least. > > The issue I had previously is that I would say I had to be more "aggressive" > in getting Windows to use the correct driver. You'll know it's working when > you're able to play audio in your VM and hear it through the laptop's > speakers. > > Might also be helpful if someone does this on a Yoga Slim. Perhaps there are > some differences in the verbs that must be sent out to the sound card. > > From here I guess what needs to be done is figure out what from these traces > is needed and maybe try to write a script that that calls hda-verb to send > the same verbs to the sound card under Linux (don't forget to re-enable the > card for use under Linux again if you had PCIE passthrough setup!). > > I'll sign up with the ALSA mailing list and give an update on this issue > since I suspect there's likely enough here for progress to be made. That sounds very promising, thank you very much! I don't currently have time but I'm definitely intrigued to look into this and hopefully finally develop a real fix.
The correct way to obtain the HDA verb sequence (note that qemu must be patched to analyze the CORB / RIRB memory DMA areas): https://github.com/torvalds/linux/commit/26928ca1f06aab4361eb5adbe7ef3b5c82f13cf2
Created attachment 297545 [details] HUGE progress! I reached out to Connor McAdams, the auth of QemuHDADump, about some issues I was having with QemuHDADump, and he directed me to https://github.com/ryanprescott/realtek-verb-tools This is a pair of scripts meant to work with the JCS fork of Qemu (which is just qemu patched for more output to stdout including CORB info for Intel HDA). That repo for that is here: https://github.com/jcs/qemu Last night I had found this repo, and I had simply tried to apply a patch from the JCS repo... It didn't work. The fields in the output were all zeros. Don't do that. Just build from the JCS repo directly. Running qemu binary from the JCS qemu, I was able to extract verbs from the the JCS Qemu output and apply them to the laptop using the realtek-verb-tools scripts. Applying these verbs initially didn't seem to work... So I tried playing music while applying them and you will get momentary blips of sound (specifically I heard blips of the track I was playing and not random noise)! What's most likely happening is that we need to extract a subset of these verbs for initialization and that some of the other verbs are stopping the sound (perhaps from when I stopped the YouTube video under windows as well as during shutdown). Don't forget to reboot your machine with pci passthrough otherwise the application of the verbs won't work because your sound card is setup up for well... passthrough. There appears to be a way to disable passthrough for the device without rebooting, but rebooting is faster for at least me. To provide some more concrete steps as to what I did: The configure I used for JCS Qemu: ./configure --prefix=/opt/qemu/jcs --enable-kvm --enable-trace-backends=log --target-list=x86_64-softmmu --disable-werror make -j$(nproc) make install How I ran it: sudo /opt/qemu/jcs/bin/qemu-system-x86_64 -enable-kvm -hda win10.qcow2 -m 8G -smp 4 -vga std -device vfio-pci,host=00:1f.3,multifunction=on,x-no-mmap=true -trace events=events.txt >output.txt python3 cleanverbs.py output.txt >verbs.txt # Rebooted without intel_iommu and without vfio-pci.ids # While playing sound: sudo python3 applyverbs.py verbs.txt With the verbs.txt, its likely that anyone on this thread with a Legion (or possibly a Yoga Slim as well) could apply these verbs and figure out what subset is needed. Which would be great because I don't know how much time I'll have now that it's Monday. It's worth noting that it's entirely possible that the Slim needs some slightly different initialization.
Created attachment 297547 [details] minimum verbs for both speakers working (so far)! I suspect we can get this shorter. But for now, the attached verbs are the minimum I've found that gives sound from both speakers: sudo python3 applyverbs.py verbs-working.txt In case anyone is curious as to how I'm doing this, I'm using 'head' to try subsets of the verbs to see the results I get: head -562 verbs.txt > verbs-working.txt sudo python3 applyverbs.py verbs-working.txt With the first 561 verbs, I only get output from one of the speakers. It's possible we can go even lower though, I just don't have the time. Putting the laptop to sleep and resuming results in non-working speakers. You will need to re-apply these verbs. It's also possible that if your laptop stays on but is idle that the speakers will go to sleep and will need to be re-initialized in that case too. I don't know if switching between headphones/bluetooth works yet, because a ways back I setup a combined audio device in my testing, and I don't think I'll have the time before work to figure out how I did it so I can undo it. I haven't had time to test the mic yet. Everyone, please test when you have free time. We're almost there!
I have very good news!! Thank you very much @Cameron!!! This file verbs-working.txt worked (apparently) for the two speackers for me on ubuntu 20.04 Legion 7i 15IMH05 kernel 5.8.0-55. I could even switch back and forth between the bluetooth headphones. The mic also looks like it is working.
For those wanting to test it. - Download the verbs-working.txt provided on https://bugzilla.kernel.org/show_bug.cgi?id=208555#c206 . - git clone https://github.com/ryanprescott/realtek-verb-tools - sudo python3 realtek-verb-tools/applyverbs.py verbs-working.txt - put some audio to play
I am not sure I have sound on both speakers though.
Tried that on a Lenovo Yoga 7i with Ubuntu 20.04LTS: - Started a Video in the browser - running the patch as described - and get a clear Sound on the speakers (as with the S3 patch) GREAT work ...
It seems similar to the S3 patch that after some seconds of not playing audio the effect disappears. But could be started immedeatly. Also attaching and deattaching the mic works as expected. The Audio test in settings shows correct output with left speaker: "Front left" bt no with the right speaker.
(In reply to woody64 from comment #212) > It seems similar to the S3 patch that after some seconds of not playing > audio the effect disappears. But could be started immedeatly. > > Also attaching and deattaching the mic works as expected. > > The Audio test in settings shows correct output with left speaker: "Front > left" bt no with the right speaker. As I mentioned above in my last comment, this is fixed by adding a few services to systemd. Follow the link I mention and it will work permanently. I have the right verbs in a script that just runs the command on each line, instead of a wrapper as mentioned now lately. So keep that in mind when adding the services (what you want to run). If you just run the script standalone, it will only work (kind of, has a few quirks you can do) "once" and you need to run it everytime before starting an audio source. //Niclas
(In reply to Niclas from comment #213) > (In reply to woody64 from comment #212) > > It seems similar to the S3 patch that after some seconds of not playing > > audio the effect disappears. But could be started immedeatly. > > > > Also attaching and deattaching the mic works as expected. > > > > The Audio test in settings shows correct output with left speaker: "Front > > left" bt no with the right speaker. > > As I mentioned above in my last comment, this is fixed by adding a few > services to systemd. Follow the link I mention and it will work permanently. > > I have the right verbs in a script that just runs the command on each line, > instead of a wrapper as mentioned now lately. So keep that in mind when > adding the services (what you want to run). > > If you just run the script standalone, it will only work (kind of, has a few > quirks you can do) "once" and you need to run it everytime before starting > an audio source. > > //Niclas This is my last comment with all the info: https://bugzilla.kernel.org/show_bug.cgi?id=208555#c181
I should clarify that you only needed to play music while applying the original verb.txt as those verbs appeared to start and stop the speakers several times. With verbs-working.txt, it doesn't matter whether or not if you're playing any sound during the apply.
Thanks for sharing, Niclas! Interesting that the verbs in your sitation were also 361. So I may have already found the magic number in just 5 minutes of testing. On 6/21/21 9:13 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #214 from Niclas (niclas@soderlund.org) --- > (In reply to Niclas from comment #213) >> (In reply to woody64 from comment #212) >>> It seems similar to the S3 patch that after some seconds of not playing >>> audio the effect disappears. But could be started immedeatly. >>> >>> Also attaching and deattaching the mic works as expected. >>> >>> The Audio test in settings shows correct output with left speaker: "Front >>> left" bt no with the right speaker. >> As I mentioned above in my last comment, this is fixed by adding a few >> services to systemd. Follow the link I mention and it will work permanently. >> >> I have the right verbs in a script that just runs the command on each line, >> instead of a wrapper as mentioned now lately. So keep that in mind when >> adding the services (what you want to run). >> >> If you just run the script standalone, it will only work (kind of, has a few >> quirks you can do) "once" and you need to run it everytime before starting >> an audio source. >> >> //Niclas > This is my last comment with all the info: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555#c181 >
(In reply to Cameron Berkenpas from comment #216) > Thanks for sharing, Niclas! > > Interesting that the verbs in your sitation were also 361. So I may have > already found the magic number in just 5 minutes of testing. > Yeah, it hardly can be a coincidence right? Well, I have everything working with this quite messy fix for now. And the new sof firmware was relased today, at least for debian. So now Im just waiting for a more complete and true fix to arrive. And in my case, with a Samsung Galaxy Book Pro, I still havent found a way to get the keyboard brightness adjusted or even turned off. But thats for anoter thread. //N
(In reply to Cameron Berkenpas from comment #215) > I should clarify that you only needed to play music while applying the > original verb.txt as those verbs appeared to start and stop the speakers > several times. > > With verbs-working.txt, it doesn't matter whether or not if you're > playing any sound during the apply. Yes, also the audio/speaker config stays now stable for the last 30 minutes.
It stays up for a while... However, after over an hour, it stopped working for me. I don't know the precise time, I just know it was more than 1 hour and less than 2. Re-applying brought sound back of course. On 6/21/21 9:51 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #218 from woody64 (andreas@mac-au.eu) --- > (In reply to Cameron Berkenpas from comment #215) >> I should clarify that you only needed to play music while applying the >> original verb.txt as those verbs appeared to start and stop the speakers >> several times. >> >> With verbs-working.txt, it doesn't matter whether or not if you're >> playing any sound during the apply. > Yes, also the audio/speaker config stays now stable for the last 30 minutes. >
(In reply to Cameron Berkenpas from comment #216) > Thanks for sharing, Niclas! > > Interesting that the verbs in your sitation were also 361. So I may have > already found the magic number in just 5 minutes of testing. > > On 6/21/21 9:13 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #214 from Niclas (niclas@soderlund.org) --- > > (In reply to Niclas from comment #213) > >> (In reply to woody64 from comment #212) > >>> It seems similar to the S3 patch that after some seconds of not playing > >>> audio the effect disappears. But could be started immedeatly. > >>> > >>> Also attaching and deattaching the mic works as expected. > >>> > >>> The Audio test in settings shows correct output with left speaker: > "Front > >>> left" bt no with the right speaker. > >> As I mentioned above in my last comment, this is fixed by adding a few > >> services to systemd. Follow the link I mention and it will work > permanently. > >> > >> I have the right verbs in a script that just runs the command on each > line, > >> instead of a wrapper as mentioned now lately. So keep that in mind when > >> adding the services (what you want to run). > >> > >> If you just run the script standalone, it will only work (kind of, has a > few > >> quirks you can do) "once" and you need to run it everytime before starting > >> an audio source. > >> > >> //Niclas > > This is my last comment with all the info: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555#c181 > > Cameron, the verbs file from Comment 206 has 562 lines. Did you manage to get it down to 361? Is the mic also working? Thanks
Whoops, I remembered the size incorrectly. It seems the mic is working for others. Definitely not going to be doing much testing today. In addition to it being a weekday, I have a Lenovo tech that's expected to be here soon to fix an unrelated issue on this laptop. Has anyone tested a 2021 Legion yet? I'm curious to know if this set of verb works. On 6/21/21 10:19 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #220 from TT (thiagotei@icloud.com) --- > (In reply to Cameron Berkenpas from comment #216) >> Thanks for sharing, Niclas! >> >> Interesting that the verbs in your sitation were also 361. So I may have >> already found the magic number in just 5 minutes of testing. >> >> On 6/21/21 9:13 AM, bugzilla-daemon@bugzilla.kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #214 from Niclas (niclas@soderlund.org) --- >>> (In reply to Niclas from comment #213) >>>> (In reply to woody64 from comment #212) >>>>> It seems similar to the S3 patch that after some seconds of not playing >>>>> audio the effect disappears. But could be started immedeatly. >>>>> >>>>> Also attaching and deattaching the mic works as expected. >>>>> >>>>> The Audio test in settings shows correct output with left speaker: >> "Front >>>>> left" bt no with the right speaker. >>>> As I mentioned above in my last comment, this is fixed by adding a few >>>> services to systemd. Follow the link I mention and it will work >> permanently. >>>> I have the right verbs in a script that just runs the command on each >> line, >>>> instead of a wrapper as mentioned now lately. So keep that in mind when >>>> adding the services (what you want to run). >>>> >>>> If you just run the script standalone, it will only work (kind of, has a >> few >>>> quirks you can do) "once" and you need to run it everytime before starting >>>> an audio source. >>>> >>>> //Niclas >>> This is my last comment with all the info: >>> >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555#c181 >>> > Cameron, > > the verbs file from Comment 206 has 562 lines. Did you manage to get it down > to > 361? Is the mic also working? > > Thanks >
(In reply to Cameron Berkenpas from comment #221) > Whoops, I remembered the size incorrectly. > > It seems the mic is working for others. > > Definitely not going to be doing much testing today. In addition to it > being a weekday, I have a Lenovo tech that's expected to be here soon to > fix an unrelated issue on this laptop. > > Has anyone tested a 2021 Legion yet? I'm curious to know if this set of > verb works. > > On 6/21/21 10:19 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #220 from TT (thiagotei@icloud.com) --- > > (In reply to Cameron Berkenpas from comment #216) > >> Thanks for sharing, Niclas! > >> > >> Interesting that the verbs in your sitation were also 361. So I may have > >> already found the magic number in just 5 minutes of testing. > >> > >> On 6/21/21 9:13 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>> > >>> --- Comment #214 from Niclas (niclas@soderlund.org) --- > >>> (In reply to Niclas from comment #213) > >>>> (In reply to woody64 from comment #212) > >>>>> It seems similar to the S3 patch that after some seconds of not playing > >>>>> audio the effect disappears. But could be started immedeatly. > >>>>> > >>>>> Also attaching and deattaching the mic works as expected. > >>>>> > >>>>> The Audio test in settings shows correct output with left speaker: > >> "Front > >>>>> left" bt no with the right speaker. > >>>> As I mentioned above in my last comment, this is fixed by adding a few > >>>> services to systemd. Follow the link I mention and it will work > >> permanently. > >>>> I have the right verbs in a script that just runs the command on each > >> line, > >>>> instead of a wrapper as mentioned now lately. So keep that in mind when > >>>> adding the services (what you want to run). > >>>> > >>>> If you just run the script standalone, it will only work (kind of, has a > >> few > >>>> quirks you can do) "once" and you need to run it everytime before > starting > >>>> an audio source. > >>>> > >>>> //Niclas > >>> This is my last comment with all the info: > >>> > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555#c181 > >>> > > Cameron, > > > > the verbs file from Comment 206 has 562 lines. Did you manage to get it > down > > to > > 361? Is the mic also working? > > > > Thanks > > I've got it down to 317 lines, but at some point I lost my mic. Thus, I need to further test it to make sure what screwed up the mic.
On 6/21/21 10:26 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > I've got it down to 317 lines, but at some point I lost my mic. > Thus, I need to further test it to make sure what screwed up the mic. > Really appreciate it. Of course please attach the verbs to the bug once you've got it narrowed down. I assume you've already tried 361. :)
(In reply to Cameron Berkenpas from comment #223) > On 6/21/21 10:26 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > I've got it down to 317 lines, but at some point I lost my mic. > > Thus, I need to further test it to make sure what screwed up the mic. > > > > Really appreciate it. Of course please attach the verbs to the bug once > you've got it narrowed down. > > I assume you've already tried 361. :) I didn't pay special attention to the 361, but that is likely the one I will try next.
(In reply to Jaroslav Kysela from comment #204) > The correct way to obtain the HDA verb sequence (note that qemu must be > patched to analyze the CORB / RIRB memory DMA areas): > > > https://github.com/torvalds/linux/commit/ > 26928ca1f06aab4361eb5adbe7ef3b5c82f13cf2 Thanks, this is _very_ helpful! This looks really straightforward to implement. Now for some newbie questions: Going through the kernel code, I see that on resume, alc_resume() is called, which will call codec->patch_ops.init(codec), this covers the resume from sleep cases. What about when the card itself (or its speakers so effectively the card) goes to sleep due to idle? Will the kernel automatically be made aware of this state? If not, how do we go about making it so the kernel is aware that the card will need to be re-inited? Once the kernel is aware that the card is in a state where it will need to be re-initialized for use, will it call the init callback or is it some other callback? Under hda_local.h, I see a number of actions are enumerated. Am I correct to assume we only need to cover the INIT case? /* fixup action definitions */ enum { HDA_FIXUP_ACT_PRE_PROBE, HDA_FIXUP_ACT_PROBE, HDA_FIXUP_ACT_INIT, HDA_FIXUP_ACT_BUILD, HDA_FIXUP_ACT_FREE, }; Thanks, again!
(In reply to TT from comment #224) > (In reply to Cameron Berkenpas from comment #223) > > On 6/21/21 10:26 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > I've got it down to 317 lines, but at some point I lost my mic. > > > Thus, I need to further test it to make sure what screwed up the mic. > > > > > > > Really appreciate it. Of course please attach the verbs to the bug once > > you've got it narrowed down. > > > > I assume you've already tried 361. :) > > I didn't pay special attention to the 361, but that is likely the one I will > try > next. made a test sequence and audio output is between 300 and 400 (in steps of 8) available from 324 ... also there are some higher numbers >1000 where my left speaker works. so I assume there are similar blocks inside which lead to the same result
to be more concrete 91-150 bytes from the beginning and 301-348 make a working sequence after reboot. These sequences can be found multiple times in the log, i.e. the on sequence on 889
Comment #208 works for me on my Legion C7i 82EHCTO1WW (Creator edition, same a the normal but with a better display) on Ubuntu 20.04.02 default kernel. But if I stop playing music 15-20 sec, I need to run the script again. I could leave with running the script once at boot, but having to do it all the time makes the solution more as a workaround, even so it is a progress, yes. I don't know if it has to do with the S3 stuff as I have not got it completely. I am like this: cat /sys/power/mem_sleep s2idle [deep] sudo dmesg | grep ACPI | grep support [ 0.535533] ACPI: (supports S0 S3 S4 S5) Which I understood means I am not impacted ?
Created attachment 297559 [details] linux-5.12.12-legion-sound-0.0.1.patch And here's a patch. PLEASE TEST! ...At your own risk. This is against Linux 5.12.2, but will likely work against many others. It seems to work even after resuming (but from the kernel code I see that sound cards are re-initialized on resume so no surprises there). I'm unsure if this will resolve the idle sound issue. If your sound still works after 2 hours, we're good to go. In my experience, it takes less than 2 hours before the speakers power down, but I don't know how long that is. 2 hours is a pretty safe test. I'm using the 562 verbs until we can get it narrowed down because we know for certain they work. I'm not sure what, if any, chain_id should be set for the Legion hence it being commented out and the TODO. However, it seems to be working without it for now. Also not sure if I'm fully following all the proper conventions, but that can be cleaned up with feedback. Unless the Yoga has the same vendor/dev ID's, this won't work there. I'll need to get those and add them to the patch. Same for newer Legion models. Enjoy!
I've done some testing with the patch. Sound still works after a few hours of activity for me so far. One big problem I've found is that if I connect head phones and then disconnect, output from the speakers no longer works unless I apply the verbs. If I connect head phones and never play any sound while they're connected, speaker output will still work. This suggests the hardware turns off the speakers if it detects head phones are the active output, which would make sense. I spent a long time trying to figure out how to re-initialize the speakers when head phones are unplugged. I couldn't figure out how to do it. Is there anyone who could please provide guidance here?
Status on the Lenovo Yoga 7i: - only left speakers work with the patch, but it seems to be stable for hours - I was in the opinion that I can narrow down to some smaller sequences (speakers off, speakers on), but that was partly not reprodcable after reboots. Additionally it turned out that the smaller sequences affects the left speaker only. But i can only hear that after S3 resume since the patch only initial enables the left side. - when doing the S3 workaraound both speakers work, but this stops when there's no activity for 10-20 seconds => would be interesting if the driver generates a similar sequence as the patch after resume from S3 ? - using the patch afterwards, the sound stays on both speakers without audio activity for minutes
Again, its not a great solution, but what I did was to make a systemd service that has the wants of hibernation and sleep. So when systemd detects that the laptop is woken up from either of those, ie resume, it just runs the script again. That fixes the problem superficially and I have constant sound and dont have to think about it. Now this is on my Samsung Galaxy Book, so I have both speakers working fine et al. But for now and until a better fix comes along, it makes it seamless. //N (In reply to woody64 from comment #231) > Status on the Lenovo Yoga 7i: > - only left speakers work with the patch, but it seems to be stable for hours > - I was in the opinion that I can narrow down to some smaller sequences > (speakers off, speakers on), but that was partly not reprodcable after > reboots. Additionally it turned out that the smaller sequences affects the > left speaker only. But i can only hear that after S3 resume since the patch > only initial enables the left side. > - when doing the S3 workaraound both speakers work, but this stops when > there's no activity for 10-20 seconds => would be interesting if the driver > generates a similar sequence as the patch after resume from S3 ? > - using the patch afterwards, the sound stays on both speakers without audio > activity for minutes
It doesn't work for me. I have ubuntu with linux kernel 5.11.0-18-generic. Applying patch returns an error patching file legion_15imhg05_speakers.c can't find file to patch at input line 502 Maybe I did something wrong?
(In reply to Niclas from comment #233) > Again, its not a great solution, but what I did was to make a systemd > service that has the wants of hibernation and sleep. So when systemd detects > that the laptop is woken up from either of those, ie resume, it just runs > the script again. Thanks for that. My summary is mainly ment for the results of Cameron which is a significant step in a patch also for the Yoga 7i ...
I experienced the same as Comment #230 and Comment #231 in Ubuntu 20.04.2 kernel 5.8.0-55. BTW, have you seen this windows program to get the dumps? RtHDDump_V236.zip It is suggested suggested by Hui Wang that has contributions to the Realtek patches. Sources: - https://asus-linux.org/blog/sound-2021-01-11/#getting-dumps - https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1852922 - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518 I have windows installed in another partition and may try it later. We may have already the coeffs to make it work but this may show something extra.
(In reply to TT from comment #208) > For those wanting to test it. > - Download the verbs-working.txt provided on > https://bugzilla.kernel.org/show_bug.cgi?id=208555#c206 . > - git clone https://github.com/ryanprescott/realtek-verb-tools > - sudo python3 realtek-verb-tools/applyverbs.py verbs-working.txt > - put some audio to play Thank you so much! This worked somehow on my lenovo legion 7i 15IMHg05. It's not permanent though as audio needs to be played constantly for it to last longer, otherwise it go back after few seconds. I hope that the fix will be patched to the kernel after some fine-tuning as I noticed that applying the verbs the quality of audio is not quite good compared to how it was on windows. But who I am to complain, I'm just happy there is a workaround to use keep me using linux on my machine. Also it's weird that the fix worked for my laptop even though I have the issue with mis-detected codecs: the specs of my laptop list ALC3306 while alsa reports ALC287.
Applying the original 562 verbs brings up both speakers though? If so, weird that this patch only brings up one. On 6/21/21 10:58 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #231 from woody64 (andreas@mac-au.eu) --- > Status on the Lenovo Yoga 7i: > - only left speakers work with the patch, but it seems to be stable for hours > - I was in the opinion that I can narrow down to some smaller sequences > (speakers off, speakers on), but that was partly not reprodcable after > reboots. > Additionally it turned out that the smaller sequences affects the left > speaker > only. But i can only hear that after S3 resume since the patch only initial > enables the left side. > - when doing the S3 workaraound both speakers work, but this stops when > there's > no activity for 10-20 seconds => would be interesting if the driver generates > a > similar sequence as the patch after resume from S3 ? > - using the patch afterwards, the sound stays on both speakers without audio > activity for minutes >
Can you provide the command you're running and the error? On 6/21/21 11:11 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #234 from Deni (deniallugo@gmail.com) --- > It doesn't work for me. > I have ubuntu with linux kernel 5.11.0-18-generic. > > Applying patch returns an error > > patching file legion_15imhg05_speakers.c > can't find file to patch at input line 502 > > Maybe I did something wrong? >
Please share your results if you try. I probably won't have the time to try this for myself for well over a week. On 6/22/21 7:42 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #236 from TT (thiagotei@icloud.com) --- > I experienced the same as Comment #230 and Comment #231 in Ubuntu 20.04.2 > kernel 5.8.0-55. > > BTW, have you seen this windows program to get the dumps? RtHDDump_V236.zip > It is suggested suggested by Hui Wang that has contributions to the Realtek > patches. Sources: > - https://asus-linux.org/blog/sound-2021-01-11/#getting-dumps > - https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1852922 > - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518 > I have windows installed in another partition and may try it later. > We may have already the coeffs to make it work but this may show something > extra. >
(In reply to Jenefer from comment #237) > (In reply to TT from comment #208) > > For those wanting to test it. > > - Download the verbs-working.txt provided on > > https://bugzilla.kernel.org/show_bug.cgi?id=208555#c206 . > > - git clone https://github.com/ryanprescott/realtek-verb-tools > > - sudo python3 realtek-verb-tools/applyverbs.py verbs-working.txt > > - put some audio to play > > Thank you so much! This worked somehow on my lenovo legion 7i 15IMHg05. > It's not permanent though as audio needs to be played constantly for it to > last longer, otherwise it go back after few seconds. I hope that the fix > will be patched to the kernel after some fine-tuning as I noticed that > applying the verbs the quality of audio is not quite good compared to how it > was on windows. But who I am to complain, I'm just happy there is a > workaround to use keep me using linux on my machine. > > Also it's weird that the fix worked for my laptop even though I have the > issue with mis-detected codecs: the specs of my laptop list ALC3306 while > alsa reports ALC287. I haven't had a chance to try comparing the audio quality, but I have wondered if that might be the case... How did you compare? Was it with the same application? Ie, maybe FireFox/Chrome and YouTube? Is anyone else seeing differences?
(In reply to Cameron Berkenpas from comment #241) > (In reply to Jenefer from comment #237) > > (In reply to TT from comment #208) > > > For those wanting to test it. > > > - Download the verbs-working.txt provided on > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555#c206 . > > > - git clone https://github.com/ryanprescott/realtek-verb-tools > > > - sudo python3 realtek-verb-tools/applyverbs.py verbs-working.txt > > > - put some audio to play > > > > Thank you so much! This worked somehow on my lenovo legion 7i 15IMHg05. > > It's not permanent though as audio needs to be played constantly for it to > > last longer, otherwise it go back after few seconds. I hope that the fix > > will be patched to the kernel after some fine-tuning as I noticed that > > applying the verbs the quality of audio is not quite good compared to how > it > > was on windows. But who I am to complain, I'm just happy there is a > > workaround to use keep me using linux on my machine. > > > > Also it's weird that the fix worked for my laptop even though I have the > > issue with mis-detected codecs: the specs of my laptop list ALC3306 while > > alsa reports ALC287. > > > I haven't had a chance to try comparing the audio quality, but I have > wondered if that might be the case... How did you compare? Was it with the > same application? Ie, maybe FireFox/Chrome and YouTube? > > Is anyone else seeing differences? I've ran firefox with the same youtube video and I also felt the quality is lower on Linux. I don't know how to describe the difference though. It is not a significant difference for me. I am good with the current quality, but there is definitelly something to improve there.
I just did the same thing, and my reaction is the same. The quality is lower under Linux, but it's not a massive difference. Maybe it sounds more tinny under Linux? Not sure what controls that... Maybe coefficients? I would say the current quality is still a massive step up over having had no sound at all. My current priority is to fix the headphone issues. I want the speakers to start working again after unplugging from the headphone jack. On 6/22/21 9:06 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #242 from TT (thiagotei@icloud.com) --- > (In reply to Cameron Berkenpas from comment #241) >> (In reply to Jenefer from comment #237) >>> (In reply to TT from comment #208) >>>> For those wanting to test it. >>>> - Download the verbs-working.txt provided on >>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555#c206 . >>>> - git clone https://github.com/ryanprescott/realtek-verb-tools >>>> - sudo python3 realtek-verb-tools/applyverbs.py verbs-working.txt >>>> - put some audio to play >>> Thank you so much! This worked somehow on my lenovo legion 7i 15IMHg05. >>> It's not permanent though as audio needs to be played constantly for it to >>> last longer, otherwise it go back after few seconds. I hope that the fix >>> will be patched to the kernel after some fine-tuning as I noticed that >>> applying the verbs the quality of audio is not quite good compared to how >> it >>> was on windows. But who I am to complain, I'm just happy there is a >>> workaround to use keep me using linux on my machine. >>> >>> Also it's weird that the fix worked for my laptop even though I have the >>> issue with mis-detected codecs: the specs of my laptop list ALC3306 while >>> alsa reports ALC287. >> >> I haven't had a chance to try comparing the audio quality, but I have >> wondered if that might be the case... How did you compare? Was it with the >> same application? Ie, maybe FireFox/Chrome and YouTube? >> >> Is anyone else seeing differences? > I've ran firefox with the same youtube video and I also felt the quality is > lower on Linux. I don't know how to describe the difference though. > It is not a significant difference for me. > I am good with the current quality, but there is definitelly something to > improve there. >
(In reply to Cameron Berkenpas from comment #243) > I just did the same thing, and my reaction is the same. The quality is > lower under Linux, but it's not a massive difference. Maybe it sounds > more tinny under Linux? > > Not sure what controls that... Maybe coefficients? > > I would say the current quality is still a massive step up over having > had no sound at all. > > My current priority is to fix the headphone issues. I want the speakers > to start working again after unplugging from the headphone jack. > > > On 6/22/21 9:06 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #242 from TT (thiagotei@icloud.com) --- > > (In reply to Cameron Berkenpas from comment #241) > >> (In reply to Jenefer from comment #237) > >>> (In reply to TT from comment #208) > >>>> For those wanting to test it. > >>>> - Download the verbs-working.txt provided on > >>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555#c206 . > >>>> - git clone https://github.com/ryanprescott/realtek-verb-tools > >>>> - sudo python3 realtek-verb-tools/applyverbs.py verbs-working.txt > >>>> - put some audio to play > >>> Thank you so much! This worked somehow on my lenovo legion 7i 15IMHg05. > >>> It's not permanent though as audio needs to be played constantly for it > to > >>> last longer, otherwise it go back after few seconds. I hope that the fix > >>> will be patched to the kernel after some fine-tuning as I noticed that > >>> applying the verbs the quality of audio is not quite good compared to how > >> it > >>> was on windows. But who I am to complain, I'm just happy there is a > >>> workaround to use keep me using linux on my machine. > >>> > >>> Also it's weird that the fix worked for my laptop even though I have the > >>> issue with mis-detected codecs: the specs of my laptop list ALC3306 while > >>> alsa reports ALC287. > >> > >> I haven't had a chance to try comparing the audio quality, but I have > >> wondered if that might be the case... How did you compare? Was it with the > >> same application? Ie, maybe FireFox/Chrome and YouTube? > >> > >> Is anyone else seeing differences? > > I've ran firefox with the same youtube video and I also felt the quality is > > lower on Linux. I don't know how to describe the difference though. > > It is not a significant difference for me. > > I am good with the current quality, but there is definitelly something to > > improve there. > > I guess you already checked, but just be sure there is no "sound enhancement" activated under Windows... On my Lenovo, there is some sound enhancer activated by default in Windows. Seems we get near to find a solution, I'll have to test on my 13S Gen2 all of this (and I will report back on the ALC3306 thread).
On 6/22/21 9:16 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > I guess you already checked, but just be sure there is no "sound enhancement" > activated under Windows... On my Lenovo, there is some sound enhancer > activated > by default in Windows. > Seems we get near to find a solution, I'll have to test on my 13S Gen2 all of > this (and I will report back on the ALC3306 thread). > I didn't know about the enhanced sound. Is that controlled in Lenovo Vantage?
(In reply to Cameron Berkenpas from comment #245) > On 6/22/21 9:16 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > > > I guess you already checked, but just be sure there is no "sound > enhancement" > > activated under Windows... On my Lenovo, there is some sound enhancer > > activated > > by default in Windows. > > Seems we get near to find a solution, I'll have to test on my 13S Gen2 all > of > > this (and I will report back on the ALC3306 thread). > > > I didn't know about the enhanced sound. Is that controlled in Lenovo > Vantage? Yes it's there in Lenovo Vantage (surround stuff, or enhancement, or I can't remember the name). I always remove those stuff, whatever they call it, because I prefer "natural" sound...
(In reply to TT from comment #236) > I experienced the same as Comment #230 and Comment #231 in Ubuntu 20.04.2 > kernel 5.8.0-55. > > BTW, have you seen this windows program to get the dumps? RtHDDump_V236.zip > It is suggested suggested by Hui Wang that has contributions to the Realtek > patches. Sources: > - https://asus-linux.org/blog/sound-2021-01-11/#getting-dumps > - https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1852922 > - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518 > I have windows installed in another partition and may try it later. > We may have already the coeffs to make it work but this may show something > extra. I've tried to follow some ideas in the dump. Don't know if that brings anybody further insights. # 1. enables output of COEF echo 1 |sudo tee /sys/module/snd_hda_codec/parameters/dump_coef # shows the result for the ALC287 cat /proc/asound/card0/codec#0 # thus allowing to dump the different COEF register states after several actions => if I'm comparing the output before and after S3 resume, I can't see a significant difference # 2. enable hda traces echo 1 | sudo tee /sys/kernel/debug/tracing/events/hda/enable # read traces sudo cat /sys/kernel/debug/tracing/trace >/tmp/1 # result in output like: # alsa-sink-HDA A-1107 [000] .... 9249.632894: hda_send_cmd: [0000:00:1f.3:0] val=0x00170500 hda-decode-verb 0x00170500 raw value = 0x00170500 cid = 0, nid = 0x01, verb = 0x705, parm = 0x00 raw value: verb = 0x705, parm = 0x0 verbname = set_power_state My main idea is that there must something happen after a S3 resume which leads to a working speaker config, and it must be in the driver code? I've tried to catch that and will upload the results soon ... Additionally looking in the kernel code you see: - HDA_CODEC_ENTRY(0x10ec0287, "ALC287", patch_alc269) - for alc269 you find - codec->patch_ops.resume = alc269_resume; => special resume handling - in alc269_resume: /* on some machine, the BIOS will clear the codec gpio data when enter * suspend, and won't restore the data after resume, so we restore it * in the driver. */ => would explain, why S3 resume is working - maybe some additonal toggle_power_output commands are also helpful Is that something which can be helpful or a complete misleading path?
Some of the tools are coming from https://kernel.org/doc/html/v4.16/sound/hd-audio/notes.html
On 6/22/21 3:05 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #247 from woody64 (andreas@mac-au.eu) --- > (In reply to TT from comment #236) >> I experienced the same as Comment #230 and Comment #231 in Ubuntu 20.04.2 >> kernel 5.8.0-55. >> >> BTW, have you seen this windows program to get the dumps? RtHDDump_V236.zip >> It is suggested suggested by Hui Wang that has contributions to the Realtek >> patches. Sources: >> - https://asus-linux.org/blog/sound-2021-01-11/#getting-dumps >> - https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1852922 >> - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518 >> I have windows installed in another partition and may try it later. >> We may have already the coeffs to make it work but this may show something >> extra. > I've tried to follow some ideas in the dump. Don't know if that brings > anybody > further insights. How direct can the dumps be translated to verbs? If translating isn't an issue (I don't know what the dump output looks like yet but I should really look), that should be a sufficient set of verbs to get both speakers going in a patch for the Yoga. Hopefully the dumps are a working alternative to running a Windows VM with PCIE passthrough... It's quite a bit of work to setup. > > # 1. enables output of COEF > echo 1 |sudo tee /sys/module/snd_hda_codec/parameters/dump_coef > # shows the result for the ALC287 > cat /proc/asound/card0/codec#0 > # thus allowing to dump the different COEF register states after several > actions > > => if I'm comparing the output before and after S3 resume, I can't see a > significant difference > > # 2. enable hda traces > echo 1 | sudo tee /sys/kernel/debug/tracing/events/hda/enable > # read traces > sudo cat /sys/kernel/debug/tracing/trace >/tmp/1 > # result in output like: > # alsa-sink-HDA A-1107 [000] .... 9249.632894: hda_send_cmd: > [0000:00:1f.3:0] val=0x00170500 > hda-decode-verb 0x00170500 > raw value = 0x00170500 > cid = 0, nid = 0x01, verb = 0x705, parm = 0x00 > raw value: verb = 0x705, parm = 0x0 > verbname = set_power_state I think these traces will very useful. Perhaps I can also use them to determine what's going on when I plug headphones into the jack and remove them so we can handle that appropriately. > > My main idea is that there must something happen after a S3 resume which > leads > to a working speaker config, and it must be in the driver code? > > I've tried to catch that and will upload the results soon ... > > Additionally looking in the kernel code you see: > - HDA_CODEC_ENTRY(0x10ec0287, "ALC287", patch_alc269) > - for alc269 you find > - codec->patch_ops.resume = alc269_resume; => special resume handling > - in alc269_resume: > /* on some machine, the BIOS will clear the codec gpio data when enter > * suspend, and won't restore the data after resume, so we restore it > * in the driver. > */ > > => would explain, why S3 resume is working > - maybe some additonal toggle_power_output commands are also helpful Well, this is like the other issue with my patch where after unplugging headphones, speaker output is gone again and can be restored by either applying the verbs or a *resume*. I did notice that resume seems to call init for the card again (which applies to the verbs that are in the patch), but the fact that this worked for the Yoga Slim *before* my patch and gets both speakers to come up *after* the patch makes me think there might be something in the firmware/BIOS. Maybe Lenovo was running into an issue on resume and the firmware/BIOS re-initializes the speakers as a workaround? Or maybe it is something in the driver? But AFAIK, looking through the kernel code, resume just seems to call the init function IIRC. And maybe this is why S3 has to be enabled by editing the DSDT table; it was giving Lenovo some trouble? > > > > Is that something which can be helpful or a complete misleading path? I think all of this is helpful, and I'm very grateful to have another pair of eyes on this. Thank you! On an unrelated note, I sent a message to alsa-devel (I signed up first) and so far no bites. However, maybe a lot of them in Europe (I'm in the US) and perhaps I'll see some responses by morning..?
> I've ran firefox with the same youtube video and I also felt the quality is > lower on Linux. I don't know how to describe the difference though. > It is not a significant difference for me. > I am good with the current quality, but there is definitelly something to > improve there. Hmm. The cut off point in verbs-working.txt is almost arbitrary. I started from an arbitrary point in verbs.txt and found the first place from that original starting point that gave me 2 working speakers on my Legion. It's possible if we go further down through verbs.txt we get to a point where the audio quality improves I suppose. I'm keeping my focus on the headphone issue for now before I try anything with the sound quality issue. Hopefully someone else can play with this in the meantime. I don't think there should be any conflict between applying verbs and using the patch. Or at least none that wouldn't exist when not using the patch anyway... :)
Created attachment 297569 [details] linux-5.12.12-legion-sound-0.0.2.patch - headphone fix Headphone issue is fixed. I believe unmute hooks are called whenever jacks are either plugged or unplugged. We'll probably want only want to send the verbs when we're in the unplugged state. I'll update that at some point before I try for a final patch. I know I implied I'd work on audio quality next... But how many people would like me to work on getting the Yoga support squared away so it's on par with the Legion support (ie, you get both speakers)? I suspect functionality is more important than what appears to be a smallish loss of quality. Also, Legion and Yoga owners, please test. Let me know of any issues. In particular, let me know whether or not speaker output still works after plugging in and then unplugging in headphones.
Created attachment 297571 [details] linux-5.12.12-legion-sound-0.0.3.patch - actual headphone fix Whoops, patch 0.0.2 is exactly the same as 0.0.1. Please use this one. Everything else from my previous message still stands.
Going through the alsa-info results posted in this bug and looking at the subsystem ID's, none of the models are supported by my patch except for the Legion. For the non-Legion users who have built their kernels with my patch applied, are you sure you aren't still using the S3 and/or the verb workarounds? In this bug, I've found the following models: Yoga Slim 7 Yoga 7 14ITL5 Yoga Duet 7 Legion 7 In sound/pci/hda/patch_realtek.c, my patch adds this line: SND_PCI_QUIRK(0x17aa, 0x3813, "Lenovo Legion 7", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), The ID's for all the other models are different which means these kernel patches should only affect Legion 7's (and possibly only the 2020 model). Therefore the patch is probably doing nothing for you and you likely have one of the other workarounds in place (S3/verbs). But please look into this and update me one way or the other. Interestingly, there's a quirk that does match the Yoga Duet in patch_realtek.c: SND_PCI_QUIRK(0x17aa, 0x3818, "Lenovo C940", ALC298_FIXUP_LENOVO_SPK_VOLUME), But I presume the "Lenovo C940" fix doesn't work for the Duet. I have enough info from alsa-info for these other non-Legion models to create a patch that will apply to them. If applying verbs-working.txt works for your model, then a patch would work as well (except your speakers presumably wouldn't stop working after a period of time, etc). Just let me know.
I've patched kernel 5.8.0-59 for Ubuntu 20.04.2/Legion 7i and everything worked well! Headphones turn the speakers off when I plug them in and back on when I plug them off. I had adapt the patch because the kernel version was different than the one in Comment #252 but that was easy.
(In reply to wave from comment #203) > (In reply to Cameron from comment #198) > > As my previous posts/attachments imply, I managed to get the sound card > > working in a Windows 10 VM with PCIE passthrough and I've been able to > trace > > the events. > > > > I was able to get this process working by following these threads, > > As well as reading various wikis: > > https://bugzilla.kernel.org/show_bug.cgi?id=207423 > > https://bbs.archlinux.org/viewtopic.php?id=256009 > > > > If anyone is interested in trying this and needs help, I can probably help > > you get going into the right direction at the very least. > > > > The issue I had previously is that I would say I had to be more > "aggressive" > > in getting Windows to use the correct driver. You'll know it's working when > > you're able to play audio in your VM and hear it through the laptop's > > speakers. > > > > Might also be helpful if someone does this on a Yoga Slim. Perhaps there > are > > some differences in the verbs that must be sent out to the sound card. > > > > From here I guess what needs to be done is figure out what from these > traces > > is needed and maybe try to write a script that that calls hda-verb to send > > the same verbs to the sound card under Linux (don't forget to re-enable the > > card for use under Linux again if you had PCIE passthrough setup!). > > > > I'll sign up with the ALSA mailing list and give an update on this issue > > since I suspect there's likely enough here for progress to be made. > > That sounds very promising, thank you very much! I don't currently have time > but I'm definitely intrigued to look into this and hopefully finally develop > a real fix. Thanks you very much, it is the same for me.
(In reply to Dre from comment #193) > (In reply to DavidLenovo from comment #184) > > (In reply to Dre from comment #174) > > > The most recent major Manjaro update broke the fix on my system. It > > > upgraded my kernel from 5.10.36-2 to 5.10.41-1. > > > > (In reply to woody64 from comment #167) > > > (In reply to DavidLenovo from comment #120) > > > > Hi ! > > > > A man have find the solution for the Yoga 7 - Yoga 7i - 14ITL5 & > 14ITL05 > > & > > > > 15ITL05 & 15ITL5 :) > > > > Sound from speakers works on Ubuntu 20.04.2LTS !!! > > > > > > > > > This method worked pretty well for me (Lenovo Yoga 7i) with kernal > > > 5.8.0-53-generic #60, > > > After update to 5.8.0-55 the S3 is not visible. > > > > How it work ? Anyone have to open a ticket, to signal it ? > > It the same for the 5.11.5 work and after 5.11.6 and more stop working > > > > Thanks :) > > The fix broke each time I updated the system (which updated the kernel). I > simply ran through the steps and it restored the fix. I'm currently on > 5.13.0-1-MANJARO and have deep sleep again after applying the fix. Ok thanks :)
(In reply to Roland from comment #192) > (In reply to DavidLenovo from comment #191) > > I think it is normal, this patch is for Lenovo Yoga 7i, and it depend on > the > > hardware, so don't have the same :(. > > It's easy to port this patch to Dell, but that's not the point: iasl fails > even without applying the patch, which should not happen ;-) But I think I > have to ask the iasl people why this fails. > > > The S3 problem can be resolve by a BIOS option, Lenovo put a locked BIOS so > > we can't. But if Dell is better on this you could try to find an option S3, > > or energy, ACPI, it disable for Windows compatibility. > > It's a similar issue on Dell. S3 in BIOS is enabled, but: > > $ cat /sys/power/mem_sleep > [s2idle] > $ sudo dmesg |grep ACPI|grep supports > [ 0.201665] ACPI: (supports S0 S4 S5) > > > You have try this 5.11.5 kernel, to be sure, it is not a kernel bug ? > > Kernel 5.11 is even worse because it doesn't even recognize the sound card. > With 5.13rc5 at least the headphone jack and the microphone is working. But > basically I think it's either this problem or the problem reported in > #213159... You sure it is the ALC287 ? For me it make no sens the driver work for us and not for you. In case of your computer recognize the sound card but the speaker don't work, it seem to be logic, but don't recognized, with a working kernel for us, I'm surprised. For me after 5.11.5 it stop working. I write 5.11.5 cause of that point. Do you have try 5.11.5 or older ?
(In reply to woody64 from comment #176) > (In reply to Dre from comment #174) > > The most recent major Manjaro update broke the fix on my system. It > > upgraded my kernel from 5.10.36-2 to 5.10.41-1. I decided to go ahead and > > upgrade to 5.13 and follow the tutorial again. The Arch Wiki fix worked on > > the experimental kernel. Once I play audio > suspend > wake the speakers > > continue to work until I log off. Even if I stop the audio for any period > > of time while logged in the speakers still work. > > @Niclas , what device are you running that on? > > So maybe that's caused by the same changes incorporated in my 5.8.0.53-#60 > to 5.8.0.55-#62 which happened between 1. June 21 and 11. June 21 breaking > the fix. > So hopefully that will disappear onecmore with the next update System was updated to 5.8.0-59-generic #66 today and: - S3 fix is oncemore working as expected (S3 can be enabled in this version onecemore by overwriting tje DSDT table) => both speakers enabled - also Cameron's workaround (verbs-working.txt) is doing the same job as before => left speaker enable trying to setup a kernel compilation environment to check also the kernal patch.
(In reply to DavidLenovo from comment #257) > You sure it is the ALC287 ? No, I'm not, although the problem sounds quote similar. This may be a coincidence, but I'll keep an eye on this issue.
Possibly the minimum verbs of the two speakers working in Yoga 7i ``` // left speaker 0x20 0x500 0x24 0x20 0x400 0x41 // unmute 0x20 0x500 0x26 0x20 0x400 0x2 0x20 0x400 0x0 0x20 0x400 0x0 0x20 0x4b0 0x20 // right speaker (I Guessed 4 times) 0x20 0x500 0x24 0x20 0x400 0x46 // may be necessary 0x20 0x500 0x26 0x20 0x400 0xc 0x20 0x400 0x0 0x20 0x400 0x2a 0x20 0x4b0 0x20 // unmute 0x20 0x500 0x26 0x20 0x400 0x2 0x20 0x400 0x0 0x20 0x400 0x0 0x20 0x4b0 0x20 ```
confirmed on Ubuntu 20.04 with kernel 5.8.0-59-generic #66. First time this "workaround" enables both speakers (so far only left speaker). Great ....
sycxyc, Great work! Is this work from the verbs I attached to the ticket or did you find these verbs on your own? Can you give me your alsa-info.sh? You can either post the the output here or upload it and share the URL. With all this and your verbs, I should be able to update the patch to cover your machine. On 6/23/21 6:17 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #260 from sycxyc (sycxyc@yandex.com) --- > Possibly the minimum verbs of the two speakers working in Yoga 7i > > ``` > > // left speaker > 0x20 0x500 0x24 > 0x20 0x400 0x41 > // unmute > 0x20 0x500 0x26 > 0x20 0x400 0x2 > 0x20 0x400 0x0 > 0x20 0x400 0x0 > 0x20 0x4b0 0x20 > // right speaker (I Guessed 4 times) > 0x20 0x500 0x24 > 0x20 0x400 0x46 > // may be necessary > 0x20 0x500 0x26 > 0x20 0x400 0xc > 0x20 0x400 0x0 > 0x20 0x400 0x2a > 0x20 0x4b0 0x20 > // unmute > 0x20 0x500 0x26 > 0x20 0x400 0x2 > 0x20 0x400 0x0 > 0x20 0x400 0x0 > 0x20 0x4b0 0x20 > > ``` >
woody64, You're on *buntu 20.04, is that right? Can you please provide your alsa-info to me? Sorry if you've already shared it. I searched through your posts in this bug and couldn't find it, but there are a lot of comments so it's possible I missed it. On 6/23/21 6:28 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #261 from woody64 (andreas@mac-au.eu) --- > confirmed on Ubuntu 20.04 with kernel 5.8.0-59-generic #66. > > First time this "workaround" enables both speakers (so far only left > speaker). > > Great .... >
That's one from the begin of the month: https://media-cdn.ubuntu-de.org/forum/attachments/23/21/9255949-alsa.txt
It definitely is. What's missing a sequence of HDA verbs specific to your model of laptop to get the speakers going. This probably sets the speaker amplifier chips. Can you share your alsa-info? Skimming through the bug, I wasn't able to find for you. Have you tried the verb work around (without the S3 workaround)? How well does that work for you? On 6/23/21 12:56 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #257 from DavidLenovo (DavidLenovoFr@protonmail.com) --- > (In reply to Roland from comment #192) >> (In reply to DavidLenovo from comment #191) >>> I think it is normal, this patch is for Lenovo Yoga 7i, and it depend on >> the >>> hardware, so don't have the same :(. >> It's easy to port this patch to Dell, but that's not the point: iasl fails >> even without applying the patch, which should not happen ;-) But I think I >> have to ask the iasl people why this fails. >> >>> The S3 problem can be resolve by a BIOS option, Lenovo put a locked BIOS so >>> we can't. But if Dell is better on this you could try to find an option S3, >>> or energy, ACPI, it disable for Windows compatibility. >> It's a similar issue on Dell. S3 in BIOS is enabled, but: >> >> $ cat /sys/power/mem_sleep >> [s2idle] >> $ sudo dmesg |grep ACPI|grep supports >> [ 0.201665] ACPI: (supports S0 S4 S5) >> >>> You have try this 5.11.5 kernel, to be sure, it is not a kernel bug ? >> Kernel 5.11 is even worse because it doesn't even recognize the sound card. >> With 5.13rc5 at least the headphone jack and the microphone is working. But >> basically I think it's either this problem or the problem reported in >> #213159... > You sure it is the ALC287 ? > For me it make no sens the driver work for us and not for you. > In case of your computer recognize the sound card but the speaker don't work, > it seem to be logic, but don't recognized, with a working kernel for us, I'm > surprised. > For me after 5.11.5 it stop working. I write 5.11.5 cause of that point. Do > you > have try 5.11.5 or older ? >
(In reply to Cameron Berkenpas from comment #262) > sycxyc, > > Great work! > > Is this work from the verbs I attached to the ticket or did you find these > verbs on your own? > > Can you give me your alsa-info.sh? You can either post the the output here > or upload it and share the URL. > > With all this and your verbs, I should be able to update the patch to cover > your machine. > > > On 6/23/21 6:17 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #260 from sycxyc (sycxyc@yandex.com) --- > > Possibly the minimum verbs of the two speakers working in Yoga 7i > > > > ``` > > > > // left speaker > > 0x20 0x500 0x24 > > 0x20 0x400 0x41 > > // unmute > > 0x20 0x500 0x26 > > 0x20 0x400 0x2 > > 0x20 0x400 0x0 > > 0x20 0x400 0x0 > > 0x20 0x4b0 0x20 > > // right speaker (I Guessed 4 times) > > 0x20 0x500 0x24 > > 0x20 0x400 0x46 > > // may be necessary > > 0x20 0x500 0x26 > > 0x20 0x400 0xc > > 0x20 0x400 0x0 > > 0x20 0x400 0x2a > > 0x20 0x4b0 0x20 > > // unmute > > 0x20 0x500 0x26 > > 0x20 0x400 0x2 > > 0x20 0x400 0x0 > > 0x20 0x400 0x0 > > 0x20 0x4b0 0x20 > > > > ``` > > These verbs are based on your attachment, but the right speaker does not work. I tried to fix the right speaker issue by changing the following. ``` 0x20 0x500 0x24 -0x20 0x400 0x42 +0x20 0x400 0x46 ``` Here's the Alsa-info for my machine. It may be similar to the yoga 7i. http://alsa-project.org/db/?f=68337a779c3297142b0afb022125fbf32f1a6c17
The Legion verbs I provided don't enable your right speaker. Got it. But I'm unclear on your set of verbs. Do YOUR verbs enable your right speaker? Thank you for the alsa-info. You have the same hardware ID's as woody64 and the same problem with the right speaker. This is progress! On 6/23/21 10:31 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #266 from sycxyc (sycxyc@yandex.com) --- > (In reply to Cameron Berkenpas from comment #262) >> sycxyc, >> >> Great work! >> >> Is this work from the verbs I attached to the ticket or did you find these >> verbs on your own? >> >> Can you give me your alsa-info.sh? You can either post the the output here >> or upload it and share the URL. >> >> With all this and your verbs, I should be able to update the patch to cover >> your machine. >> >> >> On 6/23/21 6:17 AM, bugzilla-daemon@bugzilla.kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #260 from sycxyc (sycxyc@yandex.com) --- >>> Possibly the minimum verbs of the two speakers working in Yoga 7i >>> >>> ``` >>> >>> // left speaker >>> 0x20 0x500 0x24 >>> 0x20 0x400 0x41 >>> // unmute >>> 0x20 0x500 0x26 >>> 0x20 0x400 0x2 >>> 0x20 0x400 0x0 >>> 0x20 0x400 0x0 >>> 0x20 0x4b0 0x20 >>> // right speaker (I Guessed 4 times) >>> 0x20 0x500 0x24 >>> 0x20 0x400 0x46 >>> // may be necessary >>> 0x20 0x500 0x26 >>> 0x20 0x400 0xc >>> 0x20 0x400 0x0 >>> 0x20 0x400 0x2a >>> 0x20 0x4b0 0x20 >>> // unmute >>> 0x20 0x500 0x26 >>> 0x20 0x400 0x2 >>> 0x20 0x400 0x0 >>> 0x20 0x400 0x0 >>> 0x20 0x4b0 0x20 >>> >>> ``` >>> > These verbs are based on your attachment, but the right speaker does not > work. > I tried to fix the right speaker issue by changing the following. > ``` > 0x20 0x500 0x24 > -0x20 0x400 0x42 > +0x20 0x400 0x46 > ``` > Here's the Alsa-info for my machine. It may be similar to the yoga 7i. > > http://alsa-project.org/db/?f=68337a779c3297142b0afb022125fbf32f1a6c17 >
DavidLenovo, Whoops, I misunderstood who you were responding to. But having your alsa-info would also help. Roland, Can you also share your alsa-info with me? Even if you do have an ALC287, it's likely that your Dell requires a different sequence for initialization. On 6/23/21 10:11 AM, Cameron Berkenpas wrote: > It definitely is. What's missing a sequence of HDA verbs specific to > your model of laptop to get the speakers going. This probably sets the > speaker amplifier chips. > > Can you share your alsa-info? Skimming through the bug, I wasn't able > to find for you. > > Have you tried the verb work around (without the S3 workaround)? How > well does that work for you? > > On 6/23/21 12:56 AM, bugzilla-daemon@bugzilla.kernel.org wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >> >> --- Comment #257 from DavidLenovo (DavidLenovoFr@protonmail.com) --- >> (In reply to Roland from comment #192) >>> (In reply to DavidLenovo from comment #191) >>>> I think it is normal, this patch is for Lenovo Yoga 7i, and it >>>> depend on >>> the >>>> hardware, so don't have the same :(. >>> It's easy to port this patch to Dell, but that's not the point: iasl >>> fails >>> even without applying the patch, which should not happen ;-) But I >>> think I >>> have to ask the iasl people why this fails. >>> >>>> The S3 problem can be resolve by a BIOS option, Lenovo put a locked >>>> BIOS so >>>> we can't. But if Dell is better on this you could try to find an >>>> option S3, >>>> or energy, ACPI, it disable for Windows compatibility. >>> It's a similar issue on Dell. S3 in BIOS is enabled, but: >>> >>> $ cat /sys/power/mem_sleep >>> [s2idle] >>> $ sudo dmesg |grep ACPI|grep supports >>> [ 0.201665] ACPI: (supports S0 S4 S5) >>> >>>> You have try this 5.11.5 kernel, to be sure, it is not a kernel bug ? >>> Kernel 5.11 is even worse because it doesn't even recognize the >>> sound card. >>> With 5.13rc5 at least the headphone jack and the microphone is >>> working. But >>> basically I think it's either this problem or the problem reported in >>> #213159... >> You sure it is the ALC287 ? >> For me it make no sens the driver work for us and not for you. >> In case of your computer recognize the sound card but the speaker >> don't work, >> it seem to be logic, but don't recognized, with a working kernel for >> us, I'm >> surprised. >> For me after 5.11.5 it stop working. I write 5.11.5 cause of that >> point. Do you >> have try 5.11.5 or older ? >> >
On 6/22/21 11:10 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #254 from TT (thiagotei@icloud.com) --- > I've patched kernel 5.8.0-59 for Ubuntu 20.04.2/Legion 7i and everything > worked > well! > Headphones turn the speakers off when I plug them in and back on when I plug > them off. > I had adapt the patch because the kernel version was different than the one > in > Comment #252 but that was easy. > Thank you for the confirmation!
(In reply to Cameron Berkenpas from comment #221) > Has anyone tested a 2021 Legion yet? I'm curious to know if this set of > verb works. Legion 7 2021 (16achg6) here! (According to specs it's an ALC3306 but according to Alsa it's an ALC287): http://alsa-project.org/db/?f=d3f255a8ac60504ad70c27c5cc36e6e7400eaab3 I'll try and figure out how to apply a kernel patch and see if that helps!
(In reply to Cameron Berkenpas from comment #267) > The Legion verbs I provided don't enable your right speaker. Got it. > > But I'm unclear on your set of verbs. Do YOUR verbs enable your right > speaker? > > Thank you for the alsa-info. You have the same hardware ID's as woody64 > and the same problem with the right speaker. This is progress! > Yes, the small sequence has worked for me on a Lenovo Yoga 7i without and with S3 workaraund. When using the S3 workaround without firing further outputs to the audio device and audio is then oncemore lost the verb sequence can be used to restart the Audio for both speakers. Afterwards the sound stays for a longer period, can't say when the sound disappears. So it has the same effect in this setup as in the setuo without S3 enabled or with S3 enabled and not used.
Have you tried the kernel patch (without the verb workaround)? If so, I assume it didn't work? Thank you for the info. I'll add support for this model to the patch likely at some point today. -Cameron PS: I didn't know for sure these were even out... Each time I've checked, the Lenovo site says "coming soon". With the progress I've made, I'm strongly considering getting one. Therefore even if my patch doesn't have the right verbs for initialization, I'd likely be able to add support once I had the hardware. On 6/23/21 1:50 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #270 from Alex (alex@avsmith.net) --- > (In reply to Cameron Berkenpas from comment #221) > >> Has anyone tested a 2021 Legion yet? I'm curious to know if this set of >> verb works. > Legion 7 2021 (16achg6) here! (According to specs it's an ALC3306 but > according > to Alsa it's an ALC287): > http://alsa-project.org/db/?f=d3f255a8ac60504ad70c27c5cc36e6e7400eaab3 > > I'll try and figure out how to apply a kernel patch and see if that helps! >
Created attachment 297583 [details] linux-5.12.12-legion-sound-0.0.4.patch - updated headphone fix, more models supported I've updated the headphone fix. The automute_hook wasn't the fix. Simply having an automute_hook defined means snd_hda_gen_update_outputs() is not called. The call to snd_hda_gen_update_outputs() results in do_automute() being called, which shuts down the speakers putting them into a state where they need to be re-initialized. Setting automute_speaker to off avoids do_automute() breaking the speakers and it seems we can trust the hardware to do the right thing. So please test without any of the other work arounds. Make sure speaker output resumes after unplugging headphones while sound is playing. The good news is that this patch should now affect more than the original 2020 Legion. Here are the models that can test this patch: Lenovo Legion 7i Legion 7 16ACHg6 (2021) Lenovo Yoga 7 14ITL5 Yoga 14cITL 2021 In the case of the last 2 models, you should only see output from one speaker as the same verbs are being applied as in verbs-working.txt (for now). In the case of the 16ACHg6, I have no idea what to expect. Depends if the speakers require the same (or very similar) initialization sequence or not.
(In reply to TT from comment #242) > (In reply to Cameron Berkenpas from comment #241) > > (In reply to Jenefer from comment #237) > > > (In reply to TT from comment #208) > > > > For those wanting to test it. > > > > - Download the verbs-working.txt provided on > > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555#c206 . > > > > - git clone https://github.com/ryanprescott/realtek-verb-tools > > > > - sudo python3 realtek-verb-tools/applyverbs.py verbs-working.txt > > > > - put some audio to play > > > > > > Thank you so much! This worked somehow on my lenovo legion 7i 15IMHg05. > > > It's not permanent though as audio needs to be played constantly for it > to > > > last longer, otherwise it go back after few seconds. I hope that the fix > > > will be patched to the kernel after some fine-tuning as I noticed that > > > applying the verbs the quality of audio is not quite good compared to how > > it > > > was on windows. But who I am to complain, I'm just happy there is a > > > workaround to use keep me using linux on my machine. > > > > > > Also it's weird that the fix worked for my laptop even though I have the > > > issue with mis-detected codecs: the specs of my laptop list ALC3306 while > > > alsa reports ALC287. > > > > > > I haven't had a chance to try comparing the audio quality, but I have > > wondered if that might be the case... How did you compare? Was it with the > > same application? Ie, maybe FireFox/Chrome and YouTube? > > > > Is anyone else seeing differences? > > I've ran firefox with the same youtube video and I also felt the quality is > lower on Linux. I don't know how to describe the difference though. > It is not a significant difference for me. > I am good with the current quality, but there is definitelly something to > improve there. (In reply to Vincent Morel from comment #246) > (In reply to Cameron Berkenpas from comment #245) > > On 6/22/21 9:16 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > > > > > > I guess you already checked, but just be sure there is no "sound > > enhancement" > > > activated under Windows... On my Lenovo, there is some sound enhancer > > > activated > > > by default in Windows. > > > Seems we get near to find a solution, I'll have to test on my 13S Gen2 > all > > of > > > this (and I will report back on the ALC3306 thread). > > > > > I didn't know about the enhanced sound. Is that controlled in Lenovo > > Vantage? > > Yes it's there in Lenovo Vantage (surround stuff, or enhancement, or I can't > remember the name). > I always remove those stuff, whatever they call it, because I prefer > "natural" sound... Vincent Morel, I don't have a natural setting in my Vantage... But I do have a setting to enable/disable Dolby sound. Disabling it causes the sound under Windows to sound like it does in Linux. Being able to switch back and forth on the fly with the Dolby switch in Vantage under Windows instead of waiting for reboots... The difference is more stark However, I think I can live with it. Especially since it looks like there's really nothing more to be done from my side at least: https://askubuntu.com/questions/984109/dolby-equivalent-for-ubuntu (although that link has something of a work around... I'd be curious if anyone reported back on the results). There are likely ways required to enable Dolby in the hardware side that don't involve HDA verbs or there's a proprietary software component. Probably both. The "good" news for me is that this is one less thing I have to worry about I guess. Lastly, we probably have some different sound options because we're on different models of laptop. Under Dolby, I have various settings that include gaming, movies, and so on. Maybe "Natural" falls under one of the your sub settings or you have something else entirely. *shrug* You have a 13S Gen 2, right? Could you provide your alsa-info? I haven't seen one posted for you, but there's a lot of noise (and I've just started keeping track for reference). Thanks!
(In reply to Cameron Berkenpas from comment #273) > Created attachment 297583 [details] > linux-5.12.12-legion-sound-0.0.4.patch - updated headphone fix, more models > supported > > I've updated the headphone fix. The automute_hook wasn't the fix. Simply > having an automute_hook defined means snd_hda_gen_update_outputs() is not > called. The call to snd_hda_gen_update_outputs() results in do_automute() > being called, which shuts down the speakers putting them into a state where > they need to be re-initialized. Setting automute_speaker to off avoids > do_automute() breaking the speakers and it seems we can trust the hardware > to do the right thing. > > So please test without any of the other work arounds. Make sure speaker > output resumes after unplugging headphones while sound is playing. > > The good news is that this patch should now affect more than the original > 2020 Legion. Here are the models that can test this patch: > Lenovo Legion 7i > Legion 7 16ACHg6 (2021) > Lenovo Yoga 7 14ITL5 > Yoga 14cITL 2021 > > In the case of the last 2 models, you should only see output from one > speaker as the same verbs are being applied as in verbs-working.txt (for > now). > > In the case of the 16ACHg6, I have no idea what to expect. Depends if the > speakers require the same (or very similar) initialization sequence or not. I have a Legion 7 2020 (alsa-info here:http://alsa-project.org/db/?f=c62e1da70c65a4709d137b2a48204cd6ebdeaaa1) and a bit of a Linux newbie. I'm on Pop_OS; would you explain how to apply this patch? My headphone/usb headphones work fine but speakers aren't working.
You need to pull the kernel source, know how to apply the patch, how to configure the kernel, know how to build your kernel, and then to install it. If you're new to Linux, this may not be for you. I'm *really* hesitant to provide some random kernel packages. From a security point of view, I would strongly recommend against installing packages (especially kernel packages) from some random person's web server. Hopefully someone following this bug has the time and know-how to setup a proper PPA for kernel packages with this patch for *buntu. It would help a lot of people, and it'd be nice to have some more feedback too. On 6/23/21 7:53 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #275 fromcrisicola@yahoo.com --- > (In reply to Cameron Berkenpas from comment #273) >> Created attachment 297583 [details] >> linux-5.12.12-legion-sound-0.0.4.patch - updated headphone fix, more models >> supported >> >> I've updated the headphone fix. The automute_hook wasn't the fix. Simply >> having an automute_hook defined means snd_hda_gen_update_outputs() is not >> called. The call to snd_hda_gen_update_outputs() results in do_automute() >> being called, which shuts down the speakers putting them into a state where >> they need to be re-initialized. Setting automute_speaker to off avoids >> do_automute() breaking the speakers and it seems we can trust the hardware >> to do the right thing. >> >> So please test without any of the other work arounds. Make sure speaker >> output resumes after unplugging headphones while sound is playing. >> >> The good news is that this patch should now affect more than the original >> 2020 Legion. Here are the models that can test this patch: >> Lenovo Legion 7i >> Legion 7 16ACHg6 (2021) >> Lenovo Yoga 7 14ITL5 >> Yoga 14cITL 2021 >> >> In the case of the last 2 models, you should only see output from one >> speaker as the same verbs are being applied as in verbs-working.txt (for >> now). >> >> In the case of the 16ACHg6, I have no idea what to expect. Depends if the >> speakers require the same (or very similar) initialization sequence or not. > I have a Legion 7 2020 (alsa-info > here:http://alsa-project.org/db/?f=c62e1da70c65a4709d137b2a48204cd6ebdeaaa1) > and a bit of a Linux newbie. I'm on Pop_OS; would you explain how to apply > this > patch? My headphone/usb headphones work fine but speakers aren't working. >
Yes, I have all speakers enabled. Here are more explanations of these verbs. ``` // set left speaker 0x20 0x500 0x24 0x20 0x400 0x41 // set right speaker (Legion 7i) 0x20 0x500 0x24 0x20 0x400 0x42 // set right speaker (Yoga 7i) 0x20 0x500 0x24 0x20 0x400 0x46 // reset settings and inactive speakers 0x20 0x500 0x26 0x20 0x400 0x1 0x20 0x400 0x0 0x20 0x400 0x1 0x20 0x4b0 0x20 // set to left channel 0x20 0x500 0x26 0x20 0x400 0xc 0x20 0x400 0x0 0x20 0x400 0x1a 0x20 0x4b0 0x20 // set to right channel 0x20 0x500 0x26 0x20 0x400 0xc 0x20 0x400 0x0 0x20 0x400 0x2a 0x20 0x4b0 0x20 // set to mono 0x20 0x500 0x26 0x20 0x400 0xc 0x20 0x400 0x0 0x20 0x400 0x3a 0x20 0x4b0 0x20 // activate speaker 0x20 0x500 0x26 0x20 0x400 0x2 0x20 0x400 0x0 0x20 0x400 0x0 0x20 0x4b0 0x20 ``` # Example Set the left speaker to the right channel： ``` // set left speaker 0x20 0x500 0x24 0x20 0x400 0x41 // reset settings and inactive speakers 0x20 0x500 0x26 0x20 0x400 0x1 0x20 0x400 0x0 0x20 0x400 0x1 0x20 0x4b0 0x20 // set to right channel 0x20 0x500 0x26 0x20 0x400 0xc 0x20 0x400 0x0 0x20 0x400 0x2a 0x20 0x4b0 0x20 // activate speaker 0x20 0x500 0x26 0x20 0x400 0x2 0x20 0x400 0x0 0x20 0x400 0x0 0x20 0x4b0 0x20 ``` (In reply to Cameron Berkenpas from comment #267) > The Legion verbs I provided don't enable your right speaker. Got it. > > But I'm unclear on your set of verbs. Do YOUR verbs enable your right > speaker? > > Thank you for the alsa-info. You have the same hardware ID's as woody64 > and the same problem with the right speaker. This is progress! > > On 6/23/21 10:31 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #266 from sycxyc (sycxyc@yandex.com) --- > > (In reply to Cameron Berkenpas from comment #262) > >> sycxyc, > >> > >> Great work! > >> > >> Is this work from the verbs I attached to the ticket or did you find these > >> verbs on your own? > >> > >> Can you give me your alsa-info.sh? You can either post the the output here > >> or upload it and share the URL. > >> > >> With all this and your verbs, I should be able to update the patch to > cover > >> your machine. > >> > >> > >> On 6/23/21 6:17 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>> > >>> --- Comment #260 from sycxyc (sycxyc@yandex.com) --- > >>> Possibly the minimum verbs of the two speakers working in Yoga 7i > >>> > >>> ``` > >>> > >>> // left speaker > >>> 0x20 0x500 0x24 > >>> 0x20 0x400 0x41 > >>> // unmute > >>> 0x20 0x500 0x26 > >>> 0x20 0x400 0x2 > >>> 0x20 0x400 0x0 > >>> 0x20 0x400 0x0 > >>> 0x20 0x4b0 0x20 > >>> // right speaker (I Guessed 4 times) > >>> 0x20 0x500 0x24 > >>> 0x20 0x400 0x46 > >>> // may be necessary > >>> 0x20 0x500 0x26 > >>> 0x20 0x400 0xc > >>> 0x20 0x400 0x0 > >>> 0x20 0x400 0x2a > >>> 0x20 0x4b0 0x20 > >>> // unmute > >>> 0x20 0x500 0x26 > >>> 0x20 0x400 0x2 > >>> 0x20 0x400 0x0 > >>> 0x20 0x400 0x0 > >>> 0x20 0x4b0 0x20 > >>> > >>> ``` > >>> > > These verbs are based on your attachment, but the right speaker does not > > work. > > I tried to fix the right speaker issue by changing the following. > > ``` > > 0x20 0x500 0x24 > > -0x20 0x400 0x42 > > +0x20 0x400 0x46 > > ``` > > Here's the Alsa-info for my machine. It may be similar to the yoga 7i. > > > > http://alsa-project.org/db/?f=68337a779c3297142b0afb022125fbf32f1a6c17 > >
(In reply to Cameron Berkenpas from comment #274) > (In reply to TT from comment #242) > > (In reply to Cameron Berkenpas from comment #241) > > > (In reply to Jenefer from comment #237) > > > > (In reply to TT from comment #208) > > > > > For those wanting to test it. > > > > > - Download the verbs-working.txt provided on > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555#c206 . > > > > > - git clone https://github.com/ryanprescott/realtek-verb-tools > > > > > - sudo python3 realtek-verb-tools/applyverbs.py verbs-working.txt > > > > > - put some audio to play > > > > > > > > Thank you so much! This worked somehow on my lenovo legion 7i 15IMHg05. > > > > It's not permanent though as audio needs to be played constantly for it > > to > > > > last longer, otherwise it go back after few seconds. I hope that the > fix > > > > will be patched to the kernel after some fine-tuning as I noticed that > > > > applying the verbs the quality of audio is not quite good compared to > how > > > it > > > > was on windows. But who I am to complain, I'm just happy there is a > > > > workaround to use keep me using linux on my machine. > > > > > > > > Also it's weird that the fix worked for my laptop even though I have > the > > > > issue with mis-detected codecs: the specs of my laptop list ALC3306 > while > > > > alsa reports ALC287. > > > > > > > > > I haven't had a chance to try comparing the audio quality, but I have > > > wondered if that might be the case... How did you compare? Was it with > the > > > same application? Ie, maybe FireFox/Chrome and YouTube? > > > > > > Is anyone else seeing differences? > > > > I've ran firefox with the same youtube video and I also felt the quality is > > lower on Linux. I don't know how to describe the difference though. > > It is not a significant difference for me. > > I am good with the current quality, but there is definitelly something to > > improve there. > > (In reply to Vincent Morel from comment #246) > > (In reply to Cameron Berkenpas from comment #245) > > > On 6/22/21 9:16 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > > > > > > > > > I guess you already checked, but just be sure there is no "sound > > > enhancement" > > > > activated under Windows... On my Lenovo, there is some sound enhancer > > > > activated > > > > by default in Windows. > > > > Seems we get near to find a solution, I'll have to test on my 13S Gen2 > > all > > > of > > > > this (and I will report back on the ALC3306 thread). > > > > > > > I didn't know about the enhanced sound. Is that controlled in Lenovo > > > Vantage? > > > > Yes it's there in Lenovo Vantage (surround stuff, or enhancement, or I > can't > > remember the name). > > I always remove those stuff, whatever they call it, because I prefer > > "natural" sound... > > Vincent Morel, > > I don't have a natural setting in my Vantage... But I do have a setting to > enable/disable Dolby sound. Disabling it causes the sound under Windows to > sound like it does in Linux. Being able to switch back and forth on the fly > with the Dolby switch in Vantage under Windows instead of waiting for > reboots... The difference is more stark > > However, I think I can live with it. > > Especially since it looks like there's really nothing more to be done from > my side at least: > https://askubuntu.com/questions/984109/dolby-equivalent-for-ubuntu > > (although that link has something of a work around... I'd be curious if > anyone reported back on the results). > > There are likely ways required to enable Dolby in the hardware side that > don't involve HDA verbs or there's a proprietary software component. > Probably both. > > The "good" news for me is that this is one less thing I have to worry about > I guess. > > Lastly, we probably have some different sound options because we're on > different models of laptop. Under Dolby, I have various settings that > include gaming, movies, and so on. Maybe "Natural" falls under one of the > your sub settings or you have something else entirely. *shrug* > > You have a 13S Gen 2, right? Could you provide your alsa-info? I haven't > seen one posted for you, but there's a lot of noise (and I've just started > keeping track for reference). > > Thanks! Sorry I did not saw this message. I posted my Alsa info in the bug report I created for ALC3306, but here it is! http://alsa-project.org/db/?f=1f3e847b60bd38085e39e26d992ea8680dd90869
(In reply to Cameron Berkenpas from comment #276) > You need to pull the kernel source, know how to apply the patch, how to > configure the kernel, know how to build your kernel, and then to install > it. If you're new to Linux, this may not be for you. > > I'm *really* hesitant to provide some random kernel packages. From a > security point of view, I would strongly recommend against installing > packages (especially kernel packages) from some random person's web server. > > Hopefully someone following this bug has the time and know-how to setup > a proper PPA for kernel packages with this patch for *buntu. It would > help a lot of people, and it'd be nice to have some more feedback too. > At least I was able to backport and test the patch to 5.8.0-59-lowlatency. And it works. So far I was not able to use the small version from sycxyc inside the patch. There it has no effect? But applying from outside via verb results in running both side speakers.
> At least I was able to backport and test the patch to 5.8.0-59-lowlatency. > And it works. > > So far I was not able to use the small version from sycxyc inside the patch. > There it has no effect? > But applying from outside via verb results in running both side speakers. > I tried sycxyc's stuff yesterday, but wasn't able to get it to work. I haven't tried the updated verbs from this morning yet. The kernel patch only works for one speaker though, correct?
(In reply to sycxyc from comment #277) > Yes, I have all speakers enabled. > > Here are more explanations of these verbs. > > > // reset settings and inactive speakers > 0x20 0x500 0x26 > 0x20 0x400 0x1 > 0x20 0x400 0x0 > 0x20 0x400 0x1 > 0x20 0x4b0 0x20 > Works for the left speaker on the Yoga. Do you use any source or do you guess?
Created attachment 297597 [details] legion-alc287-0.0.4.patch - snd-hda patch This is _NOT_ a kernel patch. It's a patch file for snd-hda, and therefore is much easier to try. *face palm* I forgot this could be done. This effectively does the same thing as the kernel patch... Except without having to patch, recompile, etc the kernel. This works for me on the 5.11.0-22-generic vendor kernel for *buntu 21.04 on my 2020 Lenovo Legion. Here's how to utilize it: 1. Download the "legion-alc287-0.0.4.patch" from this bug. 2. Copy it to /lib/firmware/legion-alc287-0.0.4.patch 3. Create/open "/etc/modprobe.d/lenovo-fix.conf" in your favorite text editor. Ie, "sudo nano -w /etc/modprobe.d/lenovo-fix.conf" 4. Set the contents of "/etc/modprobe.d/lenovo-fix.conf" to be following then save and exit: # Patch file to enable output on speakers. options snd-hda-intel patch=legion-alc287-0.0.4.patch 5. Reboot 6. Test your sound and report back here with your results. This patch file should work as well as applying verbs-working.txt or using the kernel patch (provided your model is supported by the patch). Some more info on snd-hda patch files can be found here for those wanting to experiment: https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html
Forgot to add... If you need to disable this patch, you can simply delete /etc/modprobe.d/lenovo-fix.conf.
(In reply to Cameron Berkenpas from comment #283) > Forgot to add... If you need to disable this patch, you can simply delete > /etc/modprobe.d/lenovo-fix.conf. Do you see any hint in dmesg that the patching is applied? I have tried it for the Yoga but with no effect (exchanged the deviceid). I see in alsa-info that the hda-intel module is started with patch=... but no further info.
No success here on a Legion 7 2021 (16ACHg6) with either the patch or full verbs list (although the speakers did make a tiny sound when rebooting the machine this time). Is there anything I can do to figure out which verbs are needed? Perhaps it's something to do with ALC3306 vs. ALC287? I really appreciate all the work you're doing here Cameron!
(In reply to Alex from comment #285) > No success here on a Legion 7 2021 (16ACHg6) with either the patch or full > verbs list (although the speakers did make a tiny sound when rebooting the > machine this time). > > Is there anything I can do to figure out which verbs are needed? Perhaps > it's something to do with ALC3306 vs. ALC287? > > I really appreciate all the work you're doing here Cameron! I have a Lenovo legion 7i 2020 and the verbs work for me. The ALC3306 vs. ALC287 should not be an issue: My laptop is listed to have ALC3306 in Lenovo Specs page but Alsa reports it as ALC287. Regardless I have sound now using the fix.
(In reply to woody64 from comment #281) > (In reply to sycxyc from comment #277) > > Yes, I have all speakers enabled. > > > > Here are more explanations of these verbs. > > > > > > // reset settings and inactive speakers > > 0x20 0x500 0x26 > > 0x20 0x400 0x1 > > 0x20 0x400 0x0 > > 0x20 0x400 0x1 > > 0x20 0x4b0 0x20 > > > > Works for the left speaker on the Yoga. > > Do you use any source or do you guess? That's my guess. The main part of the sequence has been commented. https://pastebin.com/F3Tzd0Rj
Hello, Which fix is working for you? On 6/25/21 2:48 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #286 from Jenefer (jenefer.marker@protonmail.com) --- > (In reply to Alex from comment #285) >> No success here on a Legion 7 2021 (16ACHg6) with either the patch or full >> verbs list (although the speakers did make a tiny sound when rebooting the >> machine this time). >> >> Is there anything I can do to figure out which verbs are needed? Perhaps >> it's something to do with ALC3306 vs. ALC287? >> >> I really appreciate all the work you're doing here Cameron! > I have a Lenovo legion 7i 2020 and the verbs work for me. The ALC3306 vs. > ALC287 should not be an issue: My laptop is listed to have ALC3306 in Lenovo > Specs page but Alsa reports it as ALC287. Regardless I have sound now using > the > fix. >
On 6/25/21 1:17 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #285 from Alex (alex@avsmith.net) --- > No success here on a Legion 7 2021 (16ACHg6) with either the patch or full > verbs list (although the speakers did make a tiny sound when rebooting the > machine this time). > > Is there anything I can do to figure out which verbs are needed? Perhaps it's > something to do with ALC3306 vs. ALC287? When applying the verbs while playing sound, do you hear anything? Maybe a very short blip of noise? So far it sounds like the issue is that the 16ACHg6 requires a different list of verbs. However, since you said you've heard noise during start up, there might be some slight initialization overlap). From my research, it sounds like the 16ACHg6 is the Thai (or perhaps South East Asian) version of the 16ACH6. If I end up with a 16ACH6 once they come out, I'd be able to (hopefully) figure what verbs are needed there myself. > > I really appreciate all the work you're doing here Cameron! > Thank you!
Hello, just tried to apply the patch to my 13s Gen2 ITL (ALC3306) and no change despite the fact alsa-info tell me the patch is applied... :( I should probably try to dump the hda-verb from windows with the small utility I cannot find again (have to search a little)...
The snd-hda patch just applies the same verbs as the kernel patch. If the kernel works, but this does not, then the snd-hda patch has problems with non-Legion machines, and you would be the 2nd non-Legion user the snd-hda patch does not work for so far. But then, I don't know if the kernel patch or these verbs work for the 13s Gen2 ITL at all yet so youre problem is that we don't yet know of a sequence compatible with your model yet. On 6/25/21 7:38 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #290 from Vincent Morel (dantahoua@gmail.com) --- > Hello, just tried to apply the patch to my 13s Gen2 ITL (ALC3306) and no > change > despite the fact alsa-info tell me the patch is applied... :( > I should probably try to dump the hda-verb from windows with the small > utility > I cannot find again (have to search a little)... >
Created attachment 297615 [details] verbs-14itl5_14cITL.txt These verbs work for the 14itl5 and most likely the 14cITL as well. Thank you sycxyc for finding all of the compatible verb sequences! How did you do this?! Especially so quickly? Thank you Woody64 for giving me the precise sequence needed for these models! _FANTASTIC_ work, guys!
Created attachment 297617 [details] linux-5.12-legion-sound-0.0.5.patch - updated verbs This updated kernel patch for the 5.12.x series includes the updated versions. You should now see full functionality (including both speakers) working on both the 2020 Legion and the Yoga 7. Regardless of your model, please report back on your experience. Does it work the same as before? Better? Worse? Also please test with plugging and unplugging your headset multiple times both with and without sound playing and let me know if there are any issues/regressions there.
Created attachment 297619 [details] legion-alc287-0.0.5.patch - snd-hda-intel patch This is another snd-hda-intel patch. _NOT_ a kernel patch. This works for the Legion. It may work for the Yoga 7 with output from only one speaker. I'll upload a separate snd-hda-intel patch for the Yoga 7. I've streamlined the instructions slightly: 1. Download the "legion-alc287-0.0.5.patch" from this bug. 2. Copy it to /lib/firmware/legion-alc287.patch. Ie, "sudo cp legion-alc287-0.0.5.patch /lib/firmware/legion-alc287.patch" 3. Create/open "/etc/modprobe.d/lenovo-fix.conf" in your favorite text editor. Ie, "sudo nano -w /etc/modprobe.d/lenovo-fix.conf" 4. Set the contents of "/etc/modprobe.d/lenovo-fix.conf" to be following then save and exit: # Patch file to enable output on speakers. options snd-hda-intel patch=legion-alc287.patch 5. Reboot 6. Test your sound and report back here with your results. NOTE: To disable the patch, remove /etc/modprobe.d/lenovo-fix.conf and reboot. This patch file should work as well as applying verbs-legion.txt or using the kernel patch (provided your model is supported by the patch). Some more info on snd-hda patch files can be found here for those wanting to experiment: https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html
(In reply to Cameron Berkenpas from comment #292) > Created attachment 297615 [details] > verbs-14itl5_14cITL.txt > > These verbs work for the 14itl5 and most likely the 14cITL as well. > > Thank you sycxyc for finding all of the compatible verb sequences! How did > you do this?! Especially so quickly? > I found that enabling auto-mute mode from alsamixer and then disabling it makes the speaker inactive. Using the debug mode of applyverbs.py, I can quickly determine the 5 line sequence that activates the left speaker without restarting or suspending. verbs-working.txt has two similar sections. The sequence used to activate the left speaker is at the end of the first part. It can be assumed that the later part controls the right speaker. After executing the later part, the first two lines must be executed to activate the left speaker, and it can be determined that the first two lines are used to switch speakers. I tried to modify the right speaker section and successfully activated it. The sequence of 5 lines to activate the speaker is repeated 2 times in succession and they are probably safe for the separation point. I modified applyverbs.py so that it skips comments and empty lines, which makes it easier to test and mark up.
Created attachment 297621 [details] yoga7-alc287-0.0.5.patch - snd-hda-intel patch for Yoga 7 models This is another snd-hda-intel patch. _NOT_ a kernel patch. This works for the Yoga 7. AFAIK, it should cover at least both the Yoga 7 14ITL5 and the 14cITL. I think these are likely Yoga 7 models for different regions. If yours doesn't work, please let us know what steps you took to try the patch and what specifically doesn't work. 1. Download the "yoga7-alc287-0.0.5.patch" from this bug. 2. Copy it to /lib/firmware/yoga-alc287.patch. Ie, "sudo cp yoga-alc287-0.0.5.patch /lib/firmware/yoga7-alc287.patch" 3. Create/open "/etc/modprobe.d/lenovo-fix.conf" in your favorite text editor. Ie, "sudo nano -w /etc/modprobe.d/lenovo-fix.conf" 4. Set the contents of "/etc/modprobe.d/lenovo-fix.conf" to be following then save and exit: # Patch file to enable output on speakers. options snd-hda-intel patch=yoga7-alc287.patch 5. Reboot 6. Test your sound (including with plugging and unplugging headphones while sound is playing) and report back here with your results. NOTE: To disable the patch, remove /etc/modprobe.d/lenovo-fix.conf and reboot. This patch file should work as well or better than applying verbs-yoga7.txt or as well as using the kernel patch (provided your model is supported by the patch). Some more info on snd-hda patch files can be found here for those wanting to experiment: https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html
(In reply to sycxyc from comment #295) > (In reply to Cameron Berkenpas from comment #292) I forgot about the debug mode of applyverbs.py. I was thinking of making the same modifications to applyverbs.py... Can you attach your version to this bug? It might also be worth sharing your changes with the original author too. Again, great work!
(In reply to sycxyc from comment #295) > (In reply to Cameron Berkenpas from comment #292) > > Created attachment 297615 [details] > > verbs-14itl5_14cITL.txt > > > > These verbs work for the 14itl5 and most likely the 14cITL as well. > > > > Thank you sycxyc for finding all of the compatible verb sequences! How did > > you do this?! Especially so quickly? > > > > I found that enabling auto-mute mode from alsamixer and then disabling it > makes the speaker inactive. Using the debug mode of applyverbs.py, I can > quickly determine the 5 line sequence that activates the left speaker > without restarting or suspending. > > verbs-working.txt has two similar sections. The sequence used to activate > the left speaker is at the end of the first part. It can be assumed that the > later part controls the right speaker. After executing the later part, the > first two lines must be executed to activate the left speaker, and it can be > determined that the first two lines are used to switch speakers. I tried to > modify the right speaker section and successfully activated it. > > The sequence of 5 lines to activate the speaker is repeated 2 times in > succession and they are probably safe for the separation point. > > I modified applyverbs.py so that it skips comments and empty lines, which > makes it easier to test and mark up. Very good work! That does not look so trivial though. The verbs-working.txt has more than 500 lines and finding those 5 lines looks not so easy. The debug mode makes it easier to find when to stop but not when the sequence starts. Y
I tried to follow the information about installing Qemu (https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver), but ran into problem and I'm not able to install the driver in windows (I have an error while starting qemu abut my soundcard address -> qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no available reset mechanism. ). So sadly I'm not able to get the hda_verb output here... :( Would love to help but for today I'm done. Maybe will have time sunday to try something else. Is there a program I can run into a windows partition to sniff the hda? I'm almost sure I saw something but I cannot remember where...
(In reply to Vincent Morel from comment #299) > I tried to follow the information about installing Qemu > (https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs- > from-a-Windows-sound-driver), but ran into problem and I'm not able to > install the driver in windows (I have an error while starting qemu abut my > soundcard address > -> qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no available > reset mechanism. > ). > So sadly I'm not able to get the hda_verb output here... :( Would love to > help but for today I'm done. Maybe will have time sunday to try something > else. > Is there a program I can run into a windows partition to sniff the hda? I'm > almost sure I saw something but I cannot remember where... Are you referring to RtHDDump_V236 binary? Check Comment #236.
Created attachment 297623 [details] attachment-8392-0.html Yes, it's a known issue that the sound card is non-resettable. The really good is is that this generally isn't a problem. If through your testing you start having problems, you might need to stop/start the VM, and in some cases, fully shut down the machine. I did tons of testing, and very rarely did I need to do anything more than restart the VM. Only twice did I need to shut off the entire laptop. Anyway, getting Windows to use the right driver is a bit tricky, but it can absolutely be done. I don't have the same machine, but looking at your alsa-info, this should mostly work. I don't have the URL for your laptop, but here's the Lenovo version as an example: https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/legion-series/legion-7-15imhg05/81yu/81yucto1ww/mp1t35d3/downloads/driver-list/ Find the equivalent part of the Lenovo site for your model and then download your sound driver. When opening the driver, choose to extract the driver (it won't hurt if you also install it). Anyway, here are the instructions I posted earlier in this bug: You need to force the device expanded above to use the RealTek driver. I was able to force it by *extracting* rather than installing the sound driver from the Lenovo site. Selecting update driver on the sound device listed under "Sound, video and game controllers", and from there I did: "Browse my computer for drivers" "Let me pick from a list of available drivers on my computer" "Have Disk" Browse to: C:\Drivers\Audio\201211706.15485923\Realtek\Codec_8975.1\HDXLVSST.inf Press Ok You should see "Realtek High Definition Audio(SST)" as an option. It's the only option for me) Next Yes Restart the VM when prompted Hopefully after these steps, you'll see the "Realtek High Definition Audio(SST)" device in device manager as your sound card and you'll get sound from windows. By getting a Win10 VM running with the JCS Qemu means you're a good chunk of the way done. -Cameron PS: I looked into RtHDDump_V236 and I don't think it's anything I needed for my particular case. It seems it can be used to figure out what pins should be connected to what. We'll see if you need any of that, but not yet. On 6/25/21 12:31 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #299 from Vincent Morel (dantahoua@gmail.com) --- > I tried to follow the information about installing Qemu > > (https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver), > but ran into problem and I'm not able to install the driver in windows (I > have > an error while starting qemu abut my soundcard address > -> qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no available > reset mechanism. > ). > So sadly I'm not able to get the hda_verb output here... :( Would love to > help > but for today I'm done. Maybe will have time sunday to try something else. > Is there a program I can run into a windows partition to sniff the hda? I'm > almost sure I saw something but I cannot remember where... >
Created attachment 297625 [details] attachment-12135-0.html Yes! I'll force the driver install. Thanks for your support. I have to go now but sure I will try all of this. On a side note, the Qemu I compile from the Git do not seems to start, just stuck. The one from the Ubuntu repo starts with no problem. Le ven. 25 juin 2021 à 15:37, <bugzilla-daemon@bugzilla.kernel.org> a écrit : > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #300 from TT (thiagotei@icloud.com) --- > (In reply to Vincent Morel from comment #299) > > I tried to follow the information about installing Qemu > > ( > https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs- > > from-a-Windows-sound-driver), but ran into problem and I'm not able to > > install the driver in windows (I have an error while starting qemu abut > my > > soundcard address > > -> qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no > available > > reset mechanism. > > ). > > So sadly I'm not able to get the hda_verb output here... :( Would love to > > help but for today I'm done. Maybe will have time sunday to try something > > else. > > Is there a program I can run into a windows partition to sniff the hda? > I'm > > almost sure I saw something but I cannot remember where... > > Are you referring to RtHDDump_V236 binary? > Check Comment #236. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
What were your ./configure arguments? Here were mine: ./configure --prefix=/opt/qemu/jcs --enable-kvm --enable-trace-backends=log --target-list=x86_64-softmmu Then I would run it with this script: #!/bin/bash _qemu=/opt/qemu/jcs/bin/qemu-system-x86_64 sudo $_qemu -enable-kvm -hda win10.qcow2 -m 8G -smp 4 -vga std \ -device vfio-pci,host=00:1f.3,multifunction=on,x-no-mmap=true \ -trace events=/path/to/events.txt The contents of events.txt: -vfio_region_read vfio_region_write I'm not sure if the events.txt is needed for JCS Qemu, but they don't hurt. :) Does it always hang? I did notice this version of qemu would often hang during OS startup (less than 50% of the time though). Glad to know it wasn't just me. :) On 6/25/21 12:53 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #302 from Vincent Morel (dantahoua@gmail.com) --- > Yes! > I'll force the driver install. Thanks for your support. I have to go now > but sure I will try all of this. On a side note, the Qemu I compile from > the Git do not seems to start, just stuck. > The one from the Ubuntu repo starts with no problem. > > Le ven. 25 juin 2021 à 15:37, <bugzilla-daemon@bugzilla.kernel.org> a > écrit : > >> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >> >> --- Comment #300 from TT (thiagotei@icloud.com) --- >> (In reply to Vincent Morel from comment #299) >>> I tried to follow the information about installing Qemu >>> ( >> https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs- >>> from-a-Windows-sound-driver), but ran into problem and I'm not able to >>> install the driver in windows (I have an error while starting qemu abut >> my >>> soundcard address >>> -> qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no >> available >>> reset mechanism. >>> ). >>> So sadly I'm not able to get the hda_verb output here... :( Would love to >>> help but for today I'm done. Maybe will have time sunday to try something >>> else. >>> Is there a program I can run into a windows partition to sniff the hda? >> I'm >>> almost sure I saw something but I cannot remember where... >> Are you referring to RtHDDump_V236 binary? >> Check Comment #236. >> >> -- >> You may reply to this email to add a comment. >> >> You are receiving this mail because: >> You are on the CC list for the bug.
Hey! I've tested some of these fixes on my Lenovo 16ACHg6 and had no luck. What I've tested: - Using the applyverbs.py with verbs-working.txt - Applying the legion-alc287-0.0.4.patch as per instructions - Applying the legion-alc287-0.0.5.patch as per instructions Something that may be important is that this new model is running an AMD processor and the sound controller appears as: 'Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller' On Alsa Mixer, it says the "Chip" is ALC287 but the "Card" is HD-Audio Generic. Is that important? I'm bringing this up because the instructions say: # Patch file to enable output on speakers. options snd-hda-intel patch=legion-alc287-0.0.4.patch And the intel part there may be something to change? But honestly I'm clueless so this may be waaay off. Thanks in advance!
You're not the first person to report that these fixes don't work for the 2021 Legion. Can you post your alsa-info? I'd like to order one as soon as they become available here in the USA, but I'm unsure what the availability will be. If I managed to snag one, I'll work on getting sound working there too. On 6/25/21 4:52 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Pablitar (pablitar@gmail.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |pablitar@gmail.com > > --- Comment #304 from Pablitar (pablitar@gmail.com) --- > Hey! > > I've tested some of these fixes on my Lenovo 16ACHg6 and had no luck. > > What I've tested: > - Using the applyverbs.py with verbs-working.txt > - Applying the legion-alc287-0.0.4.patch as per instructions > - Applying the legion-alc287-0.0.5.patch as per instructions > > Something that may be important is that this new model is running an AMD > processor and the sound controller appears as: > > 'Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) > HD Audio Controller' > > On Alsa Mixer, it says the "Chip" is ALC287 but the "Card" is HD-Audio > Generic. > > Is that important? I'm bringing this up because the instructions say: > > # Patch file to enable output on speakers. > options snd-hda-intel patch=legion-alc287-0.0.4.patch > > And the intel part there may be something to change? > > But honestly I'm clueless so this may be waaay off. > > Thanks in advance! >
Created attachment 297629 [details] lenovo-16ACHg6-alsa-info Sure, here is my alsa-info. I hope it helps!
And thank you so much for what you are doing Cameron! (In reply to Cameron Berkenpas from comment #305) > You're not the first person to report that these fixes don't work for > the 2021 Legion. > > Can you post your alsa-info? > > I'd like to order one as soon as they become available here in the USA, > but I'm unsure what the availability will be. If I managed to snag one, > I'll work on getting sound working there too. > > On 6/25/21 4:52 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > Pablitar (pablitar@gmail.com) changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > CC| |pablitar@gmail.com > > > > --- Comment #304 from Pablitar (pablitar@gmail.com) --- > > Hey! > > > > I've tested some of these fixes on my Lenovo 16ACHg6 and had no luck. > > > > What I've tested: > > - Using the applyverbs.py with verbs-working.txt > > - Applying the legion-alc287-0.0.4.patch as per instructions > > - Applying the legion-alc287-0.0.5.patch as per instructions > > > > Something that may be important is that this new model is running an AMD > > processor and the sound controller appears as: > > > > 'Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models > 10h-1fh) > > HD Audio Controller' > > > > On Alsa Mixer, it says the "Chip" is ALC287 but the "Card" is HD-Audio > > Generic. > > > > Is that important? I'm bringing this up because the instructions say: > > > > # Patch file to enable output on speakers. > > options snd-hda-intel patch=legion-alc287-0.0.4.patch > > > > And the intel part there may be something to change? > > > > But honestly I'm clueless so this may be waaay off. > > > > Thanks in advance! > >
(In reply to Cameron Berkenpas from comment #296) > Created attachment 297621 [details] > yoga7-alc287-0.0.5.patch - snd-hda-intel patch for Yoga 7 models > > This is another snd-hda-intel patch. _NOT_ a kernel patch. > > This works for the Yoga 7. AFAIK, it should cover at least both the Yoga 7 > 14ITL5 and the 14cITL. I think these are likely Yoga 7 models for different > regions. > > If yours doesn't work, please let us know what steps you took to try the > patch and what specifically doesn't work. > > 1. Download the "yoga7-alc287-0.0.5.patch" from this bug. > > 2. Copy it to /lib/firmware/yoga-alc287.patch. Ie, "sudo cp > yoga-alc287-0.0.5.patch /lib/firmware/yoga7-alc287.patch" > > 3. Create/open "/etc/modprobe.d/lenovo-fix.conf" in your favorite text > editor. Ie, "sudo nano -w /etc/modprobe.d/lenovo-fix.conf" > > 4. Set the contents of "/etc/modprobe.d/lenovo-fix.conf" to be following > then save and exit: > # Patch file to enable output on speakers. > options snd-hda-intel patch=yoga7-alc287.patch > > 5. Reboot > > 6. Test your sound (including with plugging and unplugging headphones while > sound is playing) and report back here with your results. > > NOTE: To disable the patch, remove /etc/modprobe.d/lenovo-fix.conf and > reboot. > > This patch file should work as well or better than applying verbs-yoga7.txt > or as well as using the kernel patch (provided your model is supported by > the patch). > > Some more info on snd-hda patch files can be found here for those wanting to > experiment: > https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html I performed the above steps on a Yoga 7 14ITL5 (reporting "Realtek ALC287" from alsa-info) running Elementary OS 6 beta (Ubuntu 20.04 LTS) with kernel 5.8.0-55. It did not work. Only speakers do not work. All other audio (headphones, HDMI, bluetooth) works.
Woody is reporting the same thing also with 5.8.0. Either The snd-hda-intel patches are no good for the Yoga 7 and/or 5.8.0 may not be recent enough for some reason. Woody did say that the kernel patches do work , fortunately. Is the yoga7-alc287-0.0.5.patch working on anyone's Yoga 7? On 6/25/21 5:55 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #308 from Dre (dreman_74@hotmail.com) --- > (In reply to Cameron Berkenpas from comment #296) >> Created attachment 297621 [details] >> yoga7-alc287-0.0.5.patch - snd-hda-intel patch for Yoga 7 models >> >> This is another snd-hda-intel patch. _NOT_ a kernel patch. >> >> This works for the Yoga 7. AFAIK, it should cover at least both the Yoga 7 >> 14ITL5 and the 14cITL. I think these are likely Yoga 7 models for different >> regions. >> >> If yours doesn't work, please let us know what steps you took to try the >> patch and what specifically doesn't work. >> >> 1. Download the "yoga7-alc287-0.0.5.patch" from this bug. >> >> 2. Copy it to /lib/firmware/yoga-alc287.patch. Ie, "sudo cp >> yoga-alc287-0.0.5.patch /lib/firmware/yoga7-alc287.patch" >> >> 3. Create/open "/etc/modprobe.d/lenovo-fix.conf" in your favorite text >> editor. Ie, "sudo nano -w /etc/modprobe.d/lenovo-fix.conf" >> >> 4. Set the contents of "/etc/modprobe.d/lenovo-fix.conf" to be following >> then save and exit: >> # Patch file to enable output on speakers. >> options snd-hda-intel patch=yoga7-alc287.patch >> >> 5. Reboot >> >> 6. Test your sound (including with plugging and unplugging headphones while >> sound is playing) and report back here with your results. >> >> NOTE: To disable the patch, remove /etc/modprobe.d/lenovo-fix.conf and >> reboot. >> >> This patch file should work as well or better than applying verbs-yoga7.txt >> or as well as using the kernel patch (provided your model is supported by >> the patch). >> >> Some more info on snd-hda patch files can be found here for those wanting to >> experiment: >> https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html > I performed the above steps on a Yoga 7 14ITL5 (reporting "Realtek ALC287" > from > alsa-info) running Elementary OS 6 beta (Ubuntu 20.04 LTS) with kernel > 5.8.0-55. It did not work. Only speakers do not work. All other audio > (headphones, HDMI, bluetooth) works. >
You're welcome. I understand the frustration! Can you or anyone else with a Legion 7 16ACHg6 check if your CPU has IOMMU support? I'm not able to find an answer to this one way or another. If so, likely the same trick can be used to find the codec initialization verb sequence. On 6/25/21 5:06 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #307 from Pablitar (pablitar@gmail.com) --- > And thank you so much for what you are doing Cameron! > > (In reply to Cameron Berkenpas from comment #305) >> You're not the first person to report that these fixes don't work for >> the 2021 Legion. >> >> Can you post your alsa-info? >> >> I'd like to order one as soon as they become available here in the USA, >> but I'm unsure what the availability will be. If I managed to snag one, >> I'll work on getting sound working there too. >> >> On 6/25/21 4:52 PM, bugzilla-daemon@bugzilla.kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> Pablitar (pablitar@gmail.com) changed: >>> >>> What |Removed |Added >>> >> ---------------------------------------------------------------------------- >>> CC| |pablitar@gmail.com >>> >>> --- Comment #304 from Pablitar (pablitar@gmail.com) --- >>> Hey! >>> >>> I've tested some of these fixes on my Lenovo 16ACHg6 and had no luck. >>> >>> What I've tested: >>> - Using the applyverbs.py with verbs-working.txt >>> - Applying the legion-alc287-0.0.4.patch as per instructions >>> - Applying the legion-alc287-0.0.5.patch as per instructions >>> >>> Something that may be important is that this new model is running an AMD >>> processor and the sound controller appears as: >>> >>> 'Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models >> 10h-1fh) >>> HD Audio Controller' >>> >>> On Alsa Mixer, it says the "Chip" is ALC287 but the "Card" is HD-Audio >>> Generic. >>> >>> Is that important? I'm bringing this up because the instructions say: >>> >>> # Patch file to enable output on speakers. >>> options snd-hda-intel patch=legion-alc287-0.0.4.patch >>> >>> And the intel part there may be something to change? >>> >>> But honestly I'm clueless so this may be waaay off. >>> >>> Thanks in advance! >>>
(In reply to Cameron Berkenpas from comment #297) > (In reply to sycxyc from comment #295) > > (In reply to Cameron Berkenpas from comment #292) > I forgot about the debug mode of applyverbs.py. > > I was thinking of making the same modifications to applyverbs.py... Can you > attach your version to this bug? It might also be worth sharing your changes > with the original author too. > > Again, great work! diff --git a/applyverbs.py b/applyverbs.py index 5296d8d..a372736 100755 --- a/applyverbs.py +++ b/applyverbs.py @@ -4,6 +4,8 @@ import sys import time def validate(verbstring): try: + if verbstring[:1] in '#/;': + return False verbsegments = verbstring.split(' ') int(verbsegments[0], 16) and int(verbsegments[1], 16) and int(verbsegments[2], 16) return verbsegments @@ -29,6 +31,8 @@ f.close() print('Applying verbs...') for i in range(0, len(verbsegments)): segment = verbsegments[i] + if not segment: + continue args = ['hda-verb', '/dev/snd/hwC0D0', *segment] result = subprocess.run(args, stderr=subprocess.DEVNULL, stdout=subprocess.PIPE).stdout.decode('utf-8') response = result[8:len(result)-1] (In reply to TT from comment #298) > (In reply to sycxyc from comment #295) > > Very good work! > That does not look so trivial though. The verbs-working.txt has more than > 500 lines and finding those 5 lines looks not so easy. The debug mode makes > it easier to find when to stop but not when the sequence starts. > Y It only takes 5 backtraces to find the starting line, but the line-by-line test is not safe and may result in the need for a forced reboot
Maybe try: dmesg | grep -i iommu On 6/25/2021 6:24 PM, Cameron Berkenpas wrote: > You're welcome. I understand the frustration! > > Can you or anyone else with a Legion 7 16ACHg6 check if your CPU has > IOMMU support? I'm not able to find an answer to this one way or > another. If so, likely the same trick can be used to find the codec > initialization verb sequence. > > > On 6/25/21 5:06 PM, bugzilla-daemon@bugzilla.kernel.org wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >> >> --- Comment #307 from Pablitar (pablitar@gmail.com) --- >> And thank you so much for what you are doing Cameron! >> >> (In reply to Cameron Berkenpas from comment #305) >>> You're not the first person to report that these fixes don't work for >>> the 2021 Legion. >>> >>> Can you post your alsa-info? >>> >>> I'd like to order one as soon as they become available here in the USA, >>> but I'm unsure what the availability will be. If I managed to snag one, >>> I'll work on getting sound working there too. >>> >>> On 6/25/21 4:52 PM, bugzilla-daemon@bugzilla.kernel.org wrote: >>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>>> >>>> Pablitar (pablitar@gmail.com) changed: >>>> >>>> What |Removed |Added >>>> >>> >>> ---------------------------------------------------------------------------- >>> >>>> CC| |pablitar@gmail.com >>>> >>>> --- Comment #304 from Pablitar (pablitar@gmail.com) --- >>>> Hey! >>>> >>>> I've tested some of these fixes on my Lenovo 16ACHg6 and had no luck. >>>> >>>> What I've tested: >>>> - Using the applyverbs.py with verbs-working.txt >>>> - Applying the legion-alc287-0.0.4.patch as per instructions >>>> - Applying the legion-alc287-0.0.5.patch as per instructions >>>> >>>> Something that may be important is that this new model is running >>>> an AMD >>>> processor and the sound controller appears as: >>>> >>>> 'Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models >>> 10h-1fh) >>>> HD Audio Controller' >>>> >>>> On Alsa Mixer, it says the "Chip" is ALC287 but the "Card" is HD-Audio >>>> Generic. >>>> >>>> Is that important? I'm bringing this up because the instructions say: >>>> >>>> # Patch file to enable output on speakers. >>>> options snd-hda-intel patch=legion-alc287-0.0.4.patch >>>> >>>> And the intel part there may be something to change? >>>> >>>> But honestly I'm clueless so this may be waaay off. >>>> >>>> Thanks in advance! >>>> >
(In reply to Cameron Berkenpas from comment #309) > Woody is reporting the same thing also with 5.8.0. Either The > snd-hda-intel patches are no good for the Yoga 7 and/or 5.8.0 may not be > recent enough for some reason. > > Woody did say that the kernel patches do work , fortunately. > > Is the yoga7-alc287-0.0.5.patch working on anyone's Yoga 7? > As far as I have seen, the snd-hda patch does not work on my Ubuntu (!) system. Neither for 5.11 nor for 5.8. My understanding is that the firmware patch does not load as expected in Ubuntu 20.04. And it is not due to the laptop model (Yoga). Maybe Ubuntu has something in between (udev) that needs a different configuration for firmwares to make it work. What has worked so far (minimum verbs/Cameron - but also very small version from sycxyc) : - the kernel patch (5.8.0-59) => pretty sure it will also work with 5.11/5.12 - The applyverbs.py (thx to sycxyc for doing the comment modification, I wanted to do that also ..) - the S3 resume method
Here it is: [ 0.293604] iommu: Default domain type: Translated [ 0.487357] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported [ 0.487484] pci 0000:00:01.0: Adding to iommu group 0 [ 0.487493] pci 0000:00:01.1: Adding to iommu group 1 [ 0.487500] pci 0000:00:01.2: Adding to iommu group 2 [ 0.487511] pci 0000:00:02.0: Adding to iommu group 3 [ 0.487518] pci 0000:00:02.1: Adding to iommu group 4 [ 0.487526] pci 0000:00:02.2: Adding to iommu group 5 [ 0.487538] pci 0000:00:08.0: Adding to iommu group 6 [ 0.487544] pci 0000:00:08.1: Adding to iommu group 6 [ 0.487550] pci 0000:00:08.2: Adding to iommu group 6 [ 0.487560] pci 0000:00:14.0: Adding to iommu group 7 [ 0.487566] pci 0000:00:14.3: Adding to iommu group 7 [ 0.487587] pci 0000:00:18.0: Adding to iommu group 8 [ 0.487593] pci 0000:00:18.1: Adding to iommu group 8 [ 0.487599] pci 0000:00:18.2: Adding to iommu group 8 [ 0.487606] pci 0000:00:18.3: Adding to iommu group 8 [ 0.487612] pci 0000:00:18.4: Adding to iommu group 8 [ 0.487618] pci 0000:00:18.5: Adding to iommu group 8 [ 0.487624] pci 0000:00:18.6: Adding to iommu group 8 [ 0.487629] pci 0000:00:18.7: Adding to iommu group 8 [ 0.487640] pci 0000:01:00.0: Adding to iommu group 9 [ 0.487648] pci 0000:01:00.1: Adding to iommu group 9 [ 0.487656] pci 0000:02:00.0: Adding to iommu group 10 [ 0.487664] pci 0000:03:00.0: Adding to iommu group 11 [ 0.487671] pci 0000:04:00.0: Adding to iommu group 12 [ 0.487685] pci 0000:05:00.0: Adding to iommu group 6 [ 0.487688] pci 0000:05:00.2: Adding to iommu group 6 [ 0.487693] pci 0000:05:00.3: Adding to iommu group 6 [ 0.487696] pci 0000:05:00.4: Adding to iommu group 6 [ 0.487700] pci 0000:05:00.6: Adding to iommu group 6 [ 0.487703] pci 0000:06:00.0: Adding to iommu group 6 [ 0.487707] pci 0000:06:00.1: Adding to iommu group 6 [ 0.489073] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40 [ 0.490935] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 counters/bank). [ 0.535396] AMD-Vi: AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de> Seems it is supported? (In reply to Cameron Berkenpas from comment #312) > Maybe try: > > dmesg | grep -i iommu > > On 6/25/2021 6:24 PM, Cameron Berkenpas wrote: > > You're welcome. I understand the frustration! > > > > Can you or anyone else with a Legion 7 16ACHg6 check if your CPU has > > IOMMU support? I'm not able to find an answer to this one way or > > another. If so, likely the same trick can be used to find the codec > > initialization verb sequence. > > > > > > On 6/25/21 5:06 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > >> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >> > >> --- Comment #307 from Pablitar (pablitar@gmail.com) --- > >> And thank you so much for what you are doing Cameron! > >> > >> (In reply to Cameron Berkenpas from comment #305) > >>> You're not the first person to report that these fixes don't work for > >>> the 2021 Legion. > >>> > >>> Can you post your alsa-info? > >>> > >>> I'd like to order one as soon as they become available here in the USA, > >>> but I'm unsure what the availability will be. If I managed to snag one, > >>> I'll work on getting sound working there too. > >>> > >>> On 6/25/21 4:52 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > >>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>>> > >>>> Pablitar (pablitar@gmail.com) changed: > >>>> > >>>> What |Removed |Added > >>>> > >>> > >>> > ---------------------------------------------------------------------------- > >>> > >>>> CC| |pablitar@gmail.com > >>>> > >>>> --- Comment #304 from Pablitar (pablitar@gmail.com) --- > >>>> Hey! > >>>> > >>>> I've tested some of these fixes on my Lenovo 16ACHg6 and had no luck. > >>>> > >>>> What I've tested: > >>>> - Using the applyverbs.py with verbs-working.txt > >>>> - Applying the legion-alc287-0.0.4.patch as per instructions > >>>> - Applying the legion-alc287-0.0.5.patch as per instructions > >>>> > >>>> Something that may be important is that this new model is running > >>>> an AMD > >>>> processor and the sound controller appears as: > >>>> > >>>> 'Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models > >>> 10h-1fh) > >>>> HD Audio Controller' > >>>> > >>>> On Alsa Mixer, it says the "Chip" is ALC287 but the "Card" is HD-Audio > >>>> Generic. > >>>> > >>>> Is that important? I'm bringing this up because the instructions say: > >>>> > >>>> # Patch file to enable output on speakers. > >>>> options snd-hda-intel patch=legion-alc287-0.0.4.patch > >>>> > >>>> And the intel part there may be something to change? > >>>> > >>>> But honestly I'm clueless so this may be waaay off. > >>>> > >>>> Thanks in advance! > >>>> > >
That is a resounding yes! Unsurprisingly for AMD, PCI passthrough is available. Is there anyone with a Legion 7 16ACHg6 who's up to setting up pci passthrough for their sound card and compiling JCS's Qemu all to run a Windows 10 VM? Someone can either try to do that for themselves or wait for me and hope there's sufficient availability. On 6/25/2021 7:45 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #314 from Pablitar (pablitar@gmail.com) --- > Here it is: > [ 0.293604] iommu: Default domain type: Translated > [ 0.487357] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported > [ 0.487484] pci 0000:00:01.0: Adding to iommu group 0 > [ 0.487493] pci 0000:00:01.1: Adding to iommu group 1 > [ 0.487500] pci 0000:00:01.2: Adding to iommu group 2 > [ 0.487511] pci 0000:00:02.0: Adding to iommu group 3 > [ 0.487518] pci 0000:00:02.1: Adding to iommu group 4 > [ 0.487526] pci 0000:00:02.2: Adding to iommu group 5 > [ 0.487538] pci 0000:00:08.0: Adding to iommu group 6 > [ 0.487544] pci 0000:00:08.1: Adding to iommu group 6 > [ 0.487550] pci 0000:00:08.2: Adding to iommu group 6 > [ 0.487560] pci 0000:00:14.0: Adding to iommu group 7 > [ 0.487566] pci 0000:00:14.3: Adding to iommu group 7 > [ 0.487587] pci 0000:00:18.0: Adding to iommu group 8 > [ 0.487593] pci 0000:00:18.1: Adding to iommu group 8 > [ 0.487599] pci 0000:00:18.2: Adding to iommu group 8 > [ 0.487606] pci 0000:00:18.3: Adding to iommu group 8 > [ 0.487612] pci 0000:00:18.4: Adding to iommu group 8 > [ 0.487618] pci 0000:00:18.5: Adding to iommu group 8 > [ 0.487624] pci 0000:00:18.6: Adding to iommu group 8 > [ 0.487629] pci 0000:00:18.7: Adding to iommu group 8 > [ 0.487640] pci 0000:01:00.0: Adding to iommu group 9 > [ 0.487648] pci 0000:01:00.1: Adding to iommu group 9 > [ 0.487656] pci 0000:02:00.0: Adding to iommu group 10 > [ 0.487664] pci 0000:03:00.0: Adding to iommu group 11 > [ 0.487671] pci 0000:04:00.0: Adding to iommu group 12 > [ 0.487685] pci 0000:05:00.0: Adding to iommu group 6 > [ 0.487688] pci 0000:05:00.2: Adding to iommu group 6 > [ 0.487693] pci 0000:05:00.3: Adding to iommu group 6 > [ 0.487696] pci 0000:05:00.4: Adding to iommu group 6 > [ 0.487700] pci 0000:05:00.6: Adding to iommu group 6 > [ 0.487703] pci 0000:06:00.0: Adding to iommu group 6 > [ 0.487707] pci 0000:06:00.1: Adding to iommu group 6 > [ 0.489073] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40 > [ 0.490935] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 > counters/bank). > [ 0.535396] AMD-Vi: AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de> > > Seems it is supported? > > (In reply to Cameron Berkenpas from comment #312) >> Maybe try: >> >> dmesg | grep -i iommu >> >> On 6/25/2021 6:24 PM, Cameron Berkenpas wrote: >>> You're welcome. I understand the frustration! >>> >>> Can you or anyone else with a Legion 7 16ACHg6 check if your CPU has >>> IOMMU support? I'm not able to find an answer to this one way or >>> another. If so, likely the same trick can be used to find the codec >>> initialization verb sequence. >>> >>> >>> On 6/25/21 5:06 PM, bugzilla-daemon@bugzilla.kernel.org wrote: >>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>>> >>>> --- Comment #307 from Pablitar (pablitar@gmail.com) --- >>>> And thank you so much for what you are doing Cameron! >>>> >>>> (In reply to Cameron Berkenpas from comment #305) >>>>> You're not the first person to report that these fixes don't work for >>>>> the 2021 Legion. >>>>> >>>>> Can you post your alsa-info? >>>>> >>>>> I'd like to order one as soon as they become available here in the USA, >>>>> but I'm unsure what the availability will be. If I managed to snag one, >>>>> I'll work on getting sound working there too. >>>>> >>>>> On 6/25/21 4:52 PM, bugzilla-daemon@bugzilla.kernel.org wrote: >>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>>>>> >>>>>> Pablitar (pablitar@gmail.com) changed: >>>>>> >>>>>> What |Removed |Added >>>>>> >>>>> >> ---------------------------------------------------------------------------- >>>>>> CC| |pablitar@gmail.com >>>>>> >>>>>> --- Comment #304 from Pablitar (pablitar@gmail.com) --- >>>>>> Hey! >>>>>> >>>>>> I've tested some of these fixes on my Lenovo 16ACHg6 and had no luck. >>>>>> >>>>>> What I've tested: >>>>>> - Using the applyverbs.py with verbs-working.txt >>>>>> - Applying the legion-alc287-0.0.4.patch as per instructions >>>>>> - Applying the legion-alc287-0.0.5.patch as per instructions >>>>>> >>>>>> Something that may be important is that this new model is running >>>>>> an AMD >>>>>> processor and the sound controller appears as: >>>>>> >>>>>> 'Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models >>>>> 10h-1fh) >>>>>> HD Audio Controller' >>>>>> >>>>>> On Alsa Mixer, it says the "Chip" is ALC287 but the "Card" is HD-Audio >>>>>> Generic. >>>>>> >>>>>> Is that important? I'm bringing this up because the instructions say: >>>>>> >>>>>> # Patch file to enable output on speakers. >>>>>> options snd-hda-intel patch=legion-alc287-0.0.4.patch >>>>>> >>>>>> And the intel part there may be something to change? >>>>>> >>>>>> But honestly I'm clueless so this may be waaay off. >>>>>> >>>>>> Thanks in advance! >>>>>>
I'll see if I have the time. And if I can hahaha. Is there a clear list of instructions in this thread? I'm lost in all the messages. I can read the thread trying to compile what to do. But if someone could point me where to look, maybe that can save me an hour or two. (In reply to Cameron Berkenpas from comment #315) > That is a resounding yes! Unsurprisingly for AMD, PCI passthrough is > available. > > Is there anyone with a Legion 7 16ACHg6 who's up to setting up pci > passthrough for their sound card and compiling JCS's Qemu all to run a > Windows 10 VM? Someone can either try to do that for themselves or wait > for me and hope there's sufficient availability. > > On 6/25/2021 7:45 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #314 from Pablitar (pablitar@gmail.com) --- > > Here it is: > > [ 0.293604] iommu: Default domain type: Translated > > [ 0.487357] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters > supported > > [ 0.487484] pci 0000:00:01.0: Adding to iommu group 0 > > [ 0.487493] pci 0000:00:01.1: Adding to iommu group 1 > > [ 0.487500] pci 0000:00:01.2: Adding to iommu group 2 > > [ 0.487511] pci 0000:00:02.0: Adding to iommu group 3 > > [ 0.487518] pci 0000:00:02.1: Adding to iommu group 4 > > [ 0.487526] pci 0000:00:02.2: Adding to iommu group 5 > > [ 0.487538] pci 0000:00:08.0: Adding to iommu group 6 > > [ 0.487544] pci 0000:00:08.1: Adding to iommu group 6 > > [ 0.487550] pci 0000:00:08.2: Adding to iommu group 6 > > [ 0.487560] pci 0000:00:14.0: Adding to iommu group 7 > > [ 0.487566] pci 0000:00:14.3: Adding to iommu group 7 > > [ 0.487587] pci 0000:00:18.0: Adding to iommu group 8 > > [ 0.487593] pci 0000:00:18.1: Adding to iommu group 8 > > [ 0.487599] pci 0000:00:18.2: Adding to iommu group 8 > > [ 0.487606] pci 0000:00:18.3: Adding to iommu group 8 > > [ 0.487612] pci 0000:00:18.4: Adding to iommu group 8 > > [ 0.487618] pci 0000:00:18.5: Adding to iommu group 8 > > [ 0.487624] pci 0000:00:18.6: Adding to iommu group 8 > > [ 0.487629] pci 0000:00:18.7: Adding to iommu group 8 > > [ 0.487640] pci 0000:01:00.0: Adding to iommu group 9 > > [ 0.487648] pci 0000:01:00.1: Adding to iommu group 9 > > [ 0.487656] pci 0000:02:00.0: Adding to iommu group 10 > > [ 0.487664] pci 0000:03:00.0: Adding to iommu group 11 > > [ 0.487671] pci 0000:04:00.0: Adding to iommu group 12 > > [ 0.487685] pci 0000:05:00.0: Adding to iommu group 6 > > [ 0.487688] pci 0000:05:00.2: Adding to iommu group 6 > > [ 0.487693] pci 0000:05:00.3: Adding to iommu group 6 > > [ 0.487696] pci 0000:05:00.4: Adding to iommu group 6 > > [ 0.487700] pci 0000:05:00.6: Adding to iommu group 6 > > [ 0.487703] pci 0000:06:00.0: Adding to iommu group 6 > > [ 0.487707] pci 0000:06:00.1: Adding to iommu group 6 > > [ 0.489073] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40 > > [ 0.490935] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 > > counters/bank). > > [ 0.535396] AMD-Vi: AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de> > > > > Seems it is supported? > > > > (In reply to Cameron Berkenpas from comment #312) > >> Maybe try: > >> > >> dmesg | grep -i iommu > >> > >> On 6/25/2021 6:24 PM, Cameron Berkenpas wrote: > >>> You're welcome. I understand the frustration! > >>> > >>> Can you or anyone else with a Legion 7 16ACHg6 check if your CPU has > >>> IOMMU support? I'm not able to find an answer to this one way or > >>> another. If so, likely the same trick can be used to find the codec > >>> initialization verb sequence. > >>> > >>> > >>> On 6/25/21 5:06 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > >>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>>> > >>>> --- Comment #307 from Pablitar (pablitar@gmail.com) --- > >>>> And thank you so much for what you are doing Cameron! > >>>> > >>>> (In reply to Cameron Berkenpas from comment #305) > >>>>> You're not the first person to report that these fixes don't work for > >>>>> the 2021 Legion. > >>>>> > >>>>> Can you post your alsa-info? > >>>>> > >>>>> I'd like to order one as soon as they become available here in the USA, > >>>>> but I'm unsure what the availability will be. If I managed to snag one, > >>>>> I'll work on getting sound working there too. > >>>>> > >>>>> On 6/25/21 4:52 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > >>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>>>>> > >>>>>> Pablitar (pablitar@gmail.com) changed: > >>>>>> > >>>>>> What |Removed |Added > >>>>>> > >>>>> > >> > ---------------------------------------------------------------------------- > >>>>>> CC| |pablitar@gmail.com > >>>>>> > >>>>>> --- Comment #304 from Pablitar (pablitar@gmail.com) --- > >>>>>> Hey! > >>>>>> > >>>>>> I've tested some of these fixes on my Lenovo 16ACHg6 and had no luck. > >>>>>> > >>>>>> What I've tested: > >>>>>> - Using the applyverbs.py with verbs-working.txt > >>>>>> - Applying the legion-alc287-0.0.4.patch as per instructions > >>>>>> - Applying the legion-alc287-0.0.5.patch as per instructions > >>>>>> > >>>>>> Something that may be important is that this new model is running > >>>>>> an AMD > >>>>>> processor and the sound controller appears as: > >>>>>> > >>>>>> 'Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models > >>>>> 10h-1fh) > >>>>>> HD Audio Controller' > >>>>>> > >>>>>> On Alsa Mixer, it says the "Chip" is ALC287 but the "Card" is HD-Audio > >>>>>> Generic. > >>>>>> > >>>>>> Is that important? I'm bringing this up because the instructions say: > >>>>>> > >>>>>> # Patch file to enable output on speakers. > >>>>>> options snd-hda-intel patch=legion-alc287-0.0.4.patch > >>>>>> > >>>>>> And the intel part there may be something to change? > >>>>>> > >>>>>> But honestly I'm clueless so this may be waaay off. > >>>>>> > >>>>>> Thanks in advance! > >>>>>>
I posted some instructions, but I've lost them in the thread too. :p I used this document to setup the PCI passthrough: https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF PCIE devices are in groups, and ALL of the devices in a group must be setup for passthrough together. However, I found I only needed to tell qemu about the sound card. On my 2020 Legion 7i, the sound card is in a group with 3 other devices. Fortunately, it didn't cause me any issues to set them all up for passthrough as none were vital to running the system. This will probably be the case for you, but we'll see. The article provides a script that lists all the PCI groups and their associated devices that is really helpful: https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Ensuring_that_the_groups_are_valid Here's part of the output of the script showing the sound card and the group that it's in as well as the other devices in that group: IOMMU Group 14: 00:1f.0 ISA bridge [0601]: Intel Corporation Comet Lake LPC Controller [8086:068d] 00:1f.3 Audio device [0403]: Intel Corporation Comet Lake PCH cAVS [8086:06c8] 00:1f.4 SMBus [0c05]: Intel Corporation Comet Lake PCH SMBus Controller [8086:06a3] 00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake PCH SPI Controller [8086:06a4] Here's JCS's Qemu. JCS just made some changes that added logging to pick out HDA verbs. https://github.com/jcs/qemu You'll need to make sure you have the build dependencies for qemu. Here's what I used for configure: ./configure --prefix=/opt/qemu/jcs --enable-kvm --enable-trace-backends=log --target-list=x86_64-softmmu You can change the prefix to whatever you personally prefer of course. From there follow up with the usual "make && make install" If you get this far, I can provide more guidance on where to go. Vincent Morel has started working on the same thing, but with an entirely different model of Lenovo laptop. If you have trouble, also feel free to reach out for help. Here's one my last posts to Vincent. It has some instructions on how I got the correct driver working with the passed through sound card in the Windows 10 vm: https://bugzilla.kernel.org/show_bug.cgi?id=208555#c301 Of course those driver instructions are for my Intel based 2020 Legion 7. You may have different paths and you may need to try several different drivers in the archive before one works. In my case, it was the very last driver that ended up working for me. A heads up that I'm going to have poor availability this weekend. I'll be able to still to respond to emails at least, but my responses will be slower and less frequent. On 6/25/21 8:04 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #316 from Pablitar (pablitar@gmail.com) --- > I'll see if I have the time. And if I can hahaha. > > Is there a clear list of instructions in this thread? I'm lost in all the > messages. > > I can read the thread trying to compile what to do. But if someone could > point > me where to look, maybe that can save me an hour or two. > > (In reply to Cameron Berkenpas from comment #315) >> That is a resounding yes! Unsurprisingly for AMD, PCI passthrough is >> available. >> >> Is there anyone with a Legion 7 16ACHg6 who's up to setting up pci >> passthrough for their sound card and compiling JCS's Qemu all to run a >> Windows 10 VM? Someone can either try to do that for themselves or wait >> for me and hope there's sufficient availability. >> >> On 6/25/2021 7:45 PM, bugzilla-daemon@bugzilla.kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #314 from Pablitar (pablitar@gmail.com) --- >>> Here it is: >>> [ 0.293604] iommu: Default domain type: Translated >>> [ 0.487357] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters >> supported >>> [ 0.487484] pci 0000:00:01.0: Adding to iommu group 0 >>> [ 0.487493] pci 0000:00:01.1: Adding to iommu group 1 >>> [ 0.487500] pci 0000:00:01.2: Adding to iommu group 2 >>> [ 0.487511] pci 0000:00:02.0: Adding to iommu group 3 >>> [ 0.487518] pci 0000:00:02.1: Adding to iommu group 4 >>> [ 0.487526] pci 0000:00:02.2: Adding to iommu group 5 >>> [ 0.487538] pci 0000:00:08.0: Adding to iommu group 6 >>> [ 0.487544] pci 0000:00:08.1: Adding to iommu group 6 >>> [ 0.487550] pci 0000:00:08.2: Adding to iommu group 6 >>> [ 0.487560] pci 0000:00:14.0: Adding to iommu group 7 >>> [ 0.487566] pci 0000:00:14.3: Adding to iommu group 7 >>> [ 0.487587] pci 0000:00:18.0: Adding to iommu group 8 >>> [ 0.487593] pci 0000:00:18.1: Adding to iommu group 8 >>> [ 0.487599] pci 0000:00:18.2: Adding to iommu group 8 >>> [ 0.487606] pci 0000:00:18.3: Adding to iommu group 8 >>> [ 0.487612] pci 0000:00:18.4: Adding to iommu group 8 >>> [ 0.487618] pci 0000:00:18.5: Adding to iommu group 8 >>> [ 0.487624] pci 0000:00:18.6: Adding to iommu group 8 >>> [ 0.487629] pci 0000:00:18.7: Adding to iommu group 8 >>> [ 0.487640] pci 0000:01:00.0: Adding to iommu group 9 >>> [ 0.487648] pci 0000:01:00.1: Adding to iommu group 9 >>> [ 0.487656] pci 0000:02:00.0: Adding to iommu group 10 >>> [ 0.487664] pci 0000:03:00.0: Adding to iommu group 11 >>> [ 0.487671] pci 0000:04:00.0: Adding to iommu group 12 >>> [ 0.487685] pci 0000:05:00.0: Adding to iommu group 6 >>> [ 0.487688] pci 0000:05:00.2: Adding to iommu group 6 >>> [ 0.487693] pci 0000:05:00.3: Adding to iommu group 6 >>> [ 0.487696] pci 0000:05:00.4: Adding to iommu group 6 >>> [ 0.487700] pci 0000:05:00.6: Adding to iommu group 6 >>> [ 0.487703] pci 0000:06:00.0: Adding to iommu group 6 >>> [ 0.487707] pci 0000:06:00.1: Adding to iommu group 6 >>> [ 0.489073] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40 >>> [ 0.490935] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 >>> counters/bank). >>> [ 0.535396] AMD-Vi: AMD IOMMUv2 driver by Joerg Roedel <jroedel@suse.de> >>> >>> Seems it is supported? >>> >>> (In reply to Cameron Berkenpas from comment #312) >>>> Maybe try: >>>> >>>> dmesg | grep -i iommu >>>> >>>> On 6/25/2021 6:24 PM, Cameron Berkenpas wrote: >>>>> You're welcome. I understand the frustration! >>>>> >>>>> Can you or anyone else with a Legion 7 16ACHg6 check if your CPU has >>>>> IOMMU support? I'm not able to find an answer to this one way or >>>>> another. If so, likely the same trick can be used to find the codec >>>>> initialization verb sequence. >>>>> >>>>> >>>>> On 6/25/21 5:06 PM, bugzilla-daemon@bugzilla.kernel.org wrote: >>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>>>>> >>>>>> --- Comment #307 from Pablitar (pablitar@gmail.com) --- >>>>>> And thank you so much for what you are doing Cameron! >>>>>> >>>>>> (In reply to Cameron Berkenpas from comment #305) >>>>>>> You're not the first person to report that these fixes don't work for >>>>>>> the 2021 Legion. >>>>>>> >>>>>>> Can you post your alsa-info? >>>>>>> >>>>>>> I'd like to order one as soon as they become available here in the USA, >>>>>>> but I'm unsure what the availability will be. If I managed to snag one, >>>>>>> I'll work on getting sound working there too. >>>>>>> >>>>>>> On 6/25/21 4:52 PM, bugzilla-daemon@bugzilla.kernel.org wrote: >>>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>>>>>>> >>>>>>>> Pablitar (pablitar@gmail.com) changed: >>>>>>>> >>>>>>>> What |Removed |Added >>>>>>>> >> ---------------------------------------------------------------------------- >>>>>>>> CC| |pablitar@gmail.com >>>>>>>> >>>>>>>> --- Comment #304 from Pablitar (pablitar@gmail.com) --- >>>>>>>> Hey! >>>>>>>> >>>>>>>> I've tested some of these fixes on my Lenovo 16ACHg6 and had no luck. >>>>>>>> >>>>>>>> What I've tested: >>>>>>>> - Using the applyverbs.py with verbs-working.txt >>>>>>>> - Applying the legion-alc287-0.0.4.patch as per instructions >>>>>>>> - Applying the legion-alc287-0.0.5.patch as per instructions >>>>>>>> >>>>>>>> Something that may be important is that this new model is running >>>>>>>> an AMD >>>>>>>> processor and the sound controller appears as: >>>>>>>> >>>>>>>> 'Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models >>>>>>> 10h-1fh) >>>>>>>> HD Audio Controller' >>>>>>>> >>>>>>>> On Alsa Mixer, it says the "Chip" is ALC287 but the "Card" is HD-Audio >>>>>>>> Generic. >>>>>>>> >>>>>>>> Is that important? I'm bringing this up because the instructions say: >>>>>>>> >>>>>>>> # Patch file to enable output on speakers. >>>>>>>> options snd-hda-intel patch=legion-alc287-0.0.4.patch >>>>>>>> >>>>>>>> And the intel part there may be something to change? >>>>>>>> >>>>>>>> But honestly I'm clueless so this may be waaay off. >>>>>>>> >>>>>>>> Thanks in advance! >>>>>>>>
Finally I have also a running patch kernel for 5.11.0-22-lowlatency on my Ubuntu 20.04 Lenovo Yoga 7i. Could not use the diff file directly but copied parts of the diff code directly in the source.
(In reply to Cameron Berkenpas from comment #301) > Created attachment 297623 [details] > attachment-8392-0.html > > Yes, it's a known issue that the sound card is non-resettable. The > really good is is that this generally isn't a problem. > > If through your testing you start having problems, you might need to > stop/start the VM, and in some cases, fully shut down the machine. I did > tons of testing, and very rarely did I need to do anything more than > restart the VM. Only twice did I need to shut off the entire laptop. > > Anyway, getting Windows to use the right driver is a bit tricky, but it > can absolutely be done. I don't have the same machine, but looking at > your alsa-info, this should mostly work. > > I don't have the URL for your laptop, but here's the Lenovo version as > an example: > https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/legion- > series/legion-7-15imhg05/81yu/81yucto1ww/mp1t35d3/downloads/driver-list/ > > Find the equivalent part of the Lenovo site for your model and then > download your sound driver. > > When opening the driver, choose to extract the driver (it won't hurt if > you also install it). > > Anyway, here are the instructions I posted earlier in this bug: > > You need to force the device expanded above to use the RealTek driver. I was > able to force it by *extracting* rather than installing the sound driver > from the Lenovo site. Selecting update driver on the sound device listed > under "Sound, video and game controllers", and from there I did: > "Browse my computer for drivers" > "Let me pick from a list of available drivers on my computer" > "Have Disk" > Browse to: > C:\Drivers\Audio\201211706.15485923\Realtek\Codec_8975.1\HDXLVSST.inf > Press Ok > You should see "Realtek High Definition Audio(SST)" as an option. It's the > only option for me) > Next > Yes > Restart the VM when prompted > > Hopefully after these steps, you'll see the "Realtek High Definition > Audio(SST)" device in device manager as your sound card and you'll get > sound from windows. > > By getting a Win10 VM running with the JCS Qemu means you're a good > chunk of the way done. > > -Cameron > > PS: I looked into RtHDDump_V236 and I don't think it's anything I needed > for my particular case. It seems it can be used to figure out what pins > should be connected to what. We'll see if you need any of that, but not yet. > > On 6/25/21 12:31 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #299 from Vincent Morel (dantahoua@gmail.com) --- > > I tried to follow the information about installing Qemu > > > > > (https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver), > > but ran into problem and I'm not able to install the driver in windows (I > > have > > an error while starting qemu abut my soundcard address > > -> qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no > available > > reset mechanism. > > ). > > So sadly I'm not able to get the hda_verb output here... :( Would love to > > help > > but for today I'm done. Maybe will have time sunday to try something else. > > Is there a program I can run into a windows partition to sniff the hda? I'm > > almost sure I saw something but I cannot remember where... > > Pffff, tried everything. -I re-compiled the Qemu with the sme configure arguments as you -Then started the VM, try witth th 0000 in front of the audio adress (0000:00:1f.3 vs 00:1f.3), same. Always have qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no available reset mechanism. And I am not able to install the driver, I even went the "browse" way (where funily windows show you A:/ by default!)...The driver for my 13s gen2 ITL seems to be 9030. And yes befor e strating Qemu I did: sudo ./vfio-bind.sh 0000:00:1f.0 0000:00:1f.3 0000:00:1f.4 0000:00:1f.5 (My sundcard seems to have those other address added, do I have to pass them to qemu also?)...
> Pffff, tried everything. > -I re-compiled the Qemu with the sme configure arguments as you > -Then started the VM, try witth th 0000 in front of the audio adress > (0000:00:1f.3 vs 00:1f.3), same. > Always have qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no > available reset mechanism. > And I am not able to install the driver, I even went the "browse" way (where > funily windows show you A:/ by default!)...The driver for my 13s gen2 ITL > seems > to be 9030. > And yes befor e strating Qemu I did: > sudo ./vfio-bind.sh 0000:00:1f.0 0000:00:1f.3 0000:00:1f.4 0000:00:1f.5 > (My sundcard seems to have those other address added, do I have to pass them > to > qemu also?)... > > Can you share the output of this script on your system? https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Ensuring_that_the_groups_are_valid What is the command line your kernel is starting with? cat /proc/cmdline Do you know if you're seeing the sound card show up in device manager but as the incorrect device? Ignore the "Cannot reset device" message. It's likely not a problem for your sound card. I get the same message. The good news is that likely you are successfully passing the device to qemu, but the above will help me confirm that. Where did you download the driver from?
(In reply to Cameron Berkenpas from comment #320) > > Pffff, tried everything. > > -I re-compiled the Qemu with the sme configure arguments as you > > -Then started the VM, try witth th 0000 in front of the audio adress > > (0000:00:1f.3 vs 00:1f.3), same. > > Always have qemu-system-x86_64: vfio: Cannot reset device 0000:00:1f.3, no > > available reset mechanism. > > And I am not able to install the driver, I even went the "browse" way > (where > > funily windows show you A:/ by default!)...The driver for my 13s gen2 ITL > > seems > > to be 9030. > > And yes befor e strating Qemu I did: > > sudo ./vfio-bind.sh 0000:00:1f.0 0000:00:1f.3 0000:00:1f.4 0000:00:1f.5 > > (My sundcard seems to have those other address added, do I have to pass > them > > to > > qemu also?)... > > > > > > Can you share the output of this script on your system? > https://wiki.archlinux.org/title/ > PCI_passthrough_via_OVMF#Ensuring_that_the_groups_are_valid > > What is the command line your kernel is starting with? > cat /proc/cmdline > > Do you know if you're seeing the sound card show up in device manager > but as the incorrect device? > > Ignore the "Cannot reset device" message. It's likely not a problem for > your sound card. I get the same message. The good news is that likely > you are successfully passing the device to qemu, but the above will help > me confirm that. > > Where did you download the driver from? Yeah, here is the results: -Result from script: ./test.sh IOMMU Group 0: 00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers [8086:9a14] (rev 01) IOMMU Group 1: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics [8086:9a49] (rev 01) IOMMU Group 2: 00:04.0 Signal processing controller [1180]: Intel Corporation Device [8086:9a03] (rev 01) IOMMU Group 3: 00:06.0 PCI bridge [0604]: Intel Corporation 11th Gen Core Processor PCIe Controller [8086:9a09] (rev 01) IOMMU Group 4: 00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP Thunderbolt PCI Express Root Port #2 [8086:9a27] (rev 01) IOMMU Group 5: 00:08.0 System peripheral [0880]: Intel Corporation Device [8086:9a11] (rev 01) IOMMU Group 6: 00:0d.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP Thunderbolt USB Controller [8086:9a13] (rev 01) 00:0d.3 USB controller [0c03]: Intel Corporation Tiger Lake-LP Thunderbolt NHI #1 [8086:9a1d] (rev 01) IOMMU Group 7: 00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller [8086:a0ed] (rev 20) 00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-LP Shared SRAM [8086:a0ef] (rev 20) IOMMU Group 8: 00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 [8086:a0f0] (rev 20) IOMMU Group 9: 00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0 [8086:a0e8] (rev 20) IOMMU Group 10: 00:16.0 Communication controller [0780]: Intel Corporation Tiger Lake-LP Management Engine Interface [8086:a0e0] (rev 20) IOMMU Group 11: 00:1f.0 ISA bridge [0601]: Intel Corporation Tiger Lake-LP LPC Controller [8086:a082] (rev 20) 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20) 00:1f.4 SMBus [0c05]: Intel Corporation Tiger Lake-LP SMBus Controller [8086:a0a3] (rev 20) 00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP SPI Controller [8086:a0a4] (rev 20) IOMMU Group 12: 01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd Device [144d:a809] -cat /proc/cmdline initrd=\EFI\Pop_OS-b0da9465-3702-45ac-91d3-7ca24016e875\initrd.img root=UUID=b0da9465-3702-45ac-91d3-7ca24016e875 ro quiet loglevel=0 systemd.show_status=false splash pci-stub.ids=8086:a0c8 iommu=pt intel_iommu=on -The audio controller seems to appear in "Other devices->Multimedia Audio Controller" with the small sign on it telling me there is a problem (driver) with it. I checked other device to see if there is something odd but all other stuff seems legit in Device Manager... -Downloaded the driver from Lenovo website and double check it is the good one (there is so much similar name in Lenovo website...). 13S Gen2 ITL https://support.lenovo.com/us/en/downloads/ds546687-realtek-audio-driver-for-windows-10-64-bit-thinkbook-13s-g2-itl-thinkbook-14s-g2-itl
Things are not quite right. You do seem to have the right sound device picked out, but you need to pass all the devices. Here's your relevant IO group: IOMMU Group 11: 00:1f.0 ISA bridge [0601]: Intel Corporation Tiger Lake-LP LPC Controller [8086:a082] (rev 20) 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20) 00:1f.4 SMBus [0c05]: Intel Corporation Tiger Lake-LP SMBus Controller [8086:a0a3] (rev 20) 00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP SPI Controller [8086:a0a4] (rev 20) Your kernel command only lists your sound card. It should all of the devices in this group. For example, I have: vfio-pci.ids=8086:068d,8086:06c8,8086:06a3,8086:06a4 Yours needs to be: vfio-pci.ids=8086:a082,8086:a0c8,8086:a0a3,8086:a0a4 In my experimentation in getting this to work, I also did not set "iommu=pt". You might try removing that as well. > Yeah, here is the results: > > -Result from script: > ./test.sh > IOMMU Group 0: > 00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core > Processor > Host Bridge/DRAM Registers [8086:9a14] (rev 01) > IOMMU Group 1: > 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD > Graphics [8086:9a49] (rev 01) > IOMMU Group 2: > 00:04.0 Signal processing controller [1180]: Intel Corporation > Device > [8086:9a03] (rev 01) > IOMMU Group 3: > 00:06.0 PCI bridge [0604]: Intel Corporation 11th Gen Core Processor > PCIe Controller [8086:9a09] (rev 01) > IOMMU Group 4: > 00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP > Thunderbolt > PCI Express Root Port #2 [8086:9a27] (rev 01) > IOMMU Group 5: > 00:08.0 System peripheral [0880]: Intel Corporation Device > [8086:9a11] > (rev 01) > IOMMU Group 6: > 00:0d.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP > Thunderbolt USB Controller [8086:9a13] (rev 01) > 00:0d.3 USB controller [0c03]: Intel Corporation Tiger Lake-LP > Thunderbolt NHI #1 [8086:9a1d] (rev 01) > IOMMU Group 7: > 00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP USB > 3.2 > Gen 2x1 xHCI Host Controller [8086:a0ed] (rev 20) > 00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-LP Shared > SRAM > [8086:a0ef] (rev 20) > IOMMU Group 8: > 00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 > [8086:a0f0] (rev 20) > IOMMU Group 9: > 00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger > Lake-LP > Serial IO I2C Controller #0 [8086:a0e8] (rev 20) > IOMMU Group 10: > 00:16.0 Communication controller [0780]: Intel Corporation Tiger > Lake-LP Management Engine Interface [8086:a0e0] (rev 20) > IOMMU Group 11: > 00:1f.0 ISA bridge [0601]: Intel Corporation Tiger Lake-LP LPC > Controller [8086:a082] (rev 20) > 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Tiger > Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20) > 00:1f.4 SMBus [0c05]: Intel Corporation Tiger Lake-LP SMBus > Controller > [8086:a0a3] (rev 20) > 00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger > Lake-LP > SPI Controller [8086:a0a4] (rev 20) > IOMMU Group 12: > 01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics > Co > Ltd Device [144d:a809] > > -cat /proc/cmdline > initrd=\EFI\Pop_OS-b0da9465-3702-45ac-91d3-7ca24016e875\initrd.img > root=UUID=b0da9465-3702-45ac-91d3-7ca24016e875 ro quiet loglevel=0 > systemd.show_status=false splash pci-stub.ids=8086:a0c8 iommu=pt > intel_iommu=on > > -The audio controller seems to appear in "Other devices->Multimedia Audio > Controller" with the small sign on it telling me there is a problem (driver) > with it. I checked other device to see if there is something odd but all > other > stuff seems legit in Device Manager... > > -Downloaded the driver from Lenovo website and double check it is the good > one > (there is so much similar name in Lenovo website...). 13S Gen2 ITL > > https://support.lenovo.com/us/en/downloads/ds546687-realtek-audio-driver-for-windows-10-64-bit-thinkbook-13s-g2-itl-thinkbook-14s-g2-itl >
Hi all, Just jumping on to say that, like darnellkeithj@gmail.com, I have a Duet 7i. They seem to have gone quiet recently so I thought I'd pipe up after this flurry of activity with the verbs. Unfortunately applying the 'verbs-working.txt' using the python script has not worked for me. I'm now following the qemu guide to try to determine the verbs, so will report back when I have something.
Ok, updated the kernel param, now I have initrd=\EFI\Pop_OS-b0da9465-3702-45ac-91d3-7ca24016e875\initrd.img root=UUID=b0da9465-3702-45ac-91d3-7ca24016e875 ro quiet loglevel=0 systemd.show_status=false splash pci-stub.ids=8086:a082,8086:a0c8,8086:a0a3,8086:a0a4 intel_iommu=on Try with or without "iommu=pt" Still no luck, no hcnag ein the VM. Note that since I added those 3 more adress from the group to the param, my audio show only "dummy" output in control panel of Linux. My VM start command is: #!/bin/bash _qemu=/opt/qemu/jcs/bin/qemu-system-x86_64 sudo qemu-system-x86_64 -L ~/windows_vm/qemu/pc-bios -enable-kvm -hda win10.img -m 4G -smp 4 -vga std -device vfio-pci,host=0000:00:1f.3,multifunction=on,x-no-mmap=true -trace events=./events.txt -monitor stdio (In reply to Cameron Berkenpas from comment #322) > Things are not quite right. You do seem to have the right sound device > picked out, but you need to pass all the devices. > > Here's your relevant IO group: > IOMMU Group 11: > 00:1f.0 ISA bridge [0601]: Intel Corporation Tiger Lake-LP LPC > Controller [8086:a082] (rev 20) > 00:1f.3 Multimedia audio controller [0401]: Intel Corporation > Tiger Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20) > 00:1f.4 SMBus [0c05]: Intel Corporation Tiger Lake-LP SMBus > Controller [8086:a0a3] (rev 20) > 00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger > Lake-LP SPI Controller [8086:a0a4] (rev 20) > > Your kernel command only lists your sound card. It should all of the > devices in this group. > > For example, I have: > vfio-pci.ids=8086:068d,8086:06c8,8086:06a3,8086:06a4 > > Yours needs to be: > vfio-pci.ids=8086:a082,8086:a0c8,8086:a0a3,8086:a0a4 > > In my experimentation in getting this to work, I also did not set > "iommu=pt". You might try removing that as well. > > > Yeah, here is the results: > > > > -Result from script: > > ./test.sh > > IOMMU Group 0: > > 00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core > > Processor > > Host Bridge/DRAM Registers [8086:9a14] (rev 01) > > IOMMU Group 1: > > 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD > > Graphics [8086:9a49] (rev 01) > > IOMMU Group 2: > > 00:04.0 Signal processing controller [1180]: Intel Corporation > > Device > > [8086:9a03] (rev 01) > > IOMMU Group 3: > > 00:06.0 PCI bridge [0604]: Intel Corporation 11th Gen Core > Processor > > PCIe Controller [8086:9a09] (rev 01) > > IOMMU Group 4: > > 00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP > > Thunderbolt > > PCI Express Root Port #2 [8086:9a27] (rev 01) > > IOMMU Group 5: > > 00:08.0 System peripheral [0880]: Intel Corporation Device > > [8086:9a11] > > (rev 01) > > IOMMU Group 6: > > 00:0d.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP > > Thunderbolt USB Controller [8086:9a13] (rev 01) > > 00:0d.3 USB controller [0c03]: Intel Corporation Tiger Lake-LP > > Thunderbolt NHI #1 [8086:9a1d] (rev 01) > > IOMMU Group 7: > > 00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP USB > > 3.2 > > Gen 2x1 xHCI Host Controller [8086:a0ed] (rev 20) > > 00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-LP Shared > > SRAM > > [8086:a0ef] (rev 20) > > IOMMU Group 8: > > 00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 > > [8086:a0f0] (rev 20) > > IOMMU Group 9: > > 00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger > > Lake-LP > > Serial IO I2C Controller #0 [8086:a0e8] (rev 20) > > IOMMU Group 10: > > 00:16.0 Communication controller [0780]: Intel Corporation Tiger > > Lake-LP Management Engine Interface [8086:a0e0] (rev 20) > > IOMMU Group 11: > > 00:1f.0 ISA bridge [0601]: Intel Corporation Tiger Lake-LP LPC > > Controller [8086:a082] (rev 20) > > 00:1f.3 Multimedia audio controller [0401]: Intel Corporation > Tiger > > Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20) > > 00:1f.4 SMBus [0c05]: Intel Corporation Tiger Lake-LP SMBus > > Controller > > [8086:a0a3] (rev 20) > > 00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger > > Lake-LP > > SPI Controller [8086:a0a4] (rev 20) > > IOMMU Group 12: > > 01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics > > Co > > Ltd Device [144d:a809] > > > > -cat /proc/cmdline > > initrd=\EFI\Pop_OS-b0da9465-3702-45ac-91d3-7ca24016e875\initrd.img > > root=UUID=b0da9465-3702-45ac-91d3-7ca24016e875 ro quiet loglevel=0 > > systemd.show_status=false splash pci-stub.ids=8086:a0c8 iommu=pt > > intel_iommu=on > > > > -The audio controller seems to appear in "Other devices->Multimedia Audio > > Controller" with the small sign on it telling me there is a problem > (driver) > > with it. I checked other device to see if there is something odd but all > > other > > stuff seems legit in Device Manager... > > > > -Downloaded the driver from Lenovo website and double check it is the good > > one > > (there is so much similar name in Lenovo website...). 13S Gen2 ITL > > > > > https://support.lenovo.com/us/en/downloads/ds546687-realtek-audio-driver-for-windows-10-64-bit-thinkbook-13s-g2-itl-thinkbook-14s-g2-itl > >
bugzilla-daemon@bugzilla.kernel.org to BCC so we can avoid spamming with trouble shooting. When we resolve this, we can share our findings. (also check your spam folder for messages directly from me). Linux should only have the dummy device as device is no longer available to the host OS. That's good! What do you see under system devices? http://vasteel.neo-zeon.de/~hiryu/287/win10-vm.png Anything relating to sound like mine? On 6/26/21 9:46 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #324 from Vincent Morel (dantahoua@gmail.com) --- > Ok, > updated the kernel param, now I have > initrd=\EFI\Pop_OS-b0da9465-3702-45ac-91d3-7ca24016e875\initrd.img > root=UUID=b0da9465-3702-45ac-91d3-7ca24016e875 ro quiet loglevel=0 > systemd.show_status=false splash > pci-stub.ids=8086:a082,8086:a0c8,8086:a0a3,8086:a0a4 intel_iommu=on > > Try with or without "iommu=pt" > > Still no luck, no hcnag ein the VM. > Note that since I added those 3 more adress from the group to the param, my > audio show only "dummy" output in control panel of Linux. > > My VM start command is: > #!/bin/bash > > _qemu=/opt/qemu/jcs/bin/qemu-system-x86_64 > > sudo qemu-system-x86_64 -L ~/windows_vm/qemu/pc-bios -enable-kvm -hda > win10.img > -m 4G -smp 4 -vga std -device > vfio-pci,host=0000:00:1f.3,multifunction=on,x-no-mmap=true -trace > events=./events.txt -monitor stdio > > (In reply to Cameron Berkenpas from comment #322) >> Things are not quite right. You do seem to have the right sound device >> picked out, but you need to pass all the devices. >> >> Here's your relevant IO group: >> IOMMU Group 11: >> 00:1f.0 ISA bridge [0601]: Intel Corporation Tiger Lake-LP LPC >> Controller [8086:a082] (rev 20) >> 00:1f.3 Multimedia audio controller [0401]: Intel Corporation >> Tiger Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20) >> 00:1f.4 SMBus [0c05]: Intel Corporation Tiger Lake-LP SMBus >> Controller [8086:a0a3] (rev 20) >> 00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger >> Lake-LP SPI Controller [8086:a0a4] (rev 20) >> >> Your kernel command only lists your sound card. It should all of the >> devices in this group. >> >> For example, I have: >> vfio-pci.ids=8086:068d,8086:06c8,8086:06a3,8086:06a4 >> >> Yours needs to be: >> vfio-pci.ids=8086:a082,8086:a0c8,8086:a0a3,8086:a0a4 >> >> In my experimentation in getting this to work, I also did not set >> "iommu=pt". You might try removing that as well. >> >>> Yeah, here is the results: >>> >>> -Result from script: >>> ./test.sh >>> IOMMU Group 0: >>> 00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core >>> Processor >>> Host Bridge/DRAM Registers [8086:9a14] (rev 01) >>> IOMMU Group 1: >>> 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD >>> Graphics [8086:9a49] (rev 01) >>> IOMMU Group 2: >>> 00:04.0 Signal processing controller [1180]: Intel Corporation >>> Device >>> [8086:9a03] (rev 01) >>> IOMMU Group 3: >>> 00:06.0 PCI bridge [0604]: Intel Corporation 11th Gen Core >> Processor >>> PCIe Controller [8086:9a09] (rev 01) >>> IOMMU Group 4: >>> 00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP >>> Thunderbolt >>> PCI Express Root Port #2 [8086:9a27] (rev 01) >>> IOMMU Group 5: >>> 00:08.0 System peripheral [0880]: Intel Corporation Device >>> [8086:9a11] >>> (rev 01) >>> IOMMU Group 6: >>> 00:0d.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP >>> Thunderbolt USB Controller [8086:9a13] (rev 01) >>> 00:0d.3 USB controller [0c03]: Intel Corporation Tiger Lake-LP >>> Thunderbolt NHI #1 [8086:9a1d] (rev 01) >>> IOMMU Group 7: >>> 00:14.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP >>> USB >>> 3.2 >>> Gen 2x1 xHCI Host Controller [8086:a0ed] (rev 20) >>> 00:14.2 RAM memory [0500]: Intel Corporation Tiger Lake-LP Shared >>> SRAM >>> [8086:a0ef] (rev 20) >>> IOMMU Group 8: >>> 00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 >>> AX201 >>> [8086:a0f0] (rev 20) >>> IOMMU Group 9: >>> 00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger >>> Lake-LP >>> Serial IO I2C Controller #0 [8086:a0e8] (rev 20) >>> IOMMU Group 10: >>> 00:16.0 Communication controller [0780]: Intel Corporation Tiger >>> Lake-LP Management Engine Interface [8086:a0e0] (rev 20) >>> IOMMU Group 11: >>> 00:1f.0 ISA bridge [0601]: Intel Corporation Tiger Lake-LP LPC >>> Controller [8086:a082] (rev 20) >>> 00:1f.3 Multimedia audio controller [0401]: Intel Corporation >> Tiger >>> Lake-LP Smart Sound Technology Audio Controller [8086:a0c8] (rev 20) >>> 00:1f.4 SMBus [0c05]: Intel Corporation Tiger Lake-LP SMBus >>> Controller >>> [8086:a0a3] (rev 20) >>> 00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger >>> Lake-LP >>> SPI Controller [8086:a0a4] (rev 20) >>> IOMMU Group 12: >>> 01:00.0 Non-Volatile memory controller [0108]: Samsung >>> Electronics >>> Co >>> Ltd Device [144d:a809] >>> >>> -cat /proc/cmdline >>> initrd=\EFI\Pop_OS-b0da9465-3702-45ac-91d3-7ca24016e875\initrd.img >>> root=UUID=b0da9465-3702-45ac-91d3-7ca24016e875 ro quiet loglevel=0 >>> systemd.show_status=false splash pci-stub.ids=8086:a0c8 iommu=pt >>> intel_iommu=on >>> >>> -The audio controller seems to appear in "Other devices->Multimedia Audio >>> Controller" with the small sign on it telling me there is a problem >> (driver) >>> with it. I checked other device to see if there is something odd but all >>> other >>> stuff seems legit in Device Manager... >>> >>> -Downloaded the driver from Lenovo website and double check it is the good >>> one >>> (there is so much similar name in Lenovo website...). 13S Gen2 ITL >>> >>> >> >> https://support.lenovo.com/us/en/downloads/ds546687-realtek-audio-driver-for-windows-10-64-bit-thinkbook-13s-g2-itl-thinkbook-14s-g2-itl
I have created the repo https://github.com/thiagotei/linux-realtek-alc287 to try to consolidate information posted here. Any help is welcome to fill the gaps.
Created attachment 297647 [details] linux-5.12-legion-sound-0.0.6.patch - Early Gen2 support No Legion changes. For the Yoga 7, automute_speaker is no longer disabled. This is needed for the Legion, but not for the Gen2. I want to see if it's needed for the Yoga 7. Early Gen2 support. Confirmed working for Vince Morel who is also working on getting those verbs trimmed down. :) Yoga 7 users, PLEASE test and see if you still have speaker output after unplugging headphones while playing sound.
Created attachment 297649 [details] trimed-verbs-Lenovo-13s-gen2-itl.txt For the 0.0.6 patch, support was specifically added for the 13s Gen2 ITL. I Should have been more clear. Anyhow, these are the verbs from Vince Morel. Thank you for expending the time and effort to setup PCI passthrough, build/run JCS Qemu, and fight with Windows to get the correct sound drivers working! Perhaps some other 13s Gen2 users are out there who can take some time to look at these verbs and help narrow them down to what's needed.
Created attachment 297653 [details] Legion 7 2021 16ACHg6 - linux codec dump
Created attachment 297655 [details] Legion 7 2021 16ACHg6 - windows speakers on dump
Created attachment 297657 [details] Legion 7 2021 16ACHg6 - windows headphones on dump
Still working on the Legion 7 2021 16ACHg6 here... I've been fiddling around but no luck getting the speakers working. Add some windows dumps if that helps anyone!
Created attachment 297663 [details] attachment-15688-0.html I tried applying the new linux-5.12-legion-sound-0.0.6 patch to the Yoga 7 to no avail. I do not have speaker output after unplugging headphones. The S3 patch still works. On Tue, Jun 29 2021 at 03:58:51 AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D208555&data=04%7C01%7C%7C91bf8eb61d9f490f266d08d93ab236a8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637605359353072439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kzmyxY2jimcuGL2CpuyoEhiAH4BEXown7FX2A6oYevI%3D&reserved=0> > > --- Comment #328 from Cameron Berkenpas (cam@neo-zeon.de > <mailto:cam@neo-zeon.de>) --- > Created attachment 297649 [details] > --> > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fattachment.cgi%3Fid%3D297649%26action%3Dedit&data=04%7C01%7C%7C91bf8eb61d9f490f266d08d93ab236a8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637605359353072439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TMAYUU8eHgFrbut3M7kvsfZGleXkZwVt8aMGtJ4Am%2Fw%3D&reserved=0> > trimed-verbs-Lenovo-13s-gen2-itl.txt > > For the 0.0.6 patch, support was specifically added for the 13s Gen2 > ITL. I > Should have been more clear. > > Anyhow, these are the verbs from Vince Morel. Thank you for expending > the time > and effort to setup PCI passthrough, build/run JCS Qemu, and fight > with Windows > to get the correct sound drivers working! > > Perhaps some other 13s Gen2 users are out there who can take some > time to look > at these verbs and help narrow them down to what's needed. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
Do you have speaker output before plugging in the headphones? On 6/29/21 7:06 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #333 from Dre (dreman_74@hotmail.com) --- > I tried applying the new linux-5.12-legion-sound-0.0.6 patch to the > Yoga 7 to no avail. I do not have speaker output after unplugging > headphones. The S3 patch still works. > > On Tue, Jun 29 2021 at 03:58:51 AM +0000, > bugzilla-daemon@bugzilla.kernel.org wrote: >> >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D208555&data=04%7C01%7C%7C91bf8eb61d9f490f266d08d93ab236a8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637605359353072439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kzmyxY2jimcuGL2CpuyoEhiAH4BEXown7FX2A6oYevI%3D&reserved=0> >> >> --- Comment #328 from Cameron Berkenpas (cam@neo-zeon.de >> <mailto:cam@neo-zeon.de>) --- >> Created attachment 297649 [details] >> --> >> >> >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fattachment.cgi%3Fid%3D297649%26action%3Dedit&data=04%7C01%7C%7C91bf8eb61d9f490f266d08d93ab236a8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637605359353072439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TMAYUU8eHgFrbut3M7kvsfZGleXkZwVt8aMGtJ4Am%2Fw%3D&reserved=0> >> trimed-verbs-Lenovo-13s-gen2-itl.txt >> >> For the 0.0.6 patch, support was specifically added for the 13s Gen2 >> ITL. I >> Should have been more clear. >> >> Anyhow, these are the verbs from Vince Morel. Thank you for expending >> the time >> and effort to setup PCI passthrough, build/run JCS Qemu, and fight >> with Windows >> to get the correct sound drivers working! >> >> Perhaps some other 13s Gen2 users are out there who can take some >> time to look >> at these verbs and help narrow them down to what's needed. >> >> -- >> You may reply to this email to add a comment. >> >> You are receiving this mail because: >> You are on the CC list for the bug.
Created attachment 297665 [details] attachment-29004-0.html No. No speaker output before plugging in the headphones. On Tue, Jun 29 2021 at 02:55:31 PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D208555&data=04%7C01%7C%7C990380a15b07471c7ccd08d93b0df2f5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637605753360253482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7GaO8l8lbTHc05Til3ULLE86Px%2Bk6%2BLQPuPJ2W6XnHg%3D&reserved=0> > > --- Comment #334 from Cameron Berkenpas (cam@neo-zeon.de > <mailto:cam@neo-zeon.de>) --- > Do you have speaker output before plugging in the headphones? > >
Does the previous patch work? What is your alsa-info? On 6/29/21 12:05 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #335 from Dre (dreman_74@hotmail.com) --- > No. No speaker output before plugging in the headphones. > > On Tue, Jun 29 2021 at 02:55:31 PM +0000, > bugzilla-daemon@bugzilla.kernel.org wrote: >> >> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D208555&data=04%7C01%7C%7C990380a15b07471c7ccd08d93b0df2f5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637605753360253482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7GaO8l8lbTHc05Til3ULLE86Px%2Bk6%2BLQPuPJ2W6XnHg%3D&reserved=0> >> >> --- Comment #334 from Cameron Berkenpas (cam@neo-zeon.de >> <mailto:cam@neo-zeon.de>) --- >> Do you have speaker output before plugging in the headphones? >> >>
Created attachment 297667 [details] alsa-info-dre-yoga7 No, the previous patch does not work. I've attached my alsa-info. On Tue, Jun 29 2021 at 07:13:27 PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D208555&data=04%7C01%7C%7Caf7926ab79dc4e93b2e908d93b31fad0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637605908106844226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rhqPCITAXYnkb4iouBoGUDcTtMNSFFZgbmyVw8pShJU%3D&reserved=0> > > --- Comment #336 from Cameron Berkenpas (cam@neo-zeon.de > <mailto:cam@neo-zeon.de>) --- > Does the previous patch work? > > What is your alsa-info? >
(In reply to Dre from comment #335) > Created attachment 297665 [details] > attachment-29004-0.html > > No. No speaker output before plugging in the headphones. > On my Yoga the patch works also after headphones in/out. Are you sure your new module is installed correctly? Maybe place a > printk(KERN_ALERT "ALS287 PATCH\n"); inside the alc287_fixup_legion_yoga7_speakers function and check afterwards via dmesg.
Created attachment 297677 [details] linux-5.12-legion-sound-0.0.7.patch Now that it's time to start moving away from just trying to get things working to having something that might actually be accepted into kernel, I'm changing how we're handling the verbs. In order to (hopefully) follow convention, I'm using the HDA_FIXUP_VERBS method to pass the verbs instead of manually calling a function to send them. 2020 Legion, 13s Gen2, and Yoga 7 are still the only supported models. I don't expect any issues, but please report any that come up. In other news, I'm working on some documentation for the linux-realtek-alc287 GitHub project that I will hopefully have completed by this week so that others can try to reproduce this process and get sound out of their laptops. Thank you, Thiago!
(In reply to woody64 from comment #338) > (In reply to Dre from comment #335) > > Created attachment 297665 [details] > > attachment-29004-0.html > > > > No. No speaker output before plugging in the headphones. > > > > On my Yoga the patch works also after headphones in/out. > > Are you sure your new module is installed correctly? > > Maybe place a > > > printk(KERN_ALERT "ALS287 PATCH\n"); > > inside the alc287_fixup_legion_yoga7_speakers function and check afterwards > via > dmesg. Perhaps it is not installed correctly. How are you applying the patch?
cd linux-5.12.14/ patch -p1 < /path/to/file.patch On 6/30/21 4:41 PM, bugzilla-daemon@bugzilla.kernel.org wrote:Perhaps it is not installed correctly. How are you applying the patch?
Hi, I am using Fedora35 rawhide, with latest kernel post update: ~~~ gkadam ~ uname --all Linux tesla 5.13.0-0.rc6.45.fc35.x86_64 #1 SMP Mon Jun 14 13:44:07 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux ~~~ I am also not able to hear sound post update. Here is the issue: ~~~ systemctl status alsa-state.service ● alsa-state.service - Manage Sound Card State (restore and store) Loaded: loaded (/usr/lib/systemd/system/alsa-state.service; static) Active: active (running) since Fri 2021-07-02 18:37:11 IST; 13min ago Main PID: 1349 (alsactl) Tasks: 1 (limit: 23786) Memory: 404.0K CPU: 13ms CGroup: /system.slice/alsa-state.service └─1349 /usr/sbin/alsactl -s -n 19 -c -E ALSA_CONFIG_PATH=/etc/alsa/alsactl.conf --initfile=/lib/alsa/init/00main rdaemon Jul 02 18:37:11 tesla systemd[1]: Started Manage Sound Card State (restore and store). Jul 02 18:37:11 tesla alsactl[1349]: alsactl 1.2.5.1 daemon started Jul 02 18:37:11 tesla alsactl[1349]: alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HDA Intel PCH at 0xf1240000 irq 131) Jul 02 18:37:11 tesla alsactl[1349]: alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -6 Jul 02 18:37:11 tesla alsactl[1349]: alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:1 use case configuration -2 ~~~ My sound card is not working properly after updating the system to the latest version. Any pointers/suggestions are appreciated. Br, Ganesh Kadam
Created attachment 297691 [details] attachment-10777-0.html I am on Holiday and will be returning on July 06 2021
> > > My sound card is not working properly after updating the system to the > latest version. > > Any pointers/suggestions are appreciated. Ganesh, Thank you for your feedback. Can you share your alsa-info? When you say post update, do you mean applying the latest patch attached to this bug report or are you referring to the latest kernel update for Fedora Rawhide?
(In reply to Cameron Berkenpas from comment #339) > Created attachment 297677 [details] > linux-5.12-legion-sound-0.0.7.patch > > Now that it's time to start moving away from just trying to get things > working to having something that might actually be accepted into kernel, I'm > changing how we're handling the verbs. In order to (hopefully) follow > convention, I'm using the HDA_FIXUP_VERBS method to pass the verbs instead > of manually calling a function to send them. > > 2020 Legion, 13s Gen2, and Yoga 7 are still the only supported models. I > don't expect any issues, but please report any that come up. > > In other news, I'm working on some documentation for the > linux-realtek-alc287 GitHub project that I will hopefully have completed by > this week so that others can try to reproduce this process and get sound out > of their laptops. Thank you, Thiago! 13s Gen2 here, I'm trying to apply this patch with this command: patch -p1 < linux-5.12-legion-sound-0.0.7.patch and getting this error : patching file sound/pci/hda/legion_15imhg05_speakers.c can't find file to patch at input line 506 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c |index e46e43dac6bf..d9fa4e4ceb5b 100644 |--- a/sound/pci/hda/patch_realtek.c |+++ b/sound/pci/hda/patch_realtek.c -------------------------- File to patch: Skip this patch? [y] n File to patch: Skip this patch? [y] Skipping patch. 4 out of 4 hunks ignored
What directory/folder are you running this command in? On 7/2/21 1:35 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > waterproof93@outlook.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |waterproof93@outlook.com > > --- Comment #345 from waterproof93@outlook.com --- > (In reply to Cameron Berkenpas from comment #339) >> Created attachment 297677 [details] >> linux-5.12-legion-sound-0.0.7.patch >> >> Now that it's time to start moving away from just trying to get things >> working to having something that might actually be accepted into kernel, I'm >> changing how we're handling the verbs. In order to (hopefully) follow >> convention, I'm using the HDA_FIXUP_VERBS method to pass the verbs instead >> of manually calling a function to send them. >> >> 2020 Legion, 13s Gen2, and Yoga 7 are still the only supported models. I >> don't expect any issues, but please report any that come up. >> >> In other news, I'm working on some documentation for the >> linux-realtek-alc287 GitHub project that I will hopefully have completed by >> this week so that others can try to reproduce this process and get sound out >> of their laptops. Thank you, Thiago! > 13s Gen2 here, I'm trying to apply this patch with this command: > > patch -p1 < linux-5.12-legion-sound-0.0.7.patch > > and getting this error : > > patching file sound/pci/hda/legion_15imhg05_speakers.c > can't find file to patch at input line 506 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -------------------------- > |diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > |index e46e43dac6bf..d9fa4e4ceb5b 100644 > |--- a/sound/pci/hda/patch_realtek.c > |+++ b/sound/pci/hda/patch_realtek.c > -------------------------- > File to patch: > Skip this patch? [y] n > File to patch: > Skip this patch? [y] > Skipping patch. > 4 out of 4 hunks ignored >
(In reply to Cameron Berkenpas from comment #346) > What directory/folder are you running this command in? > > On 7/2/21 1:35 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > waterproof93@outlook.com changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > CC| |waterproof93@outlook.com > > > > --- Comment #345 from waterproof93@outlook.com --- > > (In reply to Cameron Berkenpas from comment #339) > >> Created attachment 297677 [details] > >> linux-5.12-legion-sound-0.0.7.patch > >> > >> Now that it's time to start moving away from just trying to get things > >> working to having something that might actually be accepted into kernel, > I'm > >> changing how we're handling the verbs. In order to (hopefully) follow > >> convention, I'm using the HDA_FIXUP_VERBS method to pass the verbs instead > >> of manually calling a function to send them. > >> > >> 2020 Legion, 13s Gen2, and Yoga 7 are still the only supported models. I > >> don't expect any issues, but please report any that come up. > >> > >> In other news, I'm working on some documentation for the > >> linux-realtek-alc287 GitHub project that I will hopefully have completed > by > >> this week so that others can try to reproduce this process and get sound > out > >> of their laptops. Thank you, Thiago! > > 13s Gen2 here, I'm trying to apply this patch with this command: > > > > patch -p1 < linux-5.12-legion-sound-0.0.7.patch > > > > and getting this error : > > > > patching file sound/pci/hda/legion_15imhg05_speakers.c > > can't find file to patch at input line 506 > > Perhaps you used the wrong -p or --strip option? > > The text leading up to this was: > > -------------------------- > > |diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > > |index e46e43dac6bf..d9fa4e4ceb5b 100644 > > |--- a/sound/pci/hda/patch_realtek.c > > |+++ b/sound/pci/hda/patch_realtek.c > > -------------------------- > > File to patch: > > Skip this patch? [y] n > > File to patch: > > Skip this patch? [y] > > Skipping patch. > > 4 out of 4 hunks ignored > > right... probably the wrong one ! (~/Downloads) Kindly, how do I run this command ?
> right... probably the wrong one ! (~/Downloads) > Kindly, how do I run this command ? > This is a patch to be applied against the source of a 5.12.x kernel. You would then need to compile, install, and boot to this kernel. There are likely instructions on the net to help you do this with your distribution. However, if this is something you're not comfortable with, I'd suggest waiting these fixes to eventually make it into the kernel. In the meantime, there is a temporary work around with applying the verbs (you'd want the vebs for your model of laptop). There are caveats with the "applying the verbs" method that are discussed in the bug.
Hi Cameron, (In reply to Cameron Berkenpas from comment #344) > > > > > > My sound card is not working properly after updating the system to the > > latest version. > > > > Any pointers/suggestions are appreciated. > > Ganesh, > > Thank you for your feedback. Can you share your alsa-info? > > When you say post update, do you mean applying the latest patch attached to > this bug report or are you referring to the latest kernel update for Fedora > Rawhide? I just performed, a regular system update, using dnf update command, and after all the packages were installed, I reboot the system, since then my sound cards are not being detected. Here is the alsa-info: ~~~ http://alsa-project.org/db/?f=06e581149a25224e881b43b0b72f6439d13cde3a ~~~ BR, Ganesh Kadam
Your laptop has an ALC293 and was originally working. This bug is for Lenovo laptops with ALC287's whose sound never worked, and therefore these issues are unrelated. Sounds like you need to file a bug report with Fedora. On 7/3/21 6:39 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #349 from Ganesh Kadam (meganeshkadam@gmail.com) --- > Hi Cameron, > > (In reply to Cameron Berkenpas from comment #344) >>> >>> My sound card is not working properly after updating the system to the >>> latest version. >>> >>> Any pointers/suggestions are appreciated. >> Ganesh, >> >> Thank you for your feedback. Can you share your alsa-info? >> >> When you say post update, do you mean applying the latest patch attached to >> this bug report or are you referring to the latest kernel update for Fedora >> Rawhide? > I just performed, a regular system update, using dnf update command, and > after > all the packages were installed, I reboot the system, since then my sound > cards > are not being detected. > > Here is the alsa-info: > ~~~ > http://alsa-project.org/db/?f=06e581149a25224e881b43b0b72f6439d13cde3a > ~~~ > > BR, > Ganesh Kadam >
(In reply to Roland from comment #259) > (In reply to DavidLenovo from comment #257) > > > You sure it is the ALC287 ? > > No, I'm not, although the problem sounds quote similar. This may be a > coincidence, but I'll keep an eye on this issue. David, it's the ACL711. I didn't find any bug reports regarding this chipset, nevertheless I assume that the problem might be similar to the ACL287 reported here, since the symptoms are the same. Sadly, the verbs from this report don't work for me, so they might be different to the ACL711. I fear I have to patch qemu and try to find working verbs for my system on my own :-(
> This is a patch to be applied against the source of a 5.12.x kernel. You > would then need to compile, install, and boot to this kernel. > > There are likely instructions on the net to help you do this with your > distribution. However, if this is something you're not comfortable with, > I'd suggest waiting these fixes to eventually make it into the kernel. > > In the meantime, there is a temporary work around with applying the > verbs (you'd want the vebs for your model of laptop). There are caveats > with the "applying the verbs" method that are discussed in the bug. Thank you for those instructions. I was able to get the sound working on my 13s gen2 ! I'm using Fedora 34 and applied the patch to kernel 5.12.14. I'm finding the sound quality to not be as good as it is on windows oem install. Also the volume controls are overshooting which makes it hard to control. Are there any improvements that can be made ? The sound cuts off before reaching the lowest volume on the volume control. Is there a way to adjust the scale ?
The 13s verbs aren't in a good state and are in no condition to attempt any sort of inclusion into the kernel IMO. You're going to have to experiment with applying the 13s verbs in debug mode. Look for sycxyc's posts for some potential insights into this. As far as the quality, this may be due to the verbs needing to be cleaned up, the more advanced audio features of your laptop not being supported by Linux, or some combination of both. For example, in the case of the 2020 Legion, I've found that audio quality between Linux and Windows is about equal if you disable Dolby audio in Windows. Dolby isn't supported Linux AFAIK at this time. On 7/4/21 7:19 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #352 from waterproof93@outlook.com --- >> This is a patch to be applied against the source of a 5.12.x kernel. You >> would then need to compile, install, and boot to this kernel. >> >> There are likely instructions on the net to help you do this with your >> distribution. However, if this is something you're not comfortable with, >> I'd suggest waiting these fixes to eventually make it into the kernel. >> >> In the meantime, there is a temporary work around with applying the >> verbs (you'd want the vebs for your model of laptop). There are caveats >> with the "applying the verbs" method that are discussed in the bug. > Thank you for those instructions. > I was able to get the sound working on my 13s gen2 ! I'm using Fedora 34 and > applied the patch to kernel 5.12.14. > > I'm finding the sound quality to not be as good as it is on windows oem > install. > Also the volume controls are overshooting which makes it hard to control. > Are there any improvements that can be made ? > > The sound cuts off before reaching the lowest volume on the volume control. > Is > there a way to adjust the scale ? >
(In reply to Roland from comment #351) I've failed to get the sound card running in the windows guest and created a separate report for the ACL711 in bug #213641
It can be a lot of effort figuring out how to force Windows to use the correct drivers for the device. Unfortunately at this stage, there is no fixed set of steps since it seems to at least partially vary between laptop models. On 7/4/21 8:45 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #354 from Roland (kernel@tmp.dau-sicher.de) --- > (In reply to Roland from comment #351) > > I've failed to get the sound card running in the windows guest and created a > separate report for the ACL711 in bug #213641 >
Hi Cameron, Thanks for the inputs so far. > >> > >> Thank you for your feedback. Can you share your alsa-info? > >> > >> When you say post update, do you mean applying the latest patch attached > to > >> this bug report or are you referring to the latest kernel update for > Fedora > >> Rawhide? > > I just performed, a regular system update, using dnf update command, and > > after > > all the packages were installed, I reboot the system, since then my sound > > cards > > are not being detected. > > > > Here is the alsa-info: > > ~~~ > > http://alsa-project.org/db/?f=06e581149a25224e881b43b0b72f6439d13cde3a > > ~~~ > I performed another system update, and later on, reboot my system, now the sound cards are working perfectly fine. This behaviour I observed was on the below kernel version: ~~~ kernel-core-5.13.0-0.rc5.20210611git929d931f2b40.42.fc35.x86_64 ~~~ Now, I have this version, which resolved the issue: ~~~ kernel-core-5.14.0-0.rc0.20210701gitdbe69e433722.6.fc35.x86_64 ~~~ BR, Ganesh Kadam
Created attachment 297807 [details] linux-5.12-legion-sound-0.0.9.patch - Improved 13s Gen 2 support Big thanks for Vince Morel for providing cleaned up verbs for initialization on the 13s Gen2. We're down from around 400 to just 14! 13s Gen2 users, please test. Please ensure that audio still works after unplugging headphones and report on quality as well. When comparing audio quality, please disable any advanced audio features (such as Dolby) under Vantage as such features are unlikely to be supported under Linux anyway (Dolby is unsupported for example). Now for some bad news. Between my job and family, I really don't have time to keep trying to figure out how to get this work into the kernel especially when I don't even get any responses back at all. Probably tonight, I'll re-share this patch as a patchset of 3 in case anyone else wants to give it a shot, but I really just don't have the time anymore. And for good news, I'll likely have a 2021 Lenovo Legion at some point in August (the order has been placed since early July, but who knows when I'll actually receive it due to all the supply issues). Once I have that, I'll do this one more time and try to get sound working there as well. Once I can start the process with the 2021 Legion, I'll finish up the documentation work that I have in the pipeline. I'll document the process as I go through it again to make sure all is complete.
Created attachment 297809 [details] linux-5.12-legion-sound-0.0.9-001.patch First patch in the series. Adds 2020 Lenovo Legion support.
Created attachment 297811 [details] linux-5.12-legion-sound-0.0.9-002.patch This adds Yoga 7 support.
Created attachment 297813 [details] linux-5.12-legion-sound-0.0.9-003.patch This patch adds 13s Gen2 support. Applying the following patches: linux-5.12-legion-sound-0.0.9-001.patch linux-5.12-legion-sound-0.0.9-002.patch linux-5.12-legion-sound-0.0.9-003.patch Is exactly the same as only applying: linux-5.12-legion-sound-0.0.9.patch
Just installed the latest patch for 13SGen2. Firstly, applying the patch linux-5.12-legion-sound-0.0.9-003.patch leads to some errors : patch -p1 < linux-5.12-legion-sound-0.0.9-003.patch patching file sound/pci/hda/patch_realtek.c Hunk #1 succeeded at 6352 with fuzz 2 (offset -6 lines). Hunk #2 FAILED at 6573. Hunk #3 succeeded at 8145 with fuzz 2 (offset -27 lines). Hunk #4 FAILED at 8558. 2 out of 4 hunks FAILED -- saving rejects to file sound/pci/hda/patch_realtek.c.rej patching file sound/pci/hda/thinkbook_13s_gen2_itl_coefs.c So I directly applied linux-5.12-legion-sound-0.0.9.patch and was able to compile and install with no error. The speaker sound is definitely better, the overshoot on the volume control is manageable. Its hard to compare to windows because of Dolby, but its close. The sound works after unplugging headphones (tried it multiple times). The headphone sound still has some cracking noise and the bug on the volume control reappears (at least from what I tested). The sound on headphone is still pretty good. I noticed a bug, rebooting the computer with an HDMI cable plugged in removes completely the sound card. This bug was also present in version 0.0.7 of the patch.
What is the volume overshoot you're talking about? Probably missing the verbs to set something up there. Same goes for the HDMI probably... I hadn't thought to test even my laptop against HDMI as I never use it and don't really have a convenient way to test. Not sure what the problem with the patches is... I tried all 3 in order last night and they were fine. On 7/13/21 10:16 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #361 from waterproof93@outlook.com --- > Just installed the latest patch for 13SGen2. > > Firstly, applying the patch linux-5.12-legion-sound-0.0.9-003.patch leads to > some errors : > > patch -p1 < linux-5.12-legion-sound-0.0.9-003.patch > > patching file sound/pci/hda/patch_realtek.c > Hunk #1 succeeded at 6352 with fuzz 2 (offset -6 lines). > Hunk #2 FAILED at 6573. > Hunk #3 succeeded at 8145 with fuzz 2 (offset -27 lines). > Hunk #4 FAILED at 8558. > 2 out of 4 hunks FAILED -- saving rejects to file > sound/pci/hda/patch_realtek.c.rej > patching file sound/pci/hda/thinkbook_13s_gen2_itl_coefs.c > > So I directly applied linux-5.12-legion-sound-0.0.9.patch and was able to > compile and install with no error. > > The speaker sound is definitely better, the overshoot on the volume control > is > manageable. > Its hard to compare to windows because of Dolby, but its close. > > The sound works after unplugging headphones (tried it multiple times). > The headphone sound still has some cracking noise and the bug on the volume > control reappears (at least from what I tested). The sound on headphone is > still pretty good. > > I noticed a bug, rebooting the computer with an HDMI cable plugged in removes > completely the sound card. This bug was also present in version 0.0.7 of the > patch. >
(In reply to waterproof93 from comment #361) > Just installed the latest patch for 13SGen2. > > Firstly, applying the patch linux-5.12-legion-sound-0.0.9-003.patch leads to > some errors : > > patch -p1 < linux-5.12-legion-sound-0.0.9-003.patch > > patching file sound/pci/hda/patch_realtek.c > Hunk #1 succeeded at 6352 with fuzz 2 (offset -6 lines). > Hunk #2 FAILED at 6573. > Hunk #3 succeeded at 8145 with fuzz 2 (offset -27 lines). > Hunk #4 FAILED at 8558. > 2 out of 4 hunks FAILED -- saving rejects to file > sound/pci/hda/patch_realtek.c.rej > patching file sound/pci/hda/thinkbook_13s_gen2_itl_coefs.c > > So I directly applied linux-5.12-legion-sound-0.0.9.patch and was able to > compile and install with no error. > > The speaker sound is definitely better, the overshoot on the volume control > is manageable. > Its hard to compare to windows because of Dolby, but its close. > > The sound works after unplugging headphones (tried it multiple times). > The headphone sound still has some cracking noise and the bug on the volume > control reappears (at least from what I tested). The sound on headphone is > still pretty good. > > I noticed a bug, rebooting the computer with an HDMI cable plugged in > removes completely the sound card. This bug was also present in version > 0.0.7 of the patch. I think HDMI should not rely to those verb, probably another bug here. :) I will test it with hdmi, I admit I did not test hdmi connection (but I can with my 27" monitor)...
But the HDMI issue wasn't in 0.0.8? Probably some re-initialization is missing with only these verbs. On 7/13/21 10:34 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #363 from Vincent Morel (dantahoua@gmail.com) --- > (In reply to waterproof93 from comment #361) >> Just installed the latest patch for 13SGen2. >> >> Firstly, applying the patch linux-5.12-legion-sound-0.0.9-003.patch leads to >> some errors : >> >> patch -p1 < linux-5.12-legion-sound-0.0.9-003.patch >> >> patching file sound/pci/hda/patch_realtek.c >> Hunk #1 succeeded at 6352 with fuzz 2 (offset -6 lines). >> Hunk #2 FAILED at 6573. >> Hunk #3 succeeded at 8145 with fuzz 2 (offset -27 lines). >> Hunk #4 FAILED at 8558. >> 2 out of 4 hunks FAILED -- saving rejects to file >> sound/pci/hda/patch_realtek.c.rej >> patching file sound/pci/hda/thinkbook_13s_gen2_itl_coefs.c >> >> So I directly applied linux-5.12-legion-sound-0.0.9.patch and was able to >> compile and install with no error. >> >> The speaker sound is definitely better, the overshoot on the volume control >> is manageable. >> Its hard to compare to windows because of Dolby, but its close. >> >> The sound works after unplugging headphones (tried it multiple times). >> The headphone sound still has some cracking noise and the bug on the volume >> control reappears (at least from what I tested). The sound on headphone is >> still pretty good. >> >> I noticed a bug, rebooting the computer with an HDMI cable plugged in >> removes completely the sound card. This bug was also present in version >> 0.0.7 of the patch. > I think HDMI should not rely to those verb, probably another bug here. :) I > will test it with hdmi, I admit I did not test hdmi connection (but I can > with > my 27" monitor)... >
(In reply to Cameron Berkenpas from comment #362) > What is the volume overshoot you're talking about? Probably missing the > verbs to set something up there. > > Same goes for the HDMI probably... I hadn't thought to test even my > laptop against HDMI as I never use it and don't really have a convenient > way to test. > > Not sure what the problem with the patches is... I tried all 3 in order > last night and they were fine. Basically the bug is when you try to change volume (increase or decrease) rapidly after about the third tap, the volume goes directly to the max (or min depending on the direction). Therefore, it's hard to get to the volume that you want. This seems to only happen using the laptop keyboard. With my mechanical keyboard plugged in I can change the volume without hiccups. I don't know also about the patch issue. I'm patching against the same kernel (5.12.14) every time. (In reply to Cameron Berkenpas from comment #364) > But the HDMI issue wasn't in 0.0.8? Probably some re-initialization is > missing with only these verbs. I never tested 0.0.8, so this bug probably applies to it also.
What about when you change the volume using a software slider, does it happen then? I remember some of the verbs for the Legion/Yoga were related to volume control. Maybe this is what they were for? On 7/13/21 10:59 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #365 from waterproof93@outlook.com --- > (In reply to Cameron Berkenpas from comment #362) >> What is the volume overshoot you're talking about? Probably missing the >> verbs to set something up there. >> >> Same goes for the HDMI probably... I hadn't thought to test even my >> laptop against HDMI as I never use it and don't really have a convenient >> way to test. >> >> Not sure what the problem with the patches is... I tried all 3 in order >> last night and they were fine. > Basically the bug is when you try to change volume (increase or decrease) > rapidly after about the third tap, the volume goes directly to the max (or > min > depending on the direction). > > Therefore, it's hard to get to the volume that you want. > > This seems to only happen using the laptop keyboard. > With my mechanical keyboard plugged in I can change the volume without > hiccups. > > I don't know also about the patch issue. > I'm patching against the same kernel (5.12.14) every time. > > (In reply to Cameron Berkenpas from comment #364) >> But the HDMI issue wasn't in 0.0.8? Probably some re-initialization is >> missing with only these verbs. > I never tested 0.0.8, so this bug probably applies to it also. >
(In reply to Cameron Berkenpas from comment #366) > What about when you change the volume using a software slider, does it > happen then? > > I remember some of the verbs for the Legion/Yoga were related to volume > control. Maybe this is what they were for? I'm not sure what you mean about a software slider. There is no issue when sliding the volume using the gnome panel for example. It's smooth, every increment on the volume works and I can stop anywhere on the slider.
Sliding the volume control in the Gnome Panel is exactly what I mean. Thanks for letting me know. On 7/13/21 11:07 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #367 from waterproof93@outlook.com --- > (In reply to Cameron Berkenpas from comment #366) >> What about when you change the volume using a software slider, does it >> happen then? >> >> I remember some of the verbs for the Legion/Yoga were related to volume >> control. Maybe this is what they were for? > I'm not sure what you mean about a software slider. > There is no issue when sliding the volume using the gnome panel for example. > It's smooth, every increment on the volume works and I can stop anywhere on > the > slider. >
I've created a post Lenovo's forums for this issue, I hope someone at Lenovo with answers sees this: https://forums.lenovo.com/t5/Gaming-Laptops/Lenovo-Legion-7-s-speaker-configuration-doesn-t-seem-to-be-supported-under-linux/m-p/5089952
Just FYI, the S3 Sleep fix in the Arch Wiki for the Yoga 7i appears to no longer work.
Some update on de Legion 7 16ACHg6 (AMD Ryzen 5000), I finally got the QEMU VM working, the IOMMU groups were really bad grouped for the sound card. But started and got the HDA verbs. But still no sound, in the VM is also no sound. The Cirrus Logic amplifier needs to be initialized on this board. Got the driver but the VM doesn't pick it up. After some searching in the drivers it seems that this chip is controlled by I2C/GPIO through ACPI. Decoded the DSDT table in ACPI and found the following: Scope (_SB.I2CD) { Device (SPKR) { Name (_HID, "CLSA0100") // _HID: Hardware ID Name (_UID, One) // _UID: Unique ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { I2cSerialBusV2 (0x0040, ControllerInitiated, 0x000F4240, AddressingMode7Bit, "\\_SB.I2CD", 0x00, ResourceConsumer, , Exclusive, ) I2cSerialBusV2 (0x0041, ControllerInitiated, 0x000F4240, AddressingMode7Bit, "\\_SB.I2CD", 0x00, ResourceConsumer, , Exclusive, ) GpioIo (Exclusive, PullDown, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x0006 } GpioIo (Shared, PullUp, 0x0064, 0x0000, IoRestrictionInputOnly, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x0054 } GpioIo (Exclusive, PullUp, 0x0000, 0x0000, IoRestrictionInputOnly, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x0091 } GpioInt (Edge, ActiveBoth, Shared, PullUp, 0x0064, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x0054 } }) Return (RBUF) /* \_SB_.I2CD.SPKR._CRS.RBUF */ } Method (_STA, 0, NotSerialized) // _STA: Status { If ((MCSK == 0x04)) { Return (0x0F) } Else { Return (Zero) } } Method (_DIS, 0, NotSerialized) // _DIS: Disable Device { } } } Is there anyone that can help me from here on? Now I've no idea what to do, how to set the GPIO pins of this device from linux, maybe that works. There are also some init sequences and blobs from the Cirrus Logic drivers. Or can this be debugged from Windows in any way?
It seems everyone who's done this so far (including myself) had to really work at getting Windows to use the correct driver for the device. Likely, you'll have to do the same. I had to go into the device manager and figure out how get things working. I have some notes in this bug in what I had to do, others had to do similar steps but not exactly the same. Under my branch, I have notes on the steps I was able to use for the 2020 Legion: https://github.com/thiagotei/linux-realtek-alc287/tree/cameron/lenovo-legion Take a look at the "Getting sound working under Windows" section. I haven't worked on my branch for a while because I'm waiting to repeat this process again once I have my 2021 Legion. Unfortunately, I am likely cancelling my 2021 Legion order soon as they've pushed the ship date out to many months (*after* customer service confirmed I'd have it in August or September) . I'm just waiting to hear back for confirmation on the new shipping date from Lenovo's customer service. On 7/26/21 10:09 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Marcus (kernel@m.vb1.nl) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |kernel@m.vb1.nl > > --- Comment #371 from Marcus (kernel@m.vb1.nl) --- > Some update on de Legion 7 16ACHg6 (AMD Ryzen 5000), I finally got the QEMU > VM > working, the IOMMU groups were really bad grouped for the sound card. But > started and got the HDA verbs. But still no sound, in the VM is also no > sound. > The Cirrus Logic amplifier needs to be initialized on this board. Got the > driver but the VM doesn't pick it up. After some searching in the drivers it > seems that this chip is controlled by I2C/GPIO through ACPI. > > Decoded the DSDT table in ACPI and found the following: > Scope (_SB.I2CD) > { > Device (SPKR) > { > Name (_HID, "CLSA0100") // _HID: Hardware ID > Name (_UID, One) // _UID: Unique ID > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource > Settings > { > Name (RBUF, ResourceTemplate () > { > I2cSerialBusV2 (0x0040, ControllerInitiated, 0x000F4240, > AddressingMode7Bit, "\\_SB.I2CD", > 0x00, ResourceConsumer, , Exclusive, > ) > I2cSerialBusV2 (0x0041, ControllerInitiated, 0x000F4240, > AddressingMode7Bit, "\\_SB.I2CD", > 0x00, ResourceConsumer, , Exclusive, > ) > GpioIo (Exclusive, PullDown, 0x0000, 0x0000, > IoRestrictionOutputOnly, > "\\_SB.GPIO", 0x00, ResourceConsumer, , > ) > { // Pin list > 0x0006 > } > GpioIo (Shared, PullUp, 0x0064, 0x0000, > IoRestrictionInputOnly, > "\\_SB.GPIO", 0x00, ResourceConsumer, , > ) > { // Pin list > 0x0054 > } > GpioIo (Exclusive, PullUp, 0x0000, 0x0000, > IoRestrictionInputOnly, > "\\_SB.GPIO", 0x00, ResourceConsumer, , > ) > { // Pin list > 0x0091 > } > GpioInt (Edge, ActiveBoth, Shared, PullUp, 0x0064, > "\\_SB.GPIO", 0x00, ResourceConsumer, , > ) > { // Pin list > 0x0054 > } > }) > Return (RBUF) /* \_SB_.I2CD.SPKR._CRS.RBUF */ > } > > Method (_STA, 0, NotSerialized) // _STA: Status > { > If ((MCSK == 0x04)) > { > Return (0x0F) > } > Else > { > Return (Zero) > } > } > > Method (_DIS, 0, NotSerialized) // _DIS: Disable Device > { > } > } > } > > > Is there anyone that can help me from here on? Now I've no idea what to do, > how > to set the GPIO pins of this device from linux, maybe that works. There are > also some init sequences and blobs from the Cirrus Logic drivers. Or can this > be debugged from Windows in any way? >
Hi Cameron, I already did that step to make sure that the Lenovo drivers are used. I just reinstalled the drivers but still no sound from the VM. I also really hope that is just a driver issue in Windows so that this can be fixed sort of soon. I already start JCS QEMU as mentioned on your link. I've only one warning on startup is that the device cannot be reset, I've no idea if that is the culprit at the moment.
The device cannot reset isn't a problem. Occasionally, when experimenting with verbs, you can wedge the sound card hard enough that even restarting your laptop won't cause it to recover. You'll have to fully power the laptop off and then power it back on before it will work again. I suspect this is due to the device not being able to reset, but even in my tons of testing, this happened only a few times. On 7/26/21 11:00 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #373 from Marcus (kernel@m.vb1.nl) --- > Hi Cameron, > > I already did that step to make sure that the Lenovo drivers are used. I just > reinstalled the drivers but still no sound from the VM. I also really hope > that > is just a driver issue in Windows so that this can be fixed sort of soon. > > I already start JCS QEMU as mentioned on your link. I've only one warning on > startup is that the device cannot be reset, I've no idea if that is the > culprit > at the moment. >
Thought i'd reinstall linux to see if there were any changes with this Yoga Duet 7i. Still no sound with the newer kernels but 5.4.88-1-lts with Arch "Arco"linux does works every time. Microphone does not work. Why it works in 5.488-1-lts and not newer is beyond me. Why devs haven't compared the two and fixed it is also puzzling.
Updates: Both of the 2021 Legion's (the AMD based Legion 7 16ACHg6 and the Intel based Legion 7i 16ITHg6) have sound issues under Linux. Sound doesn't work at all under the AMD based 16ACHg6, and sound partially works under the Intel based 16ITHg6. In the case of the Intel based 16ITHg6, sound works until you suspend to memory. Plugging in and removing headphones doesn't affect speaker output (so far). Probably the BIOS initializes the amp at book, but not at resume. For now, I'm using hibernate instead of suspending to memory. Both laptops appear to have Cirrus Logic CS35L51 amplifier chips. There is presently no Linux support for this chip, and no publicly available datasheets as of yet. However, a driver is currently in the works for the CS35L41: https://www.spinics.net/lists/alsa-devel/msg129286.html So maybe we'll eventually see support for the CS35L51. This means the audio output issues with the 2021 Legion lines are unrelated to this bug or at least the ongoing work that has occurred under this bug. I will eventually update the document to reflect the state of audio are the 2021 Legion's and what we present know here: https://github.com/thiagotei/linux-realtek-alc287 Huge thanks to Marcus Aram who discovered the amplifier chip and its model and has been working towards getting this resolved.
I just want to thank you all for the work on this issue. I have a Lenovo 7i and am eagerly awaiting this fix to be accepted into the kernel so I can use Linux as my main.
Unfortunately, that's not going to happen. I tried to post my patches, and I never received even any sort of feedback. I've dedicated about as much time to this as I'm able to at this point, so unless it's something that only requires a modicum of time, there's not much else I'm able to do. On 8/10/21 9:59 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Gene (unmotivatedgene+kernel@gmail.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |unmotivatedgene+kernel@gmai > | |l.com > > --- Comment #377 from Gene (unmotivatedgene+kernel@gmail.com) --- > I just want to thank you all for the work on this issue. I have a Lenovo 7i > and > am eagerly awaiting this fix to be accepted into the kernel so I can use > Linux > as my main. >
(In reply to Cameron Berkenpas from comment #378) > Unfortunately, that's not going to happen. I tried to post my patches, > and I never received even any sort of feedback. You overlooked my comment..? https://lore.kernel.org/alsa-devel/s5hy2ah5dkb.wl-tiwai@suse.de/
Hi Takashi Iwai, I never received your comment! I even tried to follow up at one point to see if I just wasn't getting the email so not sure how I missed this. I'll try to work on the patch this weekend. One question: I don't see "AC_VERB_SET_COEF" defined anywhere. Did you mean "AC_VERB_SET_COEF_INDEX"? Thank you!!
Sorry, it was a typo of AC_VERB_SET_PROC_COEF. In short, { 0x4XX, 0xYY } is equivalent with { AC_VERB_SET_PROC_COEF, 0xXXYY } and { 0x5XX, 0xYY } is a combo of { AC_VERB_SET_COEF_INDEX, 0xXXYY }
Created attachment 298307 [details] 16achverbs2.txt For what is worth, here eare the verbs. These are from 16ACHg6 Legion 7 2021. Got them from running a Windows VM with IOMMU PCI passthrough. These only trigger the RGB lightning on the keyboard if you select the light modus that responds to sound. Hope that some can get some stuff working on this machine.
Created attachment 298309 [details] 16achverbs.txt
Created attachment 298311 [details] 16achverbs3.txt
Created attachment 298313 [details] 16achverbs4.txt
Created attachment 298337 [details] linux-5.13-legion-yoga-14ITL5-sound-0.0.10-001.patch linux-5.13-legion-yoga-14ITL5-sound-0.0.10-001.patch Adds speaker output for the 2020 Legion and the Yoga 7i. This is based against the Linux 5.13 series and incorporates Takashi's suggestions. It compiles, but I haven't been able to test this. I might be able to get ahold of the old 2020 Legion for testing later this week (I'm not on the 2021 Legion 7i). Please test and please test with headphone removal on the 2020 Legion.
Created attachment 298339 [details] linux-5.13-legion-yoga-14ITL5-sound-0.0.10-001.patch - correct patch Mistakenly attached an older patch previously. This is the correct patch. Adds speaker output for the 2020 Legion and the Yoga 7i. This is based against the Linux 5.13 series and incorporates Takashi's suggestions. It compiles, but I haven't been able to test this. I might be able to get ahold of the old 2020 Legion for testing later this week (I'm not on the 2021 Legion 7i). Please test and please test with headphone removal on the 2020 Legion as I'm unable to for the time being.
Created attachment 298341 [details] linux-5.13-legion-13s-gen2-sound-0.0.10-002.patch Adds speaker output for the 13s gen2. This is based against the Linux 5.13 series and incorporates Takashi's suggestions. This is still in a separate patch as it seems volume control (using keyboard shortcuts I think..?) are a bit wonky so unsure if this will eventually be included if this remains unchanged.
I have tested the patch from comment 387 on a humble Yoga 7 14TL5 (not Legion, BIOS version F5CN40WW & F5CN49WW) and I get sound out of the right speaker only (thank you!). I have also tried plugging and unplugging a jack and that switches correctly back and forth between headphones and speaker(s). (In reply to Cameron Berkenpas from comment #387) > Created attachment 298339 [details] > linux-5.13-legion-yoga-14ITL5-sound-0.0.10-001.patch - correct patch > > Mistakenly attached an older patch previously. This is the correct patch. > > Adds speaker output for the 2020 Legion and the Yoga 7i. This is based > against the Linux 5.13 series and incorporates Takashi's suggestions. > > It compiles, but I haven't been able to test this. I might be able to get > ahold of the old 2020 Legion for testing later this week (I'm not on the > 2021 Legion 7i). > > Please test and please test with headphone removal on the 2020 Legion as I'm > unable to for the time being.
Created attachment 298363 [details] linux-max.patch - Based on the 0.0.10 with fixed Yoga 7i support Max was able to get both speakers working again. Here is his patch. I was able to test the 0.0.10 patch on the 2020 Legion, and both speakers work. Not sure why 0.0.10 broke right speaker output on the Yoga when sound initialization is so similar between the 2 modals... When I have some time, I will try some of Max's changes against the Legion.
It looks like this patch will set both speakers to the right channel. (In reply to Cameron Berkenpas from comment #390) > Created attachment 298363 [details] > linux-max.patch - Based on the 0.0.10 with fixed Yoga 7i support > > Max was able to get both speakers working again. Here is his patch. > > I was able to test the 0.0.10 patch on the 2020 Legion, and both speakers > work. Not sure why 0.0.10 broke right speaker output on the Yoga when sound > initialization is so similar between the 2 modals... > > When I have some time, I will try some of Max's changes against the Legion. This may be helpful to you. https://gist.github.com/184de8b8a860a2b17a497ab82863c37d (In reply to Max from comment #389) > I have tested the patch from comment 387 on a humble Yoga 7 14TL5 (not > Legion, BIOS version F5CN40WW & F5CN49WW) and I get sound out of the right > speaker only (thank you!). I have also tried plugging and unplugging a jack > and that switches correctly back and forth between headphones and speaker(s).
sycxyc: (In reply to sycxyc from comment #391) > It looks like this patch will set both speakers to the right channel. [...] I can assure you that both speakers are working independently with the patch (I tested it on the hardware with `speaker-test -c2`). But I also see why you say that. According to your gist document it should have been 0x1a in line line 8223 of attachment 298363 [details], right?
sycxyc, Did you try patch 0.0.10? I converted the "0x20, 0x4b0, 0x20" lines to "0x20, AC_VERB_SET_PROC_COEF, 0xb020" and this seemed to break right speaker output on the Yoga 7i. Strangely, this didn't cause problems for the Legion, but I still want to try some of Max's changes to see if there are any differences. On 8/19/21 9:22 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #392 from Max (accounts@wireme.de) --- > sycxyc: (In reply to sycxyc from comment #391) >> It looks like this patch will set both speakers to the right channel. > [...] > > I can assure you that both speakers are working independently with the patch > (I > tested it on the hardware with `speaker-test -c2`). But I also see why you > say > that. According to your gist document it should have been 0x1a in line line > 8223 of attachment 298363 [details], right? >
Right. When using the verbs in the patch on my hardware, both speakers only have sound when `speaker-test -c2` tests "Front Right". (In reply to Max from comment #392) > I can assure you that both speakers are working independently with the patch > (I tested it on the hardware with `speaker-test -c2`). But I also see why > you say that. According to your gist document it should have been 0x1a in > line line 8223 of attachment 298363 [details], right? I replace "0x20 0x4b0 0x20" with "0x20 0x400 0xb020" and there seems to be no problem. (I only used applyverbs.py to test it.) (In reply to Cameron Berkenpas from comment #393) > sycxyc, > > Did you try patch 0.0.10? I converted the "0x20, 0x4b0, 0x20" lines to > "0x20, AC_VERB_SET_PROC_COEF, 0xb020" and this seemed to break right speaker > output on the Yoga 7i.
On a Yoga 7-14ITL5 Ideapad (82BH) here. The patches in this thread are for this device too? Installed a clean ubuntu 21.04 and dist-upgrade. I then tried using the 'linux-max.patch' based on comment 282. That is correct in how to use this patch or is this a kernel patch? If it is just a sound patch, I had no change at all as to speakers working. no sound at all from them. thanks for all the work you all are doing to try and get these devices properly working.
No, you need to apply this patch against kernel source and compile your own kernel. Once the last issues are ironed out, I'll work on getting the patches merged. On 8/19/2021 12:45 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > lazertag@gmail.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |lazertag@gmail.com > > --- Comment #395 from lazertag@gmail.com --- > On a Yoga 7-14ITL5 Ideapad (82BH) here. The patches in this thread are for > this device too? > > Installed a clean ubuntu 21.04 and dist-upgrade. I then tried using the > 'linux-max.patch' based on comment 282. That is correct in how to use this > patch or is this a kernel patch? If it is just a sound patch, I had no > change > at all as to speakers working. no sound at all from them. > > thanks for all the work you all are doing to try and get these devices > properly > working. >
Created attachment 298379 [details] little modification to the `linux-max.patch` to fix sound for Legion 7i, S740, Yoga 9i Beware of a misunderstanding. With patch 0.0.10 alias `linux-5.13-legion-yoga-14ITL5-sound-0.0.10-001.patch - correct patch` only the right speaker was working for me, the left one did not on the `Yoga 7 14ITL5`, which is how my model is called according to the back plate. It also has stickers on it, calling it a `YOGA 7i`. I restructured the patch code a little and there was this comment `set right speaker Yoga 7i.`, but that was not sitting in the middle of the code block: The code block for the left speaker was shorter, so that I compared line by line what was missing and finally copied the difference from the right speaker to the left. I compiled the kernel with that and tested it on my hardware and it works - on a Yoga 7i that is. The gist document from @sycxyc gives me a better understanding of what the code does and by the looks of it: `set the speaker` and `activate speaker` for both channels. But there are twopossibilities to `set the speaker` in the document and one is dedicated to the Yoga 7i only. Both possibilities are implemented in the patch in the same code block, so that changes for one model can influence another and I made a mistake, which could be a problem with other models: The attachment 298363 [details], line 8223 should have been `0x1a` instead of `0x2a` to select the correct speaker before activating a speaker. Attached is a patch called `linux-max-untested.patch` with the little change I mentioned. It should fix problem with other models and it should still work with the Yoga 7i. However it is untested, because I currently have no time to compile the kernel again. Have fun and good luck.
Hey Max, I think you forgot to edit the patch file fully. It would not apply until i edited it from: Change line 36 @@ -8182,6 +8199,73 @@ static const struct hda_fixup alc269_fixups[] = { To @@ -8182,6 +8199,82 @@ static const struct hda_fixup alc269_fixups[] = { Attempting compilation now. (In reply to Max from comment #397) > Created attachment 298379 [details] > little modification to the `linux-max.patch` to fix sound for Legion 7i, > S740, Yoga 9i > > Beware of a misunderstanding. With patch 0.0.10 alias > `linux-5.13-legion-yoga-14ITL5-sound-0.0.10-001.patch - correct patch` only > the right speaker was working for me, the left one did not on the `Yoga 7 > 14ITL5`, which is how my model is called according to the back plate. It > also has stickers on it, calling it a `YOGA 7i`. > > I restructured the patch code a little and there was this comment `set right > speaker Yoga 7i.`, but that was not sitting in the middle of the code block: > The code block for the left speaker was shorter, so that I compared line by > line what was missing and finally copied the difference from the right > speaker to the left. I compiled the kernel with that and tested it on my > hardware and it works - on a Yoga 7i that is. > > The gist document from @sycxyc gives me a better understanding of what the > code does and by the looks of it: `set the speaker` and `activate speaker` > for both channels. But there are twopossibilities to `set the speaker` in > the document and one is dedicated to the Yoga 7i only. Both possibilities > are implemented in the patch in the same code block, so that changes for one > model can influence another and I made a mistake, which could be a problem > with other models: The attachment 298363 [details], line 8223 should have > been `0x1a` instead of `0x2a` to select the correct speaker before > activating a speaker. > > Attached is a patch called `linux-max-untested.patch` with the little change > I mentioned. It should fix problem with other models and it should still > work with the Yoga 7i. However it is untested, because I currently have no > time to compile the kernel again. > > Have fun and good luck.
Hi I installed Ubuntu 20.04 on my Lenovo AIO A540 24ICB and my internal speakers doesnt sound. I get sound using ext speakers connected to the audio jack . I think that the problem si very similar to the problmes described here on other Lenovo machines but after reading the information here I am not sure which patch can I try. Please can you help me to find which patch can I try? I am attaching the alsa-info.txt form my machine. Best regards and thanks in advance for your help Horacio Merovich
Created attachment 298397 [details] alsa-info.txt from Lenovo A540-24ICB
On 8/19/21 10:22 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > I replace "0x20 0x4b0 0x20" with "0x20 0x400 0xb020" and there seems to be no > problem. (I only used applyverbs.py to test it.) > Are you already patching the kernel? Perhaps the right speaker is already initialized and that's why it's working
I got the linux-max-untested.patch edited to be valid and then compiled. The speakers work with their correct channels. Wired headphones work as expected and sound switches back to the speakers after unplugging them. Lenovo 7i (Lenovo 14ITL5) ( my trackpad and touchscreen don't but that is likely just on me not knowing how to compile a kernel properly ) (In reply to Gene from comment #398) > Hey Max, I think you forgot to edit the patch file fully. It would not apply > until i edited it from: > > Change line 36 > @@ -8182,6 +8199,73 @@ static const struct hda_fixup alc269_fixups[] = { > To > @@ -8182,6 +8199,82 @@ static const struct hda_fixup alc269_fixups[] = { > > Attempting compilation now. > > (In reply to Max from comment #397) > > Created attachment 298379 [details] > > little modification to the `linux-max.patch` to fix sound for Legion 7i, > > S740, Yoga 9i > > ...
(In reply to Gene from comment #403) > I got the linux-max-untested.patch edited to be valid and then compiled. The > speakers work with their correct channels. Wired headphones work as expected > and sound switches back to the speakers after unplugging them. > > Lenovo 7i (Lenovo 14ITL5) > > ( my trackpad and touchscreen don't but that is likely just on me not > knowing how to compile a kernel properly ) > > > (In reply to Gene from comment #398) > > Hey Max, I think you forgot to edit the patch file fully. It would not > apply > > until i edited it from: > > > > Change line 36 > > @@ -8182,6 +8199,73 @@ static const struct hda_fixup alc269_fixups[] = { > > To > > @@ -8182,6 +8199,82 @@ static const struct hda_fixup alc269_fixups[] = { > > > > Attempting compilation now. > > > > (In reply to Max from comment #397) > > > Created attachment 298379 [details] > > > little modification to the `linux-max.patch` to fix sound for Legion 7i, > > > S740, Yoga 9i > > > > ... I did the same(i suppose) as You, but I don't have sound on my Yoga 7 (15ITL5). Could you tell me how did you build your kernel?
I recompiled snd-hda-codec-realtek.ko using attachment 298363 [details]. When I reboot the Yoga7i both speakers work fine as @Max described. But alfter S3 sleep wake up both speakers become right channel. I changed `0x2a` to `0x1a` in line 8223 and updated snd-hda-codec-realtek.ko and then both speakers have the correct channel after S3 sleep wakeup. I assume that the channel will be reset after boot, and the speakers will be conditionally activated after S3 sleep wakeup. (In reply to Cameron Berkenpas from comment #402) > On 8/19/21 10:22 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > Are you already patching the kernel? Perhaps the right speaker is > already initialized and that's why it's working
Can somebody please explain to someone who doesn't understand the first thing about C and other low-level things what the status of this is. If it's more or less fixed, how do I use a .patch file? (looking for an explanation suitable for a web developer not a grandma please ^_^)
(In reply to Chris from comment #406) > Can somebody please explain to someone who doesn't understand the first > thing about C and other low-level things what the status of this is. If it's > more or less fixed, how do I use a .patch file? > > (looking for an explanation suitable for a web developer not a grandma > please ^_^) Unfortunately it's still on the low level and will find it's way in the standard kernel hopefully. I have no insight on that yet, but am using one adapted C level patch suitable for my kernels. If you want to step in and use the available patching offer you need to get familiar with: installing kernel headers and sources, install toolchain, compile kernel and kernel modules, apply patch to kernel module files, install changes modules and test and verify the result. And that's mainly on C development level ... One path of source for that maybe: https://yoursunny.com/t/2018/one-kernel-module/ (but it depends highly on your linux system) If you are not familiar with that keep your fingers away .... (it will cost some time and can't be explained in detail here since the guys working on that level spend much of their valueable time in solving the issues). Alternatively you can try one of the offered hda-verb solutions. Maybe start reading with: https://bugzilla.kernel.org/show_bug.cgi?id=208555#c241 (but you need to figure out what verb sequence is suitable for your system)
(In reply to woody64 from comment #407) > (In reply to Chris from comment #406) > > Can somebody please explain to someone who doesn't understand the first > > thing about C and other low-level things what the status of this is. If > it's > > more or less fixed, how do I use a .patch file? > > > > (looking for an explanation suitable for a web developer not a grandma > > please ^_^) > > Unfortunately it's still on the low level and will find it's way in the > standard kernel hopefully. > I have no insight on that yet, but am using one adapted C level patch > suitable for my kernels. > > If you want to step in and use the available patching offer you need to get > familiar with: installing kernel headers and sources, install toolchain, > compile kernel and kernel modules, apply patch to kernel module files, > install changes modules and test and verify the result. > And that's mainly on C development level ... > > One path of source for that maybe: > https://yoursunny.com/t/2018/one-kernel-module/ > (but it depends highly on your linux system) > > If you are not familiar with that keep your fingers away .... (it will cost > some time and can't be explained in detail here since the guys working on > that level spend much of their valueable time in solving the issues). > > Alternatively you can try one of the offered hda-verb solutions. Maybe start > reading with: > https://bugzilla.kernel.org/show_bug.cgi?id=208555#c241 > (but you need to figure out what verb sequence is suitable for your system) Thank you so much for your detailed response :) that all seems a bit beyond me. Was hoping it would just be a few lines in the terminal to make use of the work here. What's the "standard kernel"? Is that the core that all Linux distros build on top of? If that's the case I suppose it'll be a few years before people like me can use fully-functioning Linux on their computers T_T
(In reply to Chris from comment #408) > (In reply to woody64 from comment #407) > > Thank you so much for your detailed response :) that all seems a bit beyond > me. Was hoping it would just be a few lines in the terminal to make use of > the work here. What's the "standard kernel"? Is that the core that all Linux As said you can give the applyverbs (1-liner) a try (not checking what hw you are on and which verbs maybe suitable for you): applyverbs: https://github.com/ryanprescott/realtek-verb-tools huge verb list (starting point): https://bugzilla.kernel.org/attachment.cgi?id=297545 shell> sudo python3 realtek-verb-tools/applyverbs.py verbs-working.txt > distros build on top of? If that's the case I suppose it'll be a few years > before people like me can use fully-functioning Linux on their computers T_T Mainly yes, and if it's in then we have a goog chance that it will work for a lot of models in the future. Here we are deep in kernel stuff and I doubt that you ever have done that under windows but you are nevertheless using it:)
Are you sure 8,223 is the right line? I don't see 0x2a, I see: {0x20, AC_VERB_SET_COEF_INDEX, 0x26 }, Maybe you mean 8,221: {0x20, AC_VERB_SET_PROC_COEF, 0x2a }, Or maybe you're not patching against against 5.13 like I am. :) On 8/21/21 12:40 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #405 from sycxyc (sycxyc+kernel@yandex.com) --- > I recompiled snd-hda-codec-realtek.ko using attachment 298363 [details]. When > I > reboot the Yoga7i both speakers work fine as @Max described. But alfter S3 > sleep wake up both speakers become right channel. > > I changed `0x2a` to `0x1a` in line 8223 and updated snd-hda-codec-realtek.ko > and then both speakers have the correct channel after S3 sleep wakeup. > > I assume that the channel will be reset after boot, and the speakers will be > conditionally activated after S3 sleep wakeup. > > (In reply to Cameron Berkenpas from comment #402) >> On 8/19/21 10:22 AM, bugzilla-daemon@bugzilla.kernel.org wrote: >> Are you already patching the kernel? Perhaps the right speaker is >> already initialized and that's why it's working
I patched linux-source-5.10 and line 8223 is referenced here. https://bugzilla.kernel.org/attachment.cgi?id=298363&action=diff (In reply to Cameron Berkenpas from comment #410) > Are you sure 8,223 is the right line? I don't see 0x2a, I see: > {0x20, AC_VERB_SET_COEF_INDEX, 0x26 }, > > Maybe you mean 8,221: > {0x20, AC_VERB_SET_PROC_COEF, 0x2a }, > > Or maybe you're not patching against against 5.13 like I am. :)
(In reply to Max from comment #397) > Created attachment 298379 [details] > little modification to the `linux-max.patch` to fix sound for Legion 7i, > S740, Yoga 9i > > Beware of a misunderstanding. With patch 0.0.10 alias > `linux-5.13-legion-yoga-14ITL5-sound-0.0.10-001.patch - correct patch` only > the right speaker was working for me, the left one did not on the `Yoga 7 > 14ITL5`, which is how my model is called according to the back plate. It > also has stickers on it, calling it a `YOGA 7i`. > > I restructured the patch code a little and there was this comment `set right > speaker Yoga 7i.`, but that was not sitting in the middle of the code block: > The code block for the left speaker was shorter, so that I compared line by > line what was missing and finally copied the difference from the right > speaker to the left. I compiled the kernel with that and tested it on my > hardware and it works - on a Yoga 7i that is. > > The gist document from @sycxyc gives me a better understanding of what the > code does and by the looks of it: `set the speaker` and `activate speaker` > for both channels. But there are twopossibilities to `set the speaker` in > the document and one is dedicated to the Yoga 7i only. Both possibilities > are implemented in the patch in the same code block, so that changes for one > model can influence another and I made a mistake, which could be a problem > with other models: The attachment 298363 [details], line 8223 should have > been `0x1a` instead of `0x2a` to select the correct speaker before > activating a speaker. > > Attached is a patch called `linux-max-untested.patch` with the little change > I mentioned. It should fix problem with other models and it should still > work with the Yoga 7i. However it is untested, because I currently have no > time to compile the kernel again. > > Have fun and good luck. I've tested your patch on 15ITL5, at first try nothing happened after reboot. To make it working on Yoga 7i 15ITl5 i had to add: + SND_PCI_QUIRK(0x17aa, 0x3853, "Lenovo Yoga 7 15ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
(In reply to Cameron Berkenpas from comment #388) > Created attachment 298341 [details] > linux-5.13-legion-13s-gen2-sound-0.0.10-002.patch > > Adds speaker output for the 13s gen2. This is based against the Linux 5.13 > series and incorporates Takashi's suggestions. > > This is still in a separate patch as it seems volume control (using keyboard > shortcuts I think..?) are a bit wonky so unsure if this will eventually be > included if this remains unchanged. So regarding the volume control, I applied the patch 0.0.9 to kernel 5.13.5 and now the control seems to be working just fine ! I think this is a success. I did had some error while applying the patch and at the end of the compilation but when I rebooted on the kernel everything is working good.
Created attachment 298425 [details] linux-5.13-legion-sound-0.0.11-001.patch - 2020 Legion and Yoga 7i support Legion and Yoga verbs updated based on Max's and sycxyc's feedback work.
Created attachment 298427 [details] linux-5.13-legion-sound-0.0.11-002.patch - Support for 13s Gen2 and Yoga 7 15ITL5 If folks can confirm there's no volume weirdness with the 13s Gen2 laptops with volume control and if Yoga 7 15ITL5 support is confirmed working, I think we can merge the 2 small patches together to make one slightly less small patch. IIRC, I think around 2 people complained about weirdness with the volume on the 13s Gen2... But if it's working for someone else, maybe there's a distro specific bug?
I can confirm that, after my little addition, everything works(on Yoga 7i 15ITL5). Both channels are correcly set up, and volume control is ok. If it concerns, i have tested patches on Ubuntu 21.04, Kernel 5.13.12 TY for all contributors <3
This problem seems to affect HP SPECTRE x360 15-eb0675ng, too. This device has a Realtek ALC285 (sof-hda-dsp) sound card. Audio is working via line/headphone output, only. While a headphone is not connected, PulseAudio recognizes that nothing is plugged in, and when it's connected, it says headphone output. Alsamixer also confirms muting and unmuting of the integrated speakers, as well. Sound is working perfect via line/headphone out, but speakers don't work. We are sure that an integrated mini amp behind the sound card has to be triggered via special registers, too. We can confirm that it works under Windows, same thing as mentioned above. You may want to apply your linux-5.13-legion-sound-0.0.11-002.patch for this device, as well. The diff looks like it would only take effect on the special Lenovo laptop, so I thought it would be a good idea to inform you about it. Maybe the patch would work 1:1 on the HP laptop, too. If you need more information, I would like to support you as best as I can.
(In reply to René Knipschild from comment #418) > This problem seems to affect HP SPECTRE x360 15-eb0675ng, too. This device > has a Realtek ALC285 (sof-hda-dsp) sound card. Audio is working via > line/headphone output, only. It seems that quite a number of models of this generation are affected, see also bug #213641 and the comments on other models in this thread. Perhaps a much more fundamental change is needed here, rather than looking at each variation individually?
(In reply to Niclas from comment #157) > No luck here with making the sleep working. > > Anyone know if someone is in contact with the manufacturer? Hi Niclas I have also galaxy book pro 13.3 LTE. THANKS for the sound fix. Did you get sleep / suspend to work? Been struggling with that for days now. Got ubuntu 21.04. /Sl
hello, running Fedora 34, 5.13.12 on thinkpad X1 Nano. Speakers only work when i put "options snd-intel-dspcfg dsp_driver=1" in modprobe. I could not make Microphone work in any way. detected card is ALC287 should be ALC3306 according to https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_X1_Nano_Gen_1/ThinkPad_X1_Nano_Gen_1_Spec.PDF tried both pipewire and pulseaudio. which patch should i try ? Thanks,
What needs to be done, to add these patches to next release of kernel?
Mainly I need to follow up with Takashi's suggestions here: https://lore.kernel.org/alsa-devel/s5hy2ah5dkb.wl-tiwai@suse.de/ I just haven't had any free time as of late. I *might* be able to work on it this weekend. On 9/8/21 7:47 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #422 from Jakub Przystasz (jakub.przystasz@gmail.com) --- > What needs to be done, to add these patches to next release of kernel? >
Hello.. I've recently got a legion 7 16achg6, trying to fix the speakers so if you'd like me to test something then let me know. Also, does the kernel patches work for the 16achg6? Or not?
On 9/10/21 1:08 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > mba (mba380@outlook.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |mba380@outlook.com > > --- Comment #424 from mba (mba380@outlook.com) --- > Hello.. I've recently got a legion 7 16achg6, trying to fix the speakers so > if > you'd like me to test something then let me know. > > Also, does the kernel patches work for the 16achg6? Or not? > Unfortunately, hey do not work and will not ever work. The 16achg6's sound issue is an entirely separate. Hopefully we'll get a driver out of Cirrus Logic for this.
(In reply to Cameron Berkenpas from comment #425) Oh... well that's a bummer. Do you think there's a possibility of us getting a driver update or will we just be ignored? Do they care about these issues? > On 9/10/21 1:08 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > mba (mba380@outlook.com) changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > CC| |mba380@outlook.com > > > > --- Comment #424 from mba (mba380@outlook.com) --- > > Hello.. I've recently got a legion 7 16achg6, trying to fix the speakers so > > if > > you'd like me to test something then let me know. > > > > Also, does the kernel patches work for the 16achg6? Or not? > > > Unfortunately, hey do not work and will not ever work. The 16achg6's > sound issue is an entirely separate. > > Hopefully we'll get a driver out of Cirrus Logic for this.
Created attachment 298759 [details] linux-5.14-legion-sound-0.0.12.patch - 5.14.x support 0.0.12 patch is the 11 patches combined into a single patch since everything appears to be good, and updated for Linux 5.14.3. The 0.0.11 patches don't apply to 5.14.x (or at least not 5.14.3). I'm getting to the point where I'm going to try and submit this for inclusion in the kernel again, so let me know if there are issues.
Progress has been made on getting the patch accepted: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189649.html I'll post an updated patch based on Takashi's feedback today or tomorrow probably. I'd like to give credit to those who helped. I *think* I need full names in order to do it. So if I don't have your full name and you want to be included, please let me know (you can email me directly for that if you like). So far I have in no particular order: Vincent Morel <dantahoua _at_ gmail.com> andreas _@_ mac-au.eu (need your full name) sycxyc+kernel _at_ yandex.com (need your full name) Max Christian Pohle <max _at_ entwicklerseite.de> I don't think that's exhaustive. If I missed you on the list, it's because I'm generally a pretty busy person so please reach out (either on here or email me directly if you prefer) if you want to be included. If I already have your full name on the above let list, let me know if you don't want to be included. For users whose names I'm still missing, you won't be included unless I hear from you (or someone credibly lets me know the full names aren't needed).
Created attachment 298789 [details] linux-legion-sound-0.0.13.patch auto mute is now properly disabled as per Takashi's suggestion. This patch is against the latest Linus tree, but applies against 5.14.3 just fine. This patch includes the presumptive commit message and credit given to various people. Going through the Linux commit log, it seems full names and email addresses aren't needed, so I have a thank you list in the patch with the following: Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle If you want to be mentioned (or if you know of someone who you think that should be included), please let me know! Here's a link to the patch submission: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189698.html
Not commented for a while, but thanks everyone! :) Hope this patch gets in the Kernel. :)
Hello! Which method/patch in this long list fixed your sound issue on the Galaxy Book? I have the 12 LTE and are looking for a solution too. :) Kind regards, Andreas
Unfortunately, your model of laptop is not supported by any of the patches here. On 9/16/21 9:19 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Andreas (ate@muenster.de) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |ate@muenster.de > > --- Comment #431 from Andreas (ate@muenster.de) --- > Hello! > > Which method/patch in this long list fixed your sound issue on the Galaxy > Book? > I have the 12 LTE and are looking for a solution too. :) > > Kind regards, > Andreas >
(In reply to Cameron Berkenpas from comment #432) > Unfortunately, your model of laptop is not supported by any of the > patches here. > > On 9/16/21 9:19 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > Andreas (ate@muenster.de) changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > CC| |ate@muenster.de > > > > --- Comment #431 from Andreas (ate@muenster.de) --- > > Hello! > > > > Which method/patch in this long list fixed your sound issue on the Galaxy > > Book? > > I have the 12 LTE and are looking for a solution too. :) > > > > Kind regards, > > Andreas > > Hey Cameron, thanks for your answer! The citation of the method would have been helpful despite the fact that I won't find a direct fix for my device. Cheers, Andreas
This is a work in progress. I haven't had the time to clean up and correct the work I have in a branch. https://github.com/thiagotei/linux-realtek-alc287 You can also search around for how to use JCS' Qemu. This bug itself has most of the information on this approach. Getting the hardware to work under the Windows VM may or may not be difficult. On the 2020 Legion 7i, it took a fair amount of effort. On my current 2021 Lenovo Legion 7i, Windows immediately recognized the correct driver for the sound card. Of course, this method may not work at all on your laptop. For example, on both the AMD and Intel versions of the 2021 Legion, the method doesn't work as the amp is a separate device on the i2c bus and therefore isn't initialized by HDA verbs. I don't know of any methods to capture communication over the i2c bus, and I don't really have the time anymore to try even if I did. On 9/17/21 6:48 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #433 from Andreas (ate@muenster.de) --- > (In reply to Cameron Berkenpas from comment #432) >> Unfortunately, your model of laptop is not supported by any of the >> patches here. >> >> On 9/16/21 9:19 AM, bugzilla-daemon@bugzilla.kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> Andreas (ate@muenster.de) changed: >>> >>> What |Removed |Added >>> >> ---------------------------------------------------------------------------- >>> CC| |ate@muenster.de >>> >>> --- Comment #431 from Andreas (ate@muenster.de) --- >>> Hello! >>> >>> Which method/patch in this long list fixed your sound issue on the Galaxy >>> Book? >>> I have the 12 LTE and are looking for a solution too. :) >>> >>> Kind regards, >>> Andreas >>> > Hey Cameron, > > thanks for your answer! The citation of the method would have been helpful > despite the fact that I won't find a direct fix for my device. > > Cheers, > Andreas >
Hello! Just want to say that I had to re-install my system. So I patched kernel 5.14.3 with the latest patch and sadly I have no sound. Note that if I apply my verb, sound is working, so the verbs still good. I tried to replace in the 13S Gen2 part of the patch the "0xb020" address back to "0x20" just in case, but no more luck... Could it be verbs from other soundcard in the patch? Can anyone with a Lenovo 13s Gen2 could try to patch a kernel with this patch?
Was the latest patch tested on your previous install? This is very unfortunate as this patch appears that it just made it into Linux stable. On 10/4/21 8:56 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #435 from Vincent Morel (dantahoua@gmail.com) --- > Hello! Just want to say that I had to re-install my system. > So I patched kernel 5.14.3 with the latest patch and sadly I have no sound. > Note that if I apply my verb, sound is working, so the verbs still good. > I tried to replace in the 13S Gen2 part of the patch the "0xb020" address > back > to "0x20" just in case, but no more luck... > Could it be verbs from other soundcard in the patch? Can anyone with a Lenovo > 13s Gen2 could try to patch a kernel with this patch? >
(In reply to Cameron Berkenpas from comment #436) > Was the latest patch tested on your previous install? > > This is very unfortunate as this patch appears that it just made it into > Linux stable. > > On 10/4/21 8:56 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #435 from Vincent Morel (dantahoua@gmail.com) --- > > Hello! Just want to say that I had to re-install my system. > > So I patched kernel 5.14.3 with the latest patch and sadly I have no sound. > > Note that if I apply my verb, sound is working, so the verbs still good. > > I tried to replace in the 13S Gen2 part of the patch the "0xb020" address > > back > > to "0x20" just in case, but no more luck... > > Could it be verbs from other soundcard in the patch? Can anyone with a > Lenovo > > 13s Gen2 could try to patch a kernel with this patch? > > Aaaarrrg, I was overloaded and cannot make some test... I made some test yesterday, tried to compile 5.14.3 two time (after tweaking the patch file) but did not have any good result. Maybe I could try with another kernel or maybe it's a problem on my side when compiling but I doubt as it worked with my old 5.12.3 kernel (but it was the old patch with just the verb for the 13s). I will download the other patch version just to try and see, just a little time consuming to wait the kernel to be compiled each time! :)
(In reply to Cameron Berkenpas from comment #436) > Was the latest patch tested on your previous install? > > This is very unfortunate as this patch appears that it just made it into > Linux stable. > > On 10/4/21 8:56 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #435 from Vincent Morel (dantahoua@gmail.com) --- > > Hello! Just want to say that I had to re-install my system. > > So I patched kernel 5.14.3 with the latest patch and sadly I have no sound. > > Note that if I apply my verb, sound is working, so the verbs still good. > > I tried to replace in the 13S Gen2 part of the patch the "0xb020" address > > back > > to "0x20" just in case, but no more luck... > > Could it be verbs from other soundcard in the patch? Can anyone with a > Lenovo > > 13s Gen2 could try to patch a kernel with this patch? > > Just an update. I compiled the 5.14.3 kernel with the last patch BUT I replaced all the "verb" in the 13S section with the one in the .009 patch (the one with 0x20,0x4b0,0x20) and it's working!!! So it seems replacing "0x20,ac_verb_set_proc_coef, 0xb020" with "0x20,0x4b0,0x20" made the patch works for the 13s... Weird... That's the only thing I changed in the patch file...
Well, a patch won't be accepted with the verbs like that. Maybe you can try something else and/or someone else has some insight on this. I have no way to test this on my end. On 10/5/2021 2:09 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > Just an update. I compiled the 5.14.3 kernel with the last patch BUT I > replaced > all the "verb" in the 13S section with the one in the .009 patch (the one > with > 0x20,0x4b0,0x20) and it's working!!! So it seems replacing > "0x20,ac_verb_set_proc_coef, 0xb020" with "0x20,0x4b0,0x20" made the patch > works for the 13s... Weird... > That's the only thing I changed in the patch file...
(In reply to Takashi Iwai from comment #381) > Sorry, it was a typo of AC_VERB_SET_PROC_COEF. > > In short, { 0x4XX, 0xYY } is equivalent with { AC_VERB_SET_PROC_COEF, 0xXXYY > } > and { 0x5XX, 0xYY } is a combo of { AC_VERB_SET_COEF_INDEX, 0xXXYY } Maybe Takashi Iwai could enlight us on this issue? I'll make some other test and research...
Both must be identical from the code perspective. But, looking at the verb sequence there, I doubt whether the 0xb020 call is really correct. If it follows the similar pattern as others, it should be rather setting the COEF index 0x26 instead, i.e.: --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -8345,7 +8345,7 @@ static const struct hda_fixup alc269_fixups[] = { .v.verbs = (const struct hda_verb[]) { { 0x20, AC_VERB_SET_COEF_INDEX, 0x24 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x41 }, - { 0x20, AC_VERB_SET_PROC_COEF, 0xb020 }, + { 0x20, AC_VERB_SET_COEF_INDEX, 0x26 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x2 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x0 }, { 0x20, AC_VERB_SET_PROC_COEF, 0x0 },
(In reply to Takashi Iwai from comment #441) > Both must be identical from the code perspective. > > But, looking at the verb sequence there, I doubt whether the 0xb020 call is > really correct. If it follows the similar pattern as others, it should be > rather setting the COEF index 0x26 instead, i.e.: > > --- a/sound/pci/hda/patch_realtek.c > +++ b/sound/pci/hda/patch_realtek.c > @@ -8345,7 +8345,7 @@ static const struct hda_fixup alc269_fixups[] = { > .v.verbs = (const struct hda_verb[]) { > { 0x20, AC_VERB_SET_COEF_INDEX, 0x24 }, > { 0x20, AC_VERB_SET_PROC_COEF, 0x41 }, > - { 0x20, AC_VERB_SET_PROC_COEF, 0xb020 }, > + { 0x20, AC_VERB_SET_COEF_INDEX, 0x26 }, > { 0x20, AC_VERB_SET_PROC_COEF, 0x2 }, > { 0x20, AC_VERB_SET_PROC_COEF, 0x0 }, > { 0x20, AC_VERB_SET_PROC_COEF, 0x0 }, That make sense! I translated this into simple verb to test on a config with no sound and it works. Just compiled a new kernel with the update and it works also! Thanks Takashi Iwai! Is this update will be be pushed to the next kernel?
Nope. I'm going to have to generate a patch from this and submit it to alsa-devel. Since it seems the previous patch is in, this will just be a one line fix. I might have time this weekend. On 10/6/21 12:27 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #442 from Vincent Morel (dantahoua@gmail.com) --- > (In reply to Takashi Iwai from comment #441) >> Both must be identical from the code perspective. >> >> But, looking at the verb sequence there, I doubt whether the 0xb020 call is >> really correct. If it follows the similar pattern as others, it should be >> rather setting the COEF index 0x26 instead, i.e.: >> >> --- a/sound/pci/hda/patch_realtek.c >> +++ b/sound/pci/hda/patch_realtek.c >> @@ -8345,7 +8345,7 @@ static const struct hda_fixup alc269_fixups[] = { >> .v.verbs = (const struct hda_verb[]) { >> { 0x20, AC_VERB_SET_COEF_INDEX, 0x24 }, >> { 0x20, AC_VERB_SET_PROC_COEF, 0x41 }, >> - { 0x20, AC_VERB_SET_PROC_COEF, 0xb020 }, >> + { 0x20, AC_VERB_SET_COEF_INDEX, 0x26 }, >> { 0x20, AC_VERB_SET_PROC_COEF, 0x2 }, >> { 0x20, AC_VERB_SET_PROC_COEF, 0x0 }, >> { 0x20, AC_VERB_SET_PROC_COEF, 0x0 }, > That make sense! I translated this into simple verb to test on a config with > no > sound and it works. > Just compiled a new kernel with the update and it works also! > > Thanks Takashi Iwai! Is this update will be be pushed to the next kernel? >
Created attachment 299155 [details] linux-13s-gen2-sound-0.0.1.patch This should fix sound on the Lenovo 13s gen2. I know it's a single line change, but let's have confirmation before I submit another patch. This is against the latest Torvald's tree, but applies against 5.14.11 with a minor offset. Vince, it seems you're the only one on this bug who can test. Can you let us know? Anyone else's results are also welcome of course!
(In reply to Cameron Berkenpas from comment #444) > Created attachment 299155 [details] > linux-13s-gen2-sound-0.0.1.patch > > This should fix sound on the Lenovo 13s gen2. > > I know it's a single line change, but let's have confirmation before I > submit another patch. > > This is against the latest Torvald's tree, but applies against 5.14.11 with > a minor offset. > > Vince, it seems you're the only one on this bug who can test. Can you let us > know? Anyone else's results are also welcome of course! Gonna check it monday. :) Should work as this is exactly what I did before compiling the kernel...
(In reply to Cameron Berkenpas from comment #444) > Created attachment 299155 [details] > linux-13s-gen2-sound-0.0.1.patch > > This should fix sound on the Lenovo 13s gen2. > > I know it's a single line change, but let's have confirmation before I > submit another patch. > > This is against the latest Torvald's tree, but applies against 5.14.11 with > a minor offset. > > Vince, it seems you're the only one on this bug who can test. Can you let us > know? Anyone else's results are also welcome of course! I can confirm that it is working for me! I applied the patch against 5.14.11 and the sound is working on Lenovo 13S Gen 2.
Does anyone know if the existing patches work for the Legion 7 Gen 6 AMD? I'm considering getting one.
There are no patches to get sound working on the 2021 AMD Legion 7. On that laptop (and it's Intel cousin), there's a Cirrus Logic amp chip that needs to be initialized over the i2c bus, which is very different from the approach here. Hopefully we'll eventually see a driver from Cirrus Logic. On 10/10/21 10:54 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #447 from pyronavi@gmail.com --- > Does anyone know if the existing patches work for the Legion 7 Gen 6 AMD? I'm > considering getting one. >
(In reply to Cameron Berkenpas from comment #448) > There are no patches to get sound working on the 2021 AMD Legion 7. On > that laptop (and it's Intel cousin), there's a Cirrus Logic amp chip > that needs to be initialized over the i2c bus, which is very different > from the approach here. > > Hopefully we'll eventually see a driver from Cirrus Logic. > > On 10/10/21 10:54 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #447 from pyronavi@gmail.com --- > > Does anyone know if the existing patches work for the Legion 7 Gen 6 AMD? > I'm > > considering getting one. > > Thanks a bunch for the quick reply!
Patch submitted: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-October/190923.html We'll see what the feedback is. I forgot to include a link to reference this bug. On 10/10/21 9:47 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #446 from waterproof93@outlook.com --- > (In reply to Cameron Berkenpas from comment #444) >> Created attachment 299155 [details] >> linux-13s-gen2-sound-0.0.1.patch >> >> This should fix sound on the Lenovo 13s gen2. >> >> I know it's a single line change, but let's have confirmation before I >> submit another patch. >> >> This is against the latest Torvald's tree, but applies against 5.14.11 with >> a minor offset. >> >> Vince, it seems you're the only one on this bug who can test. Can you let us >> know? Anyone else's results are also welcome of course! > > I can confirm that it is working for me! > I applied the patch against 5.14.11 and the sound is working on Lenovo 13S > Gen > 2. >
(In reply to waterproof93 from comment #446) > (In reply to Cameron Berkenpas from comment #444) > > Created attachment 299155 [details] > > linux-13s-gen2-sound-0.0.1.patch > > > > This should fix sound on the Lenovo 13s gen2. > > > > I know it's a single line change, but let's have confirmation before I > > submit another patch. > > > > This is against the latest Torvald's tree, but applies against 5.14.11 with > > a minor offset. > > > > Vince, it seems you're the only one on this bug who can test. Can you let > us > > know? Anyone else's results are also welcome of course! > > > I can confirm that it is working for me! > I applied the patch against 5.14.11 and the sound is working on Lenovo 13S > Gen 2. Great! You beat me on this one! That's perfect! As I previously compile my kernel with this moded line and it worked, I guess we could now say it's working for sure! Great team work!
Hi, I sent an RFC about Legion 7 16ACHg6 laptop, which lays out the architecture for how to configure the Cirrus Amplifier. https://lkml.org/lkml/2021/10/8/344 As soon as we get some direction from Mark Brown and Takashi Iwai we will be providing support for that laptop. Thanks Lucas Tanure
Hello Lucas, Ecstatic to see this moving along! I'd love to do what I can to ensure that the Lenovo Legion 7i 16ITHg6 (the Intel counterpart to the 16ACHg6) is supported by this as well. I suspect it wouldn't be substantially different to support the 16ITHg6. I don't have a lot of time these days, but I'm happy to do what I can there. Thanks!!! On 10/11/21 3:48 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Lucas Tanure (tanure@linux.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |tanure@linux.com > > --- Comment #452 from Lucas Tanure (tanure@linux.com) --- > Hi, > > I sent an RFC about Legion 7 16ACHg6 laptop, which lays out the architecture > for how to configure the Cirrus Amplifier. > > https://lkml.org/lkml/2021/10/8/344 > > As soon as we get some direction from Mark Brown and Takashi Iwai we will be > providing support for that laptop. > > Thanks > Lucas Tanure >
Hello there, i have a new Thinkbook S13-IML and expierience the same sound issue under Manjaro. As i am still a beginner with linux, i am not totally sure if i understand the previous posts correctly - has this issue been solved and will this solution be available for Manjaro in the foreseeable future? I was already going to the return the besides the sound and microphone issue flawlessly working machine. Thanks for your reply.
If the S13-IML is a model of 13S, then eventually sound will start working as the patches make it into your distros kernel. Can you run "alsa-info" and provide us with a link? That way I can verify if there's a chance your sound will fixed by these patches. Googling for "S13-IML" led me to this: https://www.notebookcheck.net/Lenovo-ThinkBook-13s-IML-20RR0003GE.503100.0.html Did you make a typo? On 10/15/21 5:09 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Robert (erazerhead99@googlemail.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |erazerhead99@googlemail.com > > --- Comment #454 from Robert (erazerhead99@googlemail.com) --- > Hello there, > > i have a new Thinkbook S13-IML and expierience the same sound issue under > Manjaro. As i am still a beginner with linux, i am not totally sure if i > understand the previous posts correctly - has this issue been solved and will > this solution be available for Manjaro in the foreseeable future? > > I was already going to the return the besides the sound and microphone issue > flawlessly working machine. Thanks for your reply. >
(In reply to Cameron Berkenpas from comment #455) > If the S13-IML is a model of 13S, then eventually sound will start > working as the patches make it into your distros kernel. > > Can you run "alsa-info" and provide us with a link? That way I can > verify if there's a chance your sound will fixed by these patches. > > Googling for "S13-IML" led me to this: > https://www.notebookcheck.net/Lenovo-ThinkBook-13s-IML-20RR0003GE.503100.0. > html > > Did you make a typo? > > On 10/15/21 5:09 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > Robert (erazerhead99@googlemail.com) changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > CC| > |erazerhead99@googlemail.com > > > > --- Comment #454 from Robert (erazerhead99@googlemail.com) --- > > Hello there, > > > > i have a new Thinkbook S13-IML and expierience the same sound issue under > > Manjaro. As i am still a beginner with linux, i am not totally sure if i > > understand the previous posts correctly - has this issue been solved and > will > > this solution be available for Manjaro in the foreseeable future? > > > > I was already going to the return the besides the sound and microphone > issue > > flawlessly working machine. Thanks for your reply. > > Hello, Cameron Berkenpas can you tell if current fix will work for X1 Nano as well ? X1 nano runs ALC3306. full spec: https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_X1_Nano_Gen_1/ThinkPad_X1_Nano_Gen_1_Spec.PDF Thanks, Kind Regards, George.
I'm guessing probably not. The issue goes beyond supporting the ALC3306 (which is really just an ALC287). Linux already supports this codec (and probably for quite a while too). The issue is that these newer laptops also need their amplifier chips initialized to enable speaker output. All of the laptops whose support were added with these patches had different initialization sequences. Then there are the 2021 Lenovo Legion 7 laptops (both the AMD and Intel models). These have amp chips that must be initialized through an entirely different process. If the X1 Nano can have its speaker output enable through an hda verb initialization sequence like the laptops supported in these patches, then the same technical process could be used to reverse engineer support. The PDF linked says the X1 Nano has Dolby Atmos just like the 2020 Legion 7 which makes me hopeful that the same process could be used. However, there's no way to know with any certainty if this would work without having the laptop in hand and trying it. I still haven't been able to complete the documentation on how to perform this process due to a pretty severe lack of time for the past few months, but I'll get to it eventually. Do you already have an X1 Nano or you're just considering getting one? I really like Lenovo's hardware... I just really wish they'd be more helpful. I get that they don't want to provide technical support for Linux across their entire lineup, but I think all that most/all of us want is working hardware and not any sort of software support. On 10/15/21 7:35 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #456 from Giorgi (gioqoridze8@gmail.com) --- > (In reply to Cameron Berkenpas from comment #455) >> If the S13-IML is a model of 13S, then eventually sound will start >> working as the patches make it into your distros kernel. >> >> Can you run "alsa-info" and provide us with a link? That way I can >> verify if there's a chance your sound will fixed by these patches. >> >> Googling for "S13-IML" led me to this: >> https://www.notebookcheck.net/Lenovo-ThinkBook-13s-IML-20RR0003GE.503100.0. >> html >> >> Did you make a typo? >> >> On 10/15/21 5:09 AM, bugzilla-daemon@bugzilla.kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> Robert (erazerhead99@googlemail.com) changed: >>> >>> What |Removed |Added >>> >> ---------------------------------------------------------------------------- >>> CC| >> |erazerhead99@googlemail.com >>> --- Comment #454 from Robert (erazerhead99@googlemail.com) --- >>> Hello there, >>> >>> i have a new Thinkbook S13-IML and expierience the same sound issue under >>> Manjaro. As i am still a beginner with linux, i am not totally sure if i >>> understand the previous posts correctly - has this issue been solved and >> will >>> this solution be available for Manjaro in the foreseeable future? >>> >>> I was already going to the return the besides the sound and microphone >> issue >>> flawlessly working machine. Thanks for your reply. >>> > Hello, > > Cameron Berkenpas can you tell if current fix will work for X1 Nano as well ? > X1 nano runs ALC3306. > > full spec: > > https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_X1_Nano_Gen_1/ThinkPad_X1_Nano_Gen_1_Spec.PDF > > > Thanks, > Kind Regards, George. >
I made a typo, i was talking about the Thinkbook 13s - and could resolve the issue. Installing sof-firmware and switching to the kernel 5.15rc3 made the sound working. Thanks all for the help.
On 10/15/21 11:15 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #458 from Robert (erazerhead99@googlemail.com) --- > I made a typo, i was talking about the Thinkbook 13s - and could resolve the > issue. Installing sof-firmware and switching to the kernel 5.15rc3 made the > sound working. > > Thanks all for the help. > Are you sure it's rc3? It seems even rc5 doesn't have any of the patches I submitted. "uname -r" should provide the exact version (if you didn't already know). 5.14.12 has my first patch, but does not yet have the 2nd patch to correctly enable speaker output on the 13s gen2. I only submitted the patch patch a week ago so it takes a bit of time to trickle down. I'm not familiar with sof-firmware, but it seems to include firmware needed to get audio working on some Intel systems. Maybe someone else with a 13s Gen2 can confirm if that firmware alone is enough to get audio working once we confirm the kernel version. Now I'm really curious!
I am sure. Kernel 5.15rc3 on Manjaro. I am not sure if the installation of sof-firmware or the Kernel made the difference, will report back after testing.
Did you compile your own kernel or is this a Manjaro package? On 10/15/21 12:01 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #460 from Robert (erazerhead99@googlemail.com) --- > I am sure. Kernel 5.15rc3 on Manjaro. I am not sure if the installation of > sof-firmware or the Kernel made the difference, will report back after > testing. >
This is the official Manjaro Kernel. My computer model is a ThinkBook 13s-IML and i can confirm fully working sound.
I suspect it will work without the sof firmware, but thank you for confirming! On 10/15/21 2:49 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #462 from Robert (erazerhead99@googlemail.com) --- > This is the official Manjaro Kernel. My computer model is a ThinkBook 13s-IML > and i can confirm fully working sound. >
Hi, I've done my best to read through this thread, so I apologize if I've misunderstood. But as far as I understand the 2021 AMD Legion 7 has amplifier chips that are currently not supported and no current information exists as to how they operate? I have an AMD 2021 Legion 7 and can help out if anyone is allocating time to this issue. Unfortunately I'm not a driver/kernel developer, but I can run scripts, retrieve information and test potential fixes. I do appreciate the work that has been put into the other models!
I have great news for you. Lucas Tanure (who has posted on this bug about this recently) is working on this right now: https://www.spinics.net/lists/alsa-devel/msg132632.html His work is still in the very early stages as there's back and forth to determine the best way to implement support for these chips. I think we're still a ways out from working support, but at least things are moving in the right direction. This bug has gotten very long, and I also feel like this is really a separate issue. Would it make more sense to start a new bug for tracking the support of the Cirrus Logic cs35l41 for laptops? And this isn't technically a bug. Can we file kernel bugs that are actually driver (feature) requests? On 10/16/21 9:01 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Jack Brennan (social@sourcenix.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |social@sourcenix.com > > --- Comment #464 from Jack Brennan (social@sourcenix.com) --- > Hi, > > I've done my best to read through this thread, so I apologize if I've > misunderstood. But as far as I understand the 2021 AMD Legion 7 has amplifier > chips that are currently not supported and no current information exists as > to > how they operate? > > I have an AMD 2021 Legion 7 and can help out if anyone is allocating time to > this issue. Unfortunately I'm not a driver/kernel developer, but I can run > scripts, retrieve information and test potential fixes. > > I do appreciate the work that has been put into the other models! >
Thanks Cameron, that is great news! I'll keep an eye on that thread. (In reply to Cameron Berkenpas from comment #465) > I have great news for you. Lucas Tanure (who has posted on this bug > about this recently) is working on this right now: > https://www.spinics.net/lists/alsa-devel/msg132632.html > > His work is still in the very early stages as there's back and forth to > determine the best way to implement support for these chips. I think > we're still a ways out from working support, but at least things are > moving in the right direction. > > This bug has gotten very long, and I also feel like this is really a > separate issue. Would it make more sense to start a new bug for tracking > the support of the Cirrus Logic cs35l41 for laptops? > > And this isn't technically a bug. Can we file kernel bugs that are > actually driver (feature) requests? > > On 10/16/21 9:01 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > Jack Brennan (social@sourcenix.com) changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > CC| |social@sourcenix.com > > > > --- Comment #464 from Jack Brennan (social@sourcenix.com) --- > > Hi, > > > > I've done my best to read through this thread, so I apologize if I've > > misunderstood. But as far as I understand the 2021 AMD Legion 7 has > amplifier > > chips that are currently not supported and no current information exists as > > to > > how they operate? > > > > I have an AMD 2021 Legion 7 and can help out if anyone is allocating time > to > > this issue. Unfortunately I'm not a driver/kernel developer, but I can run > > scripts, retrieve information and test potential fixes. > > > > I do appreciate the work that has been put into the other models! > >
Cameron, I already have x1 nano, running fedora 34 with sway. modifying modprobe with: options snd-intel-dspcfg dsp_driver=1 options snd-hda-intel model=thinkpad enables audio out, but mic is not working and audio out is horrible with constant static in background. I will gladly contribute in reverse engineering, but do not really have any prior knowledge in that regrade. Currently holding RHCE and done lot of tinkering with swaywm/i3wm hope it helps. Thanks, Kind Regards, George. (In reply to Cameron Berkenpas from comment #457) > I'm guessing probably not. The issue goes beyond supporting the ALC3306 > (which is really just an ALC287). Linux already supports this codec (and > probably for quite a while too). The issue is that these newer laptops > also need their amplifier chips initialized to enable speaker output. > > All of the laptops whose support were added with these patches had > different initialization sequences. > > Then there are the 2021 Lenovo Legion 7 laptops (both the AMD and Intel > models). These have amp chips that must be initialized through an > entirely different process. > > If the X1 Nano can have its speaker output enable through an hda verb > initialization sequence like the laptops supported in these patches, > then the same technical process could be used to reverse engineer support. > > The PDF linked says the X1 Nano has Dolby Atmos just like the 2020 > Legion 7 which makes me hopeful that the same process could be used. > > However, there's no way to know with any certainty if this would work > without having the laptop in hand and trying it. > > I still haven't been able to complete the documentation on how to > perform this process due to a pretty severe lack of time for the past > few months, but I'll get to it eventually. > > Do you already have an X1 Nano or you're just considering getting one? > > I really like Lenovo's hardware... I just really wish they'd be more > helpful. I get that they don't want to provide technical support for > Linux across their entire lineup, but I think all that most/all of us > want is working hardware and not any sort of software support. > > On 10/15/21 7:35 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #456 from Giorgi (gioqoridze8@gmail.com) --- > > (In reply to Cameron Berkenpas from comment #455) > >> If the S13-IML is a model of 13S, then eventually sound will start > >> working as the patches make it into your distros kernel. > >> > >> Can you run "alsa-info" and provide us with a link? That way I can > >> verify if there's a chance your sound will fixed by these patches. > >> > >> Googling for "S13-IML" led me to this: > >> > https://www.notebookcheck.net/Lenovo-ThinkBook-13s-IML-20RR0003GE.503100.0. > >> html > >> > >> Did you make a typo? > >> > >> On 10/15/21 5:09 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>> > >>> Robert (erazerhead99@googlemail.com) changed: > >>> > >>> What |Removed |Added > >>> > >> > ---------------------------------------------------------------------------- > >>> CC| > >> |erazerhead99@googlemail.com > >>> --- Comment #454 from Robert (erazerhead99@googlemail.com) --- > >>> Hello there, > >>> > >>> i have a new Thinkbook S13-IML and expierience the same sound issue under > >>> Manjaro. As i am still a beginner with linux, i am not totally sure if i > >>> understand the previous posts correctly - has this issue been solved and > >> will > >>> this solution be available for Manjaro in the foreseeable future? > >>> > >>> I was already going to the return the besides the sound and microphone > >> issue > >>> flawlessly working machine. Thanks for your reply. > >>> > > Hello, > > > > Cameron Berkenpas can you tell if current fix will work for X1 Nano as well > ? > > X1 nano runs ALC3306. > > > > full spec: > > > > > https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_X1_Nano_Gen_1/ThinkPad_X1_Nano_Gen_1_Spec.PDF > > > > > > Thanks, > > Kind Regards, George. > >
Hi, Another patch series for Legion 7 16ACHg6 laptop: https://www.spinics.net/lists/alsa-devel/msg132941.html Thanks Lucas
Thanks for the update, Lucas! I know you already have some feedback on this next RFC patch, but how close are we to a functional driver? On 10/20/21 02:05, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #468 from Lucas Tanure (tanure@linux.com) --- > Hi, > > Another patch series for Legion 7 16ACHg6 laptop: > > https://www.spinics.net/lists/alsa-devel/msg132941.html > > Thanks > Lucas >
Hi, It will take a few weeks for sure. Because this is not my top priority laptop to support. I hope that by the next start of the year will be done, but that depends on how the maintainers review my code. The last comments from Takashi are complex and require changes that I don't know yet how to do, but we will get there. Thanks Lucas Tanure
I can also confirm that sound is working on the thinkbook 13s gen2 on 5.14.2 on arch with sof-firmware installed and no other patches applied.
I'm just reporting, sound is working on newest kernel from Fedora, on ThinkBook 13S Gen2: 5.14.12-200.fc34.x86_64 No patch applied, no other firmware or tweaks. Was the newest patch merged on the kernel?
The 13s fix went out recently and made it into the latest round of kernel updates (ie, 5.14.14). It's probable that this made it out into Fedora's kernel, especially if updated relatively recently. On 10/21/21 07:40, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #472 from waterproof93@outlook.com --- > I'm just reporting, sound is working on newest kernel from Fedora, on > ThinkBook > 13S Gen2: > 5.14.12-200.fc34.x86_64 > > No patch applied, no other firmware or tweaks. > > Was the newest patch merged on the kernel? >
George, I haven't forgotten about you and so finally I've made updates to the documentation: https://github.com/thiagotei/linux-realtek-alc287/tree/cameron If you're up to it, hopefully that will get you on your way to debugging this issue. It's also possible this won't work for the X1 Nano... From your alsa-info, we might be able to see if you have any Cirrus Logic amp chips to worry about it. But the fact that it has the ALC3306 makes me hopeful. To everyone, I've been really busy the last few months so it's been really hard for me to find the time to work on this. These updates are still in my branch as I'm sure there's more to cleanup. If you come across typos, grammatical errors, things that need to be clarified, etc feel free to let me know (either on through GitHub or you can even email me. On 10/17/21 23:24, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #467 from Giorgi (gioqoridze8@gmail.com) --- > Cameron, > > I already have x1 nano, running fedora 34 with sway. > > modifying modprobe with: > > options snd-intel-dspcfg dsp_driver=1 > options snd-hda-intel model=thinkpad > > enables audio out, but mic is not working and audio out is horrible with > constant static in background. > > I will gladly contribute in reverse engineering, but do not really have any > prior knowledge in that regrade. > > Currently holding RHCE and done lot of tinkering with swaywm/i3wm hope it > helps. > > Thanks, > Kind Regards, George. >
Hello. Manjaro Pahvo 21. kernel 5.14.10 Updates installed, Sound WORKS!
Fedora 34 with kernel 5.14 (after the initial update), sound works on Lenovo Yoga 7i!
Thank you ! Sound Works! On Lenovo Yoga 7i running Ubuntu 21.10 with update to Kernel 5.13
logged in to say thank you, sound works with 5.14.14-manjaro :)
Would it be possible to add the IdeaPad/Yoga Slim 9i (0x17aa, 0x3834) to the list where the ALC287_FIXUP_YOGA7_14ITL_SPEAKERS quirk is applied? I tested this with a kernel based on 5.15.1 and it works perfectly.
I really don't have a lot of time right now... But if you share your alsa-info, I could grab the more complete model name of your laptop. Or if you're up to it, you could submit a patch yourself: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html You would need to subscribe and submit your patch to the alsa-devel mailing list. On 11/10/21 01:59, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Bart (kernel@tarmack.eu) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |kernel@tarmack.eu > > --- Comment #479 from Bart (kernel@tarmack.eu) --- > Would it be possible to add the IdeaPad/Yoga Slim 9i (0x17aa, 0x3834) to the > list where the ALC287_FIXUP_YOGA7_14ITL_SPEAKERS quirk is applied? I tested > this with a kernel based on 5.15.1 and it works perfectly. >
i've followed this thread since january 2021 and also here to confirm recent ubuntu kernel update solved this i'm glad we held out, boys!!!!! Lenovo Legion 7i 15 w/ Realtek ALC287
I can confirm that this change must have been delivered as part of Ubuntu 5.13.0-21. It fixed it for me. Lenovo Yoga 7 14ITL5 and ALC287 chip.
I see that people with the ALC287 are reporting their sound issues to be fixed.. Can anyone with a legion 7 16achg6 confirm this? Unless you're already mentioned it, I couldn't find it.. I believe it has the same chipset, alc287. Thank you.
The 16ITHg6 and 16achg6 are specifically not supported by any of these patches as they require a very different approach. Lucas Tanure is working on support and hopes to have something preliminary out early next year. On 11/12/21 08:39, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #483 from mba (mba380@outlook.com) --- > I see that people with the ALC287 are reporting their sound issues to be > fixed.. > Can anyone with a legion 7 16achg6 confirm this? Unless you're already > mentioned it, I couldn't find it.. > > I believe it has the same chipset, alc287. > > Thank you. >
It works on my Legion Ci7 82EHCTO1WW now, running Ubuntu 20.04.3 and default kernel 5.4.0-90. Thank you
(In reply to Cameron Berkenpas from comment #484) > The 16ITHg6 and 16achg6 are specifically not supported by any of these > patches as they require a very different approach. Lucas Tanure is > working on support and hopes to have something preliminary out early > next year. > > On 11/12/21 08:39, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #483 from mba (mba380@outlook.com) --- > > I see that people with the ALC287 are reporting their sound issues to be > > fixed.. > > Can anyone with a legion 7 16achg6 confirm this? Unless you're already > > mentioned it, I couldn't find it.. > > > > I believe it has the same chipset, alc287. > > > > Thank you. > > Okay, great! Thank you! Do you know how I can keep upto date with the progress (when he posts progress updates)? Is there like a list I can subscribe to or anything?
More or less. He's posted on this bug 2-3 times IIRC. He's also had some discussion on the alsa-devel mailing list to determine the best approach to this driver. Not sure it's worth signing up for alsa-devel just for that... It's a bit like drinking from a fire hose. I'm only subscribed as I've submitted 2 patches so far snf may submit some more. On 11/12/21 11:25, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #486 from mba (mba380@outlook.com) --- > (In reply to Cameron Berkenpas from comment #484) >> The 16ITHg6 and 16achg6 are specifically not supported by any of these >> patches as they require a very different approach. Lucas Tanure is >> working on support and hopes to have something preliminary out early >> next year. >> >> On 11/12/21 08:39, bugzilla-daemon@bugzilla.kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #483 from mba (mba380@outlook.com) --- >>> I see that people with the ALC287 are reporting their sound issues to be >>> fixed.. >>> Can anyone with a legion 7 16achg6 confirm this? Unless you're already >>> mentioned it, I couldn't find it.. >>> >>> I believe it has the same chipset, alc287. >>> >>> Thank you. >>> > Okay, great! Thank you! > > Do you know how I can keep upto date with the progress (when he posts > progress > updates)? Is there like a list I can subscribe to or anything? >
Hi, The 3rd version of the driver is almost done, probably by the 22 of November I will submit the 3rd version of the driver. Thanks Lucas
(In reply to Brian Long from comment #482) > I can confirm that this change must have been delivered as part of Ubuntu > 5.13.0-21. It fixed it for me. Lenovo Yoga 7 14ITL5 and ALC287 chip. uname -a Linux Yoga-7-14ITL5 5.13.0-21-lowlatency #21~20.04.1-Ubuntu SMP PREEMPT Tue Oct 26 21:29:26 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Yes, the same for me and replaces my own patched kernel now. Unfortunately I can't state that for newer versions since my boot stucks for higher versions (but that's not connected to this problem).
Hello Lucas, Will this patch be functional or just another RFC? Thank you for your work on this! On 11/14/21 01:50, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #488 from Lucas Tanure (tanure@linux.com) --- > Hi, > > The 3rd version of the driver is almost done, probably by the 22 of November > I > will submit the 3rd version of the driver. > > Thanks > Lucas >
Not sure how exactly the patch is rolling out, but on my Lenovo-Legion-S7-15IMH5, I'm running Mint 20.2, switched to kernel 5.13.0-21-generic, and it's not working. I assume I should go through Cameron's guide on Github, unless I'm missing something and should just wait.
Not sure how Mint handles patching its kernels, but mainline 5.13 doesn't have my patch. I think 5.13 in Ubuntu does though. My guide is useful for (theoretically) creating patches, however, that's really not necessary in your case since the support is already there in newer kernels. The latest 5.14.x and 5.15.x kernels do have the patches so if you have some familiarity with building and running your own kernel, building your own v5.14 or v5.15 would likely be the easiest route. Hmm. Now that I'm thinking about it... Maybe there's a repo for Mint with newer kernels available, which would certainly save you some time/effort. Or maybe you could ask the Mint devs to pull these fixes in. On 11/14/2021 11:21 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Andrei Miculita (andreimiculita+kern@gmail.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |andreimiculita+kern@gmail.c > | |om > > --- Comment #491 from Andrei Miculita (andreimiculita+kern@gmail.com) --- > Not sure how exactly the patch is rolling out, but on my > Lenovo-Legion-S7-15IMH5, I'm running Mint 20.2, switched to kernel > 5.13.0-21-generic, and it's not working. I assume I should go through > Cameron's > guide on Github, unless I'm missing something and should just wait. >
Hi, Will this patch be functional or just another RFC? Just RFC. Please do not use RFC patches as they are not fully functional. Thanks Lucas
Are these patches applied only to latest kernels, used in ubuntu 21, or there's a chance that they will be used in 5.11 kernel (ubuntu 20.04.3) also?
Hi, Only the latest kernel, and will not be ported to older kernels as they are a new feature and not a bug fix.
(In reply to Alexey Stogny from comment #494) > Are these patches applied only to latest kernels, used in ubuntu 21, or > there's a chance that they will be used in 5.11 kernel (ubuntu 20.04.3) also? I have an original Ubuntu 20.04.1-#21 with includes the patch ...
(In reply to Lucas Tanure from comment #495) > Hi, > > Only the latest kernel, and will not be ported to older kernels as they are > a new feature and not a bug fix. This is why we need a separate kernel bug to track your work. :)
Hi, V3 is out. Not RFC anymore, an actual patch now. https://lkml.org/lkml/2021/11/23/723 Thanks Lucas
Actual patch? As in it's actually functional? If yes, I'll test it on my Lenovo Legion 7i 16ITHg6. :) Thanks, Lucas! On 11/23/21 08:36, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #498 from Lucas Tanure (tanure@linux.com) --- > Hi, > > V3 is out. Not RFC anymore, an actual patch now. > > https://lkml.org/lkml/2021/11/23/723 > > Thanks > Lucas >
(In reply to Lucas Tanure from comment #498) > Hi, > > V3 is out. Not RFC anymore, an actual patch now. > > https://lkml.org/lkml/2021/11/23/723 > > Thanks > Lucas Lucas, confirm that this patch is working on the Legion 7 16ACHg7. Feels little awkward that there is finally sound from the speakers :-) Thanks for your (and David) great work.
Looking at the patches, it seems that some adjustments will be needed to make this work on the Intel model. Marcus, What tree or branch did you apply this against? Did you need firmware as suggested in the patch notes? On 11/23/21 14:09, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #500 from Marcus (kernel@m.vb1.nl) --- > (In reply to Lucas Tanure from comment #498) >> Hi, >> >> V3 is out. Not RFC anymore, an actual patch now. >> >> https://lkml.org/lkml/2021/11/23/723 >> >> Thanks >> Lucas > Lucas, confirm that this patch is working on the Legion 7 16ACHg7. Feels > little > awkward that there is finally sound from the speakers :-) Thanks for your > (and > David) great work. >
Hi, Can I have the full dsdt of this Intel model? Thanks Lucas
(In reply to Cameron Berkenpas from comment #501) > Looking at the patches, it seems that some adjustments will be needed to > make this work on the Intel model. > > Marcus, > > What tree or branch did you apply this against? > > Did you need firmware as suggested in the patch notes? I did checkout 5.16-rc2 and first patched with the patches from David https://patchwork.kernel.org/project/alsa-devel/patch/20211029214028.401284-1-drhodes@opensource.cirrus.com/ and after that the patches by Lucas mentioned here. No, did not used any additional firmware. Sound is just working with these patches. Sound could be tuned by the firmwares from Lenovo probably.
Created attachment 299691 [details] 2021 Lenovo Legion 7i 16ITHg6 DSDT Lucas, Is this what you're looking for? Here's my alsa-info as well: http://alsa-project.org/db/?f=8200e38c38b74e3291b7f2e30b33e162a45b488e You can see in both that instead of CLSA0100 like the 16ACHg6, the 16ITHg6 has CLSA0101. I think it's likely the same amp chip or very nearly the same. Marcus brings up a good point. There are audio profiles available for different models of laptops. Is there any intention of supporting these? While it would be nice, I suspect it's unlikely and probably the audio quality is good enough without them.
There are only 2 patches in that linked series and it seems more are needed. The 2 patches do get me to a state where some of the first patches in Lucas' apply, but there are rejects for the last couple of patches. I'm patching against 5.16-rc2. I suppose I'll try them against sound.git. On 11/23/21 14:21, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #503 from Marcus (kernel@m.vb1.nl) --- > (In reply to Cameron Berkenpas from comment #501) >> Looking at the patches, it seems that some adjustments will be needed to >> make this work on the Intel model. >> >> Marcus, >> >> What tree or branch did you apply this against? >> >> Did you need firmware as suggested in the patch notes? > I did checkout 5.16-rc2 and first patched with the patches from David > > https://patchwork.kernel.org/project/alsa-devel/patch/20211029214028.401284-1-drhodes@opensource.cirrus.com/ > and after that the patches by Lucas mentioned here. > > No, did not used any additional firmware. Sound is just working with these > patches. Sound could be tuned by the firmwares from Lenovo probably. >
Turns out one of my patches was wrong. Now it all applies. I've been busy today (and just generally) so all I've tried so far is replacing all instances of CLSA0100 with CLSA0101 and adding a quirk with my laptop's subsystem ID. Unsurprisingly it didn't work. I suspect I'll have a bit of time to look into it more thoroughly tomorrow though.
Just a heads up of my results so far: Okay, so I compiled the latest Ubuntu unstable branch of 5.16-rc2 with a pull from Boonie: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound plus patches from Lucas: https://patchwork.kernel.org/project/alsa-devel/list/?series=585017. (My fork over here: https://github.com/PIPIPIG233666/linux/commits/cs35l51) I am using the Intel model as well and speakers do work out of the box but even with the amplifier fixes, I don't think the amplifier is working by any chance. (In reply to Cameron Berkenpas from comment #505) > There are only 2 patches in that linked series and it seems more are > needed. The 2 patches do get me to a state where some of the first > patches in Lucas' apply, but there are rejects for the last couple of > patches. > > I'm patching against 5.16-rc2. > > I suppose I'll try them against sound.git. > > On 11/23/21 14:21, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #503 from Marcus (kernel@m.vb1.nl) --- > > (In reply to Cameron Berkenpas from comment #501) > >> Looking at the patches, it seems that some adjustments will be needed to > >> make this work on the Intel model. > >> > >> Marcus, > >> > >> What tree or branch did you apply this against? > >> > >> Did you need firmware as suggested in the patch notes? > > I did checkout 5.16-rc2 and first patched with the patches from David > > > > > https://patchwork.kernel.org/project/alsa-devel/patch/20211029214028.401284-1-drhodes@opensource.cirrus.com/ > > and after that the patches by Lucas mentioned here. > > > > No, did not used any additional firmware. Sound is just working with these > > patches. Sound could be tuned by the firmwares from Lenovo probably. > > Tuning firmwares are present under Windows in C:\Windows\System32\csaudio while at it.
Created attachment 299745 [details] attachment-32614-0.html Correct, on the Legion 7i 16ITHG6 "works" out of the box, but you only get the left channel (sounds like from both speakers too) as it seems the 16ITHG6's firmware incorrectly initializes the amp chips during bootup and only during bootup. Resuming from sleep results in speaker output no longer working as there's no code to re-init the amps on the 16ITHG6 yet. My work around from this has been to instead suspend to disk, which has a lot of problems with the Nvidia GPU... so I run Linux in Intel iGPUU-only mode. But with only a single audio channel, gaming isn't very viable under Linux right now. Additionally, in the ACPI dsdt, the amp shows up as CLSA0101 rather than CLSA0100. Therefore applying the ALC287_FIXUP_LEGION_16ACHG6 quirk alone to the 16ITHG6 is not enough to get it working. I did try replacing all instances of CLSA0100 with CLSA0101 in the patch, but that doesn't seem to work. In my limited testing, find_comp_by_dev_name() in patch_realtek.c isn't able to find any amp chips, which suggests to me that they're not being detected before we even get to the realtek code. It seems all the values in "spec->comps[i].name" are empty strings (and certainly don't match anything like "i2c-CLSA010*:00-cs35l41-hda.*" I'm not really sure how Linux detects devices via ACPI (or in general). I do know there's some differences in regards to i2c on Intel Vs. AMD (something like one has 2 i2c controllers where as the other has just 1), but I strongly suspect the kernel abstracts much of that away. On 11/26/21 17:23, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Weikai Kong (pig.priv@gmail.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |pig.priv@gmail.com > > --- Comment #507 from Weikai Kong (pig.priv@gmail.com) --- > Just a heads up of my results so far: > Okay, so I compiled the latest Ubuntu unstable branch of 5.16-rc2 with a pull > from Boonie:https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound > plus > patches from Lucas: > https://patchwork.kernel.org/project/alsa-devel/list/?series=585017. > (My fork over here:https://github.com/PIPIPIG233666/linux/commits/cs35l51) > I am using the Intel model as well and speakers do work out of the box but > even > with the amplifier fixes, I don't think the amplifier is working by any > chance. > > (In reply to Cameron Berkenpas from comment #505) >> There are only 2 patches in that linked series and it seems more are >> needed. The 2 patches do get me to a state where some of the first >> patches in Lucas' apply, but there are rejects for the last couple of >> patches. >> >> I'm patching against 5.16-rc2. >> >> I suppose I'll try them against sound.git. >> >> On 11/23/21 14:21,bugzilla-daemon@bugzilla.kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #503 from Marcus (kernel@m.vb1.nl) --- >>> (In reply to Cameron Berkenpas from comment #501) >>>> Looking at the patches, it seems that some adjustments will be needed to >>>> make this work on the Intel model. >>>> >>>> Marcus, >>>> >>>> What tree or branch did you apply this against? >>>> >>>> Did you need firmware as suggested in the patch notes? >>> I did checkout 5.16-rc2 and first patched with the patches from David >>> >>> >> >> https://patchwork.kernel.org/project/alsa-devel/patch/20211029214028.401284-1-drhodes@opensource.cirrus.com/ >>> and after that the patches by Lucas mentioned here. >>> >>> No, did not used any additional firmware. Sound is just working with these >>> patches. Sound could be tuned by the firmwares from Lenovo probably. >>> > Tuning firmwares are present under Windows in C:\Windows\System32\csaudio > while > at it. >
(In reply to Cameron Berkenpas from comment #508) > I did try replacing all instances of CLSA0100 with CLSA0101 in the > patch, but that doesn't seem to work. > > In my limited testing, find_comp_by_dev_name() in patch_realtek.c isn't > able to find any amp chips, which suggests to me that they're not being > detected before we even get to the realtek code. It seems all the values > in "spec->comps[i].name" are empty strings (and certainly don't match > anything like "i2c-CLSA010*:00-cs35l41-hda.*" > > I'm not really sure how Linux detects devices via ACPI (or in general). > I do know there's some differences in regards to i2c on Intel Vs. AMD > (something like one has 2 i2c controllers where as the other has just > 1), but I strongly suspect the kernel abstracts much of that away. > I have a NULL pointer dereference at alc287_legion_16achg6_playback_hook+0xec/0x1c0 after adding CLSA0101 to where CLSA0100 is, I don't know if you are having the same issue. As far as I can tell that up until component_match_add() everything seems fine. Node names with CLSA* or cs35l41 Before patches: /sys/bus/acpi/devices/CLSA0101:00 /sys/bus/i2c/devices/i2c-CLSA0101:00 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:84/CLSA0101:00 /sys/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-3/i2c-CLSA0101:00 After patches: /sys/bus/acpi/devices/CLSA0101:00 /sys/bus/i2c/drivers/cs35l41 /sys/bus/i2c/drivers/cs35l41-hda /sys/bus/platform/devices/CLSA0101:00 /sys/bus/spi/drivers/cs35l41 /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:84/CLSA0101:00 /sys/devices/pci0000:00/0000:00:15.2/CLSA0101:00 /sys/kernel/btf/snd_hda_codec_cs35l41_i2c /sys/kernel/btf/snd_soc_cs35l41_i2c /sys/kernel/btf/snd_soc_cs35l41_spi /sys/module/snd_hda_codec_cs35l41_i2c /sys/module/snd_hda_codec_cs35l41_i2c/drivers/i2c:cs35l41-hda /sys/module/snd_pcm/holders/snd_soc_cs35l41_i2c /sys/module/snd_pcm/holders/snd_soc_cs35l41_spi /sys/module/snd_soc_core/holders/snd_soc_cs35l41_i2c /sys/module/snd_soc_core/holders/snd_soc_cs35l41_spi /sys/module/snd_soc_cs35l41_i2c /sys/module/snd_soc_cs35l41_i2c/drivers/i2c:cs35l41 /sys/module/snd_soc_cs35l41_spi /sys/module/snd_soc_cs35l41_spi/drivers/spi:cs35l41 /sys/module/snd_soc_wm_adsp/holders/snd_soc_cs35l41_i2c /sys/module/snd_soc_wm_adsp/holders/snd_soc_cs35l41_spi
Created attachment 299749 [details] attachment-3712-0.html Without the patches, I'm missing: /sys/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-3/i2c-CLSA0101:00 With the patches, I'm missing: /sys/kernel/btf/snd_hda_codec_cs35l41_i2c /sys/kernel/btf/snd_soc_cs35l41_i2c /sys/kernel/btf/snd_soc_cs35l41_spi /sys/module/snd_pcm/holders/snd_soc_cs35l41_i2c /sys/module/snd_pcm/holders/snd_soc_cs35l41_spi snd_pcm is compiled directly in though, and the btf stuff appears related to debugging options I don't have enabled. Seems that for where it matters, our related kernel options are identical. I don't have any NULL pointer dereferences. Also, it seems there's been a new BIOS release since early September. I doubt it, but I wonder if would make any difference. I'm hesitant to try it in case if makes a permanent upgrade related to the amp chips that would completely break my sound. Here's the BIOS info I have (from lshw): version: H1CN33WW date: 07/18/2021 On 11/27/21 07:42, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #509 from Weikai Kong (pig.priv@gmail.com) --- > (In reply to Cameron Berkenpas from comment #508) >> I did try replacing all instances of CLSA0100 with CLSA0101 in the >> patch, but that doesn't seem to work. >> >> In my limited testing, find_comp_by_dev_name() in patch_realtek.c isn't >> able to find any amp chips, which suggests to me that they're not being >> detected before we even get to the realtek code. It seems all the values >> in "spec->comps[i].name" are empty strings (and certainly don't match >> anything like "i2c-CLSA010*:00-cs35l41-hda.*" >> >> I'm not really sure how Linux detects devices via ACPI (or in general). >> I do know there's some differences in regards to i2c on Intel Vs. AMD >> (something like one has 2 i2c controllers where as the other has just >> 1), but I strongly suspect the kernel abstracts much of that away. >> > I have a NULL pointer dereference at > alc287_legion_16achg6_playback_hook+0xec/0x1c0 after adding CLSA0101 to where > CLSA0100 is, I don't know if you are having the same issue. > As far as I can tell that up until component_match_add() everything seems > fine. > > Node names with CLSA* or cs35l41 > Before patches: > /sys/bus/acpi/devices/CLSA0101:00 > /sys/bus/i2c/devices/i2c-CLSA0101:00 > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:84/CLSA0101:00 > /sys/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-3/i2c-CLSA0101:00 > > After patches: > /sys/bus/acpi/devices/CLSA0101:00 > /sys/bus/i2c/drivers/cs35l41 > /sys/bus/i2c/drivers/cs35l41-hda > /sys/bus/platform/devices/CLSA0101:00 > /sys/bus/spi/drivers/cs35l41 > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:84/CLSA0101:00 > /sys/devices/pci0000:00/0000:00:15.2/CLSA0101:00 > /sys/kernel/btf/snd_hda_codec_cs35l41_i2c > /sys/kernel/btf/snd_soc_cs35l41_i2c > /sys/kernel/btf/snd_soc_cs35l41_spi > /sys/module/snd_hda_codec_cs35l41_i2c > /sys/module/snd_hda_codec_cs35l41_i2c/drivers/i2c:cs35l41-hda > /sys/module/snd_pcm/holders/snd_soc_cs35l41_i2c > /sys/module/snd_pcm/holders/snd_soc_cs35l41_spi > /sys/module/snd_soc_core/holders/snd_soc_cs35l41_i2c > /sys/module/snd_soc_core/holders/snd_soc_cs35l41_spi > /sys/module/snd_soc_cs35l41_i2c > /sys/module/snd_soc_cs35l41_i2c/drivers/i2c:cs35l41 > /sys/module/snd_soc_cs35l41_spi > /sys/module/snd_soc_cs35l41_spi/drivers/spi:cs35l41 > /sys/module/snd_soc_wm_adsp/holders/snd_soc_cs35l41_i2c > /sys/module/snd_soc_wm_adsp/holders/snd_soc_cs35l41_spi >
(In reply to Cameron Berkenpas from comment #510) > Created attachment 299749 [details] > attachment-3712-0.html > > Without the patches, I'm missing: > /sys/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-3/i2c-CLSA0101:00 > > With the patches, I'm missing: > /sys/kernel/btf/snd_hda_codec_cs35l41_i2c > /sys/kernel/btf/snd_soc_cs35l41_i2c > /sys/kernel/btf/snd_soc_cs35l41_spi > /sys/module/snd_pcm/holders/snd_soc_cs35l41_i2c > /sys/module/snd_pcm/holders/snd_soc_cs35l41_spi > > snd_pcm is compiled directly in though, and the btf stuff appears > related to debugging options I don't have enabled. Seems that for where > it matters, our related kernel options are identical. > > I don't have any NULL pointer dereferences. You have all modules built-in, it seems. > Also, it seems there's been a new BIOS release since early September. I > doubt it, but I wonder if would make any difference. I'm hesitant to try > it in case if makes a permanent upgrade related to the amp chips that > would completely break my sound. Here's the BIOS info I have (from lshw): > version: H1CN33WW > date: 07/18/2021 > I'm on the latest 39 BIOS and nothing has really changed. Speaker still partially works.
The cs35l41 modules aren't built in. Only snd_pcm is. Not that it makes any real difference. Originally I thought I was only getting left channel audio out of the right speaker, but it seems I'm getting left channel audio speakers out of both speakers. It's possible this is a pinctrl issue that's separate from the cs35l41 amp support. If that's the case, it's likely fixable by making pinctl changes. We'd still have no audio resuming from sleep, but it would be an improvement. Can you confirm what your audio situation is, Weikai Kong? Are you getting left channel audio from both speakers like I am? On 11/27/21 11:54, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #511 from Weikai Kong (pig.priv@gmail.com) --- > (In reply to Cameron Berkenpas from comment #510) >> Created attachment 299749 [details] >> attachment-3712-0.html >> >> Without the patches, I'm missing: >> /sys/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-3/i2c-CLSA0101:00 >> >> With the patches, I'm missing: >> /sys/kernel/btf/snd_hda_codec_cs35l41_i2c >> /sys/kernel/btf/snd_soc_cs35l41_i2c >> /sys/kernel/btf/snd_soc_cs35l41_spi >> /sys/module/snd_pcm/holders/snd_soc_cs35l41_i2c >> /sys/module/snd_pcm/holders/snd_soc_cs35l41_spi >> >> snd_pcm is compiled directly in though, and the btf stuff appears >> related to debugging options I don't have enabled. Seems that for where >> it matters, our related kernel options are identical. >> >> I don't have any NULL pointer dereferences. > You have all modules built-in, it seems. > >> Also, it seems there's been a new BIOS release since early September. I >> doubt it, but I wonder if would make any difference. I'm hesitant to try >> it in case if makes a permanent upgrade related to the amp chips that >> would completely break my sound. Here's the BIOS info I have (from lshw): >> version: H1CN33WW >> date: 07/18/2021 >> > I'm on the latest 39 BIOS and nothing has really changed. Speaker still > partially works. >
(In reply to Cameron Berkenpas from comment #512) > We'd still have no audio resuming from sleep, but it would be an > improvement. > > Can you confirm what your audio situation is, Weikai Kong? Are you > getting left channel audio from both speakers like I am? > Originally I thought I was only getting left channel audio out of the > right speaker, but it seems I'm getting left channel audio speakers out > of both speakers. It's possible this is a pinctrl issue that's separate > from the cs35l41 amp support. If that's the case, it's likely fixable by > making pinctl changes. It's typically an amplifier issue for sure, my android phone once had the same issue with the stereo speaker (right channel) broken and I had to write an amplifier HAL to enable the amplifier feedback. > Can you confirm what your audio situation is, Weikai Kong? Are you > getting left channel audio from both speakers like I am? Yeah, I have exactly the same issue as yours. https://www.youtube.com/watch?v=6TWJaFD6R2s this is the video that I used to test audio, btw.
Another thing I have to point out is that when I uninstalled Cirrus Logic Amplifiers from Windows the same thing happened as well. > I'm not really sure how Linux detects devices via ACPI (or in general). > I do know there's some differences in regards to i2c on Intel Vs. AMD > (something like one has 2 i2c controllers where as the other has just > 1), but I strongly suspect the kernel abstracts much of that away. I don't see 2 I2Cs controllers for the amplifier or things like that while at it. The amplifier is connected to Intel(R) Serial IO I2C Host Controller - 43EA (\_SB.PC00.I2C2) on Windows. The other 43E9 (\_SB.PC00.I2C1) controller is for HID. Nothing is connected to 43E8(\_SB.PC00.I2C0) for me.
Well, I did make a tiny bit of progress. Seems the option to enable CS35L41 amp support needs to define some dependencies... But for now, we can enable them in the kernel manually. You may already have it enabled, but the "i2c-multi-instantiate" module is also needed. For convenience, the kernel option is simply I2C_MULTI_INSTANTIATE. Unfortunately, it doesn't quite work: [ 1364.629567] acpi CLSA0101:00: GPIO: looking up 0 in _CRS [ 1364.629582] acpi CLSA0101:00: GPIO: looking up 1 in _CRS [ 1364.629592] acpi CLSA0101:00: GPIO: looking up 2 in _CRS [ 1364.629605] acpi CLSA0101:00: GPIO: looking up 3 in _CRS [ 1364.629655] gpio gpiochip0: Persistence not supported for GPIO 230 [ 1364.629711] I2C multi instantiate pseudo device driver CLSA0101:00: Error requesting irq at index 0: -22 [ 1364.629732] I2C multi instantiate pseudo device driver: probe of CLSA0101:00 failed with error -22 under drivers/platform/x86/i2c-multi-instantiate.c, we have: static const struct i2c_inst_data clsa0100_data[] = { { "cs35l41-hda", IRQ_RESOURCE_GPIO, 0 }, { "cs35l41-hda", IRQ_RESOURCE_GPIO, 0 }, {} }; Maybe something about this doesn't quite work on Intel or at least this model of laptop? On another note: When I first got this laptop some months back, the touchpad initially didn't work due to some some mapping issues with GPIO on TigerLake. It was quickly fixed: https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git/commit/?h=fixes&id=2f658f7a3953f6d70bab90e117aff8d0ad44e200 Maybe there's some more Tigerlake/GPIO issues to be sorted out? Probably not; this is just a shot in the dark. On 11/27/21 13:01, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #514 from Weikai Kong (pig.priv@gmail.com) --- > Another thing I have to point out is that when I uninstalled Cirrus Logic > Amplifiers from Windows the same thing happened as well. > >> I'm not really sure how Linux detects devices via ACPI (or in general). >> I do know there's some differences in regards to i2c on Intel Vs. AMD >> (something like one has 2 i2c controllers where as the other has just >> 1), but I strongly suspect the kernel abstracts much of that away. > I don't see 2 I2Cs controllers for the amplifier or things like that while at > it. > The amplifier is connected to Intel(R) Serial IO I2C Host Controller - 43EA > (\_SB.PC00.I2C2) on Windows. The other 43E9 (\_SB.PC00.I2C1) controller is > for > HID. Nothing is connected to 43E8(\_SB.PC00.I2C0) for me. >
(In reply to Cameron Berkenpas from comment #515) > Well, I did make a tiny bit of progress. > > Seems the option to enable CS35L41 amp support needs to define some > dependencies... But for now, we can enable them in the kernel manually. > > You may already have it enabled, but the "i2c-multi-instantiate" module > is also needed. For convenience, the kernel option is simply > I2C_MULTI_INSTANTIATE. I did not do anything and I also have the following in dmesg: [ 3.258973] I2C multi instantiate pseudo device driver CLSA0101:00: Error requesting irq at index 0: -22 [ 3.260295] I2C multi instantiate pseudo device driver: probe of CLSA0101:00 failed with error -22 However, I have nothing else. And you are right, the touchpad was fixed by that patch or that series of patches.
FYI, internal speakers are working on the Yoga 7i (14ITL5) in Elementary OS 6 (Odin, daily build) with kernel 5.11.0-40 (fresh install, no post-install patching).
Hello, thank you for implementing the fix for the lenovo legion 7i. I just wanted to point out that when the audio volume is higher that a certain threshold (around 60%), the sound cracks or get distorted for some notes (maybe ones with high frequencies). I don't know if I'm the only one having this issue. I am running Manjaro KDE on kernel version 5.15.7-1-MANJARO. Thank you
Thank you for the patch, Cameron Berkenpas. However, my Yoga 7 15ITL5's subsystem device ID number is different from the one checked for in the patch. For me `cat /sys/bus/hdaudio/devices/ehdaudio0D0/subsystem_id` returns 0x17aa384a Editing the code to check for that causes the speakers to work. The patch I used can be seen here: https://github.com/oreo639/void-packages/commit/d59710b8b266200d6936e95fd1d9307e8e17132d I'm not sure where this difference comes from or if this is normal, I'm not familiar with this so I was hoping you (or anyone else ofc) could help. Sorry for any trouble.
Seems you have a different revision of the laptop. Once thing I've noticed is that different countries tend to have different subsystem Ids, but it could also be a different reason. On 12/21/21 13:37, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > oreo639@outlook.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |oreo639@outlook.com > > --- Comment #519 from oreo639@outlook.com --- > Thank you for the patch, Cameron Berkenpas. > However, my Yoga 7 15ITL5's subsystem device ID number is different from the > one checked for in the patch. > > For me `cat /sys/bus/hdaudio/devices/ehdaudio0D0/subsystem_id` returns > 0x17aa384a > > Editing the code to check for that causes the speakers to work. > The patch I used can be seen here: > > https://github.com/oreo639/void-packages/commit/d59710b8b266200d6936e95fd1d9307e8e17132d > > I'm not sure where this difference comes from or if this is normal, I'm not > familiar with this so I was hoping you (or anyone else ofc) could help. Sorry > for any trouble. >
(In reply to Cameron Berkenpas from comment #520) > Seems you have a different revision of the laptop. Once thing I've > noticed is that different countries tend to have different subsystem > Ids, but it could also be a different reason. If there is anything you want/need from me, feel free to ask. I am using a US machine with the latest BIOS update. Not sure if that is helpful at all.
Err, to be specific, the BIOS version I am using is F5CN52WW.
You haven't submitted this as a patch to alsa-devel I take it? If not, do you have experience with that? On 12/21/21 16:17, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #521 from oreo639@outlook.com --- > (In reply to Cameron Berkenpas from comment #520) >> Seems you have a different revision of the laptop. Once thing I've >> noticed is that different countries tend to have different subsystem >> Ids, but it could also be a different reason. > If there is anything you want/need from me, feel free to ask. I am using a US > machine with the latest BIOS update. Not sure if that is helpful at all. >
Created attachment 300117 [details] attachment-32437-0.html I am currently out of the office on holiday I will be returning on Tuesday January 4, I will have limited access to email.
(In reply to Cameron Berkenpas from comment #523) > You haven't submitted this as a patch to alsa-devel I take it? > > If not, do you have experience with that? > > On 12/21/21 16:17, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #521 from oreo639@outlook.com --- > > (In reply to Cameron Berkenpas from comment #520) > >> Seems you have a different revision of the laptop. Once thing I've > >> noticed is that different countries tend to have different subsystem > >> Ids, but it could also be a different reason. > > If there is anything you want/need from me, feel free to ask. I am using a > US > > machine with the latest BIOS update. Not sure if that is helpful at all. > > That is correct. I have no experience with submitting patches to any of the kernel projects, but I have submitted a patch to a different project using patchwork in the past. That being said, I am available and can look into submitting the patch and ofc, if there is anything I need to change or add, feel free to let me know. Thank you for the response.
Edit: It wasn't patchwork I got mixed up and was thinking of something else, I'm sorry. If someone else wants to submit the patch, I'm fine with that.
I'm currently far too busy so I'm not up to submitting it personally. Here's info on how to submit patches: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html In this case, you'd have to submit it to the alsa-devel mailing list. On 12/22/2021 6:16 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #526 from oreo639@outlook.com --- > Edit: It wasn't patchwork I got mixed up and was thinking of something else, > I'm sorry. > > If someone else wants to submit the patch, I'm fine with that. >
(In reply to Cameron Berkenpas from comment #527) > I'm currently far too busy so I'm not up to submitting it personally. > > Here's info on how to submit patches: > https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html > > In this case, you'd have to submit it to the alsa-devel mailing list. > > On 12/22/2021 6:16 PM, bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #526 from oreo639@outlook.com --- > > Edit: It wasn't patchwork I got mixed up and was thinking of something > else, > > I'm sorry. > > > > If someone else wants to submit the patch, I'm fine with that. > > Alright. Thank you for the link, it is definitely helpful.
(In reply to Cameron Berkenpas from comment #527) > I'm currently far too busy so I'm not up to submitting it personally. > > Here's info on how to submit patches: > https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html > > In this case, you'd have to submit it to the alsa-devel mailing list. > Alright, I submitted the patch (it still needs moderator approval in alsa-devel). https://lore.kernel.org/lkml/20211223232857.30741-1-arsgeiger@gmail.com/ If there are any with it feel free to let me know. Thank you for the help and enjoy the holidays/new year.
Hi all, first things first: thanks for all your work! I have updated everything possible in my Ubuntu 21.10 but there is still no sound from the speakers. Here is my alsa-info: http://alsa-project.org/db/?f=04f696f1754fdb43fd92324f5d9d074fe704f8b9. Can someone help me find out what's wrong or how to fix it?
(In reply to Simone from comment #530) > Hi all, first things first: thanks for all your work! > > I have updated everything possible in my Ubuntu 21.10 but there is still no > sound from the speakers. > Here is my alsa-info: > http://alsa-project.org/db/?f=04f696f1754fdb43fd92324f5d9d074fe704f8b9. > > Can someone help me find out what's wrong or how to fix it? Can you please verify, that you have: - Lenovo Legion S7 15IMH5 cat /sys/bus/hdaudio/devices/ehdaudio0D0/subsystem_id - according to your ALSA it should be Subsystem Id: 0x17aa3822 (the same as for Andrei Miculita ?) to my understanding there's currently no patch for this device in the code. Woody64
(In reply to woody64 from comment #531) > (In reply to Simone from comment #530) > > Hi all, first things first: thanks for all your work! > > > > I have updated everything possible in my Ubuntu 21.10 but there is still no > > sound from the speakers. > > Here is my alsa-info: > > http://alsa-project.org/db/?f=04f696f1754fdb43fd92324f5d9d074fe704f8b9. > > > > Can someone help me find out what's wrong or how to fix it? > > Can you please verify, that you have: > - Lenovo Legion S7 15IMH5 > > cat /sys/bus/hdaudio/devices/ehdaudio0D0/subsystem_id > > - according to your ALSA it should be > Subsystem Id: 0x17aa3822 > (the same as for Andrei Miculita ?) I don't have that exact directory but I have the following: $ cat /sys/bus/hdaudio/devices/hdaudioC0D0/subsystem_id 0x17aa3822 and: $ cat /sys/bus/hdaudio/devices/hdaudioC1D0/subsystem_id 0x17aa3801 > to my understanding there's currently no patch for this device in the code. Is there any way I can help with that? I know almost nothing about kernel but I can extract whatever you need or maybe if you can point me to some documentation I can try to do something myself.
> $ cat /sys/bus/hdaudio/devices/hdaudioC0D0/subsystem_id > 0x17aa3822 > and: > $ cat /sys/bus/hdaudio/devices/hdaudioC1D0/subsystem_id > 0x17aa3801 > Is there any way I can help with that? > I know almost nothing about kernel but I can extract whatever you need or > maybe if you can point me to some documentation I can try to do something > myself. Maybe the available patch work also for your ID, since it's an ALC287 with at least similar settings: But now it becomes difficult, you can try (but need a certain knowledge) about it: 1) Quick test: install hda-verbs, python3 and applyverbs.py. Load verbs.txt (see attaches above and maybe try different) and give it a try, You find the necessary documentations in this thread. sudo python3 applyverbs.py verbs.txt 2) If you are able to build a kernel then find in patch_realtek.c (makes only sense if 1) works) SND_PCI_QUIRK(0x17aa, 0x3852, "Lenovo Yoga 7 14ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), and add a line for your id: (0x17aa, 0x3822 ....) hopefully adding the line is correct and need nothing more. 3) if 1) is not working you may try S3 mode (see comment #120 ....). sudo dmesg |grep ACPI| grep supports # may give you an indication if S3 is enabked on your device 4) There are maybe a handful of experts which are able to debug the correct hda_verbs (I do assume it can be solved with that on your device) out of the setup Cameron has described, but .... But non of these options is an easy way and you need to do it yourself or find something with the same device helping you. Option 1) can be done with some Linux experiences .... Woody64
(In reply to woody64 from comment #533) > 2) If you are able to build a kernel then find in patch_realtek.c (makes > only sense if 1) works) > SND_PCI_QUIRK(0x17aa, 0x3852, "Lenovo Yoga 7 14ITL5", > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), > and add a line for your id: (0x17aa, 0x3822 ....) > hopefully adding the line is correct and need nothing more. > I saw that oreo639 reported a similar case and was successfull with adding: SND_PCI_QUIRK(0x17aa, 0x384a, "Lenovo Yoga 7 15ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
Do you know how to compile and run your own kernel? If so, you can try updating the file with a line such as that one. On 12/25/2021 11:40 AM, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #534 from woody64 (andreas@mac-au.eu) --- > (In reply to woody64 from comment #533) >> 2) If you are able to build a kernel then find in patch_realtek.c (makes >> only sense if 1) works) >> SND_PCI_QUIRK(0x17aa, 0x3852, "Lenovo Yoga 7 14ITL5", >> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), >> and add a line for your id: (0x17aa, 0x3822 ....) >> hopefully adding the line is correct and need nothing more. >> > I saw that oreo639 reported a similar case and was successfull with adding: > > SND_PCI_QUIRK(0x17aa, 0x384a, "Lenovo Yoga 7 15ITL5", > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), >
(In reply to Simone from comment #532) > I know almost nothing about kernel but I can extract whatever you need or > maybe if you can point me to some documentation I can try to do something > myself. For compiling a kernel module that's a good doc. Start with: Obtain the kernel headers and the compiler, and download the kernel sources ... https://yoursunny.com/t/2018/one-kernel-module/
Hello all, I apologize if this comment is irrelevant but I think this would be a good place to ask for help as I'm quite new to kernel compilation. I have been watching this thread for a little while and I'm not quite sure how I can make sound work on my Legion 7 16ACHg6. I tried applying the following two patches against kernel 5.16-rc8: https://patchwork.kernel.org/project/alsa-devel/patch/20211029214028.401284-1-drhodes@opensource.cirrus.com/ https://patchwork.kernel.org/project/alsa-devel/patch/20211217115708.882525-11-tanureal@opensource.cirrus.com/ However, I got rejects for the second series and after I tried manually fixing them, I got errors during compilation. I also tried applying Lucas' patches against sound.git (https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound) and that compiled fine but PulseAudio refuses to work. Am I missing something? Thanks!
Hello again, I've tried compiling kernel 5.17-rc2 (and rc1) now that the patches have been merged and I still can't get any audio on my Legion 7 16achg6. The modules snd_hda_scodec_cs35l41_i2c and snd_hda_scodec_cs35l41 seem to have loaded properly so I'm not sure what the problem is. I have tried both PipeWire (my current choice) and PulseAudio, and neither worked. A patch also exists for my device's subsystem id: cat /sys/bus/hdaudio/devices/hdaudioC1D0/subsystem_id 0x17aa3847 patch_realtek.c:9131: SND_PCI_QUIRK(0x17aa, 0x3847, "Legion 7 16ACHG6", ALC287_FIXUP_LEGION_16ACHG6), I can confirm that this isn't an isolated case since someone left a comment on a blog post I made confirming that he's also having trouble. Any support would be appreciated!
Hi, We are waiting for this patch series to be merged: https://lkml.org/lkml/2022/1/21/471 Thanks Lucas
I completely missed that series, after applying it the speakers finally work! Cheers!
Thanks for all your work Lucas Tanure!! Please tell us if this patch is applied in the 5.17-rc3 or another. Regards!
(In reply to Nikolaos Karaolidis from comment #538) > Hello again, > > I've tried compiling kernel 5.17-rc2 (and rc1) now that the patches have > been merged and I still can't get any audio on my Legion 7 16achg6. > > The modules snd_hda_scodec_cs35l41_i2c and snd_hda_scodec_cs35l41 seem to > have loaded properly so I'm not sure what the problem is. I have tried both > PipeWire (my current choice) and PulseAudio, and neither worked. > > A patch also exists for my device's subsystem id: > > cat /sys/bus/hdaudio/devices/hdaudioC1D0/subsystem_id > 0x17aa3847 > > patch_realtek.c:9131: > SND_PCI_QUIRK(0x17aa, 0x3847, "Legion 7 16ACHG6", > ALC287_FIXUP_LEGION_16ACHG6), > > I can confirm that this isn't an isolated case since someone left a comment > on a blog post I made confirming that he's also having trouble. > > Any support would be appreciated! Hi Nikolaos, I am new to compiling the kernel and was attempting the same rc2 compiles/testing/fail (sans the lkml patches). Could you please share your kernel .config as I want to validate against mine. Thanks!
(In reply to Darin Miller from comment #542) > > Hi Nikolaos, I am new to compiling the kernel and was attempting the same > rc2 compiles/testing/fail (sans the lkml patches). Could you please share > your kernel .config as I want to validate against mine. Thanks! Here you go: https://pastebin.com/g35uwwEu Keep in mind that this has other changes as well but the audio should be working... Regards, Nick
Hi, Legion AMD version fully works on the linux-next/master branch. No patches needed, only enable configs: CONFIG_SND_HDA_SCODEC_CS35L41_I2C CONFIG_SERIAL_MULTI_INSTANTIATE Thanks Lucas
Hi Lucas, great!! sory for this simple question, but how/where whe must enable this configs?: CONFIG_SND_HDA_SCODEC_CS35L41_I2C CONFIG_SERIAL_MULTI_INSTANTIATE Thanks!!!
I build the kernel like this: (Arch Linux) zcat /proc/config.gz > .config make olddefconfig ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE make -j16 all And install that kernel.
Hello all, I recently bought a new IdeaPad (Yoga) Slim 7 Carbon and still can't get the sound fully working after trying different things in this bug. My laptop has ALC287/ALC3306 + 2 CS35L53 (denoted as CLSA0102 in the DSDT) and 0x17aa3856 as subsystem id. There are 4 speakers on this laptop, 2 tweeters and 2 subwoofers. The tweeters can create sound but subwoofer is muted. Disable EAPD through HDA verbs will cause tweeter be muted (re-enable EAPD also only re-enables tweeters) I applied the original "v6 8/10" i2c multi-instantiate patch (modified id to CLSA0102) and similarly modified and enabled quirk ALC287_FIXUP_CS35L41_I2C_2 on my device. From dmesg everything loaded correctly. I also tried to set the CS35L41_AMP_GAIN_CTRL to 17.5db according to the inf file I found in windows configuring speakers for this laptop. [ 3.607141] cs35l41-hda i2c-CLSA0102:00-cs35l41-hda.0: Cirrus Logic CS35L41 (35a40), Revision: B2 [ 3.607367] cs35l41-hda i2c-CLSA0102:00-cs35l41-hda.1: Reset line busy, assuming shared reset [ 3.653480] cs35l41-hda i2c-CLSA0102:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2 However, I still can't get my subwoofer working. One thing I wonder is for both ALC287_FIXUP_CS35L41_I2C_2 and ALC287_FIXUP_LEGION_16ACHG6 there're no coefficient fix and only amp fixes. I wonder if it's possible coefficient fixes are also required in my case. I tried multiple coefficients (in this thread and in kernel) too but none of them made my subwoofer working. ALC287_FIXUP_LEGION_16ACHG6 with modification to support CLSA0102 also don't work. I don't think it's firmware related as the hda config in cs35l41 bypassed dsp firmware. Great thanks for the help! inf file: https://pastebin.ubuntu.com/p/Q2kCg4X2s8/ modified v6 8/10 i2c-multi-instantiate patch: https://pastebin.ubuntu.com/p/DpCZbG5VdN/ quirk patch: https://pastebin.ubuntu.com/p/NnGNcdFNp6/ psref to my device: https://psref.lenovo.com/Product/IdeaPad/IdeaPad_Slim_7_Carbon_14ACN6 All applied on 5.17rc2
> My laptop has ALC287/ALC3306 + 2 CS35L53 (denoted as CLSA0102 in the DSDT) Just curious, how do you know it's a CS35L53? My laptop has a CLSA0101 and these patches don't work for me either. Lucas has informed me that this will be supported at some point. I've no idea what current the status is. I assume the CLSA0102 is likely in the same situation. Perhaps the codec for the cs35l41/2 doesn't quite work our AMP chips. (Digging through the Windows drivers, it seems I might have the CS35L51.) To make your life a bit easier, linux-next seems to have all the up to date code: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git You'd still have to muck around the code to get your CSLA0102 in there, but it's probably a bit more convenient than dealing with the patches.
Hi, Please do not change CS35L41_AMP_GAIN_CTRL from 4.5 db. Without the firmware for the device, the laptop speaker has no protection, and a higher gain can damage the speaker. Thanks Lucas
Lucas, Do the CS35L5* chips require firmware to operate? It seems the CS35L41/2's do not. And out of curiosity, does the CLSA0101 have the CS35L51? On 2/7/22 00:36, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #549 from Lucas Tanure (tanure@linux.com) --- > Hi, > > Please do not change CS35L41_AMP_GAIN_CTRL from 4.5 db. > Without the firmware for the device, the laptop speaker has no protection, > and > a higher gain can damage the speaker. > > Thanks > Lucas >
(In reply to darnellkeithj from comment #375) > Thought i'd reinstall linux to see if there were any changes with this Yoga > Duet 7i. Still no sound with the newer kernels but 5.4.88-1-lts with Arch > "Arco"linux does works every time. Microphone does not work. Why it works in > 5.488-1-lts and not newer is beyond me. Why devs haven't compared the two > and fixed it is also puzzling. Hi all, New Lenovo Yoga Duet 7 13IML05 (2020) user here. The Duet 7 is a really nice, light and compact 13-inch tablet, ideal for triple-booting Windows, Linux and macOS. The only issue currently with this device is getting the ALC287 sound chip to work in Linux and macOS. I confirm darnellkeithj's findings that the sound output (speakers and headphones) works out of the box with the Arch kernel up to and including 5.4.88-1-lts. I'm actually using Manjaro Linux for testing, which allows installing several kernels and switching easily between them. Older Arch kernels may be downloaded from the Arch Linux Archive at https://archive.archlinux.org/packages/l/linux-lts/ and https://archive.archlinux.org/packages/l/linux/. Kernel 5.4.89 breaks sound output on the Yoga Duet 7 because of the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/releases/5.4.89/alsa-hda-realtek-fix-speaker-volume-control-on-lenovo-c940.patch?id=1889f9ac9f9eb7f91ffc22e607a2e3db3db2e72e For some odd reason, the Lenovo Yoga C940 seems to be using the same audio subsystem ID 0x17aa, 0x3818 as the Yoga Duet 7, so any quirk applied to the C940 will apply to the Duet 7 as well, even if it is not required. Reverting this commit fixes the sound output for kernels up to and including 5.4.98-1-lts. Kernels 5.x break sound output again, even with this commit reverted... So this is not an optimal approach. However, I found an easy way for fixing the sound output (speakers and headphones) on the Yoga Duet 7. The cool thing is that it doesn't require compiling a custom kernel. Sadly, the fix works only for kernels up to and including 5.10.1. Simply disable the snd-sof-pci driver and force the use of the legacy snd-hda-intel driver by adding the following two lines to /etc/modprobe.d/alsa-base.conf "blacklist snd-sof-pci" "options snd-intel-dspcfg dsp_driver=1" With both solutions, the digital microphone won't work at all, as it requires the SOF firmware. The mic is detected and works perfectly on newer kernels (> 5.9.x) when using the SOF firmware. The headphones work as well, only the speakers won't emit any sound. Basically, you have to choose between having a mic or having a speaker. No microphone is fine for me and kernel 5.10.1 is quite modern, so I could live with the situation for the time being. I'll play around with the Realtek verbs in the next few days to find a real solution, as the above fixes are dead ends. I'd be very glad to receive some input from the other Yoga Duet 7 owners. Cheers for now!
Hi all, Good news for Lenovo Yoga Duet 7 13IML05 owners! The HDA verbs (and therefore the quirks) for the Yoga 7 work perfectly on the Yoga Duet 7 13IML05 after the following patch is reverted: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/releases/5.4.89/alsa-hda-realtek-fix-speaker-volume-control-on-lenovo-c940.patch?id=1889f9ac9f9eb7f91ffc22e607a2e3db3db2e72e Thus, writing a kernel patch for the Yoga Duet 7 becomes trivial: --- a/sound/pci/hda/patch_realtek.c +++ a/sound/pci/hda/patch_realtek.c @@ -9008,7 +9008,7 @@ SND_PCI_QUIRK(0x17aa, 0x3178, "ThinkCentre Station", ALC283_FIXUP_HEADSET_MIC), SND_PCI_QUIRK(0x17aa, 0x31af, "ThinkCentre Station", ALC623_FIXUP_LENOVO_THINKSTATION_P340), SND_PCI_QUIRK(0x17aa, 0x3813, "Legion 7i 15IMHG05", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), - SND_PCI_QUIRK(0x17aa, 0x3818, "Lenovo C940", ALC298_FIXUP_LENOVO_SPK_VOLUME), + SND_PCI_QUIRK(0x17aa, 0x3818, "Yoga Duet 7 13IML05", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x3819, "Lenovo 13s Gen2 ITL", ALC287_FIXUP_13S_GEN2_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x3824, "Legion Y9000X 2020", ALC285_FIXUP_LEGION_Y9000X_SPEAKERS), SND_PCI_QUIRK(0x17aa, 0x3827, "Ideapad S740", ALC285_FIXUP_IDEAPAD_S740_COEF), With this patch, the internal speakers, headphones, headset mic and internal microphone all work on the Duet 7. Now, I'm not sure how to get this patch to be merged, as reverting the patch for the C940 would obviously break sound on the C940. Why Lenovo decided to use the same subsystem ID (0x17aa, 0x3818) on both laptops is beyond me. I haven't been able to find another example of identical subsystem IDs for two different machines anywhere else in the "patch_realtek.c" file. At first, I thought that simply adding the quirk for the Yoga Duet 7 with the same subsystem ID might work, as the different DMI info allows to distinguish between both laptops. Well, that doesn't do the trick, so the only working fix right now is to revert the c940 patch. Perhaps someone from the ALSA team would know how to deal with this odd issue. By the way, no need to compile the whole kernel, compiling the 'snd-hda-codec-realtek.ko' module is enough. Backup and replace the module in /lib/modules/5.x.x/kernel/sound/pci/hda/ with the new module you just compiled and reboot to have working sound.
Probably the models of laptop each need their own set of verbs. On 2/14/22 05:34, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #552 from Jürg Lempen (info@jlempen.com) --- > Hi all, > > Good news for Lenovo Yoga Duet 7 13IML05 owners! > > The HDA verbs (and therefore the quirks) for the Yoga 7 work perfectly on the > Yoga Duet 7 13IML05 after the following patch is reverted: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/releases/5.4.89/alsa-hda-realtek-fix-speaker-volume-control-on-lenovo-c940.patch?id=1889f9ac9f9eb7f91ffc22e607a2e3db3db2e72e > > Thus, writing a kernel patch for the Yoga Duet 7 becomes trivial: > > --- a/sound/pci/hda/patch_realtek.c > +++ a/sound/pci/hda/patch_realtek.c > @@ -9008,7 +9008,7 @@ > SND_PCI_QUIRK(0x17aa, 0x3178, "ThinkCentre Station", > ALC283_FIXUP_HEADSET_MIC), > SND_PCI_QUIRK(0x17aa, 0x31af, "ThinkCentre Station", > ALC623_FIXUP_LENOVO_THINKSTATION_P340), > SND_PCI_QUIRK(0x17aa, 0x3813, "Legion 7i 15IMHG05", > ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), > - SND_PCI_QUIRK(0x17aa, 0x3818, "Lenovo C940", > ALC298_FIXUP_LENOVO_SPK_VOLUME), > + SND_PCI_QUIRK(0x17aa, 0x3818, "Yoga Duet 7 13IML05", > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), > SND_PCI_QUIRK(0x17aa, 0x3819, "Lenovo 13s Gen2 ITL", > ALC287_FIXUP_13S_GEN2_SPEAKERS), > SND_PCI_QUIRK(0x17aa, 0x3824, "Legion Y9000X 2020", > ALC285_FIXUP_LEGION_Y9000X_SPEAKERS), > SND_PCI_QUIRK(0x17aa, 0x3827, "Ideapad S740", > ALC285_FIXUP_IDEAPAD_S740_COEF), > > With this patch, the internal speakers, headphones, headset mic and internal > microphone all work on the Duet 7. > > Now, I'm not sure how to get this patch to be merged, as reverting the patch > for the C940 would obviously break sound on the C940. Why Lenovo decided to > use > the same subsystem ID (0x17aa, 0x3818) on both laptops is beyond me. I > haven't > been able to find another example of identical subsystem IDs for two > different > machines anywhere else in the "patch_realtek.c" file. At first, I thought > that > simply adding the quirk for the Yoga Duet 7 with the same subsystem ID might > work, as the different DMI info allows to distinguish between both laptops. > Well, that doesn't do the trick, so the only working fix right now is to > revert > the c940 patch. > > Perhaps someone from the ALSA team would know how to deal with this odd > issue. > > By the way, no need to compile the whole kernel, compiling the > 'snd-hda-codec-realtek.ko' module is enough. Backup and replace the module in > /lib/modules/5.x.x/kernel/sound/pci/hda/ with the new module you just > compiled > and reboot to have working sound. >
(In reply to Lucas Tanure from comment #539) > Hi, > > We are waiting for this patch series to be merged: > > https://lkml.org/lkml/2022/1/21/471 > > Thanks > Lucas Hi, just wanted to confirm, adding these patches on top of 5.17-rc4 works for me on my 2021 Legion 7 (AMD). This is running Ubuntu 21.04. I grabbed the kernel source from the Ubuntu tree, as linked here https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17-rc4/ And built following the instructions here https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel In the editconfigs step you have to navigate in menuconfig to Device Drivers / X86 Platform Specific Device Drivers / I2C and SPI multi instantiate pseudo device driver and select that module. Then Exit/Save the config and build. It takes a few minutes to build, but the process goes smoothly. Thanks for getting this working!
(In reply to Howard Chu from comment #554) > (In reply to Lucas Tanure from comment #539) > > Hi, > > > > We are waiting for this patch series to be merged: > > > > https://lkml.org/lkml/2022/1/21/471 > > > > Thanks > > Lucas > > Hi, just wanted to confirm, adding these patches on top of 5.17-rc4 works > for me on my 2021 Legion 7 (AMD). This is running Ubuntu 21.04. I grabbed > the kernel source from the Ubuntu tree, as linked here > > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17-rc4/ > > And built following the instructions here > > https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel > > In the editconfigs step you have to navigate in menuconfig to Device Drivers > / > X86 Platform Specific Device Drivers / > I2C and SPI multi instantiate pseudo device driver > > and select that module. Then Exit/Save the config and build. It takes a few > minutes to build, but the process goes smoothly. > > Thanks for getting this working! I've tried with that kernel direct from kernel.org but couldn't find the SPI multi..., is there any previous step I'm missing?, I read something about a patch, but I don't know which one is ( I have the same laptop than you )
(In reply to henry.hormaza from comment #555) > (In reply to Howard Chu from comment #554) > > (In reply to Lucas Tanure from comment #539) > > > Hi, > > > > > > We are waiting for this patch series to be merged: > > > > > > https://lkml.org/lkml/2022/1/21/471 > > > > > > Thanks > > > Lucas > > > > Hi, just wanted to confirm, adding these patches on top of 5.17-rc4 works > > for me on my 2021 Legion 7 (AMD). This is running Ubuntu 21.04. I grabbed > > the kernel source from the Ubuntu tree, as linked here > I've tried with that kernel direct from kernel.org but couldn't find the SPI > multi..., is there any previous step I'm missing?, I read something about a > patch, but I don't know which one is ( I have the same laptop than you ) The patch in the comment I replied to, comment #539. That's why I replied to that specific comment.
(In reply to Howard Chu from comment #554) > (In reply to Lucas Tanure from comment #539) > > Hi, > > > > We are waiting for this patch series to be merged: > > > > https://lkml.org/lkml/2022/1/21/471 > > > > Thanks > > Lucas > > Hi, just wanted to confirm, adding these patches on top of 5.17-rc4 works > for me on my 2021 Legion 7 (AMD). This is running Ubuntu 21.04. I grabbed > the kernel source from the Ubuntu tree, as linked here > > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.17-rc4/ > > And built following the instructions here > > https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel > > In the editconfigs step you have to navigate in menuconfig to Device Drivers > / > X86 Platform Specific Device Drivers / > I2C and SPI multi instantiate pseudo device driver > > and select that module. Then Exit/Save the config and build. It takes a few > minutes to build, but the process goes smoothly. > > Thanks for getting this working! Heyy, did it worked for Legion 16achg6? Now speakers work properly? if yes can you post step by step how to do that please? i would realy appreciate that!
(In reply to Howard Chu from comment #556) > (In reply to henry.hormaza from comment #555) > > (In reply to Howard Chu from comment #554) > > > (In reply to Lucas Tanure from comment #539) > > > > Hi, > > > > > > > > We are waiting for this patch series to be merged: > > > > > > > > https://lkml.org/lkml/2022/1/21/471 > > > > > > > > Thanks > > > > Lucas > > > > > > Hi, just wanted to confirm, adding these patches on top of 5.17-rc4 works > > > for me on my 2021 Legion 7 (AMD). This is running Ubuntu 21.04. I grabbed > > > the kernel source from the Ubuntu tree, as linked here > > > I've tried with that kernel direct from kernel.org but couldn't find the > SPI > > multi..., is there any previous step I'm missing?, I read something about a > > patch, but I don't know which one is ( I have the same laptop than you ) > > The patch in the comment I replied to, comment #539. > > That's why I replied to that specific comment. that's where I got lost, I can't find any .patch in that thread, how do I apply the patch? I'm using this kernel: https://github.com/torvalds/linux/tree/v5.17-rc4 And I can compile with no issues, but the patch is what I'm missing thank you in advance
I have Yoga Slim 7 Carbon 14ACN6 with same issues as comment #547. Woofers are not detected it seams, but i have sound from tweeters. Sound is low, thin and tremble. It's basically the same configuration. Audio Chip: High Definition (HD) Audio, Realtek ALC3306 codec psref: https://psref.lenovo.com/Detail/Yoga/Yoga_Slim_7_Carbon_14ACN6?M=82L0005RMX alsa-info: http://alsa-project.org/db/?f=30ea86f14dc3385057e6016e94d82540900e6a5e
well finally found the way to make it work in the legion 7 2021 AMD (16achg6)... this is a short tutorial to build the kernel with the patch (I've done it on fedora 35): 1) make sure you have all the tools to build the kernel (https://fedoraproject.org/wiki/Building_a_custom_kernel): * sudo dnf install fedpkg fedora-packager rpmdevtools ncurses-devel pesign grubby git 2) clone the kernel from github and checkout to v5.17 branch: * git clone https://github.com/torvalds/linux.git * cd linux * git checkout v5.17-rc4 * git pull 3) get the patch and install it: get the patch form this site: (top rigth corner "series" button): https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4-sbinding@opensource.cirrus.com/ * git am Support-Spi-in-i2c-multi-instantiate-driver.patch 4) load your old kernel config * make olddefconfig 5) change configuration at menuconfig as Howard Chu explained in his previous post * menuconfig -> Device Drivers / X86 Platform Specific Device Drivers / I2C and SPI multi instantiate pseudo device driver ------> Enable this 6) build the kernel * make -j 16 7) install the kernel * sudo make module_install * sudo make install 8) reboot and enjoy internal speakers (if anyone sees a mistake or something that I did wrong please feel free to correct these steps) Thank you to everyone who worked on this patch
Hi, Yes, you are right. You don't need to get that series patch if you use the linux-next tree or just wait for the next linux kernel release. Also, you could just: $ make olddefconfig $ ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE $ ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C $ ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI Instead of using menuconfig step. Thanks Lucas Tanure
(In reply to henry.hormaza from comment #560) > well finally found the way to make it work in the legion 7 2021 AMD > (16achg6)... > > this is a short tutorial to build the kernel with the patch (I've done it on > fedora 35): > > 1) make sure you have all the tools to build the kernel > (https://fedoraproject.org/wiki/Building_a_custom_kernel): > > * sudo dnf install fedpkg fedora-packager rpmdevtools ncurses-devel pesign > grubby git > > 2) clone the kernel from github and checkout to v5.17 branch: > > * git clone https://github.com/torvalds/linux.git > * cd linux > * git checkout v5.17-rc4 > * git pull > > 3) get the patch and install it: > > get the patch form this site: (top rigth corner "series" button): > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > sbinding@opensource.cirrus.com/ > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > 4) load your old kernel config > > * make olddefconfig > > 5) change configuration at menuconfig as Howard Chu explained in his > previous post > > * menuconfig -> Device Drivers / X86 Platform Specific Device Drivers / I2C > and SPI multi instantiate pseudo device driver ------> Enable this > > 6) build the kernel > > * make -j 16 > > 7) install the kernel > > * sudo make module_install > * sudo make install > > 8) reboot and enjoy internal speakers > > > (if anyone sees a mistake or something that I did wrong please feel free to > correct these steps) > > Thank you to everyone who worked on this patch legion 7 2021 AMD (16achg6) Can anyone do this tutorial for UBUNTU please?
*Ubuntu version: 1) install kernel build tools: (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git 2) clone the kernel from github and checkout to v5.17 branch (Rather large, multiple GB's): * git clone https://github.com/torvalds/linux.git * cd linux * git checkout v5.17-rc4 3) get the patch and install it: get the patch form this site and save to "linux" directory: (top right corner "series" button) and use the following "git am ..." line to apply the patch: https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4-sbinding@opensource.cirrus.com/ * git am Support-Spi-in-i2c-multi-instantiate-driver.patch 4) load current kernel config and change configuration then run the following scripts/config commands: * make olddefconfig * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI * ./scripts/config --disable CONFIG_DEBUG_INFO * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" 6) build the kernel * make -j 16 7) install the kernel * sudo make module_install * sudo make install
Note to *Ubuntu users, every time I install a fresh, self compiled kernel, the computer locks up on first boot. All subsequent boots work fine.
(In reply to Darin Miller from comment #563) > *Ubuntu version: > > 1) install kernel build tools: > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > 2) clone the kernel from github and checkout to v5.17 branch (Rather large, > multiple GB's): > > * git clone https://github.com/torvalds/linux.git > * cd linux > * git checkout v5.17-rc4 > > 3) get the patch and install it: > > get the patch form this site and save to "linux" directory: (top right > corner "series" button) and use the following "git am ..." line to apply the > patch: > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > sbinding@opensource.cirrus.com/ > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > 4) load current kernel config and change configuration then run the > following scripts/config commands: > > * make olddefconfig > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > * ./scripts/config --disable CONFIG_DEBUG_INFO > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > 6) build the kernel > > * make -j 16 > > 7) install the kernel > > * sudo make module_install > * sudo make install hi Darin!, First of all, thanks for sharing I tried in ubuntu 21.10 your guide, steps 1 to 6 perfect, no problem at all, in the 7), when run: sudo make module_install, i have: No rule to make target 'modules_install'. Stop. Later when i reboot the laptop (a lot of times), i have a missing modules error and the boot stay crashed on a initframs prompt. im missing to do something?. Regards!
Hmmm, I too now cannot get past the "sudo make module_install" message: No rule to make target 'modules_install'. Stop. I tried re-installing headers and relinking build & src directories as follows: sudo ln -s /usr/src/linux-headers-`uname -r` /lib/modules/`uname -r`/build sudo ln -s /usr/src/linux-headers-`uname -r` /lib/modules/`uname -r`/src but no progress.
(In reply to Fer Korol from comment #565) in the 7), when run: sudo make module_install, i have: > No rule to make target 'modules_install'. Stop. it's `sudo make modules_install` you are missing an 's'
I can confirm (In reply to Darin Miller from comment #563) > *Ubuntu version: > > 1) install kernel build tools: > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > 2) clone the kernel from github and checkout to v5.17 branch (Rather large, > multiple GB's): > > * git clone https://github.com/torvalds/linux.git > * cd linux > * git checkout v5.17-rc4 > > 3) get the patch and install it: > > get the patch form this site and save to "linux" directory: (top right > corner "series" button) and use the following "git am ..." line to apply the > patch: > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > sbinding@opensource.cirrus.com/ > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > 4) load current kernel config and change configuration then run the > following scripts/config commands: > > * make olddefconfig > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > * ./scripts/config --disable CONFIG_DEBUG_INFO > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > 6) build the kernel > > * make -j 16 > > 7) install the kernel > > * sudo make module_install > * sudo make install I confirm this guide works flawless on ubuntu 21.10 with this considerations: * The steps 3) and above, i run as root user (sudo su or su) * In the 7) step, as have been comented, the correct command is: sudo make modules_install With this tweaks no more freezes at the boot. Regards!
(In reply to Fer Korol from comment #568) > I can confirm (In reply to Darin Miller from comment #563) > > *Ubuntu version: > > > > 1) install kernel build tools: > > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms > > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > > > 2) clone the kernel from github and checkout to v5.17 branch (Rather large, > > multiple GB's): > > > > * git clone https://github.com/torvalds/linux.git > > * cd linux > > * git checkout v5.17-rc4 > > > > 3) get the patch and install it: > > > > get the patch form this site and save to "linux" directory: (top right > > corner "series" button) and use the following "git am ..." line to apply > the > > patch: > > > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > > sbinding@opensource.cirrus.com/ > > > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > > > 4) load current kernel config and change configuration then run the > > following scripts/config commands: > > > > * make olddefconfig > > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > > * ./scripts/config --disable CONFIG_DEBUG_INFO > > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > > > 6) build the kernel > > > > * make -j 16 > > > > 7) install the kernel > > > > * sudo make module_install > > * sudo make install > > I confirm this guide works flawless on ubuntu 21.10 with this considerations: > * The steps 3) and above, i run as root user (sudo su or su) > * In the 7) step, as have been comented, the correct command is: > sudo make modules_install > > With this tweaks no more freezes at the boot. > > Regards! What pc model?
(In reply to darnellkeithj from comment #569) > (In reply to Fer Korol from comment #568) > > I can confirm (In reply to Darin Miller from comment #563) > > > *Ubuntu version: > > > > > > 1) install kernel build tools: > > > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > > > > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms > > > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > > > > > 2) clone the kernel from github and checkout to v5.17 branch (Rather > large, > > > multiple GB's): > > > > > > * git clone https://github.com/torvalds/linux.git > > > * cd linux > > > * git checkout v5.17-rc4 > > > > > > 3) get the patch and install it: > > > > > > get the patch form this site and save to "linux" directory: (top right > > > corner "series" button) and use the following "git am ..." line to apply > > the > > > patch: > > > > > > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > > > sbinding@opensource.cirrus.com/ > > > > > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > > > > > 4) load current kernel config and change configuration then run the > > > following scripts/config commands: > > > > > > * make olddefconfig > > > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > > > * ./scripts/config --disable CONFIG_DEBUG_INFO > > > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > > > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > > > > > 6) build the kernel > > > > > > * make -j 16 > > > > > > 7) install the kernel > > > > > > * sudo make module_install > > > * sudo make install > > > > I confirm this guide works flawless on ubuntu 21.10 with this > considerations: > > * The steps 3) and above, i run as root user (sudo su or su) > > * In the 7) step, as have been comented, the correct command is: > > sudo make modules_install > > > > With this tweaks no more freezes at the boot. > > > > Regards! > > What pc model? Lenovo Legion 7 5800h RTX-3070
(In reply to Fer Korol from comment #570) > (In reply to darnellkeithj from comment #569) > > (In reply to Fer Korol from comment #568) > > > I can confirm (In reply to Darin Miller from comment #563) > > > > *Ubuntu version: > > > > > > > > 1) install kernel build tools: > > > > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > > > > > > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev > dkms > > > > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > > > > > > > 2) clone the kernel from github and checkout to v5.17 branch (Rather > > large, > > > > multiple GB's): > > > > > > > > * git clone https://github.com/torvalds/linux.git > > > > * cd linux > > > > * git checkout v5.17-rc4 > > > > > > > > 3) get the patch and install it: > > > > > > > > get the patch form this site and save to "linux" directory: (top right > > > > corner "series" button) and use the following "git am ..." line to > apply > > > the > > > > patch: > > > > > > > > > > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > > > > sbinding@opensource.cirrus.com/ > > > > > > > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > > > > > > > 4) load current kernel config and change configuration then run the > > > > following scripts/config commands: > > > > > > > > * make olddefconfig > > > > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > > > > * ./scripts/config --disable CONFIG_DEBUG_INFO > > > > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > > > > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > > > > > > > 6) build the kernel > > > > > > > > * make -j 16 > > > > > > > > 7) install the kernel > > > > > > > > * sudo make module_install > > > > * sudo make install > > > > > > I confirm this guide works flawless on ubuntu 21.10 with this > > considerations: > > > * The steps 3) and above, i run as root user (sudo su or su) > > > * In the 7) step, as have been comented, the correct command is: > > > sudo make modules_install > > > > > > With this tweaks no more freezes at the boot. > > > > > > Regards! > > > > What pc model? > > Lenovo Legion 7 5800h RTX-3070 I have the same, just got it two days ago. Unforntunately even with installing the release candidate rc4 and rc5 of kernel5.17, the sound does not work. When going to sound settings it does not list anything as output devices. I am using ubuntu 21.0 actually. Any idea? I also had plenty of issues setting the bluetooth connections to my keyboard, gnome-shell is consuming CPU like crazy etc - so seems like some kind of outside force is trying to keep this PC and ubuntu as far as possible :D
Here is another variant, now with RC6, works the sound and the nvidia drivers at the same time! (with some tricks): A) FIRST TIME 1) install kernel build tools: (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git p7zip-full 2) clone the kernel from github and checkout to v5.17 branch (Rather large, multiple GB's): * git clone https://github.com/torvalds/linux.git 3)Make a 7z of the linux folder in a clear state 7z a linux-clean.7z linux 3) get the patch and let it in one superior level of the linux folder: https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4-sbinding@opensource.cirrus.com/ A) FOR EACH RC RELEASE: 7z x linux-clean.7z cp Support-Spi-in-i2c-multi-instantiate-driver.patch linux/ cd linux git pull git checkout v5.17-rc6 git am Support-Spi-in-i2c-multi-instantiate-driver.patch make olddefconfig ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI ./scripts/config --disable CONFIG_DEBUG_INFO ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" make -j 16 make modules_install make install The patch is mandatory to enable the sound in ubuntu, im tried without the path and the sound don't work. With this steps will do. In order to make work the nvidia drivers in the 17-rc6 im just change in "more drivers" option of ubuntu, the current versión of the nvidia driver for another (511 to 470 for example). Im using hybrid graphics mode in the bios.
> In order to make work the nvidia drivers in the 17-rc6 im just change in > "more drivers" option of ubuntu, the current versión of the nvidia driver > for another (511 to 470 for example). > Im using hybrid graphics mode in the bios. Great discovery on enabling the NVidia drivers under Ubuntu. A side note for Kubuntu users, run: sudo software-properties-qt Then toggle the driver version on the Additional Drivers tab. A second note. In order to boot into discrete graphics mode, change the profile to "nvidia" either in NVidia settings or command line: sudo prime-select nvidia Reboot into BIOS and select the dedicated graphics option. I assigned the following command to a shortcut key to boot reboot directly to BIOS: systemctl reboot --firmware-setup
Can't someone just make a kernel build for ubuntu or some widely used Linux version and put it on github? There is a lot of patching going on here but no good documentation on how to do it.
(In reply to darnellkeithj from comment #574) > Can't someone just make a kernel build for ubuntu or some widely used Linux > version and put it on github? There is a lot of patching going on here but > no good documentation on how to do it. Probably yes, but not sure you should trust and install a kernel hosted by just anyone ;-) I'm hoping that this patch will just soon find it's way to the official distributed kernels...
(In reply to Fer Korol from comment #572) > Here is another variant, now with RC6, works the sound and the nvidia > drivers at the same time! (with some tricks): > > A) FIRST TIME > 1) install kernel build tools: > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git p7zip-full > > 2) clone the kernel from github and checkout to v5.17 branch (Rather large, > multiple GB's): > > * git clone https://github.com/torvalds/linux.git > > 3)Make a 7z of the linux folder in a clear state > 7z a linux-clean.7z linux > > 3) get the patch and let it in one superior level of the linux folder: > > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > sbinding@opensource.cirrus.com/ > > > A) FOR EACH RC RELEASE: > 7z x linux-clean.7z > cp Support-Spi-in-i2c-multi-instantiate-driver.patch linux/ > cd linux > git pull > git checkout v5.17-rc6 > git am Support-Spi-in-i2c-multi-instantiate-driver.patch > make olddefconfig > ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > ./scripts/config --disable CONFIG_DEBUG_INFO > ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > make -j 16 > make modules_install > make install > > > The patch is mandatory to enable the sound in ubuntu, im tried without the > path and the sound don't work. With this steps will do. > In order to make work the nvidia drivers in the 17-rc6 im just change in > "more drivers" option of ubuntu, the current versión of the nvidia driver > for another (511 to 470 for example). > Im using hybrid graphics mode in the bios. Thanks! I just tried this rc6 version on my machine, and sound plus nvidia drivers work fine with this. In addition to the described steps, I also did run a "make headers_install", to make sure that nvidia could compile it's module. My machine: Lenovo Legion 7 16ACHg6 82N6 - Laptop 16" IPS 2560 x 1600 (WQXGA) 165 Hz - AMD Ryzen - with 3 external monitors connected and working (2560x1440). I hope the patch gets propagated soon to a real release.
(In reply to Darin Miller from comment #563) > *Ubuntu version: > > 1) install kernel build tools: > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > 2) clone the kernel from github and checkout to v5.17 branch (Rather large, > multiple GB's): > > * git clone https://github.com/torvalds/linux.git > * cd linux > * git checkout v5.17-rc4 > > 3) get the patch and install it: > > get the patch form this site and save to "linux" directory: (top right > corner "series" button) and use the following "git am ..." line to apply the > patch: > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > sbinding@opensource.cirrus.com/ > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > 4) load current kernel config and change configuration then run the > following scripts/config commands: > > * make olddefconfig > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > * ./scripts/config --disable CONFIG_DEBUG_INFO > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > 6) build the kernel > > * make -j 16 > > 7) install the kernel > > * sudo make module_install > * sudo make install Hi guys, This is my first time compiling a kernel (Legion 7 16ACHg6/Ubuntu 20.04). I followed these steps (checked out the v5.17-rc8 branch on git) but at the end I am getting this error at the last step, just before running sudo make install: arch/x86/Makefile:154: CONFIG_X86_X32 enabled but no binutils support sh ./arch/x86/boot/install.sh 5.17.0-rc8+ \ arch/x86/boot/bzImage System.map "/boot" *** Missing file: arch/x86/boot/bzImage *** You need to run "make" before "make install". make: *** [arch/x86/Makefile:278: install] Error 1 Any help would be appreciated
(In reply to vpi from comment #577) > (In reply to Darin Miller from comment #563) > > *Ubuntu version: > > > > 1) install kernel build tools: > > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms > > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > > > 2) clone the kernel from github and checkout to v5.17 branch (Rather large, > > multiple GB's): > > > > * git clone https://github.com/torvalds/linux.git > > * cd linux > > * git checkout v5.17-rc4 > > > > 3) get the patch and install it: > > > > get the patch form this site and save to "linux" directory: (top right > > corner "series" button) and use the following "git am ..." line to apply > the > > patch: > > > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > > sbinding@opensource.cirrus.com/ > > > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > > > 4) load current kernel config and change configuration then run the > > following scripts/config commands: > > > > * make olddefconfig > > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > > * ./scripts/config --disable CONFIG_DEBUG_INFO > > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > > > 6) build the kernel > > > > * make -j 16 > > > > 7) install the kernel > > > > * sudo make module_install > > * sudo make install > > Hi guys, > > This is my first time compiling a kernel (Legion 7 16ACHg6/Ubuntu 20.04). I > followed these steps (checked out the v5.17-rc8 branch on git) but at the > end I am getting this error at the last step, just before running sudo make > install: > > arch/x86/Makefile:154: CONFIG_X86_X32 enabled but no binutils support > sh ./arch/x86/boot/install.sh 5.17.0-rc8+ \ > arch/x86/boot/bzImage System.map "/boot" > > *** Missing file: arch/x86/boot/bzImage > *** You need to run "make" before "make install". > > make: *** [arch/x86/Makefile:278: install] Error 1 > > Any help would be appreciated Hello @vpi Before running "make install" you need to compile the kernel with "make". "make install" will install the compiled kernel, so you need to compile it first.
(In reply to Mark York from comment #578) > (In reply to vpi from comment #577) > > (In reply to Darin Miller from comment #563) > > > *Ubuntu version: > > > > > > 1) install kernel build tools: > > > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > > > > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms > > > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > > > > > 2) clone the kernel from github and checkout to v5.17 branch (Rather > large, > > > multiple GB's): > > > > > > * git clone https://github.com/torvalds/linux.git > > > * cd linux > > > * git checkout v5.17-rc4 > > > > > > 3) get the patch and install it: > > > > > > get the patch form this site and save to "linux" directory: (top right > > > corner "series" button) and use the following "git am ..." line to apply > > the > > > patch: > > > > > > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > > > sbinding@opensource.cirrus.com/ > > > > > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > > > > > 4) load current kernel config and change configuration then run the > > > following scripts/config commands: > > > > > > * make olddefconfig > > > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > > > * ./scripts/config --disable CONFIG_DEBUG_INFO > > > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > > > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > > > > > 6) build the kernel > > > > > > * make -j 16 > > > > > > 7) install the kernel > > > > > > * sudo make module_install > > > * sudo make install > > > > Hi guys, > > > > This is my first time compiling a kernel (Legion 7 16ACHg6/Ubuntu 20.04). I > > followed these steps (checked out the v5.17-rc8 branch on git) but at the > > end I am getting this error at the last step, just before running sudo make > > install: > > > > arch/x86/Makefile:154: CONFIG_X86_X32 enabled but no binutils support > > sh ./arch/x86/boot/install.sh 5.17.0-rc8+ \ > > arch/x86/boot/bzImage System.map "/boot" > > > > *** Missing file: arch/x86/boot/bzImage > > *** You need to run "make" before "make install". > > > > make: *** [arch/x86/Makefile:278: install] Error 1 > > > > Any help would be appreciated > > > Hello @vpi > > Before running "make install" you need to compile the kernel with "make". > "make install" will install the compiled kernel, so you need to compile it > first. Hi Mark, I should've been clearer in my last comment. I followed the instructions stepwise, which means I ran "make -j 16" before running "make install". And yet I was getting this error.
(In reply to vpi from comment #579) > (In reply to Mark York from comment #578) > > (In reply to vpi from comment #577) > > > (In reply to Darin Miller from comment #563) > > > > *Ubuntu version: > > > > > > > > 1) install kernel build tools: > > > > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > > > > > > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev > dkms > > > > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > > > > > > > 2) clone the kernel from github and checkout to v5.17 branch (Rather > > large, > > > > multiple GB's): > > > > > > > > * git clone https://github.com/torvalds/linux.git > > > > * cd linux > > > > * git checkout v5.17-rc4 > > > > > > > > 3) get the patch and install it: > > > > > > > > get the patch form this site and save to "linux" directory: (top right > > > > corner "series" button) and use the following "git am ..." line to > apply > > > the > > > > patch: > > > > > > > > > > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > > > > sbinding@opensource.cirrus.com/ > > > > > > > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > > > > > > > 4) load current kernel config and change configuration then run the > > > > following scripts/config commands: > > > > > > > > * make olddefconfig > > > > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > > > > * ./scripts/config --disable CONFIG_DEBUG_INFO > > > > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > > > > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > > > > > > > 6) build the kernel > > > > > > > > * make -j 16 > > > > > > > > 7) install the kernel > > > > > > > > * sudo make module_install > > > > * sudo make install > > > > > > Hi guys, > > > > > > This is my first time compiling a kernel (Legion 7 16ACHg6/Ubuntu 20.04). > I > > > followed these steps (checked out the v5.17-rc8 branch on git) but at the > > > end I am getting this error at the last step, just before running sudo > make > > > install: > > > > > > arch/x86/Makefile:154: CONFIG_X86_X32 enabled but no binutils support > > > sh ./arch/x86/boot/install.sh 5.17.0-rc8+ \ > > > arch/x86/boot/bzImage System.map "/boot" > > > > > > *** Missing file: arch/x86/boot/bzImage > > > *** You need to run "make" before "make install". > > > > > > make: *** [arch/x86/Makefile:278: install] Error 1 > > > > > > Any help would be appreciated > > > > > > Hello @vpi > > > > Before running "make install" you need to compile the kernel with "make". > > "make install" will install the compiled kernel, so you need to compile it > > first. > > Hi Mark, > > I should've been clearer in my last comment. I followed the instructions > stepwise, which means I ran "make -j 16" before running "make install". And > yet I was getting this error. Hi vpi, I would recommend to start fresh. What I would do is: 1. Get into the kernel config with "make menuconfig", load the .config file from the "Load" button at the bottom. 2. Exit the menu, this will save the and accommodate the config. 3. Compile the kernel with "make" and whatever options you want. 3. Compile the kernel modules (if you have chosen to build drivers as modules) with "make modules_install". 5. Install the kernel image in /boot with "make install". Try this and let me know of the results. I'm really interested in fixing this problem myself as well. I have a Legion 7 16ACHg6 (AMD) and speakers don't work on Arch Linux. 4.
(In reply to Mark York from comment #580) > (In reply to vpi from comment #579) > > (In reply to Mark York from comment #578) > > > (In reply to vpi from comment #577) > > > > (In reply to Darin Miller from comment #563) > > > > > *Ubuntu version: > > > > > > > > > > 1) install kernel build tools: > > > > > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > > > > > > > > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev > > dkms > > > > > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > > > > > > > > > 2) clone the kernel from github and checkout to v5.17 branch (Rather > > > large, > > > > > multiple GB's): > > > > > > > > > > * git clone https://github.com/torvalds/linux.git > > > > > * cd linux > > > > > * git checkout v5.17-rc4 > > > > > > > > > > 3) get the patch and install it: > > > > > > > > > > get the patch form this site and save to "linux" directory: (top > right > > > > > corner "series" button) and use the following "git am ..." line to > > apply > > > > the > > > > > patch: > > > > > > > > > > > > > > > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > > > > > sbinding@opensource.cirrus.com/ > > > > > > > > > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > > > > > > > > > 4) load current kernel config and change configuration then run the > > > > > following scripts/config commands: > > > > > > > > > > * make olddefconfig > > > > > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > > > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > > > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > > > > > * ./scripts/config --disable CONFIG_DEBUG_INFO > > > > > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > > > > > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > > > > > > > > > 6) build the kernel > > > > > > > > > > * make -j 16 > > > > > > > > > > 7) install the kernel > > > > > > > > > > * sudo make module_install > > > > > * sudo make install > > > > > > > > Hi guys, > > > > > > > > This is my first time compiling a kernel (Legion 7 16ACHg6/Ubuntu > 20.04). > > I > > > > followed these steps (checked out the v5.17-rc8 branch on git) but at > the > > > > end I am getting this error at the last step, just before running sudo > > make > > > > install: > > > > > > > > arch/x86/Makefile:154: CONFIG_X86_X32 enabled but no binutils support > > > > sh ./arch/x86/boot/install.sh 5.17.0-rc8+ \ > > > > arch/x86/boot/bzImage System.map "/boot" > > > > > > > > *** Missing file: arch/x86/boot/bzImage > > > > *** You need to run "make" before "make install". > > > > > > > > make: *** [arch/x86/Makefile:278: install] Error 1 > > > > > > > > Any help would be appreciated > > > > > > > > > Hello @vpi > > > > > > Before running "make install" you need to compile the kernel with "make". > > > "make install" will install the compiled kernel, so you need to compile > it > > > first. > > > > Hi Mark, > > > > I should've been clearer in my last comment. I followed the instructions > > stepwise, which means I ran "make -j 16" before running "make install". And > > yet I was getting this error. > > Hi vpi, > > I would recommend to start fresh. What I would do is: > 1. Get into the kernel config with "make menuconfig", load the .config file > from the "Load" button at the bottom. > 2. Exit the menu, this will save the and accommodate the config. > 3. Compile the kernel with "make" and whatever options you want. > 3. Compile the kernel modules (if you have chosen to build drivers as > modules) with "make modules_install". > 5. Install the kernel image in /boot with "make install". > > Try this and let me know of the results. I'm really interested in fixing > this problem myself as well. I have a Legion 7 16ACHg6 (AMD) and speakers > don't work on Arch Linux. > 4. Remember to check GRUB's config files to include the new kernel image.
(In reply to Mark York from comment #580) > (In reply to vpi from comment #579) > > (In reply to Mark York from comment #578) > > > (In reply to vpi from comment #577) > > > > (In reply to Darin Miller from comment #563) > > > > > *Ubuntu version: > > > > > > > > > > 1) install kernel build tools: > > > > > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > > > > > > > > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev > > dkms > > > > > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > > > > > > > > > 2) clone the kernel from github and checkout to v5.17 branch (Rather > > > large, > > > > > multiple GB's): > > > > > > > > > > * git clone https://github.com/torvalds/linux.git > > > > > * cd linux > > > > > * git checkout v5.17-rc4 > > > > > > > > > > 3) get the patch and install it: > > > > > > > > > > get the patch form this site and save to "linux" directory: (top > right > > > > > corner "series" button) and use the following "git am ..." line to > > apply > > > > the > > > > > patch: > > > > > > > > > > > > > > > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > > > > > sbinding@opensource.cirrus.com/ > > > > > > > > > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > > > > > > > > > 4) load current kernel config and change configuration then run the > > > > > following scripts/config commands: > > > > > > > > > > * make olddefconfig > > > > > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > > > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > > > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > > > > > * ./scripts/config --disable CONFIG_DEBUG_INFO > > > > > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > > > > > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > > > > > > > > > 6) build the kernel > > > > > > > > > > * make -j 16 > > > > > > > > > > 7) install the kernel > > > > > > > > > > * sudo make module_install > > > > > * sudo make install > > > > > > > > Hi guys, > > > > > > > > This is my first time compiling a kernel (Legion 7 16ACHg6/Ubuntu > 20.04). > > I > > > > followed these steps (checked out the v5.17-rc8 branch on git) but at > the > > > > end I am getting this error at the last step, just before running sudo > > make > > > > install: > > > > > > > > arch/x86/Makefile:154: CONFIG_X86_X32 enabled but no binutils support > > > > sh ./arch/x86/boot/install.sh 5.17.0-rc8+ \ > > > > arch/x86/boot/bzImage System.map "/boot" > > > > > > > > *** Missing file: arch/x86/boot/bzImage > > > > *** You need to run "make" before "make install". > > > > > > > > make: *** [arch/x86/Makefile:278: install] Error 1 > > > > > > > > Any help would be appreciated > > > > > > > > > Hello @vpi > > > > > > Before running "make install" you need to compile the kernel with "make". > > > "make install" will install the compiled kernel, so you need to compile > it > > > first. > > > > Hi Mark, > > > > I should've been clearer in my last comment. I followed the instructions > > stepwise, which means I ran "make -j 16" before running "make install". And > > yet I was getting this error. > > Hi vpi, > > I would recommend to start fresh. What I would do is: > 1. Get into the kernel config with "make menuconfig", load the .config file > from the "Load" button at the bottom. > 2. Exit the menu, this will save the and accommodate the config. > 3. Compile the kernel with "make" and whatever options you want. > 3. Compile the kernel modules (if you have chosen to build drivers as > modules) with "make modules_install". > 5. Install the kernel image in /boot with "make install". > > Try this and let me know of the results. I'm really interested in fixing > this problem myself as well. I have a Legion 7 16ACHg6 (AMD) and speakers > don't work on Arch Linux. > 4. I forgot to mention that you should add the patches after loading the conf file.
Hi, I'm trying the new fedora 36, right now it has the 5.17.0 RC8, what should I do to enable the configuration without building the kernel? or is just that the RC8 don't have the patch yet?
(In reply to henry.hormaza from comment #583) > Hi, I'm trying the new fedora 36, right now it has the 5.17.0 RC8, what > should I do to enable the configuration without building the kernel? or is > just that the RC8 don't have the patch yet? I using Fedora 35 right now, I have the Galaxy Book Pro 360, but it has the ALC298 realtek chip. I tried this patch for the kernel within this bug report but still didn't work for me. Also, the kernel 5.16.15 still doesn't seem to have a fix or even 5.17. However, this guide works: https://forum.manjaro.org/t/howto-set-up-the-audio-card-in-samsung-galaxy-book/37090 All I needed to do was install alsa-tools then run the script with the hda-verbs and after running the script (need to run it a few times) my audio works from my speakers and headphone. Without this, just audio works from headphone jack but not from speakers. Additionally, after some time maybe 1 hr or so, or, if I exit a page with audio running, I need to re run the script again to apply the hda-verbs for my speakers to work. Anyways, that worked for me and it might work for you. No need to mess with any kernel patches.
(In reply to Alex from comment #584) > (In reply to henry.hormaza from comment #583) > > Hi, I'm trying the new fedora 36, right now it has the 5.17.0 RC8, what > > should I do to enable the configuration without building the kernel? or is > > just that the RC8 don't have the patch yet? > > I using Fedora 35 right now, I have the Galaxy Book Pro 360, but it has the > ALC298 realtek chip. I tried this patch for the kernel within this bug > report but still didn't work for me. Also, the kernel 5.16.15 still doesn't > seem to have a fix or even 5.17. > > However, this guide works: > https://forum.manjaro.org/t/howto-set-up-the-audio-card-in-samsung-galaxy- > book/37090 > > All I needed to do was install alsa-tools then run the script with the > hda-verbs and after running the script (need to run it a few times) my audio > works from my speakers and headphone. Without this, just audio works from > headphone jack but not from speakers. > > Additionally, after some time maybe 1 hr or so, or, if I exit a page with > audio running, I need to re run the script again to apply the hda-verbs for > my speakers to work. > > Anyways, that worked for me and it might work for you. No need to mess with > any kernel patches. I already have my laptop with sound on fedora 35 (comment 560), I was talking about the kernel 5.17 that will be set in fedora 36. I don't understand how is merged every patch in a new kernel release.
(In reply to Mark York from comment #580) > (In reply to vpi from comment #579) > > (In reply to Mark York from comment #578) > > > (In reply to vpi from comment #577) > > > > (In reply to Darin Miller from comment #563) > > > > > *Ubuntu version: > > > > > > > > > > 1) install kernel build tools: > > > > > (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel): > > > > > > > > > > * sudo apt install libncurses-dev gawk flex bison openssl libssl-dev > > dkms > > > > > libelf-dev libudev-dev libpci-dev libiberty-dev autoconf git > > > > > > > > > > 2) clone the kernel from github and checkout to v5.17 branch (Rather > > > large, > > > > > multiple GB's): > > > > > > > > > > * git clone https://github.com/torvalds/linux.git > > > > > * cd linux > > > > > * git checkout v5.17-rc4 > > > > > > > > > > 3) get the patch and install it: > > > > > > > > > > get the patch form this site and save to "linux" directory: (top > right > > > > > corner "series" button) and use the following "git am ..." line to > > apply > > > > the > > > > > patch: > > > > > > > > > > > > > > > https://patchwork.kernel.org/project/linux-acpi/patch/20220121172431.6876-4- > > > > > sbinding@opensource.cirrus.com/ > > > > > > > > > > * git am Support-Spi-in-i2c-multi-instantiate-driver.patch > > > > > > > > > > 4) load current kernel config and change configuration then run the > > > > > following scripts/config commands: > > > > > > > > > > * make olddefconfig > > > > > * ./scripts/config --enable CONFIG_SERIAL_MULTI_INSTANTIATE > > > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_I2C > > > > > * ./scripts/config --enable CONFIG_SND_HDA_SCODEC_CS35L41_SPI > > > > > * ./scripts/config --disable CONFIG_DEBUG_INFO > > > > > * ./scripts/config --set-str CONFIG_SYSTEM_TRUSTED_KEYS "" > > > > > * ./scripts/config --set-str CONFIG_SYSTEM_REVOCATION_KEYS "" > > > > > > > > > > 6) build the kernel > > > > > > > > > > * make -j 16 > > > > > > > > > > 7) install the kernel > > > > > > > > > > * sudo make module_install > > > > > * sudo make install > > > > > > > > Hi guys, > > > > > > > > This is my first time compiling a kernel (Legion 7 16ACHg6/Ubuntu > 20.04). > > I > > > > followed these steps (checked out the v5.17-rc8 branch on git) but at > the > > > > end I am getting this error at the last step, just before running sudo > > make > > > > install: > > > > > > > > arch/x86/Makefile:154: CONFIG_X86_X32 enabled but no binutils support > > > > sh ./arch/x86/boot/install.sh 5.17.0-rc8+ \ > > > > arch/x86/boot/bzImage System.map "/boot" > > > > > > > > *** Missing file: arch/x86/boot/bzImage > > > > *** You need to run "make" before "make install". > > > > > > > > make: *** [arch/x86/Makefile:278: install] Error 1 > > > > > > > > Any help would be appreciated > > > > > > > > > Hello @vpi > > > > > > Before running "make install" you need to compile the kernel with "make". > > > "make install" will install the compiled kernel, so you need to compile > it > > > first. > > > > Hi Mark, > > > > I should've been clearer in my last comment. I followed the instructions > > stepwise, which means I ran "make -j 16" before running "make install". And > > yet I was getting this error. > > Hi vpi, > > I would recommend to start fresh. What I would do is: > 1. Get into the kernel config with "make menuconfig", load the .config file > from the "Load" button at the bottom. > 2. Exit the menu, this will save the and accommodate the config. > 3. Compile the kernel with "make" and whatever options you want. > 3. Compile the kernel modules (if you have chosen to build drivers as > modules) with "make modules_install". > 5. Install the kernel image in /boot with "make install". > > Try this and let me know of the results. I'm really interested in fixing > this problem myself as well. I have a Legion 7 16ACHg6 (AMD) and speakers > don't work on Arch Linux. > 4. Since its my first time doing this, I am kinda confused about these steps. When I run "make menuconfig" and try to load the file at path .config in the subsequent screen, it says file does not exist. So where am I supposed to find this? And when you say "Remember to check GRUB's config files to include the new kernel image." what exactly do you mean? Thanks.
Can somebody confirm what Kernel this is actually submitted to as a working solution without patches etc? I have been following for a long time and I was under the impression that the official 5.17 release had it incorporated? I am currently using Manjaro Linux with the 5.17.1-3 kernel, and I still have no sound from the speakers. ->> Legion 7-16ACHg6 Laptop (Lenovo) - Type 82N6 Any help appreciated. I really don't want to bother with patches etc, I just would like to know what official kernel will get my speakers working. Thanks
(In reply to jansen from comment #587) > Can somebody confirm what Kernel this is actually submitted to as a working > solution without patches etc? I have been following for a long time and I > was under the impression that the official 5.17 release had it incorporated? > > I am currently using Manjaro Linux with the 5.17.1-3 kernel, and I still > have no sound from the speakers. > > ->> Legion 7-16ACHg6 Laptop (Lenovo) - Type 82N6 > > Any help appreciated. I really don't want to bother with patches etc, I just > would like to know what official kernel will get my speakers working. Thanks The same issue. Linux mint 20.3 with the 5.17.1 kernel, no sound from the speakers ->> Legion 7 16ACHg6 (Lenovo)
I am using Pop_OS 21.10, with xanmod edge kernel(5.17.1) and no audio either :(
Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ Thank you everyone for all your efforts!
(In reply to Darin Miller from comment #590) > Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for > LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : > > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ > > Thank you everyone for all your efforts! I installed the kernel in PopOS, and it works! I now have speakers working!!! They sound a lot quieter and crappier than in Windows, but now they work. Thanks!
(In reply to bettodiaz from comment #591) > (In reply to Darin Miller from comment #590) > > Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for > > LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : > > > > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ > > > > Thank you everyone for all your efforts! > > I installed the kernel in PopOS, and it works! I now have speakers working!!! > They sound a lot quieter and crappier than in Windows, but now they work. > > Thanks! Can anyone change brightness with this kernel?
(In reply to Popescu Robertto from comment #592) > (In reply to bettodiaz from comment #591) > > (In reply to Darin Miller from comment #590) > > > Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for > > > LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : > > > > > > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ > > > > > > Thank you everyone for all your efforts! > > > > I installed the kernel in PopOS, and it works! I now have speakers > working!!! > > They sound a lot quieter and crappier than in Windows, but now they work. > > > > Thanks! > > Can anyone change brightness with this kernel? I have not tried that mentioned ubuntu kernel. With the source of 5.17.0-rc8+ and patches as described in this thread I do have audio but no brightness control. It does show a brightness bar on screen when hitting the keys, but no effect on screen itself. Running linux mint 20.3, XFCE version, on Lenovo Legion 7 16ACHg6 82N6. Note: before running this patched kernel, also my laptop screen sometimes stayed black after then screensaver/screen-lock was active. With the patched rc8 I have not seen that happening anymore. Running nvidia 510.54-* drivers. Thijs.
Currently the 5.18-rc1 kernel throws an error when attempting install 510 drivers: dpkg: error processing package nvidia-driver-510 (--configure): dependency problems - leaving unconfigured Subsequently, laptop refuses to boot discrete graphics when prime-select = nvidia. However, on-demand "works" (but no perf tests to support). Regardless, brightness control have always worked in on-demand or "intel" (built-in vega) graphics mode. As soon as I can fully install the 510 driver, I will check brightness controls and report back. (We need another thread for this discussion other this bug report... any suggestions?)
The issue appears to be that the Nvidia kernel module is failing to build and therefore you do not have working Nvidia support with this kernel. I'm not sure how you configured your kernel so I suspect you have one OR both of the following issues: 1. Nvidia's drivers do not yet support 5.18-rc1. Either Nvidia hasn't added support yet or your distribution's drivers are a little behind. Given that this is an rc1, it could be Nvidia that's behind. 2. Something in your kernel config is incompatible with the Nvidia drivers. I strongly suspect it's #1 as others are having the same problem. try: lsmod | grep nvidia You likely won't see anything. At this point, it depends what's more important to you... Gaming or sound. You can revert to an older kernel or remove the Nvidia drivers for now. Eventually, newer kernels will be supported. In my experience, Nvidia usually isn't too far behind the curve on newer kernel support. On a related note, brightness control with Nvidia in discrete mode has never worked for me on my Lenovo Legion 7i 16ITHg6. (In reply to Darin Miller from comment #594) > Currently the 5.18-rc1 kernel throws an error when attempting install 510 > drivers: > > dpkg: error processing package nvidia-driver-510 (--configure): > dependency problems - leaving unconfigured > > Subsequently, laptop refuses to boot discrete graphics when prime-select = > nvidia. However, on-demand "works" (but no perf tests to support). > > Regardless, brightness control have always worked in on-demand or "intel" > (built-in vega) graphics mode. > > As soon as I can fully install the 510 driver, I will check brightness > controls and report back. (We need another thread for this discussion other > this bug report... any suggestions?)
I am assuming this is the same issue. My laptop is a Yoga 9 and I am able to get sound but it is very quite, not nearly as loud as in Windows. I have the pavucontrol cranked all the way up and its still super quite. Host: 82LU Yoga 9 14IAP7 Kernel: 5.17.1-arch1-1 I was under the understanding that upgrading to 5.17 would fix this but I guess not. Any help is appreciated
(In reply to semaj4712 from comment #596) > I am assuming this is the same issue. My laptop is a Yoga 9 and I am able > to get sound but it is very quite, not nearly as loud as in Windows. I have > the pavucontrol cranked all the way up and its still super quite. > > Host: 82LU Yoga 9 14IAP7 > Kernel: 5.17.1-arch1-1 > > I was under the understanding that upgrading to 5.17 would fix this but I > guess not. Any help is appreciated Use aslamixer to increase max volume (command line tool). Some recent versions of pipewire tends to reset devices to very low levels and pavucontrol is not able to override the volume limiters. A couple of my systems required this method to fix sound volumes.
In my case I am using Lenovo yoga slim7 and install pop-os with 5.16.19 kernel. I am able to generate audio output, but failed at input devices. Any help is appreciated.
Lenovo Legion S7 15IMH5 Has anyone managed to get their sound working on it? Would appreciate a tutorial or some tips (the more specific, the better, as this thread is full of other devices as well and it'd take a long time to try everything)
Looking at the model number, there's a chance it's compatible with the verbs of the 15IMHG05, or another model from around that time. Do you know how to build and run your own kernel? Also, please provide a URL to your alsa-info. On 5/15/2022 12:12 PM, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #599 from Andrei Miculita (andreimiculita+kern@gmail.com) --- > Lenovo Legion S7 15IMH5 > > Has anyone managed to get their sound working on it? Would appreciate a > tutorial or some tips (the more specific, the better, as this thread is full > of > other devices as well and it'd take a long time to try everything) >
(In reply to Cameron Berkenpas from comment #600) > Looking at the model number, there's a chance it's compatible with the > verbs of the 15IMHG05, or another model from around that time. > > Do you know how to build and run your own kernel? > > Also, please provide a URL to your alsa-info. > > On 5/15/2022 12:12 PM, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #599 from Andrei Miculita (andreimiculita+kern@gmail.com) --- > > Lenovo Legion S7 15IMH5 > > > > Has anyone managed to get their sound working on it? Would appreciate a > > tutorial or some tips (the more specific, the better, as this thread is > full > > of > > other devices as well and it'd take a long time to try everything) > > I do, it might take me a while to get it done if I start now, but I've done it before for fun. My alsa-info: http://alsa-project.org/db/?f=c1ba1098da13b2d7d6793fbce823e4feed2ac4ee
Created attachment 300990 [details] attachment-14829-0.html From your alsa-info (thanks!), I see that your subsystem id is 0x3822 compared to the 0x1813 of the 15IMHG05. In the root of the linux source folder/directory, open the file: sound/pci/hda/patch_realtek.c Find this line: SND_PCI_QUIRK(0x17aa, 0x3813, "Legion 7i 15IMHG05", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), Next to that line (before or after doesn't matter), add your own line: SND_PCI_QUIRK(0x17aa, 0x3822, "Legion 7i 15IMH5", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), If the ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS fix doesn't work for your laptop, try theALC287_FIXUP_YOGA7_14ITL_SPEAKERS fix as well. Ie, SND_PCI_QUIRK(0x17aa, 0x3822, "Legion 7i 15IMH5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), But given the similarities between our laptop models, I strongly suspect the 15IMHG05 fix will work for your laptop as well. Looks like you're running linux Mint, which, IIRC, is based on Debian or Ubuntu. For deb based distributions, you can build packages for your kernel like this: make bindeb-pkg You only really need the linux-image and linux-headers (for Nvidia) packages. To speed up the compile, you can pass in the -j option to parallelize the build: make -j$(nproc) bindeb-pkg On 5/17/22 14:32, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #601 from Andrei Miculita (andreimiculita+kern@gmail.com) --- > (In reply to Cameron Berkenpas from comment #600) >> Looking at the model number, there's a chance it's compatible with the >> verbs of the 15IMHG05, or another model from around that time. >> >> Do you know how to build and run your own kernel? >> >> Also, please provide a URL to your alsa-info. >> >> On 5/15/2022 12:12 PM,bugzilla-daemon@kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #599 from Andrei Miculita (andreimiculita+kern@gmail.com) --- >>> Lenovo Legion S7 15IMH5 >>> >>> Has anyone managed to get their sound working on it? Would appreciate a >>> tutorial or some tips (the more specific, the better, as this thread is >> full >>> of >>> other devices as well and it'd take a long time to try everything) >>> > > I do, it might take me a while to get it done if I start now, but I've done > it > before for fun. > > > My alsa-info: > http://alsa-project.org/db/?f=c1ba1098da13b2d7d6793fbce823e4feed2ac4ee >
Hi all, I'm facing the same problem with my Lenovo Legion 7. I'm running Ubuntu 20.04.4 LTS and am not very familiar with kernels. I tried finding the linux source folder/directory, open the file: sound/pci/hda/patch_realtek.c but I don't have the pci folder. Is there already a solution for this? My alsa-info: http://alsa-project.org/db/?f=bb246fbe1fe783444da0b95a9bab4fba09613c8a Appreciate any suggestions. Thanks!
Created attachment 301012 [details] attachment-29335-0.html I am currently out of the office on holiday I will be returning on Monday June 6, I will have limited access to email.
(In reply to sheryl@liang.at from comment #603) > Hi all, > I'm facing the same problem with my Lenovo Legion 7. I'm running Ubuntu > 20.04.4 LTS and am not very familiar with kernels. I tried finding the linux > source folder/directory, open the file: sound/pci/hda/patch_realtek.c but I > don't have the pci folder. > > Is there already a solution for this? > > My alsa-info: > http://alsa-project.org/db/?f=bb246fbe1fe783444da0b95a9bab4fba09613c8a > > Appreciate any suggestions. > Thanks! Seems you haven't installed the kernel source tree. Obtain the kernel headers and the compiler, and download the kernel sources ... sudo apt-get source linux-image-$(uname -r) sudo apt-get build-dep linux-image-$(uname -r) For compiling a kernel module that's a good doc. Start with: https://yoursunny.com/t/2018/one-kernel-module/ ... at the end there's only the need to replace one kernel module Seems that your ALC287 has the id 0x17aa3847 Unfortunately having never done that before will need some learning time ... The 2nd method would be to use the applyverbs method used also in one of our early trials (see comment 403). Please make sure that the underlying "hda-verb" is installed, which may need some searching. It simple fires the needed sequence to the devices as done in the kernel patch. Good luck ...
So maybe for all not used to build kernel modules you may give that a try: (sorry a comment describing that was 409) # install hda-verb # hopefully I have found the correct one sudo apt-get install alsa-tools # get applyverb.py https://github.com/ryanprescott/realtek-verb-tools # get the verbs txt file which does the miracle, i.e. https://bugzilla.kernel.org/attachment.cgi?id=297545 # patch the chip: sudo python3 applyverbs.py verbs.txt then run a youtube video or any other sound stuff ... Woody64
According to your alsa-info, you have the already supported 16ACHg6 which is supported in the latest versions of the kernel. There should be a repo you can add on your system to be able to pull the latest mainline kernels. I don't have it handy at the moment as I've been building/installing kernels myself since the 90's, but I'll try find it and post it in a little bit. The steps Woody shared are not necessary (no offense Woody), because: 1) Your hardware is already officially supported in newer kernel versions. 2) Our models of laptop have amp chips that are on the i2c bus and therefore cannot be enabled via HDA verbs. On 5/22/22 06:31, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > sheryl@liang.at (sheryl@liang.at) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |sheryl@liang.at > > --- Comment #603 from sheryl@liang.at (sheryl@liang.at) --- > Hi all, > I'm facing the same problem with my Lenovo Legion 7. I'm running Ubuntu > 20.04.4 > LTS and am not very familiar with kernels. I tried finding the linux source > folder/directory, open the file: sound/pci/hda/patch_realtek.c but I don't > have > the pci folder. > > Is there already a solution for this? > > My alsa-info: > http://alsa-project.org/db/?f=bb246fbe1fe783444da0b95a9bab4fba09613c8a > > Appreciate any suggestions. > Thanks! >
Seems like this is the best way to do it (but if someone knows of a better way for Ubuntu, let us know): https://sleeplessbeastie.eu/2021/11/01/how-to-install-mainline-linux-kernel-on-ubuntu-based-distribution/ Seems this gets you a tool that allows you to manage and install mainline kernels. You'll need a 5.17 (which is the latest stable mainline release) to get your sound working. Keep us posted. (In reply to Cameron Berkenpas from comment #607) > There should be a repo you can add on your system to be able to pull the > latest mainline kernels. I don't have it handy at the moment as I've > been building/installing kernels myself since the 90's, but I'll try > find it and post it in a little bit.
Thanks for the quick responses. I followed the instructions to install the latest version. Is it supposed to work if I installed 5.18 too? It's not working and it stopped recognising my external monitors too. (In reply to Cameron Berkenpas from comment #608) > Seems like this is the best way to do it (but if someone knows of a better > way for Ubuntu, let us know): > https://sleeplessbeastie.eu/2021/11/01/how-to-install-mainline-linux-kernel- > on-ubuntu-based-distribution/ > > Seems this gets you a tool that allows you to manage and install mainline > kernels. You'll need a 5.17 (which is the latest stable mainline release) to > get your sound working. > > Keep us posted. > > > (In reply to Cameron Berkenpas from comment #607) > > > There should be a repo you can add on your system to be able to pull the > > latest mainline kernels. I don't have it handy at the moment as I've > > been building/installing kernels myself since the 90's, but I'll try > > find it and post it in a little bit.
Hello everyone, I really appreciate this thread and all of the solutions that have been produced for this issue. Thanks to everyone contributing, especially Cameron Berkenpas who has been very helpful to a number of users and the main driving force for fixes:) Now to my issue: I own a Lenovo Yoga 7i 15ITL05 82AC with the ALC287. Currently it runs Ubuntu 22.04. LTS with the included 5.15 Kernel. Before I have run Pop_OS 21.04. and 22.04. With all these distros, the sound worked partially but never fully. The experience is the same as many other users here, where there would only be sound coming out the from the downward firing speakers, but not from the soundbar above the keyboard, which are the bass speakers judging by the tinny sound I get now. The sound works beautifully in Windows, since the lower end frequencies can be replayed. Quite honestly, I've lost the overview over this thread and am not so sure which patch I should apply. I've tried manually update my Ubuntu 22.04. to the mainline 5.17 Kernel, which worked OS-wise but didn't change sound. My hope was that the sound patches have been included in that Kernel, but it seems they're only working for the Legion 7. Could someone point me to the right patch or verbs that have to be applied for my Lenovo model in order for the bass speakers to work? Maybe someone has figured it out for this particular case? Much thanks in advance. Here's my alsa-info: http://alsa-project.org/db/?f=ad3990bed59a24417ea6429250275012611a0302
I would try try 5.17. 5.18 only came out yesterday, and therefore doesn't even have any point releases so chances are reasonably high you'll run into bugs. Additionally, I don't have the ACHg6. It's possible you'll need to specify which modules to load. In the likely event that 5.17 doesn't work, perhaps someone can provide information on what's needed there. Possibly these steps will work: sudo modprobe snd-hda-codec-cs35l41-i2c sudo modeprobe snd_soc_cs35l41_i2c sudo modeprobe i2c-multi-instantiate (In reply to sheryl@liang.at from comment #609) > Thanks for the quick responses. I followed the instructions to install the > latest version. Is it supposed to work if I installed 5.18 too? It's not > working and it stopped recognising my external monitors too. >
There's no patch for your laptop yet. Assuming your sound bar is initialized through verbs (I suspect it is), you'll need to find the verb sequence yourself: https://github.com/thiagotei/linux-realtek-alc287/tree/cameron Once there's a working verb sequence, a patch can be created. On 5/23/22 04:50, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #611 from singo (hnsinan.ta@gmail.com) --- > Hello everyone, > > I really appreciate this thread and all of the solutions that have been > produced for this issue. Thanks to everyone contributing, especially Cameron > Berkenpas who has been very helpful to a number of users and the main driving > force for fixes:) > > Now to my issue: I own a Lenovo Yoga 7i 15ITL05 82AC with the ALC287. > Currently > it runs Ubuntu 22.04. LTS with the included 5.15 Kernel. Before I have run > Pop_OS 21.04. and 22.04. With all these distros, the sound worked partially > but > never fully. The experience is the same as many other users here, where there > would only be sound coming out the from the downward firing speakers, but not > from the soundbar above the keyboard, which are the bass speakers judging by > the tinny sound I get now. The sound works beautifully in Windows, since the > lower end frequencies can be replayed. > > Quite honestly, I've lost the overview over this thread and am not so sure > which patch I should apply. I've tried manually update my Ubuntu 22.04. to > the > mainline 5.17 Kernel, which worked OS-wise but didn't change sound. My hope > was > that the sound patches have been included in that Kernel, but it seems > they're > only working for the Legion 7. > > Could someone point me to the right patch or verbs that have to be applied > for > my Lenovo model in order for the bass speakers to work? Maybe someone has > figured it out for this particular case? > > Much thanks in advance. > > Here's my alsa-info: > > http://alsa-project.org/db/?f=ad3990bed59a24417ea6429250275012611a0302 >
The first two modprobe commands returned ` modprobe: FATAL: Module snd-hda-codec-cs35l41-i2c not found in directory /lib/modules/5.13.0-051300-generic ` The third one returns nothing. I tried reinstalling my nvidia driver too but even after purging all it doesn't seem to work :\ I tried following these instructions: https://forums.developer.nvidia.com/t/nvidia-smi-has-failed-because-it-couldnt-communicate-with-the-nvidia-driver-make-sure-that-the-latest-nvidia-driver-is-installed-and-running/197141/6 (In reply to Cameron Berkenpas from comment #612) > I would try try 5.17. 5.18 only came out yesterday, and therefore doesn't > even have any point releases so chances are reasonably high you'll run into > bugs. > > Additionally, I don't have the ACHg6. It's possible you'll need to specify > which modules to load. In the likely event that 5.17 doesn't work, perhaps > someone can provide information on what's needed there. > > Possibly these steps will work: > sudo modprobe snd-hda-codec-cs35l41-i2c > sudo modeprobe snd_soc_cs35l41_i2c > sudo modeprobe i2c-multi-instantiate > > (In reply to sheryl@liang.at from comment #609) > > Thanks for the quick responses. I followed the instructions to install the > > latest version. Is it supposed to work if I installed 5.18 too? It's not > > working and it stopped recognising my external monitors too. > >
Your error message shows you're 5.13, which definitely doesn't have support. On 5/23/22 08:46, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #614 from sheryl@liang.at (sheryl@liang.at) --- > The first two modprobe commands returned > ` > modprobe: FATAL: Module snd-hda-codec-cs35l41-i2c not found in directory > /lib/modules/5.13.0-051300-generic > ` > The third one returns nothing. > > I tried reinstalling my nvidia driver too but even after purging all it > doesn't > seem to work :\ > > I tried following these instructions: > > https://forums.developer.nvidia.com/t/nvidia-smi-has-failed-because-it-couldnt-communicate-with-the-nvidia-driver-make-sure-that-the-latest-nvidia-driver-is-installed-and-running/197141/6 > > (In reply to Cameron Berkenpas from comment #612) >> I would try try 5.17. 5.18 only came out yesterday, and therefore doesn't >> even have any point releases so chances are reasonably high you'll run into >> bugs. >> >> Additionally, I don't have the ACHg6. It's possible you'll need to specify >> which modules to load. In the likely event that 5.17 doesn't work, perhaps >> someone can provide information on what's needed there. >> >> Possibly these steps will work: >> sudo modprobe snd-hda-codec-cs35l41-i2c >> sudo modeprobe snd_soc_cs35l41_i2c >> sudo modeprobe i2c-multi-instantiate >> >> (In reply to sheryl@liang.at from comment #609) >>> Thanks for the quick responses. I followed the instructions to install the >>> latest version. Is it supposed to work if I installed 5.18 too? It's not >>> working and it stopped recognising my external monitors too. >>>
Oh, sorry I was in the wrong one version cuz I tried reverting to the older one when nvidia didn't work anymore. In kernel 5.17.0 the first command gives $ sudo modprobe snd-hda-codec-cs35l41-i2c modprobe: FATAL: Module snd-hda-codec-cs35l41-i2c not found in directory /lib/modules/5.17.0-051700-generic while the other two give nothing. (In reply to Cameron Berkenpas from comment #615) > Your error message shows you're 5.13, which definitely doesn't have support. > > > > On 5/23/22 08:46, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #614 from sheryl@liang.at (sheryl@liang.at) --- > > The first two modprobe commands returned > > ` > > modprobe: FATAL: Module snd-hda-codec-cs35l41-i2c not found in directory > > /lib/modules/5.13.0-051300-generic > > ` > > The third one returns nothing. > > > > I tried reinstalling my nvidia driver too but even after purging all it > > doesn't > > seem to work :\ > > > > I tried following these instructions: > > > > > https://forums.developer.nvidia.com/t/nvidia-smi-has-failed-because-it-couldnt-communicate-with-the-nvidia-driver-make-sure-that-the-latest-nvidia-driver-is-installed-and-running/197141/6 > > > > (In reply to Cameron Berkenpas from comment #612) > >> I would try try 5.17. 5.18 only came out yesterday, and therefore doesn't > >> even have any point releases so chances are reasonably high you'll run > into > >> bugs. > >> > >> Additionally, I don't have the ACHg6. It's possible you'll need to specify > >> which modules to load. In the likely event that 5.17 doesn't work, perhaps > >> someone can provide information on what's needed there. > >> > >> Possibly these steps will work: > >> sudo modprobe snd-hda-codec-cs35l41-i2c > >> sudo modeprobe snd_soc_cs35l41_i2c > >> sudo modeprobe i2c-multi-instantiate > >> > >> (In reply to sheryl@liang.at from comment #609) > >>> Thanks for the quick responses. I followed the instructions to install > the > >>> latest version. Is it supposed to work if I installed 5.18 too? It's not > >>> working and it stopped recognising my external monitors too. > >>>
Thanks for the quick reply and the pointer to the github tutorial. I've tried going down this rabbit hole but face numerous error messages when following the guide. Unfortunately I failed at building the js qemu fork. Maybe it fails because I'm on Ubuntu 22.04.? Anyways, I can't build it and thus can't even continue with the actual hard part. Here's the output for the failed configuration of qemu: https://pastebin.com/Lfq5vPz6 Maybe it has to do with the dependencies? When executing sudo apt install build-essential && apt build-dep qemu-system-x86 it will says something along the lines of "choosing qemu instead of quemu-system-x86". (In reply to Cameron Berkenpas from comment #613) > There's no patch for your laptop yet. > > Assuming your sound bar is initialized through verbs (I suspect it is), > you'll need to find the verb sequence yourself: > https://github.com/thiagotei/linux-realtek-alc287/tree/cameron > > Once there's a working verb sequence, a patch can be created. > > On 5/23/22 04:50, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #611 from singo (hnsinan.ta@gmail.com) --- > > Hello everyone, > > > > I really appreciate this thread and all of the solutions that have been > > produced for this issue. Thanks to everyone contributing, especially > Cameron > > Berkenpas who has been very helpful to a number of users and the main > driving > > force for fixes:) > > > > Now to my issue: I own a Lenovo Yoga 7i 15ITL05 82AC with the ALC287. > > Currently > > it runs Ubuntu 22.04. LTS with the included 5.15 Kernel. Before I have run > > Pop_OS 21.04. and 22.04. With all these distros, the sound worked partially > > but > > never fully. The experience is the same as many other users here, where > there > > would only be sound coming out the from the downward firing speakers, but > not > > from the soundbar above the keyboard, which are the bass speakers judging > by > > the tinny sound I get now. The sound works beautifully in Windows, since > the > > lower end frequencies can be replayed. > > > > Quite honestly, I've lost the overview over this thread and am not so sure > > which patch I should apply. I've tried manually update my Ubuntu 22.04. to > > the > > mainline 5.17 Kernel, which worked OS-wise but didn't change sound. My hope > > was > > that the sound patches have been included in that Kernel, but it seems > > they're > > only working for the Legion 7. > > > > Could someone point me to the right patch or verbs that have to be applied > > for > > my Lenovo model in order for the bass speakers to work? Maybe someone has > > figured it out for this particular case? > > > > Much thanks in advance. > > > > Here's my alsa-info: > > > > http://alsa-project.org/db/?f=ad3990bed59a24417ea6429250275012611a0302 > >
It seems the path to endian.h may have changed from /usr/include/sys/endian.h to /usr/include/endian.h. In the failing file(s), try changing it from: #include <sys/endian.h> To: #include <endian.h> On 5/24/22 05:37, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #617 from singo (hnsinan.ta@gmail.com) --- > Thanks for the quick reply and the pointer to the github tutorial. I've tried > going down this rabbit hole but face numerous error messages when following > the > guide. Unfortunately I failed at building the js qemu fork. Maybe it fails > because I'm on Ubuntu 22.04.? Anyways, I can't build it and thus can't even > continue with the actual hard part. > > Here's the output for the failed configuration of qemu: > https://pastebin.com/Lfq5vPz6 > > Maybe it has to do with the dependencies? When executing sudo apt install > build-essential && apt build-dep qemu-system-x86 it will says something along > the lines of "choosing qemu instead of quemu-system-x86". > > > (In reply to Cameron Berkenpas from comment #613) >> There's no patch for your laptop yet. >> >> Assuming your sound bar is initialized through verbs (I suspect it is), >> you'll need to find the verb sequence yourself: >> https://github.com/thiagotei/linux-realtek-alc287/tree/cameron >> >> Once there's a working verb sequence, a patch can be created. >> >> On 5/23/22 04:50, bugzilla-daemon@kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #611 from singo (hnsinan.ta@gmail.com) --- >>> Hello everyone, >>> >>> I really appreciate this thread and all of the solutions that have been >>> produced for this issue. Thanks to everyone contributing, especially >> Cameron >>> Berkenpas who has been very helpful to a number of users and the main >> driving >>> force for fixes:) >>> >>> Now to my issue: I own a Lenovo Yoga 7i 15ITL05 82AC with the ALC287. >>> Currently >>> it runs Ubuntu 22.04. LTS with the included 5.15 Kernel. Before I have run >>> Pop_OS 21.04. and 22.04. With all these distros, the sound worked partially >>> but >>> never fully. The experience is the same as many other users here, where >> there >>> would only be sound coming out the from the downward firing speakers, but >> not >>> from the soundbar above the keyboard, which are the bass speakers judging >> by >>> the tinny sound I get now. The sound works beautifully in Windows, since >> the >>> lower end frequencies can be replayed. >>> >>> Quite honestly, I've lost the overview over this thread and am not so sure >>> which patch I should apply. I've tried manually update my Ubuntu 22.04. to >>> the >>> mainline 5.17 Kernel, which worked OS-wise but didn't change sound. My hope >>> was >>> that the sound patches have been included in that Kernel, but it seems >>> they're >>> only working for the Legion 7. >>> >>> Could someone point me to the right patch or verbs that have to be applied >>> for >>> my Lenovo model in order for the bass speakers to work? Maybe someone has >>> figured it out for this particular case? >>> >>> Much thanks in advance. >>> >>> Here's my alsa-info: >>> >>> http://alsa-project.org/db/?f=ad3990bed59a24417ea6429250275012611a0302 >>>
Appears that these kernels are including these drivers. You might have to figure out how to build your own kernel while enabling the necessary kernel options yourself after all. On 5/24/22 01:46, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #616 from sheryl@liang.at (sheryl@liang.at) --- > Oh, sorry I was in the wrong one version cuz I tried reverting to the older > one > when nvidia didn't work anymore. > > In kernel 5.17.0 the first command gives > $ sudo modprobe snd-hda-codec-cs35l41-i2c > modprobe: FATAL: Module snd-hda-codec-cs35l41-i2c not found in directory > /lib/modules/5.17.0-051700-generic > > while the other two give nothing. > > > (In reply to Cameron Berkenpas from comment #615) >> Your error message shows you're 5.13, which definitely doesn't have support. >> >> >> >> On 5/23/22 08:46, bugzilla-daemon@kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #614 from sheryl@liang.at (sheryl@liang.at) --- >>> The first two modprobe commands returned >>> ` >>> modprobe: FATAL: Module snd-hda-codec-cs35l41-i2c not found in directory >>> /lib/modules/5.13.0-051300-generic >>> ` >>> The third one returns nothing. >>> >>> I tried reinstalling my nvidia driver too but even after purging all it >>> doesn't >>> seem to work :\ >>> >>> I tried following these instructions: >>> >> >> https://forums.developer.nvidia.com/t/nvidia-smi-has-failed-because-it-couldnt-communicate-with-the-nvidia-driver-make-sure-that-the-latest-nvidia-driver-is-installed-and-running/197141/6 >>> (In reply to Cameron Berkenpas from comment #612) >>>> I would try try 5.17. 5.18 only came out yesterday, and therefore doesn't >>>> even have any point releases so chances are reasonably high you'll run >> into >>>> bugs. >>>> >>>> Additionally, I don't have the ACHg6. It's possible you'll need to specify >>>> which modules to load. In the likely event that 5.17 doesn't work, perhaps >>>> someone can provide information on what's needed there. >>>> >>>> Possibly these steps will work: >>>> sudo modprobe snd-hda-codec-cs35l41-i2c >>>> sudo modeprobe snd_soc_cs35l41_i2c >>>> sudo modeprobe i2c-multi-instantiate >>>> >>>> (In reply to sheryl@liang.at from comment #609) >>>>> Thanks for the quick responses. I followed the instructions to install >> the >>>>> latest version. Is it supposed to work if I installed 5.18 too? It's not >>>>> working and it stopped recognising my external monitors too. >>>>>
(In reply to Cameron Berkenpas from comment #619) > Appears that these kernels are including these drivers. You might have > to figure out how to build your own kernel while enabling the necessary > kernel options yourself after all. > > On 5/24/22 01:46, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #616 from sheryl@liang.at (sheryl@liang.at) --- > > Oh, sorry I was in the wrong one version cuz I tried reverting to the older > > one > > when nvidia didn't work anymore. > > > > In kernel 5.17.0 the first command gives > > $ sudo modprobe snd-hda-codec-cs35l41-i2c > > modprobe: FATAL: Module snd-hda-codec-cs35l41-i2c not found in directory > > /lib/modules/5.17.0-051700-generic > > > > while the other two give nothing. > > > > > > (In reply to Cameron Berkenpas from comment #615) > >> Your error message shows you're 5.13, which definitely doesn't have > support. > >> > >> > >> > >> On 5/23/22 08:46, bugzilla-daemon@kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>> > >>> --- Comment #614 from sheryl@liang.at (sheryl@liang.at) --- > >>> The first two modprobe commands returned > >>> ` > >>> modprobe: FATAL: Module snd-hda-codec-cs35l41-i2c not found in directory > >>> /lib/modules/5.13.0-051300-generic > >>> ` > >>> The third one returns nothing. > >>> > >>> I tried reinstalling my nvidia driver too but even after purging all it > >>> doesn't > >>> seem to work :\ > >>> > >>> I tried following these instructions: > >>> > >> > >> > https://forums.developer.nvidia.com/t/nvidia-smi-has-failed-because-it-couldnt-communicate-with-the-nvidia-driver-make-sure-that-the-latest-nvidia-driver-is-installed-and-running/197141/6 > >>> (In reply to Cameron Berkenpas from comment #612) > >>>> I would try try 5.17. 5.18 only came out yesterday, and therefore > doesn't > >>>> even have any point releases so chances are reasonably high you'll run > >> into > >>>> bugs. > >>>> > >>>> Additionally, I don't have the ACHg6. It's possible you'll need to > specify > >>>> which modules to load. In the likely event that 5.17 doesn't work, > perhaps > >>>> someone can provide information on what's needed there. > >>>> > >>>> Possibly these steps will work: > >>>> sudo modprobe snd-hda-codec-cs35l41-i2c > >>>> sudo modeprobe snd_soc_cs35l41_i2c > >>>> sudo modeprobe i2c-multi-instantiate > >>>> > >>>> (In reply to sheryl@liang.at from comment #609) > >>>>> Thanks for the quick responses. I followed the instructions to install > >> the > >>>>> latest version. Is it supposed to work if I installed 5.18 too? It's > not > >>>>> working and it stopped recognising my external monitors too. > >>>>> Hi everyone, with a thanks of your support! I recently bought a new model of Yoga 7i 16" alsa-info is here: https://pastebin.com/cPPAp0vq I so i do have 4 speakers with amp on which is not working in Linux (as everybody mentioned here on windows sound it is strong), the rest of the sound in headphones, bluetooth mic are loading fine . I've read carefully most of you posts, and I tested some commands in my Arcolinux system (Archlinux) So with kernel 5.17 it is support for following modules:( i am currently on linux 5.18.0-arch1-1) serial_multi_instantiate snd-soc-cs35l41-lib snd-hda-scodec-cs35l41-i2c snd-hda-scodec-cs35l41-spi and i managed to load them helped by modinfo command noticed that some of them have dependencies other modules. So I preload the dep and then i made an file in /etc/modules-load/ where i listed all this modules in order to be load at boot. I checked after boot to see it all these modules are loaded- was successfully done. But my sound is still the same - the AMP on speakers doesn't work! I won't give up testing the further suggestions you might have, t!
Thank you soo much!
Looking at your alsa-info, you don't have the CLS0100 amplifier chips, which is what those modules would enable support for. Your laptop is not supported by those modules and likely aren't supported at all. (In reply to cris223 from comment #620) > > Hi everyone, with a thanks of your support! > I recently bought a new model of Yoga 7i 16" alsa-info is here: > https://pastebin.com/cPPAp0vq > I so i do have 4 speakers with amp on which is not working in Linux (as > everybody mentioned here on windows sound it is strong), the rest of the > sound in headphones, bluetooth mic are loading fine . I've read carefully > most of you posts, and I tested some commands in my Arcolinux system > (Archlinux) > > So with kernel 5.17 it is support for following modules:( i am currently on > linux 5.18.0-arch1-1) > serial_multi_instantiate > snd-soc-cs35l41-lib > snd-hda-scodec-cs35l41-i2c > snd-hda-scodec-cs35l41-spi > > and i managed to load them helped by modinfo command noticed that some of > them have dependencies other modules. So I preload the dep and then i made > an file in /etc/modules-load/ where i listed all this modules in order to be > load at boot. I checked after boot to see it all these modules are loaded- > was successfully done. > > But my sound is still the same - the AMP on speakers doesn't work! > > I won't give up testing the further suggestions you might have, t!
(In reply to Cameron Berkenpas from comment #622) > Looking at your alsa-info, you don't have the CLS0100 amplifier chips, which > is what those modules would enable support for. Your laptop is not supported > by those modules and likely aren't supported at all. > > (In reply to cris223 from comment #620) > > > > Hi everyone, with a thanks of your support! > > I recently bought a new model of Yoga 7i 16" alsa-info is here: > > https://pastebin.com/cPPAp0vq > > I so i do have 4 speakers with amp on which is not working in Linux (as > > everybody mentioned here on windows sound it is strong), the rest of the > > sound in headphones, bluetooth mic are loading fine . I've read carefully > > most of you posts, and I tested some commands in my Arcolinux system > > (Archlinux) > > > > So with kernel 5.17 it is support for following modules:( i am currently on > > linux 5.18.0-arch1-1) > > serial_multi_instantiate > > snd-soc-cs35l41-lib > > snd-hda-scodec-cs35l41-i2c > > snd-hda-scodec-cs35l41-spi > > > > and i managed to load them helped by modinfo command noticed that some of > > them have dependencies other modules. So I preload the dep and then i made > > an file in /etc/modules-load/ where i listed all this modules in order to > be > > load at boot. I checked after boot to see it all these modules are loaded- > > was successfully done. > > > > But my sound is still the same - the AMP on speakers doesn't work! > > > > I won't give up testing the further suggestions you might have, t! that is a terrible new for me...i wanted to replace windows totality in my new machine...but for now i ll stick with the dual boot
(In reply to Cameron Berkenpas from comment #429) > Created attachment 298789 [details] > linux-legion-sound-0.0.13.patch > > auto mute is now properly disabled as per Takashi's suggestion. > > This patch is against the latest Linus tree, but applies against 5.14.3 just > fine. > > This patch includes the presumptive commit message and credit given to > various people. > > Going through the Linux commit log, it seems full names and email addresses > aren't needed, so I have a thank you list in the patch with the following: > Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle > > If you want to be mentioned (or if you know of someone who you think that > should be included), please let me know! > > Here's a link to the patch submission: > https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189698. > html Hello, there is a device could use the patch, could you help me add it to the patch file? SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
Did you test this yourself? On 6/3/22 00:11, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Songine (donglingluoying@gmail.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |donglingluoying@gmail.com > > --- Comment #624 from Songine (donglingluoying@gmail.com) --- > (In reply to Cameron Berkenpas from comment #429) >> Created attachment 298789 [details] >> linux-legion-sound-0.0.13.patch >> >> auto mute is now properly disabled as per Takashi's suggestion. >> >> This patch is against the latest Linus tree, but applies against 5.14.3 just >> fine. >> >> This patch includes the presumptive commit message and credit given to >> various people. >> >> Going through the Linux commit log, it seems full names and email addresses >> aren't needed, so I have a thank you list in the patch with the following: >> Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle >> >> If you want to be mentioned (or if you know of someone who you think that >> should be included), please let me know! >> >> Here's a link to the patch submission: >> https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189698. >> html > Hello, there is a device could use the patch, could you help me add it to the > patch file? > > SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), >
(In reply to Cameron Berkenpas from comment #625) > Did you test this yourself? > > On 6/3/22 00:11, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > Songine (donglingluoying@gmail.com) changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > CC| |donglingluoying@gmail.com > > > > --- Comment #624 from Songine (donglingluoying@gmail.com) --- > > (In reply to Cameron Berkenpas from comment #429) > >> Created attachment 298789 [details] > >> linux-legion-sound-0.0.13.patch > >> > >> auto mute is now properly disabled as per Takashi's suggestion. > >> > >> This patch is against the latest Linus tree, but applies against 5.14.3 > just > >> fine. > >> > >> This patch includes the presumptive commit message and credit given to > >> various people. > >> > >> Going through the Linux commit log, it seems full names and email > addresses > >> aren't needed, so I have a thank you list in the patch with the following: > >> Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle > >> > >> If you want to be mentioned (or if you know of someone who you think that > >> should be included), please let me know! > >> > >> Here's a link to the patch submission: > >> > https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189698. > >> html > > Hello, there is a device could use the patch, could you help me add it to > the > > patch file? > > > > SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", > > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), > > Yes, tested, and I am enjoging my speaker now.😃
Great! Some probably silly questions: 1) Do both speakers work? Do you get left channel sound out of the left speaker and right channel sound out of the right speaker? 2) After resuming from suspend/hibernate, does your sound still work? 3) What if you insert headphones and remove them? Does sound still work? Try removing the headphones both while sound is not playing and while it's not. Given that this old quirk works for your laptop, I think all of the above will be fine and I can work toward getting this submitted. On 6/3/2022 5:34 PM, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #626 from Songine (donglingluoying@gmail.com) --- > (In reply to Cameron Berkenpas from comment #625) >> Did you test this yourself? >> >> On 6/3/22 00:11, bugzilla-daemon@kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> Songine (donglingluoying@gmail.com) changed: >>> >>> What |Removed |Added >>> >> ---------------------------------------------------------------------------- >>> CC| >>> |donglingluoying@gmail.com >>> >>> --- Comment #624 from Songine (donglingluoying@gmail.com) --- >>> (In reply to Cameron Berkenpas from comment #429) >>>> Created attachment 298789 [details] >>>> linux-legion-sound-0.0.13.patch >>>> >>>> auto mute is now properly disabled as per Takashi's suggestion. >>>> >>>> This patch is against the latest Linus tree, but applies against 5.14.3 >> just >>>> fine. >>>> >>>> This patch includes the presumptive commit message and credit given to >>>> various people. >>>> >>>> Going through the Linux commit log, it seems full names and email >> addresses >>>> aren't needed, so I have a thank you list in the patch with the following: >>>> Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle >>>> >>>> If you want to be mentioned (or if you know of someone who you think that >>>> should be included), please let me know! >>>> >>>> Here's a link to the patch submission: >>>> >> https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189698. >>>> html >>> Hello, there is a device could use the patch, could you help me add it to >> the >>> patch file? >>> >>> SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", >>> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), >>> > Yes, tested, and I am enjoging my speaker now.😃 >
Yeah, both the speaker and headphones work fine with correct channel. And still work after resuming from suspend/hibernate. Also fine after hotplug events, whatever it is playing or not. Thanks for your patch a lot! (In reply to Cameron Berkenpas from comment #627) > Great! > > Some probably silly questions: > 1) Do both speakers work? Do you get left channel sound out of the left > speaker and right channel sound out of the right speaker? > > 2) After resuming from suspend/hibernate, does your sound still work? > > 3) What if you insert headphones and remove them? Does sound still work? > Try removing the headphones both while sound is not playing and while > it's not. > > Given that this old quirk works for your laptop, I think all of the > above will be fine and I can work toward getting this submitted. > > > On 6/3/2022 5:34 PM, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #626 from Songine (donglingluoying@gmail.com) --- > > (In reply to Cameron Berkenpas from comment #625) > >> Did you test this yourself? > >> > >> On 6/3/22 00:11, bugzilla-daemon@kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>> > >>> Songine (donglingluoying@gmail.com) changed: > >>> > >>> What |Removed |Added > >>> > >> > ---------------------------------------------------------------------------- > >>> CC| > >>> |donglingluoying@gmail.com > >>> > >>> --- Comment #624 from Songine (donglingluoying@gmail.com) --- > >>> (In reply to Cameron Berkenpas from comment #429) > >>>> Created attachment 298789 [details] > >>>> linux-legion-sound-0.0.13.patch > >>>> > >>>> auto mute is now properly disabled as per Takashi's suggestion. > >>>> > >>>> This patch is against the latest Linus tree, but applies against 5.14.3 > >> just > >>>> fine. > >>>> > >>>> This patch includes the presumptive commit message and credit given to > >>>> various people. > >>>> > >>>> Going through the Linux commit log, it seems full names and email > >> addresses > >>>> aren't needed, so I have a thank you list in the patch with the > following: > >>>> Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle > >>>> > >>>> If you want to be mentioned (or if you know of someone who you think > that > >>>> should be included), please let me know! > >>>> > >>>> Here's a link to the patch submission: > >>>> > >> > https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189698. > >>>> html > >>> Hello, there is a device could use the patch, could you help me add it to > >> the > >>> patch file? > >>> > >>> SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", > >>> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), > >>> > > Yes, tested, and I am enjoging my speaker now.😃 > >
Songine, Can you provide more info about your specific model? You should be able to get that from running "lshw". For the top of my output, I get: version: Legion 7 16ITHg6 On 6/4/22 17:46, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #628 from Songine (donglingluoying@gmail.com) --- > Yeah, both the speaker and headphones work fine with correct channel. > > And still work after resuming from suspend/hibernate. > > Also fine after hotplug events, whatever it is playing or not. > > Thanks for your patch a lot! > > (In reply to Cameron Berkenpas from comment #627) >> Great! >> >> Some probably silly questions: >> 1) Do both speakers work? Do you get left channel sound out of the left >> speaker and right channel sound out of the right speaker? >> >> 2) After resuming from suspend/hibernate, does your sound still work? >> >> 3) What if you insert headphones and remove them? Does sound still work? >> Try removing the headphones both while sound is not playing and while >> it's not. >> >> Given that this old quirk works for your laptop, I think all of the >> above will be fine and I can work toward getting this submitted. >> >> >> On 6/3/2022 5:34 PM, bugzilla-daemon@kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #626 from Songine (donglingluoying@gmail.com) --- >>> (In reply to Cameron Berkenpas from comment #625) >>>> Did you test this yourself? >>>> >>>> On 6/3/22 00:11, bugzilla-daemon@kernel.org wrote: >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>>>> >>>>> Songine (donglingluoying@gmail.com) changed: >>>>> >>>>> What |Removed |Added >>>>> >> ---------------------------------------------------------------------------- >>>>> CC| >>>>> |donglingluoying@gmail.com >>>>> >>>>> --- Comment #624 from Songine (donglingluoying@gmail.com) --- >>>>> (In reply to Cameron Berkenpas from comment #429) >>>>>> Created attachment 298789 [details] >>>>>> linux-legion-sound-0.0.13.patch >>>>>> >>>>>> auto mute is now properly disabled as per Takashi's suggestion. >>>>>> >>>>>> This patch is against the latest Linus tree, but applies against 5.14.3 >>>> just >>>>>> fine. >>>>>> >>>>>> This patch includes the presumptive commit message and credit given to >>>>>> various people. >>>>>> >>>>>> Going through the Linux commit log, it seems full names and email >>>> addresses >>>>>> aren't needed, so I have a thank you list in the patch with the >> following: >>>>>> Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle >>>>>> >>>>>> If you want to be mentioned (or if you know of someone who you think >> that >>>>>> should be included), please let me know! >>>>>> >>>>>> Here's a link to the patch submission: >>>>>> >> https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189698. >>>>>> html >>>>> Hello, there is a device could use the patch, could you help me add it to >>>> the >>>>> patch file? >>>>> >>>>> SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", >>>>> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), >>>>> >>> Yes, tested, and I am enjoging my speaker now.😃 >>>
Sure. songine@DEBIAN-DUET2021:~$ sudo lshw debian-duet2021 description: Detachable product: 82MA (LENOVO_MT_82MA_BU_idea_FM_Yoga DuetITL 2021) vendor: LENOVO version: Yoga DuetITL 2021 serial: YX027470 width: 64 bits capabilities: smbios-3.3.0 dmi-3.3.0 smp vsyscall32 (In reply to Cameron Berkenpas from comment #629) > Songine, > > Can you provide more info about your specific model? You should be able > to get that from running "lshw". > > For the top of my output, I get: > version: Legion 7 16ITHg6 > > On 6/4/22 17:46, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #628 from Songine (donglingluoying@gmail.com) --- > > Yeah, both the speaker and headphones work fine with correct channel. > > > > And still work after resuming from suspend/hibernate. > > > > Also fine after hotplug events, whatever it is playing or not. > > > > Thanks for your patch a lot! > > > > (In reply to Cameron Berkenpas from comment #627) > >> Great! > >> > >> Some probably silly questions: > >> 1) Do both speakers work? Do you get left channel sound out of the left > >> speaker and right channel sound out of the right speaker? > >> > >> 2) After resuming from suspend/hibernate, does your sound still work? > >> > >> 3) What if you insert headphones and remove them? Does sound still work? > >> Try removing the headphones both while sound is not playing and while > >> it's not. > >> > >> Given that this old quirk works for your laptop, I think all of the > >> above will be fine and I can work toward getting this submitted. > >> > >> > >> On 6/3/2022 5:34 PM, bugzilla-daemon@kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>> > >>> --- Comment #626 from Songine (donglingluoying@gmail.com) --- > >>> (In reply to Cameron Berkenpas from comment #625) > >>>> Did you test this yourself? > >>>> > >>>> On 6/3/22 00:11, bugzilla-daemon@kernel.org wrote: > >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>>>> > >>>>> Songine (donglingluoying@gmail.com) changed: > >>>>> > >>>>> What |Removed |Added > >>>>> > >> > ---------------------------------------------------------------------------- > >>>>> CC| > >>>>> |donglingluoying@gmail.com > >>>>> > >>>>> --- Comment #624 from Songine (donglingluoying@gmail.com) --- > >>>>> (In reply to Cameron Berkenpas from comment #429) > >>>>>> Created attachment 298789 [details] > >>>>>> linux-legion-sound-0.0.13.patch > >>>>>> > >>>>>> auto mute is now properly disabled as per Takashi's suggestion. > >>>>>> > >>>>>> This patch is against the latest Linus tree, but applies against > 5.14.3 > >>>> just > >>>>>> fine. > >>>>>> > >>>>>> This patch includes the presumptive commit message and credit given to > >>>>>> various people. > >>>>>> > >>>>>> Going through the Linux commit log, it seems full names and email > >>>> addresses > >>>>>> aren't needed, so I have a thank you list in the patch with the > >> following: > >>>>>> Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle > >>>>>> > >>>>>> If you want to be mentioned (or if you know of someone who you think > >> that > >>>>>> should be included), please let me know! > >>>>>> > >>>>>> Here's a link to the patch submission: > >>>>>> > >> > https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/189698. > >>>>>> html > >>>>> Hello, there is a device could use the patch, could you help me add it > to > >>>> the > >>>>> patch file? > >>>>> > >>>>> SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", > >>>>> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), > >>>>> > >>> Yes, tested, and I am enjoging my speaker now.😃 > >>>
Quick update: it works! sort of... I applied the first fixup (LEGION_15IMHG05), but it didn't work, and the second (YOGA7_14ITL) didn't either. But while booted from the kernel with the 2nd fixup, I decided to give it a quick suspend/wakeup cycle. After the wakeup, there is sound! But only from the left speaker. The sound is coming only from the left channel. I will report back after retrying the 1st fixup, this time with a suspend/wakeup cycle. (In reply to Cameron Berkenpas from comment #602) > Created attachment 300990 [details] > attachment-14829-0.html > > From your alsa-info (thanks!), I see that your subsystem id is 0x3822 > compared to the 0x1813 of the 15IMHG05. > > In the root of the linux source folder/directory, open the file: > sound/pci/hda/patch_realtek.c > > Find this line: > SND_PCI_QUIRK(0x17aa, 0x3813, "Legion 7i 15IMHG05", > ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), > > Next to that line (before or after doesn't matter), add your own line: > SND_PCI_QUIRK(0x17aa, 0x3822, "Legion 7i 15IMH5", > ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), > > If the ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS fix doesn't work for your > laptop, try theALC287_FIXUP_YOGA7_14ITL_SPEAKERS fix as well. Ie, > SND_PCI_QUIRK(0x17aa, 0x3822, "Legion 7i 15IMH5", > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), > > But given the similarities between our laptop models, I strongly suspect > the 15IMHG05 fix will work for your laptop as well. > > Looks like you're running linux Mint, which, IIRC, is based on Debian or > Ubuntu. For deb based distributions, you can build packages for your > kernel like this: > make bindeb-pkg > > You only really need the linux-image and linux-headers (for Nvidia) > packages. To speed up the compile, you can pass in the -j option to > parallelize the build: > make -j$(nproc) bindeb-pkg > > > On 5/17/22 14:32, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #601 from Andrei Miculita (andreimiculita+kern@gmail.com) --- > > (In reply to Cameron Berkenpas from comment #600) > >> Looking at the model number, there's a chance it's compatible with the > >> verbs of the 15IMHG05, or another model from around that time. > >> > >> Do you know how to build and run your own kernel? > >> > >> Also, please provide a URL to your alsa-info. > >> > >> On 5/15/2022 12:12 PM,bugzilla-daemon@kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>> > >>> --- Comment #599 from Andrei Miculita (andreimiculita+kern@gmail.com) --- > >>> Lenovo Legion S7 15IMH5 > >>> > >>> Has anyone managed to get their sound working on it? Would appreciate a > >>> tutorial or some tips (the more specific, the better, as this thread is > >> full > >>> of > >>> other devices as well and it'd take a long time to try everything) > >>> > > > > I do, it might take me a while to get it done if I start now, but I've done > > it > > before for fun. > > > > > > My alsa-info: > > http://alsa-project.org/db/?f=c1ba1098da13b2d7d6793fbce823e4feed2ac4ee > >
(In reply to bettodiaz from comment #591) > (In reply to Darin Miller from comment #590) > > Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for > > LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : > > > > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ > > > > Thank you everyone for all your efforts! > > I installed the kernel in PopOS, and it works! I now have speakers working!!! > They sound a lot quieter and crappier than in Windows, but now they work. > > Thanks! I installed one of the newer kernel (5.18.3-1) on my 16ACHg6 with Manjaro and the sound now works beautifully. However, I also noticed that the speaker would stop working if I were to restore the machine from hibernation. So far the only workaround would be to restart the laptop to resolve the issue.
When you say hibernation, do you specifically mean suspend to disk? Or do you mean suspend to RAM? Or both? On 6/15/22 12:42, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #633 from matrix1999@gmail.com --- > (In reply to bettodiaz from comment #591) >> (In reply to Darin Miller from comment #590) >>> Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for >>> LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : >>> >>> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ >>> >>> Thank you everyone for all your efforts! >> I installed the kernel in PopOS, and it works! I now have speakers >> working!!! >> They sound a lot quieter and crappier than in Windows, but now they work. >> >> Thanks! > I installed one of the newer kernel (5.18.3-1) on my 16ACHg6 with Manjaro and > the sound now works beautifully. However, I also noticed that the speaker > would stop working if I were to restore the machine from hibernation. So far > the only workaround would be to restart the laptop to resolve the issue. >
(In reply to Cameron Berkenpas from comment #634) > When you say hibernation, do you specifically mean suspend to disk? Or > do you mean suspend to RAM? Or both? Great question and sorry I should have been more specific. In my repo experience, I meant to say it is the hibernation to disk, specifically to a swapfile, and not a swap partition (not sure if that matters but I figured might as well disclose in full). I haven't tried to hibernate to RAM yet. I can give it a shot if you like. > On 6/15/22 12:42, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #633 from matrix1999@gmail.com --- > > (In reply to bettodiaz from comment #591) > >> (In reply to Darin Miller from comment #590) > >>> Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for > >>> LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : > >>> > >>> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ > >>> > >>> Thank you everyone for all your efforts! > >> I installed the kernel in PopOS, and it works! I now have speakers > >> working!!! > >> They sound a lot quieter and crappier than in Windows, but now they work. > >> > >> Thanks! > > I installed one of the newer kernel (5.18.3-1) on my 16ACHg6 with Manjaro > and > > the sound now works beautifully. However, I also noticed that the speaker > > would stop working if I were to restore the machine from hibernation. So > far > > the only workaround would be to restart the laptop to resolve the issue. > >
I have news on the Lenovo Yoga 9 14IAP7. The bass speakers are not working, but the soundbar works out of the box. Here's the alsa-info on a default Arch Linux 5.18.3-arch1 kernel. http://alsa-project.org/db/?f=88c18fe2a7e900cc9a1aef2b62d5a963460b7d74 Since my bass speakers weren't even recognized by the kernel (node 0x17 was 'not connected') I used hdajackretask to map the node as a Speaker. This did not work either. I tried to enable the 'ALC287_FIXUP_BASS_SPK_AMP' quirk in 'sound/pci/hda/patch_realtek' for my device. This, especially the chained 'ALC285_FIXUP_THINKPAD_X1_GEN7' quirk, made the left bass speaker work. The right one remains mute. Here's the new alsa-info after the patch and forceing snd-hda-intel instead of SOF. http://alsa-project.org/db/?f=85bad6aac1448e944c730e4971ebd24672a67d86 Some fiddeling with alsamixer produced: Without headphones plugged in: - headphone jack mute switch does nothing (as expected). - speaker mute switch mutes both soundbar and bass. - bass mute switch mutes both soundbar and bass. - adjusting DAC1 changes bass volume. - adjusting DAC2 changes soundbar volume. With headphone plugged in: - headphone mute switch mutes headphones, soundbar and bass. - speaker mute switch mutes bass. - bass mute switch mutes soundbar. - DAC1 changes bass and headphone volume. - DAC2 changes soundbar volume. I am not familiar with the signal path through HDA devices. Could someone explain or help me deduce the internal connections? I can patch a kernel and probably write a fixup myself once I understand whats going wrong.
Please give that a shot. It's possible there's a new bug, or that it wasn't tested against hibernate (just suspend). On 6/15/22 13:04, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #635 from matrix1999@gmail.com --- > (In reply to Cameron Berkenpas from comment #634) >> When you say hibernation, do you specifically mean suspend to disk? Or >> do you mean suspend to RAM? Or both? > Great question and sorry I should have been more specific. In my repo > experience, I meant to say it is the hibernation to disk, specifically to a > swapfile, and not a swap partition (not sure if that matters but I figured > might as well disclose in full). > > I haven't tried to hibernate to RAM yet. I can give it a shot if you like. > > > >> On 6/15/22 12:42, bugzilla-daemon@kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #633 from matrix1999@gmail.com --- >>> (In reply to bettodiaz from comment #591) >>>> (In reply to Darin Miller from comment #590) >>>>> Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for >>>>> LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : >>>>> >>>>> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ >>>>> >>>>> Thank you everyone for all your efforts! >>>> I installed the kernel in PopOS, and it works! I now have speakers >>>> working!!! >>>> They sound a lot quieter and crappier than in Windows, but now they work. >>>> >>>> Thanks! >>> I installed one of the newer kernel (5.18.3-1) on my 16ACHg6 with Manjaro >> and >>> the sound now works beautifully. However, I also noticed that the speaker >>> would stop working if I were to restore the machine from hibernation. So >> far >>> the only workaround would be to restart the laptop to resolve the issue. >>>
(In reply to Cameron Berkenpas from comment #637) > Please give that a shot. It's possible there's a new bug, or that it > wasn't tested against hibernate (just suspend). I just tried all 3 options (running Xfce on Manjaro) and here are the results: Hibernate (saves to HDD/SSD): FAIL - sound stops working upon resume Suspend (saves to RAM): PASS - sound continues to work upon resume Hybrid Sleep (saves to HDD/SSD and RAM): PASS - sound continues to work upon resume My hypothesis is that Hybrid Sleep works because I didn't shut down the laptop long enough to drain the battery power in full, thus the resume works via RAM instead of HDD/SSD. My conclusion is that there is a new bug where the sound stops working upon resume from HDD/SSD. > On 6/15/22 13:04, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #635 from matrix1999@gmail.com --- > > (In reply to Cameron Berkenpas from comment #634) > >> When you say hibernation, do you specifically mean suspend to disk? Or > >> do you mean suspend to RAM? Or both? > > Great question and sorry I should have been more specific. In my repo > > experience, I meant to say it is the hibernation to disk, specifically to a > > swapfile, and not a swap partition (not sure if that matters but I figured > > might as well disclose in full). > > > > I haven't tried to hibernate to RAM yet. I can give it a shot if you like. > > > > > > > >> On 6/15/22 12:42, bugzilla-daemon@kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>> > >>> --- Comment #633 from matrix1999@gmail.com --- > >>> (In reply to bettodiaz from comment #591) > >>>> (In reply to Darin Miller from comment #590) > >>>>> Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for > >>>>> LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : > >>>>> > >>>>> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ > >>>>> > >>>>> Thank you everyone for all your efforts! > >>>> I installed the kernel in PopOS, and it works! I now have speakers > >>>> working!!! > >>>> They sound a lot quieter and crappier than in Windows, but now they > work. > >>>> > >>>> Thanks! > >>> I installed one of the newer kernel (5.18.3-1) on my 16ACHg6 with Manjaro > >> and > >>> the sound now works beautifully. However, I also noticed that the > speaker > >>> would stop working if I were to restore the machine from hibernation. So > >> far > >>> the only workaround would be to restart the laptop to resolve the issue. > >>>
When did the 16ACHg6 first get support? 5.18? Possibly it was never tested with hibernate. On 6/15/22 13:55, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #638 from matrix1999@gmail.com --- > (In reply to Cameron Berkenpas from comment #637) >> Please give that a shot. It's possible there's a new bug, or that it >> wasn't tested against hibernate (just suspend). > I just tried all 3 options (running Xfce on Manjaro) and here are the > results: > Hibernate (saves to HDD/SSD): FAIL - sound stops working upon resume > Suspend (saves to RAM): PASS - sound continues to work upon resume > Hybrid Sleep (saves to HDD/SSD and RAM): PASS - sound continues to work upon > resume > > My hypothesis is that Hybrid Sleep works because I didn't shut down the > laptop > long enough to drain the battery power in full, thus the resume works via RAM > instead of HDD/SSD. > > My conclusion is that there is a new bug where the sound stops working upon > resume from HDD/SSD. > > > >> On 6/15/22 13:04, bugzilla-daemon@kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> --- Comment #635 from matrix1999@gmail.com --- >>> (In reply to Cameron Berkenpas from comment #634) >>>> When you say hibernation, do you specifically mean suspend to disk? Or >>>> do you mean suspend to RAM? Or both? >>> Great question and sorry I should have been more specific. In my repo >>> experience, I meant to say it is the hibernation to disk, specifically to a >>> swapfile, and not a swap partition (not sure if that matters but I figured >>> might as well disclose in full). >>> >>> I haven't tried to hibernate to RAM yet. I can give it a shot if you like. >>> >>> >>> >>>> On 6/15/22 12:42, bugzilla-daemon@kernel.org wrote: >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>>>> >>>>> --- Comment #633 from matrix1999@gmail.com --- >>>>> (In reply to bettodiaz from comment #591) >>>>>> (In reply to Darin Miller from comment #590) >>>>>>> Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for >>>>>>> LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : >>>>>>> >>>>>>> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ >>>>>>> >>>>>>> Thank you everyone for all your efforts! >>>>>> I installed the kernel in PopOS, and it works! I now have speakers >>>>>> working!!! >>>>>> They sound a lot quieter and crappier than in Windows, but now they >> work. >>>>>> Thanks! >>>>> I installed one of the newer kernel (5.18.3-1) on my 16ACHg6 with Manjaro >>>> and >>>>> the sound now works beautifully. However, I also noticed that the >> speaker >>>>> would stop working if I were to restore the machine from hibernation. So >>>> far >>>>> the only workaround would be to restart the laptop to resolve the issue. >>>>>
(In reply to Cameron Berkenpas from comment #639) > When did the 16ACHg6 first get support? 5.18? Possibly it was never > tested with hibernate. Yes, 5.18. I tried 5.17 and didn't work for me. > > On 6/15/22 13:55, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #638 from matrix1999@gmail.com --- > > (In reply to Cameron Berkenpas from comment #637) > >> Please give that a shot. It's possible there's a new bug, or that it > >> wasn't tested against hibernate (just suspend). > > I just tried all 3 options (running Xfce on Manjaro) and here are the > > results: > > Hibernate (saves to HDD/SSD): FAIL - sound stops working upon resume > > Suspend (saves to RAM): PASS - sound continues to work upon resume > > Hybrid Sleep (saves to HDD/SSD and RAM): PASS - sound continues to work > upon > > resume > > > > My hypothesis is that Hybrid Sleep works because I didn't shut down the > > laptop > > long enough to drain the battery power in full, thus the resume works via > RAM > > instead of HDD/SSD. > > > > My conclusion is that there is a new bug where the sound stops working upon > > resume from HDD/SSD. > > > > > > > >> On 6/15/22 13:04, bugzilla-daemon@kernel.org wrote: > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>> > >>> --- Comment #635 from matrix1999@gmail.com --- > >>> (In reply to Cameron Berkenpas from comment #634) > >>>> When you say hibernation, do you specifically mean suspend to disk? Or > >>>> do you mean suspend to RAM? Or both? > >>> Great question and sorry I should have been more specific. In my repo > >>> experience, I meant to say it is the hibernation to disk, specifically to > a > >>> swapfile, and not a swap partition (not sure if that matters but I > figured > >>> might as well disclose in full). > >>> > >>> I haven't tried to hibernate to RAM yet. I can give it a shot if you > like. > >>> > >>> > >>> > >>>> On 6/15/22 12:42, bugzilla-daemon@kernel.org wrote: > >>>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > >>>>> > >>>>> --- Comment #633 from matrix1999@gmail.com --- > >>>>> (In reply to bettodiaz from comment #591) > >>>>>> (In reply to Darin Miller from comment #590) > >>>>>>> Ubuntu kernel 5.18v-rc1 includes the sound patches that fix sound for > >>>>>>> LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6 : > >>>>>>> > >>>>>>> https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc1/ > >>>>>>> > >>>>>>> Thank you everyone for all your efforts! > >>>>>> I installed the kernel in PopOS, and it works! I now have speakers > >>>>>> working!!! > >>>>>> They sound a lot quieter and crappier than in Windows, but now they > >> work. > >>>>>> Thanks! > >>>>> I installed one of the newer kernel (5.18.3-1) on my 16ACHg6 with > Manjaro > >>>> and > >>>>> the sound now works beautifully. However, I also noticed that the > >> speaker > >>>>> would stop working if I were to restore the machine from hibernation. > So > >>>> far > >>>>> the only workaround would be to restart the laptop to resolve the > issue. > >>>>>
(In reply to semaj4712 from comment #596) > I am assuming this is the same issue. My laptop is a Yoga 9 and I am able > to get sound but it is very quite, not nearly as loud as in Windows. I have > the pavucontrol cranked all the way up and its still super quite. > > Host: 82LU Yoga 9 14IAP7 > Kernel: 5.17.1-arch1-1 > > I was under the understanding that upgrading to 5.17 would fix this but I > guess not. Any help is appreciated I think that I found the relevant HDA verbs by sniffing on a Windows 10 VM. Would someone else like to test the patch I wrote before can I try to submit it?
Can confirm it works! The ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS makes both speakers work on the 15IMH5, stereo sound. It does require a suspend/wakeup cycle first though. On another note, the screen brightness controls on this device also have the same issue: they only work after a suspend/wakeup cycle. It's usable though, better than nothing. Would this be good enough to be added to the main kernel? If that's ok I can also do it, more for the educational value than anything :) With appropriate credit to Cameron Berkenpas of course. (In reply to Andrei Miculita from comment #631) > Quick update: it works! sort of... > > I applied the first fixup (LEGION_15IMHG05), but it didn't work, and the > second (YOGA7_14ITL) didn't either. But while booted from the kernel with > the 2nd fixup, I decided to give it a quick suspend/wakeup cycle. After the > wakeup, there is sound! But only from the left speaker. The sound is coming > only from the left channel. > > I will report back after retrying the 1st fixup, this time with a > suspend/wakeup cycle. > > (In reply to Cameron Berkenpas from comment #602) > > Created attachment 300990 [details] > > attachment-14829-0.html > > > > From your alsa-info (thanks!), I see that your subsystem id is 0x3822 > > compared to the 0x1813 of the 15IMHG05. > > > > In the root of the linux source folder/directory, open the file: > > sound/pci/hda/patch_realtek.c > > > > Find this line: > > SND_PCI_QUIRK(0x17aa, 0x3813, "Legion 7i 15IMHG05", > > ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), > > > > Next to that line (before or after doesn't matter), add your own line: > > SND_PCI_QUIRK(0x17aa, 0x3822, "Legion 7i 15IMH5", > > ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), > > > > If the ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS fix doesn't work for your > > laptop, try theALC287_FIXUP_YOGA7_14ITL_SPEAKERS fix as well. Ie, > > SND_PCI_QUIRK(0x17aa, 0x3822, "Legion 7i 15IMH5", > > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), > > > > But given the similarities between our laptop models, I strongly suspect > > the 15IMHG05 fix will work for your laptop as well. > > > > Looks like you're running linux Mint, which, IIRC, is based on Debian or > > Ubuntu. For deb based distributions, you can build packages for your > > kernel like this: > > make bindeb-pkg > > > > You only really need the linux-image and linux-headers (for Nvidia) > > packages. To speed up the compile, you can pass in the -j option to > > parallelize the build: > > make -j$(nproc) bindeb-pkg > > > > > > On 5/17/22 14:32, bugzilla-daemon@kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > > > --- Comment #601 from Andrei Miculita (andreimiculita+kern@gmail.com) --- > > > (In reply to Cameron Berkenpas from comment #600) > > >> Looking at the model number, there's a chance it's compatible with the > > >> verbs of the 15IMHG05, or another model from around that time. > > >> > > >> Do you know how to build and run your own kernel? > > >> > > >> Also, please provide a URL to your alsa-info. > > >> > > >> On 5/15/2022 12:12 PM,bugzilla-daemon@kernel.org wrote: > > >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > >>> > > >>> --- Comment #599 from Andrei Miculita (andreimiculita+kern@gmail.com) > --- > > >>> Lenovo Legion S7 15IMH5 > > >>> > > >>> Has anyone managed to get their sound working on it? Would appreciate a > > >>> tutorial or some tips (the more specific, the better, as this thread is > > >> full > > >>> of > > >>> other devices as well and it'd take a long time to try everything) > > >>> > > > > > > I do, it might take me a while to get it done if I start now, but I've > done > > > it > > > before for fun. > > > > > > > > > My alsa-info: > > > http://alsa-project.org/db/?f=c1ba1098da13b2d7d6793fbce823e4feed2ac4ee > > >
I'm in the same exact situation as Philipp (quoted below). Lenovo Yoga 9 14IAP7, Arch Linux 5.18.7, no sound from woofers. My alsa-info is here https://pastebin.com/UFneLZh7 I have a simple question: is there a way to fix this with the HDA verbs patch? How do I find them? (In reply to Philipp Jungkamp from comment #636) > I have news on the Lenovo Yoga 9 14IAP7. > > The bass speakers are not working, but the soundbar works out of the box. > > Here's the alsa-info on a default Arch Linux 5.18.3-arch1 kernel. > http://alsa-project.org/db/?f=88c18fe2a7e900cc9a1aef2b62d5a963460b7d74 > > Since my bass speakers weren't even recognized by the kernel (node 0x17 was > 'not connected') I used hdajackretask to map the node as a Speaker. > > This did not work either. > > I tried to enable the 'ALC287_FIXUP_BASS_SPK_AMP' quirk in > 'sound/pci/hda/patch_realtek' for my device. > > This, especially the chained 'ALC285_FIXUP_THINKPAD_X1_GEN7' quirk, made the > left bass speaker work. The right one remains mute. > > Here's the new alsa-info after the patch and forceing snd-hda-intel instead > of SOF. > http://alsa-project.org/db/?f=85bad6aac1448e944c730e4971ebd24672a67d86 > > Some fiddeling with alsamixer produced: > > Without headphones plugged in: > - headphone jack mute switch does nothing (as expected). > - speaker mute switch mutes both soundbar and bass. > - bass mute switch mutes both soundbar and bass. > - adjusting DAC1 changes bass volume. > - adjusting DAC2 changes soundbar volume. > > With headphone plugged in: > - headphone mute switch mutes headphones, soundbar and bass. > - speaker mute switch mutes bass. > - bass mute switch mutes soundbar. > - DAC1 changes bass and headphone volume. > - DAC2 changes soundbar volume. > > I am not familiar with the signal path through HDA devices. Could someone > explain or help me deduce the internal connections? > > I can patch a kernel and probably write a fixup myself once I understand > whats going wrong.
> > > > Host: 82LU Yoga 9 14IAP7 > > Kernel: 5.17.1-arch1-1 > > > > I was under the understanding that upgrading to 5.17 would fix this but I > > guess not. Any help is appreciated > > I think that I found the relevant HDA verbs by sniffing on a Windows 10 VM. > > Would someone else like to test the patch I wrote before can I try to submit > it? I would be happy to test it. Did they work for your yoga 9 14IAP7?
Created attachment 301327 [details] Patch for the ALC287 on the Lenovo Yoga 14IAP7 I did not include the FIXUP_THINKPAD_ACPI quirk in the fixup chain as I don't understand what it does. Could someone explain why it is done on other Lenovo Hardware and whether it could be needed on the Yoga9i?
(In reply to Philipp Jungkamp from comment #645) > Created attachment 301327 [details] > Patch for the ALC287 on the Lenovo Yoga 14IAP7 > > I did not include the FIXUP_THINKPAD_ACPI quirk in the fixup chain as I > don't understand what it does. Could someone explain why it is done on other > Lenovo Hardware and whether it could be needed on the Yoga9i? Is this a kernel patch that fixes the yoga 9i gen7 issue? That would be amazing! Thank you Philipp! One last request, I am not sure how to patch the kernel, would it be possible to have that patch in the form of a sh script that simply rewires the hda-verbs so I can test it (and implement it on each boot while the kernel gets patched)? I was experimenting with a script like this: hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x10 hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0320 hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x24 hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0041 hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x24 hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x0041 { ... and so on ...} But I didn't get anywhere.
(In reply to Philipp Jungkamp from comment #645) > Created attachment 301327 [details] > Patch for the ALC287 on the Lenovo Yoga 14IAP7 > > I did not include the FIXUP_THINKPAD_ACPI quirk in the fixup chain as I > don't understand what it does. Could someone explain why it is done on other > Lenovo Hardware and whether it could be needed on the Yoga9i? Hi, I can confirm this patch fixes the issue for 14IAP7 (applied it manually to 5.18.10 on arch linux). Million thanks!
Hi guys! I also have problem with subwoofers (like in comment #559) on Lenovo Yoga Slim 7 Carbon 14ACN6. https://psref.lenovo.com/Detail/Yoga/Yoga_Slim_7_Carbon_14ACN6?M=82L0005PRK I tried kernels 5.18.10, 5.17.15 (and 5.17.0-1012-oem on Ubuntu). The sound is bad everywhere :( alsa-info: http://alsa-project.org/db/?f=be90ab6208aa1484ed902f5bf89612219f634980
I tried apply patch from comment #645 to kernel 5.18.10. No changes in speakers for Lenovo Yoga Slim 7 Carbon 14ACN6. Subwoofer silent. alas-info: http://alsa-project.org/db/?f=2e070ab2ed78f5c06bf70ac47a0ec9908f941976
I also tried add next line after applied patch SND_PCI_QUIRK(0x17aa, 0x3856, "Yoga 7 Carbon 14ACN6", ALC287_FIXUP_YOGA9_IAP7_BASS_SPK_PIN) to sound/pci/hda/patch_realtek.c After kernel build and install bass not working. linux-5.18.10/ $ make clean $ make olddefconfig $ make -j 16 # make modules_install # make install NOTE: I building kernel from ubuntu with kernel 5.17.0-1012-oem. It's can affect "make olddefconfig"?
(In reply to Philipp Jungkamp from comment #645) > Created attachment 301327 [details] > Patch for the ALC287 on the Lenovo Yoga 14IAP7 > > I did not include the FIXUP_THINKPAD_ACPI quirk in the fixup chain as I > don't understand what it does. Could someone explain why it is done on other > Lenovo Hardware and whether it could be needed on the Yoga9i? Hello Philipp. I have the same Yoga 14IAP7 with no subwoofers sound. I'm using Ubuntu 22.04. I downloaded the vanilla 5.18 kernel ando could apply your patch, compile and install the kernel. I still have no sound in my subwoofers, but the alsa-info output changed. Do I have to blacklist any module or anything? I haven't made any change in that regard. My system is still loading the default intel sof drivers. Could you provide a short list of steps? Regards, Gervasio
(In reply to eruyome from comment #647) > (In reply to Philipp Jungkamp from comment #645) > > Created attachment 301327 [details] > > Patch for the ALC287 on the Lenovo Yoga 14IAP7 > > > > I did not include the FIXUP_THINKPAD_ACPI quirk in the fixup chain as I > > don't understand what it does. Could someone explain why it is done on > other > > Lenovo Hardware and whether it could be needed on the Yoga9i? > > Hi, > > I can confirm this patch fixes the issue for 14IAP7 (applied it manually to > 5.18.10 on arch linux). Million thanks! Hi eruyome, Could you provide details on how did you try this? I built 5.18.12 with this patch in arch and couldn't get the speakers working after reboot. Regards, Gervasio
Created attachment 301462 [details] bottomspeakers-for-14iap7-kernel-518.patch Hi Gervasio, I am attaching the modified Phillip's patch which worked for me for kernels in the 5.18 branch since there seem to be others who have trouble applying the patch. For Arch Linux specifically while a bit off-topic but I have the PKGBUILD here for convenience: https://pastebin.com/StvVZhwa (send me a personal email if you have trouble using it). (In reply to Gervasio Perez from comment #652) On Wed, 2022-07-20 at 06:32 +0000, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #652 from Gervasio Perez (gerva_98@hotmail.com) --- > > (In reply to eruyome from comment #647) > > > > (In reply to Philipp Jungkamp from comment #645) > > > > > > Created attachment 301327 [details] > > > > > > Patch for the ALC287 on the Lenovo Yoga 14IAP7 > > > > > > > > > > > > I did not include the FIXUP_THINKPAD_ACPI quirk in the > > > > > > fixup > > > chain as I > > > > > > don't understand what it does. Could someone explain why it > > > > > > is > > > done on > > > > other > > > > > > Lenovo Hardware and whether it could be needed on the > > > > > > Yoga9i? > > > > > > > > Hi, > > > > > > > > I can confirm this patch fixes the issue for 14IAP7 (applied it > > > > > > manually to > > > > 5.18.10 on arch linux). Million thanks! > > > > Hi eruyome, > > > > Could you provide details on how did you try this? > > I built 5.18.12 with this patch in arch and couldn't get the > > speakers > working > > after reboot. > > > > Regards, > > Gervasio > >
Hi all, After several unsuccessful tries applying Philipp patch for Yoga 9 14IAP7, I realised I have a different lenovo sound device ID (0x381c instead of 0x3801). I added to the patch the following line: + SND_PCI_QUIRK(0x17aa, 0x381c, "Yoga 9 14IAP7", ALC287_FIXUP_YOGA9_IAP7_BASS_SPK_PIN), and the patch worked flawlessly. Regards, Gervasio
Hello everybody, I have a similar problem as desribed in this thread: I have a Lenovo Yoga 7i 14ial7 (some kind of exclusive german / swiss / austrian model) with Realtek ALC3306 which is also recognized as an ALC287 by ALSA. Bass speakers do not work so I just have a very weak sound from the bottom speakers. I'm using Fedora 36 with the latest stable kernel (and parallel latest vanilla kernel hoping it will get fixed). I have seen there are some patches in this thread and also in the latest Kernel-Versions, but I have a different audio codec ID so they don't apply. My codec ID is 0x17aa3869. I'm actually not a noob to linux but also not advanced enough to compile my own kernel and apply any kind of patch to it. Is there anybody who can help me to get my speakers to work properly? What kind of output is needed? Thanks in advance and kind regards Pascal
(In reply to baipush from comment #655) > Hello everybody, > > I have a similar problem as desribed in this thread: > > I have a Lenovo Yoga 7i 14ial7 (some kind of exclusive german / swiss / > austrian model) with Realtek ALC3306 which is also recognized as an ALC287 > by ALSA. Bass speakers do not work so I just have a very weak sound from the > bottom speakers. > > I'm using Fedora 36 with the latest stable kernel (and parallel latest > vanilla kernel hoping it will get fixed). > > I have seen there are some patches in this thread and also in the latest > Kernel-Versions, but I have a different audio codec ID so they don't apply. > > My codec ID is 0x17aa3869. > > I'm actually not a noob to linux but also not advanced enough to compile my > own kernel and apply any kind of patch to it. > > Is there anybody who can help me to get my speakers to work properly? > > What kind of output is needed? > > Thanks in advance and kind regards > > Pascal Hi Pascal, You should try what I did: patch the kernel with your device ID. I don't use Fedore but they have a tutorial for building custom kernels: https://fedoraproject.org/wiki/Building_a_custom_kernel You should follow those instructions up to the line which says "You can now make whatever changes / customizations you need before generating the rpms and installing them" At that point you have to apply the patch. In your case, you should edit in the patch file provided by Philipp the following line: + SND_PCI_QUIRK(0x17aa, 0x3801, "Yoga 9 14IAP7", ALC287_FIXUP_YOGA9_IAP7_BASS_SPK_PIN), And edit your device id: + SND_PCI_QUIRK(0x17aa, 0x3869, "Yoga 9 14IAP7", ALC287_FIXUP_YOGA9_IAP7_BASS_SPK_PIN), To apply the patch, you should get into the kernel source directory (the one containing the "sound/" directory) and execute the following command: patch -p1 < your_edited_patch_file.patch The patch application might fail, and you may end up with these three files in your sound/pci/hda/ folder: patch_realtek.c (the partial patch) patch_realtek.c.orig (the original file) patch_realtek.c.rej (the rejected part of the patch) In my own experience, the rejected part for this patch is the SND_PCI_QUIRK line mentioned above. In that case, you can edit manually the patch_realtek.c file and add that new line (there is a loooong list of SND_PCI_QUIRK entries near the end of the file, and the order doesn't matter, so you can just add it anywhere in the middle). Keep in mind that the trailing "+" symbol should not be written when manually editing the source file (it's part of the patch tool syntax). After doing that, you can go ahead and compile/install/try the new kernel (following the rest of the Fedora tutorial). I can help if you get stuck. Send me an email. Regards, Gervasio
Hi Gervasio, Thank you very much for your advice and that great manual. I will try it as soon as possible. Will that patch "stay" in my Kernel when I update to a new Kernel Version or do I have to apply that patch every time there is a Kernel update? Thanks and regards Pascal
(In reply to baipush from comment #657) > Hi Gervasio, > > Thank you very much for your advice and that great manual. > I will try it as soon as possible. You're welcome!. > > Will that patch "stay" in my Kernel when I update to a new Kernel Version or > do I have to apply that patch every time there is a Kernel update? No. If you want to update to a new kernel version you'll have to repeat the process. > > Thanks and regards > > Pascal
OMG!!!! It is working!!!! My sound is on my ARCH system as Windows!!! Speakers full with amplifyers!! So my machine: Yoga 7i 16IAP7 Codec id : Codec: Realtek ALC287 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0287 Subsystem Id: 0x17aa386a it is 2022 Lenovo yoga release on the market was in April(i bought it in May) and i really can't believe it I do have full sound on it. Guys thank you, thank you soo much: Gervasio Perez for the explanations how to modify the patch and for posted PKGBUILD on arch and Philipp Jungkamp for the code of the patch!
Yes I did it ...for long i was looking for a solution compiling mainline, xanmod, clear-kernels looking for the right modules of my machine.. thank you once more
Now we know it works, how do we get into the mainline Kernel?
I used PKGBUILD posted with some mod and the new ver 5.18.13.arch1
i don't think i have the rights to post here my files
this is what i've done posted on my github https://github.com/322sirc/nemesis/tree/main/linux-14iap7 i'll test mainline kernel and i will post it
tested linux-mainline v5.19-rc7 --Works perfect! here is the github link: https://github.com/322sirc/linux-mainline For everyone new: you have to change your config file according to your machine kernel modules (unless you use the original one) and modify the patch with your machine sound card Subsystem Id: 0x17aa38XX (easily found info in /proc/asound/card0)in bottomspeakers-for-14iap7-kernel*.patch on line 169 and line 311. I'll make an update on my github for linux-xanmod-edge too.
I'm happy to see other people could make it work. I think the way to go is to collect all the ids compatible with Philipp's patch and submit a single patch for all of them...
Hello everybody I can confirm it works for me too (thx Gervasio for pushing forward on me :) ). How do we get the patches for all these different Lenovo models that have been touched in this thread into the original Kernel so that everybody can have them by default when installing their favorite distro?
I'd prefer to submit my patch as soon as possible myself to have the fixup/quirk mainlined. Other people can then just use a module parameter to enable the patch and check if it works properly for their devices. You can then submit the 'PCI_QUIRK' line for your hardware yourself. The module parameter should be an acceptable tradeoff until other devices' quirk lines are mainlined.
That sounds good. I hadn't thought of the possibility of a module option. I haven't submitted any patches myself and suggested sending several PCI_QUIRKs together (at least the ones identified in this thread for Yoga 9i 14IAP7) because I don't know the delays involved in the submission process..
@Philipp Why not submit all the patches from this thread? So it's easier for the maintainers of the kernel and there will be more devices supported by default in the future if somebody installs Linux on his Lenovo device. To be honest I wouldn't even know how to submit a patch, I just learned compiling a kernel...I would really appreciate your help with this.
Created attachment 301501 [details] attachment-17412-0.html I would vote for it 100%! For sure this patch becoming a module in the next kernel release would help not only Lenovo machines with this kind of audio hardware. On Thu, Jul 28, 2022 at 11:00 AM <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #668 from Philipp Jungkamp (p.jungkamp@gmx.net) --- > I'd prefer to submit my patch as soon as possible myself to have the > fixup/quirk mainlined. Other people can then just use a module parameter to > enable the patch and check if it works properly for their devices. You can > then > submit the 'PCI_QUIRK' line for your hardware yourself. The module > parameter > should be an acceptable tradeoff until other devices' quirk lines are > mainlined. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
(In reply to cris223 from comment #665) > tested linux-mainline v5.19-rc7 --Works perfect! > here is the github link: > > https://github.com/322sirc/linux-mainline > > For everyone new: you have to change your config file according to your > machine kernel modules (unless you use the original one) and modify the > patch with your machine sound card Subsystem Id: 0x17aa38XX (easily found > info in /proc/asound/card0)in bottomspeakers-for-14iap7-kernel*.patch on > line 169 and line 311. > > I'll make an update on my github for linux-xanmod-edge too. I tested this on the Lenovo Carbon 14ACN6 and it did not appear to work. Card0 is a digital and card has subsystem ID 0x17aa3856, which is what I updated in the patch file.
Created attachment 301503 [details] attachment-965-0.html Feel sorry to hear that. Is that because your machine is not an Intel cpu? i'm just wondering..(i'm not an expert) On Thu, Jul 28, 2022 at 8:32 PM <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > durbgork@gmail.com changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |durbgork@gmail.com > > --- Comment #672 from durbgork@gmail.com --- > (In reply to cris223 from comment #665) > > tested linux-mainline v5.19-rc7 --Works perfect! > > here is the github link: > > > > https://github.com/322sirc/linux-mainline > > > > For everyone new: you have to change your config file according to your > > machine kernel modules (unless you use the original one) and modify the > > patch with your machine sound card Subsystem Id: 0x17aa38XX (easily found > > info in /proc/asound/card0)in bottomspeakers-for-14iap7-kernel*.patch on > > line 169 and line 311. > > > > I'll make an update on my github for linux-xanmod-edge too. > > I tested this on the Lenovo Carbon 14ACN6 and it did not appear to work. > Card0 > is a digital and card has subsystem ID 0x17aa3856, which is what I updated > in > the patch file. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
A note on the 'model' and 'patch' options of of the 'snd_hda_intel' module. The 'model' option can be used to apply a fixup written for another device. You can check the fixups available for the ALC287 in the docs or in the 'alc269_fixup_models' array at sound/pci/hda/pathch_realtek.c:9551. See https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html#model-option The 'patch' option is similar, but way more powerful. I used it to try a lot of configurations before I got the sound working. See https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html#early-patching I'd like to see the patch merged so people with devices for which the fixup might work can try the module option instead of compiling a patched kernel. Something along the lines of --- # /etc/modprobe.d/snd.conf # use snd_hda_intel instead of snd_sof options snd_intel_dspcfg dsp_driver=1 # enable the fixup options snd_hda_intel model=alc287-yoga9-bass-spk-pin --- should then work to apply the fixup until a PCI_QUIRK is added. I'll give an update when I know when it's going mainline. There were actually three problems with the bass speakers on the Lenovo Yoga9 14IAP7: 1. The Pin Complex node of the codec with NID 0x17 on which the bass speakers are connected reported itself as unconnected. 2. The bass speakers have amplifiers which need to be enabled via NID 0x20 of the codec. (similar to the Lenovo Yoga 7 14ITL5 fixup) 3. The driver connected the bass speaker Pin Complex to the DAC on NID 0x06 of the codec which has no volume control. (bass speakers always on max volume) You can check whether your device is affected by problem 1 by checking the 'Pin Default' on 'Node 0x17' in the 'HDA-Intel Codec information' in your alsa-info.txt. e.g. $ grep -A6 'Node 0x17' < alsa-info.txt A 'Pin Default' that starts with 0x4, 0x5, 0x6 or 0x7 indicates and unconnected pin and thus problem 1 assuming the bass speakers are really on NID 0x17 on your device. If your device is not affected by problem 1, the mainline fixes for the 'Yoga 7 ITL5' or 'Legion 7i' might already work.
https://mailman.alsa-project.org/pipermail/alsa-devel/2022-July/204315.html The patch has been applied by a 'SOUND' subsystem maintainer. It will probably be merged in the next merge window (Linux 5.20). You can see the entry for the 'model' parameter in the patch.
The Lenovo Legion 7i Gen 7 (2022) model is now available in the USA: https://www.lenovo.com/us/en/p/laptops/legion-laptops/legion-7-series/legion-7i-gen-7-(16-inch-intel)/len101g0018 If you have one of these laptops, please share your alsa-info here. I strongly suspect it has Cirrus Logic cs35l41 amplifier chips in it. Hopefully the more generic approaches will work here (such as cs35l41_fixup_i2c_two()).
I lost all sound devices recently using Kubuntu 22.04 and the 5.18 kernel on my Legion 7 16ACHg6. Following this guide restored my devices: https://pipewire-debian.github.io/pipewire-debian/ Note: I installed all of the recommended wireplumber and BT options as well as the pipewire packages.
Philipp Jungkamp's patch is already module in the new kernel release candidate linux-6.0-rc1. For those who want to try it just compile the new kernel without patch and add in /etc/modprobe.d/snd.conf # use snd_hda_intel instead of snd_sof options snd_intel_dspcfg dsp_driver=1 # enable the fixup options snd_hda_intel model=alc287-yoga9-bass-spk-pin Thank you and Congrats!
(In reply to cris223 from comment #678) > Philipp Jungkamp's patch is already module in the new kernel release > candidate linux-6.0-rc1. > For those who want to try it just compile the new kernel without patch and > add in > /etc/modprobe.d/snd.conf > > # use snd_hda_intel instead of snd_sof > options snd_intel_dspcfg dsp_driver=1 > > # enable the fixup > options snd_hda_intel model=alc287-yoga9-bass-spk-pin > > Thank you and Congrats! I have Yoga 9 14IAP7, running 5.19.2 kernel w the patch and modprobe; $ cat /etc/modprobe.d/snd.conf options snd_intel_dspcfg dsp_driver=1 options snd_hda_intel model=alc287-yoga9-bass-spk-pin This does fix the speaker out (volume/amp & bass) however the microphone input is no longer available. http://alsa-project.org/db/?f=afa1f4aeb21b32e58d6d0b047997b2fa9baf2e60
Remove 'options snd_intel_dspcfg dsp_driver=1' and replace the second options line as 'options snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin' to get the full (including microphone) support.
Created attachment 301613 [details] attachment-19333-0.html For people with exact Yoga 9 14IAP7 machine is not necessary to include /etc/modprobe.d/snd.conf. The module is in the new kernel. For those with different machine that want to try it, can use the snd.conf at first then if you want to have the mic working you might have to patch the kernel with your machine model. I have an example of patch in my github https://github.com/322sirc/linux-16IAP7/blob/main/0007-ALSA-hda-realtek-Add-quirk-for-Yoga-devices.patch On Sat, Aug 20, 2022 at 3:12 PM <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #680 from Jaroslav Kysela (perex@perex.cz) --- > Remove 'options snd_intel_dspcfg dsp_driver=1' and replace the second > options > line as 'options snd-sof-intel-hda-common > hda_model=alc287-yoga9-bass-spk-pin' > to get the full (including microphone) support. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
I don't see that result for Yoga 9 14IAP7. Speakers don't work properly without both modprobe lines. Microphone input ceased to work whenever "options snd_intel_dspcfg dsp_driver=1" modprobe is applied: I tested the 4 possible cases: 1: /etc/modprobe.d/snd.conf: options snd_intel_dspcfg dsp_driver=1 options snd_hda_intel model=alc287-yoga9-bass-spk-pin Speakers: normal (bass & volume) Microphone: none http://alsa-project.org/db/?f=0046e5dd537e34323abbc4c75774881f7d846433 2: /etc/modprobe.d/snd.conf: # no modprobe Speakers: bad (no bass, low volume) Microphone: works http://alsa-project.org/db/?f=cb2fc1d8681f00d5567fc348236dec17e50d710c 3: /etc/modprobe.d/snd.conf: options snd_hda_intel model=alc287-yoga9-bass-spk-pin Speakers: bad (no bass, low volume) Microphone: works http://alsa-project.org/db/?f=3962d43a920565850cbc11f58884b3056a8b2fe3 4: /etc/modprobe.d/snd.conf: options snd_intel_dspcfg dsp_driver=1 Speakers: bad (no bass, low volume) Microphone: none http://alsa-project.org/db/?f=055e2b92be114acdac5125faf311a4ae6b107e02
Jaroslav Kysela's single modprobe ... 'options snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin' Causes the speakers & microphone to work properly.
Created attachment 301617 [details] attachment-22375-0.html I test this option in modprobe (kernel without special patch for my model) works for my machine! Thank you - good to know On Sun, Aug 21, 2022 at 9:10 AM <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #683 from Steve Alexander (stevea12345@gmail.com) --- > Jaroslav Kysela's single modprobe ... > 'options snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin' > Causes the speakers & microphone to work properly. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
I am on HP EliteBook 865 16 inch G9 (amd 6850h) with alc245 Cirrus Logic CS35L41 on Fedora 37 (rawhide) with 6.0rc3 kernel and still got issues of low volume sound (CS35L41 amp not active) where the volume is 1/4 of that of windows11 and fidelity is horrible if cranked above 100%. Even got the following dmesg error from cs35l41 driver. [ 407.695559] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: DSP1: Failed to read 4 bytes from 28007e8: -121 Here is my machine and sound hw/config: http://alsa-project.org/db/?f=6a7039fe66fc4310f82de9f4a933268ba34d9382 Do I have similar if not identical issue as the ALC287 here? Thanks.
I have a similar problem on my Lenovo Yoga 7 (14ARB 82QF000GGE) with AMD Ryzen 7 6800U. Speakers: bad (no bass, low volume) Microphone: none Here is my alsa-info.sh result: http://alsa-project.org/db/?f=00f394a64f4d0068ee23f1cbd8dc87f391694adc Please don't get confused from lines: > !!Modprobe options (Sound related) > !!-------------------------------- > > snd_sof_intel_hda_common: hda_model=alc287-yoga9-bass-spk-pin I have just putted the params in modprobe. Of cause it have no effect like that. I need to apply the patch. I will try it later. Just wanted to provide the relevant information. Subsystem Id: 0x17aa3870
I have a Lenovo Yoga 7 14ARB7 too. I think it uses an TAS2563 amplifier chip. According to the windows driver it has a firmware too. There is some support in the kernel too. https://github.com/torvalds/linux/blob/master/sound/soc/codecs/tas2562.c The ACPI part: ``` Scope (_SB.I2CD) { Device (TAS) { Name (_HID, "INT8866") // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { I2cSerialBusV2 (0x004C, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2CD", 0x00, ResourceConsumer, , Exclusive, ) I2cSerialBusV2 (0x004D, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2CD", 0x00, ResourceConsumer, , Exclusive, ) GpioInt (Edge, ActiveLow, SharedAndWake, PullNone, 0x0000, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x0020 } }) Return (RBUF) /* \_SB_.I2CD.TAS_._CRS.RBUF */ } Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0F) } } } ```
Created attachment 301857 [details] attachment-28445-0.html I am currently out of the office on holiday I will be returning on Monday September 26, I will not have access to email so replies will be delayed
The TAS2563 works without the firmware (tuning file). Documentation: https://www.ti.com/product/TAS2553 However there is an android driver with firmware loading support. https://git.ti.com/cgit/tas256xsw-android/tas2563-android-driver/ Or a mainline RFC: https://lkml.org/lkml/2020/6/9/800 The bass speakers can be enabled with: i2cset 3 0x4c 0x2 0 i2cset 3 0x4d 0x2 0 they are listening on 0x48 too, so in one turn: i2cset 3 0x48 0x2 0 I don't know how safe it is to use it this way. They have to be enabled after suspend, and if you plug in-out the headphone (only if auto mute is enabled).
I fall to my knees! This helps: i2cset 3 0x48 0x2 0 I have a Lenovo 7 14arb7 with Ubuntu-22.10 kernel-6rc6. In normal stereo 2.0 it sounds good now. No bass in 2.1 In 4.0 bass, but sounds strangely delayed. :O)(In reply to Gergo K from comment #689) > The TAS2563 works without the firmware (tuning file). > Documentation: > https://www.ti.com/product/TAS2553 > > However there is an android driver with firmware loading support. > https://git.ti.com/cgit/tas256xsw-android/tas2563-android-driver/ > Or a mainline RFC: > https://lkml.org/lkml/2020/6/9/800 > > > The bass speakers can be enabled with: > i2cset 3 0x4c 0x2 0 > i2cset 3 0x4d 0x2 0 > > they are listening on 0x48 too, so in one turn: > i2cset 3 0x48 0x2 0 > > I don't know how safe it is to use it this way. > > They have to be enabled after suspend, and if you plug in-out the headphone > (only if auto mute is enabled). (In reply to Gergo K from comment #689) > The TAS2563 works without the firmware (tuning file). > Documentation: > https://www.ti.com/product/TAS2553 > > However there is an android driver with firmware loading support. > https://git.ti.com/cgit/tas256xsw-android/tas2563-android-driver/ > Or a mainline RFC: > https://lkml.org/lkml/2020/6/9/800 > > > The bass speakers can be enabled with: > i2cset 3 0x4c 0x2 0 > i2cset 3 0x4d 0x2 0 > > they are listening on 0x48 too, so in one turn: > i2cset 3 0x48 0x2 0 > > I don't know how safe it is to use it this way. > > They have to be enabled after suspend, and if you plug in-out the headphone > (only if auto mute is enabled). (In reply to Gergo K from comment #689) > The TAS2563 works without the firmware (tuning file). > Documentation: > https://www.ti.com/product/TAS2553 > > However there is an android driver with firmware loading support. > https://git.ti.com/cgit/tas256xsw-android/tas2563-android-driver/ > Or a mainline RFC: > https://lkml.org/lkml/2020/6/9/800 > > > The bass speakers can be enabled with: > i2cset 3 0x4c 0x2 0 > i2cset 3 0x4d 0x2 0 > > they are listening on 0x48 too, so in one turn: > i2cset 3 0x48 0x2 0 > > I don't know how safe it is to use it this way. > > They have to be enabled after suspend, and if you plug in-out the headphone > (only if auto mute is enabled).
(In reply to Gergo K from comment #689) > The TAS2563 works without the firmware (tuning file). > Documentation: > https://www.ti.com/product/TAS2553 > > However there is an android driver with firmware loading support. > https://git.ti.com/cgit/tas256xsw-android/tas2563-android-driver/ > Or a mainline RFC: > https://lkml.org/lkml/2020/6/9/800 > > > The bass speakers can be enabled with: > i2cset 3 0x4c 0x2 0 > i2cset 3 0x4d 0x2 0 > > they are listening on 0x48 too, so in one turn: > i2cset 3 0x48 0x2 0 > > I don't know how safe it is to use it this way. > > They have to be enabled after suspend, and if you plug in-out the headphone > (only if auto mute is enabled). OK, that works! But what can I do to make this register (3 0x38 0x02 0) set automatically? Does that have something to do with the power settings under /sys/bus/i2c/devices/i2c-3/device/power/*?
I've managed to get my Lenovo Legion 7 16ACHg6 speakers working on kernel 5.18.x by setting the following kernel configuration CONFIG_SND_SOC_CS35L41_I2C=m CONFIG_SERIAL_MULTI_INSTANTIATE=m However, kernel 5.19.x seems to break it as with the same kernel config, the modules are loaded by do not work. Apart from the speaker, I'm having the same issue with the touchpad (works on 5.18, but not on 5.19). Any ideas why it would work on 5.18, but not on 5.19?
(In reply to Marko from comment #691) > (In reply to Gergo K from comment #689) > > The TAS2563 works without the firmware (tuning file). > > Documentation: > > https://www.ti.com/product/TAS2553 > > > > However there is an android driver with firmware loading support. > > https://git.ti.com/cgit/tas256xsw-android/tas2563-android-driver/ > > Or a mainline RFC: > > https://lkml.org/lkml/2020/6/9/800 > > > > > > The bass speakers can be enabled with: > > i2cset 3 0x4c 0x2 0 > > i2cset 3 0x4d 0x2 0 > > > > they are listening on 0x48 too, so in one turn: > > i2cset 3 0x48 0x2 0 > > > > I don't know how safe it is to use it this way. > > > > They have to be enabled after suspend, and if you plug in-out the headphone > > (only if auto mute is enabled). > > OK, that works! But what can I do to make this register (3 0x38 0x02 0) set > automatically? > Does that have something to do with the power settings under > /sys/bus/i2c/devices/i2c-3/device/power/*? I think you can run it with systemd after resume/hibernate/boot while I write a driver for it.
Thanks for the tip Gergo! I disable the sound power management with the tlp.service and set the i2c-register with a own customboot.service after the tlp.service is started. It works for now :o) /root/bass-speaker-on.sh #!/usr/bin/env bash /usr/sbin/i2cset -y 3 0x48 0x2 0 /etc/systemd/system/customboot.service [Unit] Description=Custom Bootup Script After=tlp.service [Service] ExecStart=/root/bass-speaker-on.sh [Install] WantedBy=default.target /etc/tlp.conf SOUND_POWER_SAVE_ON_AC=0 SOUND_POWER_SAVE_ON_BAT=0 SOUND_POWER_SAVE_CONTROLLER=N
(In reply to Marko from comment #694) > Thanks for the tip Gergo! > I disable the sound power management with the tlp.service and set the > i2c-register with a own customboot.service after the tlp.service is started. > It works for now :o) > > /root/bass-speaker-on.sh > #!/usr/bin/env bash > /usr/sbin/i2cset -y 3 0x48 0x2 0 > > /etc/systemd/system/customboot.service > [Unit] > Description=Custom Bootup Script > After=tlp.service > [Service] > ExecStart=/root/bass-speaker-on.sh > [Install] > WantedBy=default.target > > /etc/tlp.conf > SOUND_POWER_SAVE_ON_AC=0 > SOUND_POWER_SAVE_ON_BAT=0 > SOUND_POWER_SAVE_CONTROLLER=N One thing to protect your speakers. It's a 6W amplifier so the default gain may be too much. I didn't dump the registers in windows yet, but in the limited sound on c940 issue ( https://bugzilla.kernel.org/show_bug.cgi?id=205755 ) they write about 11 dB for a 2W bass speaker. I think that's a different amplifier, so the register values may not match. Please add i2cset -y 3 0x48 0x3 0x00 to your script until the windows dump is done.
I seem to have the same issue on a lenovo Legion S7 16ARHA7, here is my alsa-info hopefully it's of some use: http://alsa-project.org/db/?f=59acbf18b993b0a49edaaee0027d4b57fcf2055c
Created attachment 301907 [details] attachment-12523-0.html Almost certainly your laptop doesn't have the _DSD entries needed to properly get sound working. Check dmesg for either of these messages: dmesg | grep -i "Platform not supported -EINVAL" or dmesg | grep -i "Error: ACPI _DSD Properties are missing for HID" For reference, see: https://www.spinics.net/lists/alsa-devel/msg146157.html https://bugzilla.kernel.org/show_bug.cgi?id=216194 I have the same problem with the Lenovo Legion 2022 Gen 7 (16IAX7). I filed a support ticket with Lenovo a few weeks back, but when support followed back they wanted to text during work hours, and I was too busy to deal with that then and too busy to deal with it since. I think I may actually have some time today. If you have either message in your dmesg, I'd suggest filing a support ticket. If enough people complain about these issues, it may compel them to add the proper _DSD entries into a BIOS update. There's no reason that Lenovo can't include this information in a BIOS update. It does seem that going forward that the intention of Cirrus Logic is for the vendors to include this information in the BIOS. For vendors where this is not the case, likely what's happening is that these values are hard coded in the vendor provided drivers or firmware. It doesn't require them to touch Linux at all. It should be relatively simple for them to add this information as there's already an incomplete entry in the ACPI table as it is. In the kernel bug linked above, I attached a hacky patch that gets sound working on the 16IAX7... But it's a hack where I guessed and hard-coded the values and these could physically damage your speakers if the settings are too inappropriate for your model of laptop (including the 16IAX7). This is very much a USE AT YOUR OWN RISK scenario, and I sincerely recommend against using my patches to avoid any possibility of damage to your laptop. Furthermore, sound doesn't work after resume anyway. Although it could be argued that if people start trying to use hacks like these to enable sound under Linux for their laptop, vendors such as Lenovo may need to issue BIOS updates to address this to avoid costly laptop repairs. On 9/30/22 05:11, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > jochempmgo@gmail.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |jochempmgo@gmail.com > > --- Comment #696 fromjochempmgo@gmail.com --- > I seem to have the same issue on a lenovo Legion S7 16ARHA7, here is my > alsa-info hopefully it's of some use: > http://alsa-project.org/db/?f=59acbf18b993b0a49edaaee0027d4b57fcf2055c >
(In reply to Cameron Berkenpas from comment #697) > Created attachment 301907 [details] > attachment-12523-0.html > > Almost certainly your laptop doesn't have the _DSD entries needed to > properly get sound working. > > Check dmesg for either of these messages: > dmesg | grep -i "Platform not supported -EINVAL" > or > dmesg | grep -i "Error: ACPI _DSD Properties are missing for HID" > > For reference, see: > https://www.spinics.net/lists/alsa-devel/msg146157.html > https://bugzilla.kernel.org/show_bug.cgi?id=216194 > > I have the same problem with the Lenovo Legion 2022 Gen 7 (16IAX7). I > filed a support ticket with Lenovo a few weeks back, but when support > followed back they wanted to text during work hours, and I was too busy > to deal with that then and too busy to deal with it since. I think I may > actually have some time today. > > If you have either message in your dmesg, I'd suggest filing a support > ticket. If enough people complain about these issues, it may compel them > to add the proper _DSD entries into a BIOS update. > > There's no reason that Lenovo can't include this information in a BIOS > update. It does seem that going forward that the intention of Cirrus > Logic is for the vendors to include this information in the BIOS. For > vendors where this is not the case, likely what's happening is that > these values are hard coded in the vendor provided drivers or firmware. > > It doesn't require them to touch Linux at all. > > It should be relatively simple for them to add this information as > there's already an incomplete entry in the ACPI table as it is. > > In the kernel bug linked above, I attached a hacky patch that gets sound > working on the 16IAX7... But it's a hack where I guessed and hard-coded > the values and these could physically damage your speakers if the > settings are too inappropriate for your model of laptop (including the > 16IAX7). This is very much a USE AT YOUR OWN RISK scenario, and I > sincerely recommend against using my patches to avoid any possibility of > damage to your laptop. Furthermore, sound doesn't work after resume anyway. > > Although it could be argued that if people start trying to use hacks > like these to enable sound under Linux for their laptop, vendors such as > Lenovo may need to issue BIOS updates to address this to avoid costly > laptop repairs. > > On 9/30/22 05:11, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > jochempmgo@gmail.com changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > CC| |jochempmgo@gmail.com > > > > --- Comment #696 fromjochempmgo@gmail.com --- > > I seem to have the same issue on a lenovo Legion S7 16ARHA7, here is my > > alsa-info hopefully it's of some use: > > http://alsa-project.org/db/?f=59acbf18b993b0a49edaaee0027d4b57fcf2055c > > Thanks for the info, appreciate it. using grep i didn't find any of those messages though. so might not be the same issue after all then.
You could share your dmesg. The other possibility is that the kernel doesn't include the configuration (arch IIRC?). On 10/1/22 04:48, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #698 from jochempmgo@gmail.com --- > (In reply to Cameron Berkenpas from comment #697) >> Created attachment 301907 [details] >> attachment-12523-0.html >> >> Almost certainly your laptop doesn't have the _DSD entries needed to >> properly get sound working. >> >> Check dmesg for either of these messages: >> dmesg | grep -i "Platform not supported -EINVAL" >> or >> dmesg | grep -i "Error: ACPI _DSD Properties are missing for HID" >> >> For reference, see: >> https://www.spinics.net/lists/alsa-devel/msg146157.html >> https://bugzilla.kernel.org/show_bug.cgi?id=216194 >> >> I have the same problem with the Lenovo Legion 2022 Gen 7 (16IAX7). I >> filed a support ticket with Lenovo a few weeks back, but when support >> followed back they wanted to text during work hours, and I was too busy >> to deal with that then and too busy to deal with it since. I think I may >> actually have some time today. >> >> If you have either message in your dmesg, I'd suggest filing a support >> ticket. If enough people complain about these issues, it may compel them >> to add the proper _DSD entries into a BIOS update. >> >> There's no reason that Lenovo can't include this information in a BIOS >> update. It does seem that going forward that the intention of Cirrus >> Logic is for the vendors to include this information in the BIOS. For >> vendors where this is not the case, likely what's happening is that >> these values are hard coded in the vendor provided drivers or firmware. >> >> It doesn't require them to touch Linux at all. >> >> It should be relatively simple for them to add this information as >> there's already an incomplete entry in the ACPI table as it is. >> >> In the kernel bug linked above, I attached a hacky patch that gets sound >> working on the 16IAX7... But it's a hack where I guessed and hard-coded >> the values and these could physically damage your speakers if the >> settings are too inappropriate for your model of laptop (including the >> 16IAX7). This is very much a USE AT YOUR OWN RISK scenario, and I >> sincerely recommend against using my patches to avoid any possibility of >> damage to your laptop. Furthermore, sound doesn't work after resume anyway. >> >> Although it could be argued that if people start trying to use hacks >> like these to enable sound under Linux for their laptop, vendors such as >> Lenovo may need to issue BIOS updates to address this to avoid costly >> laptop repairs. >> >> On 9/30/22 05:11, bugzilla-daemon@kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> jochempmgo@gmail.com changed: >>> >>> What |Removed |Added >>> >> ---------------------------------------------------------------------------- >>> CC| |jochempmgo@gmail.com >>> >>> --- Comment #696 fromjochempmgo@gmail.com --- >>> I seem to have the same issue on a lenovo Legion S7 16ARHA7, here is my >>> alsa-info hopefully it's of some use: >>> http://alsa-project.org/db/?f=59acbf18b993b0a49edaaee0027d4b57fcf2055c >>> > Thanks for the info, appreciate it. > using grep i didn't find any of those messages though. so might not be the > same > issue after all then. >
Created attachment 302940 [details] alsa info for this laptop ( https://psref.lenovo.com/Detail/Legion/Legion_S7_16ARHA7?M=82UG0029SP ) alsa info for this laptop ( https://psref.lenovo.com/Detail/Legion/Legion_S7_16ARHA7?M=82UG0029SP )
Created attachment 302941 [details] dmesg for Legion S7 16ARHA7-82UG dmesg for this laptop ( https://psref.lenovo.com/Detail/Legion/Legion_S7_16ARHA7?M=82UG0029SP )
(In reply to toyeisfree from comment #701) > Created attachment 302941 [details] > dmesg for Legion S7 16ARHA7-82UG > > dmesg for this laptop ( > https://psref.lenovo.com/Detail/Legion/Legion_S7_16ARHA7?M=82UG0029SP ) Because your ACPI table is missing the _DSD entries just like mine: [ 6.111053] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: error -EINVAL: Platform not supported -22 [ 6.111082] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.0 failed with error -22 [ 6.111138] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: error -EINVAL: Platform not supported -22 [ 6.111155] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed with error -22 jochempmgo@gmail.com, Looks like I had you grepping for the wrong thing. This is likely your issue as well if you want to share your dmesg. jochempmgo@gmail.com & toyeisfree@gmail.com, My suggestion for both of you is to follow up with Lenovo support as I mentioned and see where that gets us. If enough of us take issue, they might be inclined to fix it. Failing that, if enough of us are affected, maybe we can start a petition? I still haven't been able to follow up on my ticket. Too busy with work/life.
(In reply to Cameron Berkenpas from comment #702) > jochempmgo@gmail.com & toyeisfree@gmail.com, > My suggestion for both of you is to follow up with Lenovo support as I > mentioned and see where that gets us. If enough of us take issue, they might > be inclined to fix it. > > Failing that, if enough of us are affected, maybe we can start a petition? > > I still haven't been able to follow up on my ticket. Too busy with work/life. Same issue for me on a Legion S7 16ARHA7. I've opened a support case with Lenovo, let's see how it goes.
(In reply to fishsemxpinha from comment #692) > I've managed to get my Lenovo Legion 7 16ACHg6 speakers working on kernel > 5.18.x by setting the following kernel configuration > > CONFIG_SND_SOC_CS35L41_I2C=m > CONFIG_SERIAL_MULTI_INSTANTIATE=m > > However, kernel 5.19.x seems to break it as with the same kernel config, the > modules are loaded but do not work. Apart from the speaker, I'm having the > same issue with the touchpad (works on 5.18, but not on 5.19). > > Any ideas why it would work on 5.18, but not on 5.19? Any ideas or suggestions on this?
I bought the Legion 7 AMD Advantage (16IAX7) and I am unable to get the audio to work in archlinux. I also tried PopOS! and PCLinuxOS which was on 5.18. It only works in Windows Enabling the CONFIG_SERIAL_MULTI_INSTANTIATE does not help in 6.0.3. I also tried adding this quirk and compiling: SND_PCI_QUIRK(0x17aa, 0x387, "Legion 7 16IAX7", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS), I have not had the chance to go back and check in 5.18. I also tried the 0.0.5 patch and that did not work either. Here are the dmesg errors: [ 35.177946] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: error -EINVAL: Platform not supported [ 35.179512] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: error -EINVAL: Platform not supported [ 2.331045] ACPI: \_SB_.PCI0.LPC0.EC0_: Boot DSDT EC initialization complete [ 35.177183] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD Properties are missing for HID CSC3551. [ 35.178812] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Error: ACPI _DSD Properties are missing for HID CSC3551. Subsystem: 3877 http://alsa-project.org/db/?f=b122164954536a489dd3f9bc659f96b1ca2aa5a4 I am assuming it's the Lenovo BIOS is missing the DSD entries? I tried to put in a lenovo ticket, and they just sent me to a page on how to fix it in Windows.
Apologies, wrong laptop model#. It is: Legion S7 16ARHA7 as in the linked alsa-project url.
(In reply to antidense from comment #705) > Here are the dmesg errors: > [ 35.177946] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: error -EINVAL: > Platform not supported > [ 35.179512] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: error -EINVAL: > Platform not supported > > [ 2.331045] ACPI: \_SB_.PCI0.LPC0.EC0_: Boot DSDT EC initialization > complete > [ 35.177183] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD > Properties are missing for HID CSC3551. > [ 35.178812] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: Error: ACPI _DSD > Properties are missing for HID CSC3551. As referenced here: https://bugzilla.kernel.org/show_bug.cgi?id=208555#c702 (Newer kernels had a patch that fortunately clarifies that it's a matter of missing _DSD properties) Your laptop is missing the _DSD entries to setup this device. I suggest opening a support ticket. Hopefully with enough pressure, they'll add the entries. Especially since it doesn't require Lenovo to touch Linux or anything else other than to update their own BIOS images for the affected models.
i'm a normal user and i can be super wrong but... why we say that the bios is missing something and in Windows work perfectly without that ?
(In reply to toyeisfree from comment #708) > i'm a normal user and i can be super wrong but... why we say that the bios > is missing something and in Windows work perfectly without that ? Because the windows drivers from Lenovo have those values hardcoded into them. Seems that Cirrus Logic generally expects these properties to be in the ACPI tables even for Windows. Sounds like missing properties is an issue in "older" laptop models. I don't think my model is very old, but could be that the work on it started earlier. The properties are specific to a given laptop model and having the wrong values could physically damage your speakers. Before I knew this, I hard coded the values into a kernel patch and managed to get my own sound working. Fortunately, my speakers are fine. I certainly don't know how, but perhaps the drivers could be reverse engineered to discover the values of the properties for a given model, and then you could override the DSDT like this to get your sound working: https://wiki.debian.org/OverridingDSDT IIRC, you could then use the Intel HDA early patching to set your laptop to use the quirk of another laptop that uses the cs35l41 quirk so you could get sound working without any changes at all to the kernel to get your sound working.
Hi, I might've missed this but - do we know for certain that the 7th gen Legion 7 (2022 model) uses the same amplifier chip as the 6th gen (2021 model)?
It does not, which is unfortunate, as the 6th gen model recently finally got support. The gen 7 uses the CSC3551 and the gen 7 is missing the properties in the _DSD tables. Do you already have the Gen 7? Try submitting a Lenovo support ticket asking them to add the properties. I have a ticket they haven't follow up on yet so I added a comment to the ticket I think less than an hour ago. On 10/24/22 09:55, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #710 from Howard Chu (hyc@highlandsun.com) --- > Hi, I might've missed this but - do we know for certain that the 7th gen > Legion > 7 (2022 model) uses the same amplifier chip as the 6th gen (2021 model)? >
Does anyone know if both the intel and amd versions of legion gen 7 have the same problem with the DSD tables or just the amd version?
The Intel based Legion 7i Gen 7 definitely has this problem as I have one. On 10/27/22 09:16, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #712 from antidense@gmail.com --- > Does anyone know if both the intel and amd versions of legion gen 7 have the > same problem with the DSD tables or just the amd version? >
Any news from Lenovo support ?
None. Whenever I picked up their calls, it would hang up, so the ticket would close. I'm going to try their support chat when I have time... Whenever that will be. On 11/4/22 12:41, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #714 from david.renoux@protonmail.com --- > Any news from Lenovo support ? >
(In reply to david.renoux from comment #714) > Any news from Lenovo support ? No luck from my side, support stated that they don't support non Microsoft platforms for this model.
Same problem (so sound from internal speakers) here, with Legion Y740S. Fixed it with adding to ALC285 quirks list to call alc285_fixup_ideapad_s740_coef. sudo dmidecode | grep Family | grep Legion Family: Legion Y740S-15IMH lspci | grep Audio 00:1f.3 Audio device: Intel Corporation Comet Lake PCH cAVS lspci -v -s 00:1f.3 -n 00:1f.3 0403: 8086:06c8 (prog-if 80) Subsystem: 17aa:3825 Patched against ubuntu tag: jammy-stable-v5.15.76, but should merge with vanilla 5.17+, too. Will attach patch for reference, hopefully this will be merged to vanilla upstream. Regards,
Created attachment 303238 [details] Add Lenovo Y740S audio pci id to quirks list for alc285
(In reply to Cameron Berkenpas from comment #711) > It does not, which is unfortunate, as the 6th gen model recently finally > got support. > > The gen 7 uses the CSC3551 and the gen 7 is missing the properties in > the _DSD tables. > > Do you already have the Gen 7? Try submitting a Lenovo support ticket > asking them to add the properties. I have a ticket they haven't follow > up on yet so I added a comment to the ticket I think less than an hour ago. > > On 10/24/22 09:55, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #710 from Howard Chu (hyc@highlandsun.com) --- > > Hi, I might've missed this but - do we know for certain that the 7th gen > > Legion > > 7 (2022 model) uses the same amplifier chip as the 6th gen (2021 model)? > > Hi Cameron, I got my Legion Slim 7 Gen 7 AMD version yesterday and when I excitedly installed Fedora, I found the audio did not work. I would like to throw my weight behind this to get it fixed, but I don't know what to say to support exactly in my ticket. What do I need to ask them for? I would really prefer not to have to send this laptop back. Is there anything else I can do to help?
(In reply to Blake Lee from comment #719) > (In reply to Cameron Berkenpas from comment #711) > > It does not, which is unfortunate, as the 6th gen model recently finally > > got support. > > > > The gen 7 uses the CSC3551 and the gen 7 is missing the properties in > > the _DSD tables. > > > > Do you already have the Gen 7? Try submitting a Lenovo support ticket > > asking them to add the properties. I have a ticket they haven't follow > > up on yet so I added a comment to the ticket I think less than an hour ago. > > > > On 10/24/22 09:55, bugzilla-daemon@kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > > > --- Comment #710 from Howard Chu (hyc@highlandsun.com) --- > > > Hi, I might've missed this but - do we know for certain that the 7th gen > > > Legion > > > 7 (2022 model) uses the same amplifier chip as the 6th gen (2021 model)? > > > > > Hi Cameron, > > I got my Legion Slim 7 Gen 7 AMD version yesterday and when I excitedly > installed Fedora, I found the audio did not work. I would like to throw my > weight behind this to get it fixed, but I don't know what to say to support > exactly in my ticket. What do I need to ask them for? > > I would really prefer not to have to send this laptop back. Is there > anything else I can do to help? I wish I knew. My understanding is that they have to add DSD entries in the next BIOS update. Maybe someone could elaborate further. When I put a ticket in they just sent me a generic sound troubleshooting guide for Windows. I am currently dualbooting hoping for an eventual solution (other than headphones or a bluetooth speaker). Nov 25 21:36:05 [redacted] kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPC0.EC0.OKEC], AE_NOT_FOUND (20220331/psargs-330) Nov 25 21:36:05 [redacted] kernel: ccp 0000:07:00.2: ccp: unable to access the device: you might be running a broken BIOS. Nov 26 00:18:21 [redacted] kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPC0.EC0.OKEC], AE_NOT_FOUND (20220331/psargs-330) Nov 26 11:55:07 [redacted] kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPC0.EC0.OKEC], AE_NOT_FOUND (20220331/psargs-330)
Hello, I'll follow up with you guys probably tomorrow (but possibly as soon as later today). I've just been having an eventful holiday weekend. As tomorrow is a normal weekday that I have off, I'll finally reach out to Lenovo again tomorrow myself. Doing a quick search, I don't think anyone has shared their Legion Slim 7 Gen 7 AMD alsa-info. Can someone do that? It's likely still the CSC3551, but it would be good to confirm. As for those ACPI messages... Looks like you have ACPI some stuff that isn't supported under Linux yet. It's a fairly new laptop, so that's to be expected. I don't really see that on my current laptop, but I do see it with my current desktop which I've had for under a month (Asus Crosshair x670 Extreme). The CCP messages means Linux can't utilize the AMD Crypto Co-Processor on your CPU. I've had this message for my current desktop as well as my previous (AMD 7950 and 5950 CPU's respectively). From my research, the motherboard vendor (both Asus in my case) need to fix the BIOS. Maybe it's a similar issue to what we're seeing with our laptops. While unfortunately, it hasn't really impacted me. On 11/26/22 11:28, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #720 from antidense@gmail.com --- > (In reply to Blake Lee from comment #719) >> (In reply to Cameron Berkenpas from comment #711) >>> It does not, which is unfortunate, as the 6th gen model recently finally >>> got support. >>> >>> The gen 7 uses the CSC3551 and the gen 7 is missing the properties in >>> the _DSD tables. >>> >>> Do you already have the Gen 7? Try submitting a Lenovo support ticket >>> asking them to add the properties. I have a ticket they haven't follow >>> up on yet so I added a comment to the ticket I think less than an hour ago. >>> >>> On 10/24/22 09:55, bugzilla-daemon@kernel.org wrote: >>>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>>> >>>> --- Comment #710 from Howard Chu (hyc@highlandsun.com) --- >>>> Hi, I might've missed this but - do we know for certain that the 7th gen >>>> Legion >>>> 7 (2022 model) uses the same amplifier chip as the 6th gen (2021 model)? >>>> >> Hi Cameron, >> >> I got my Legion Slim 7 Gen 7 AMD version yesterday and when I excitedly >> installed Fedora, I found the audio did not work. I would like to throw my >> weight behind this to get it fixed, but I don't know what to say to support >> exactly in my ticket. What do I need to ask them for? >> >> I would really prefer not to have to send this laptop back. Is there >> anything else I can do to help? > I wish I knew. My understanding is that they have to add DSD entries in the > next BIOS update. Maybe someone could elaborate further. When I put a ticket > in they just sent me a generic sound troubleshooting guide for Windows. I am > currently dualbooting hoping for an eventual solution (other than headphones > or > a bluetooth speaker). > > Nov 25 21:36:05 [redacted] kernel: ACPI BIOS Error (bug): Could not resolve > symbol [\_SB.PCI0.LPC0.EC0.OKEC], AE_NOT_FOUND (20220331/psargs-330) > Nov 25 21:36:05 [redacted] kernel: ccp 0000:07:00.2: ccp: unable to access > the > device: you might be running a broken BIOS. > Nov 26 00:18:21 [redacted] kernel: ACPI BIOS Error (bug): Could not resolve > symbol [\_SB.PCI0.LPC0.EC0.OKEC], AE_NOT_FOUND (20220331/psargs-330) > Nov 26 11:55:07 [redacted] kernel: ACPI BIOS Error (bug): Could not resolve > symbol [\_SB.PCI0.LPC0.EC0.OKEC], AE_NOT_FOUND (20220331/psargs-330) >
(In reply to Cameron Berkenpas from comment #721) > Hello, > > > Doing a quick search, I don't think anyone has shared their Legion Slim > 7 Gen 7 AMD alsa-info. Can someone do that? It's likely still the > CSC3551, but it would be good to confirm. check the comment 700
(In reply to Blake Lee from comment #719) > Hi Cameron, > > I got my Legion Slim 7 Gen 7 AMD version yesterday and when I excitedly > installed Fedora, I found the audio did not work. I would like to throw my > weight behind this to get it fixed, but I don't know what to say to support > exactly in my ticket. What do I need to ask them for? > > I would really prefer not to have to send this laptop back. Is there > anything else I can do to help? I don't really have a plan of attack on this as I'm pretty busy generally. I haven't had time to follow up with Lenovo support yet. I'm just hoping if they get enough feedback, they'll do something. Otherwise, maybe we can try a petition? But you might try explaining that all you need is for Lenovo to add the requisite info to the DSD table in a BIOS update. Linux doesn't need to be touched at all. Just a BIOS update. Here's a working example (that I got from https://bugzilla.kernel.org/show_bug.cgi?id=216194): Name (_DSD, Package (0x02) // _DSD: Device-Specific Data { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */, Package (0x05) { Package (0x02) { "cirrus,dev-index", Package (0x02) { 0x40, 0x42 } }, Package (0x02) { "reset-gpios", Package (0x08) { SPKR, One, Zero, Zero, SPKR, One, Zero, Zero } }, Package (0x02) { "cirrus,speaker-position", Package (0x02) { One, Zero } }, Package (0x02) { "cirrus,gpio1-func", Package (0x02) { Zero, One } }, Package (0x02) { "cirrus,gpio2-func", Package (0x02) { 0x02, 0x02 } } } }) This information appears to be hard-coded in the drivers or related files somehow. If this information could be determined, perhaps there could be a kernel look up table with static values for supported laptops? Lenovo could easily add this information (that is specific to the given model of laptop) in a BIOS update. Some (many?) laptops with the CSC3551 amplifier chips have this information in the BIOS. Not to support Linux, but because it seems their drivers for Windows expect it to be there as well... Which leads me to believe this is probably the approach that Cirrus Logic wants to take (at least going forward). Perhaps models of laptop without this info are older. Maybe not necessarily in terms of the launch date, but design started earlier than the laptops that do have this information in their DSDT's.
(In reply to Cameron Berkenpas from comment #711) > It does not, which is unfortunate, as the 6th gen model recently finally > got support. > > The gen 7 uses the CSC3551 and the gen 7 is missing the properties in > the _DSD tables. > > Do you already have the Gen 7? No, I just have a Gen 6 and it's still working fine on a patched 5.17 kernel. > Try submitting a Lenovo support ticket > asking them to add the properties. I have a ticket they haven't follow > up on yet so I added a comment to the ticket I think less than an hour ago. I wish the kernel guys weren't so dead set against loadable DSDTs. There's still so many reasons why we need to be able to patch these ourselves and there's no good reason to have to rebuild an entire kernel just to add missing table entries. > On 10/24/22 09:55, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > --- Comment #710 from Howard Chu (hyc@highlandsun.com) --- > > Hi, I might've missed this but - do we know for certain that the 7th gen > > Legion > > 7 (2022 model) uses the same amplifier chip as the 6th gen (2021 model)? > >
https://wiki.archlinux.org/title/DSDT#Using_modified_code: We should be able to override it. From here, using early patching should allow you to specify using a quirk to support CSC3551. From there's a question of using safe values in your override. Also, you won't have suspend/resume for the support for the amp chips with the Gen 6 unless you're using a 6.1 kernel. On 11/30/22 03:40, bugzilla-daemon@kernel.org wrote: > I wish the kernel guys weren't so dead set against loadable DSDTs. There's > still so many reasons why we need to be able to patch these ourselves and > there's no good reason to have to rebuild an entire kernel just to add > missing > table entries.
Found this thread after hours of trying to fix the audio on my Legion 7 Slim, Gen 7 as well most other things work OOTB, but audio isn't working.
I think none of the Gen 7 Legions have support. Basically, all Lenovo needs to do is add some info to the ACPI _DSD tables which will allow the cs35l41 drivers to know how to configure the amp chips in our laptops. Lenovo so far has been unwilling to do this. Maybe the AMD based Gen 7 does, but I don't remember on that one. On 12/17/2022 9:06 AM, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > zacherytapp@gmail.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |zacherytapp@gmail.com > > --- Comment #726 from zacherytapp@gmail.com --- > Found this thread after hours of trying to fix the audio on my Legion 7 Slim, > Gen 7 as well most other things work OOTB, but audio isn't working. >
AMD based Gen 7 has the same problem. Here's the alsainfo: http://alsa-project.org/db/?f=fa86a2cb02044c07dee609a6decc51aaa1d02cea
New patch for Lenovo Legion 7i Gen7 (16IAX7) lenovo-7i-gen7-sound-6.2.0-rc1-0.0.3.patch posted: https://bugzilla.kernel.org/show_bug.cgi?id=216194 This is still very much a use-at-your-own-risk sort of thing... However, I have it on good word that someone who's been using this virtually everyday for the last few months has had zero problems develop so probably the hard-coded values are pretty safe for the 16IAX7.
Created attachment 303507 [details] attachment-20611-0.html I am currently out of the office on holiday I will be returning on Tuesday Janurary 3, I will be checking email perodically
(In reply to Cameron Berkenpas from comment #729) > New patch for Lenovo Legion 7i Gen7 (16IAX7) > lenovo-7i-gen7-sound-6.2.0-rc1-0.0.3.patch posted: > https://bugzilla.kernel.org/show_bug.cgi?id=216194 > > This is still very much a use-at-your-own-risk sort of thing... However, I > have it on good word that someone who's been using this virtually everyday > for the last few months has had zero problems develop so probably the > hard-coded values are pretty safe for the 16IAX7. Hi Cameron, is that patch also good for the AMD version of the Slim 7 Gen 7?
No, only the 16IAX7 is covered. You could a quirk for your laptop model... But I have to wonder how different the speakers are for a slim model, which would concern me. On 12/30/22 16:17, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #731 from Blake Lee (blake99lee@gmail.com) --- > (In reply to Cameron Berkenpas from comment #729) >> New patch for Lenovo Legion 7i Gen7 (16IAX7) >> lenovo-7i-gen7-sound-6.2.0-rc1-0.0.3.patch posted: >> https://bugzilla.kernel.org/show_bug.cgi?id=216194 >> >> This is still very much a use-at-your-own-risk sort of thing... However, I >> have it on good word that someone who's been using this virtually everyday >> for the last few months has had zero problems develop so probably the >> hard-coded values are pretty safe for the 16IAX7. > Hi Cameron, is that patch also good for the AMD version of the Slim 7 Gen 7? >
Yoga 9 14IAP7; Fedora FC37, 6.0.15-300.fc37.x86_64 Kernel FYI still need the "options snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin" or I get no bass & low volume. A new issue. If I use the option above, internal sound works. If I then use the headphone jack, the headphones work as expected. Upon removing the headphone jack, the internal speakers revert to no bass & low volume.
Does anyone know if this patch (or any other available patch) does work for the Legion Slim 7i Gen 7 (16IAH7)? I'm completely new to patching a kernel and stuff so any help would be very much appreciated, thanks :) (In reply to Cameron Berkenpas from comment #729) > New patch for Lenovo Legion 7i Gen7 (16IAX7) > lenovo-7i-gen7-sound-6.2.0-rc1-0.0.3.patch posted: > https://bugzilla.kernel.org/show_bug.cgi?id=216194 > > This is still very much a use-at-your-own-risk sort of thing... However, I > have it on good word that someone who's been using this virtually everyday > for the last few months has had zero problems develop so probably the > hard-coded values are pretty safe for the 16IAX7.
I wanted to report a similar issue on Lenovo Legion 7 Slim AMD. Onboard speakers do not seem to produce sound but in settings menu sound appears to be getting produced on the speakers. Headphones work fine. Thankfully I primarily use headphones but wanted to report the issue.
I own a Lenovo Legion Slim 7 Intel 16IAH7 with the same issue (no speaker sound but headphones ok). Alsa-info for this particular machine can be found here: http://www.alsa-project.org/db/?f=9f1deb511b2604f1b52a7905889deb4463ca9211. Would these alsa-info be enough for someone to create a patch for this model? If not, I'm ok to spend some time on the issue. I have no particular knowledge on how fixups are implemented but patching and compiling the kernel is not an issue. Probably I can take example on existing fixups to implement a new one. If so, some pointer on documentation or resource on where to start would be much appreciated.
For details around why this doesn't work as well as a use at your own risk patch (which SO FAR has proven safe), look here: https://bugzilla.kernel.org/show_bug.cgi?id=216194 The short short version is that Lenovo has zero interest in adding entries in a BIOS update that would allow sound to work out of the box. On 2/27/23 07:12, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Pierre Hébert (pierrox@pierrox.net) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |pierrox@pierrox.net > > --- Comment #736 from Pierre Hébert (pierrox@pierrox.net) --- > I own a Lenovo Legion Slim 7 Intel 16IAH7 with the same issue (no speaker > sound > but headphones ok). > > Alsa-info for this particular machine can be found here: > http://www.alsa-project.org/db/?f=9f1deb511b2604f1b52a7905889deb4463ca9211. > > Would these alsa-info be enough for someone to create a patch for this model? > If not, I'm ok to spend some time on the issue. I have no particular > knowledge > on how fixups are implemented but patching and compiling the kernel is not an > issue. Probably I can take example on existing fixups to implement a new one. > If so, some pointer on documentation or resource on where to start would be > much appreciated. >
Thank you very much for the link! I missed this other discussion. It doesn't work yet with my current 6.1.12 kernel (although the patch applies quite nicely) but I'll give it a try soon.
(In reply to Cameron Berkenpas from comment #737) With Linux 6.2.1, I get the same error "Serial bus multi instantiate pseudo device driver CSC3551:00: error -ENOENT: Error requesting irq at index 0". I guess your patch is not reached at all then. If I understand correctly, this is somewhat unrelated to this original bug, maybe I should look further around CS35L41 and/or serial multi-instantiate driver?
As the 6.1.x kernel worked, likely something else isn't quite right. Are you sure you're running your patched kernel? Which patch did you apply? On 2/28/23 06:00, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #739 from Pierre Hébert (pierrox@pierrox.net) --- > (In reply to Cameron Berkenpas from comment #737) > > With Linux 6.2.1, I get the same error "Serial bus multi instantiate pseudo > device driver CSC3551:00: error -ENOENT: Error requesting irq at index 0". I > guess your patch is not reached at all then. > > If I understand correctly, this is somewhat unrelated to this original bug, > maybe I should look further around CS35L41 and/or serial multi-instantiate > driver? >
I'm not too sure that this worked for the slim variant of the legion 7 gen 7, or at least jmaximusix, who uses a slim 7 too, doesn't seem to have it working neither (https://bugzilla.kernel.org/show_bug.cgi?id=216194#c49). Also I get the very same error message regarding CSC3551 (where the serial multi-instanciate driver fails to get an irq in smi_i2c_probe). I applied lenovo-7i-gen7-sound-6.2.0-rc3-0.0.4.patch and I have no doubt that the path is active in the currently running kernel. Unfortunately this is the only thing I know for sure, I'm sorry to be quite ignorant in most other areas regarding sound and amplifiers in Linux :-/
You have the slim? I don't think I added slim support to the patch. I think someone else did and it worked. It's not that hard to do. The numeric ID you need can be found in your alsa-info.
(In reply to Cameron Berkenpas from comment #742) > You have the slim? I don't think I added slim support to the patch. I think > someone else did and it worked. > > It's not that hard to do. The numeric ID you need can be found in your > alsa-info. Hi Cameron, I'm trying to get my Legion Slim 7 Gen 7 AMD version working... How do I modify the patch, or are you planning to? My alsa-info is below.. http://alsa-project.org/db/?f=3c10f6ee9607eabbc8f783505b7b29c87b7d0cca Thank you for being so helpful to everyone, this is a great computer I'm just sick of using headphones lol
Created attachment 303815 [details] attachment-24448-0.html Uploaded lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b.patch to https://bugzilla.kernel.org/show_bug.cgi?id=216194 Although I forgot to update it in the patch name... This patch is against 6.2.1 I put a disclaimer that this is a use-at-your-own-risk as the missing settings were guessed for the full-sized Legion 7i, and it appears the the Legion 7i has been working without issue since August or so without any serious issues developing. The previous patch includes 7i Slim support and it seems this has been working for some people... If you've been using my patches for the 7i Slim, I would like to hear if things are still working for you without issue. With that feedback other 7i Slim users will be able to make an informed decision on the use of these patches. This updated patch adds support for the Slim 7 (AMD version). Same thing stands. If there are serious issues such as perhaps loudness, distorted sound, "amp short" messages in dmesg (when this happens the affected speaker will no longer output sound), etc, I suggest to stop using the patch to avoid the possibility of permanent damage (as well as following up with your issues). Since the 1-2 reports I saw that it seemed to work okay for the Slim 7i, I suspect it will for the AMD based Slim 7 as well, but I can't make any guarantees. And finally... I did work on overriding the ACPI DSD table to get sound working months back... While I did have some initial success, I was running into "AMP short" issues. My patch was originally based on an older version of the cs35l41 support and so it actually ends up bypassing some of the code paths used in the current CS35l41 driver. If I change the driver to go through that newer path, it has approximately the same problems that using a DSD override does. So it seems my patch works because it's "cheating" somehow due to historical reasons... Probably the info I use in the DSD override is very slightly off from what's needed, but if the issues could be ironed out... We'd have a solution that didn't require patching the kernel. However, we'd still be left with the problem of determining safe values and the values are (more or less) going to be specific to your model of laptop. This is why it's so frustrating that Lenovo won't add this info in a BIOS update where as my understanding is that Asus has, in at least a few cases, added these DSD entires in BIOS updates to get sound working under Linux. As I no longer require my laptop to specifically have a more professional Lenovo look, my next laptop will likely be Asus. Like many of you, Linux is my daily driver (and has been since the late 90's in my case). But being able to boot to Windows to play games with advanced optimus, some mild HDR support, etc... has been really great. Anyway, looking forward to the feedback. On 2/28/23 11:56, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #743 from Blake Lee (blake99lee@gmail.com) --- > (In reply to Cameron Berkenpas from comment #742) >> You have the slim? I don't think I added slim support to the patch. I think >> someone else did and it worked. >> >> It's not that hard to do. The numeric ID you need can be found in your >> alsa-info. > Hi Cameron, I'm trying to get my Legion Slim 7 Gen 7 AMD version working... > How > do I modify the patch, or are you planning to? My alsa-info is below.. > > http://alsa-project.org/db/?f=3c10f6ee9607eabbc8f783505b7b29c87b7d0cca > > Thank you for being so helpful to everyone, this is a great computer I'm just > sick of using headphones lol >
Yes, I confirm that the patch includes the slim 7 in the list of fixups, with the right "16IAH7" model number and right numeric id: 0x17aa:0x3803 (same as my alsa-info), so I thought there was some success for this computer. But rewinding the discussion to the top in this thread and the other one (https://bugzilla.kernel.org/show_bug.cgi?id=216194) doesn't show any evidence of success for the "slim" variant. Or maybe I missed it? I noticed that the clear text name for the entry in the patch is named "Legion 7" not "Legion S7". Maybe there's some mismatch here? I mean: could the slim references have been used in place of another model, maybe another 7 variant? Lenovo's naming scheme is confusing: there's the 7, the 7i, the 7 Pro and the S7 which is either named S7 (without "i" no matter Intel or AMD) or Slim 7 (only AMD) or Slim 7i (only Intel). I understand the issue with DSD and why it's frustrating. This isn't by far the first frustration I get with this kind of issue... But fortunately these little issues are more than balanced by the benefits of running Linux :-) Using 6.2.1 on my slim 7i (16IAH7), the cs35l41 driver fails to load. If my understanding is correct, this will prevent code in the patch to be executed, even if some code paths in cs35l41 are bypassed by the patch, right? Please correct me if I'm wrong, as really I'm a newbie in this area. I'm 100% sure that the patch is applied though, but I don't see the related printk in the kernel log (in particular there is no "CSC3551: probing"). What I am trying to understand is whether this is because of the cs35l41 error, and in which case I should look into this issue first, or whether this is due to another problem. While unloading and reloading cs35l41 modules (snd_hda_scodec_cs35l41_i2c snd_hda_scodec_cs35l41_spi snd_hda_scodec_cs35l41 snd_soc_cs35l41_lib snd_hda_cs_dsp_ctls cs_dsp), there's no indication of the driver being initialized again in kernel logs, so my guess is that this is triggered by another sound module. Would you have any hint on a what should be done to unload/reload the sound subsystem and avoid reboot between each code modification/build? Thank you so far for the help and the patches. Even if I cannot ever hear sound from the speakers (and I can perfectly live with this), your work is really appreciated! (In reply to Cameron Berkenpas from comment #742) > You have the slim? I don't think I added slim support to the patch. I think > someone else did and it worked. > > It's not that hard to do. The numeric ID you need can be found in your > alsa-info.
The name doesn't matter, just the numeric ID. If I had a patch worth submitting, I would fix the names but otherwise they don't matter. Please share the following outputs with me: uname -a And mostly I need this: dmesg | egrep -i '(csc3551|cs35l41|reset_gpio|short|adev|speaker)' On 2/28/23 23:47, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #745 from Pierre Hébert (pierrox@pierrox.net) --- > Yes, I confirm that the patch includes the slim 7 in the list of fixups, with > the right "16IAH7" model number and right numeric id: 0x17aa:0x3803 (same as > my > alsa-info), so I thought there was some success for this computer. But > rewinding the discussion to the top in this thread and the other one > (https://bugzilla.kernel.org/show_bug.cgi?id=216194) doesn't show any > evidence > of success for the "slim" variant. Or maybe I missed it? > I noticed that the clear text name for the entry in the patch is named > "Legion > 7" not "Legion S7". Maybe there's some mismatch here? I mean: could the slim > references have been used in place of another model, maybe another 7 variant? > Lenovo's naming scheme is confusing: there's the 7, the 7i, the 7 Pro and the > S7 which is either named S7 (without "i" no matter Intel or AMD) or Slim 7 > (only AMD) or Slim 7i (only Intel). > > I understand the issue with DSD and why it's frustrating. This isn't by far > the > first frustration I get with this kind of issue... But fortunately these > little > issues are more than balanced by the benefits of running Linux :-) > > Using 6.2.1 on my slim 7i (16IAH7), the cs35l41 driver fails to load. If my > understanding is correct, this will prevent code in the patch to be executed, > even if some code paths in cs35l41 are bypassed by the patch, right? Please > correct me if I'm wrong, as really I'm a newbie in this area. > > I'm 100% sure that the patch is applied though, but I don't see the related > printk in the kernel log (in particular there is no "CSC3551: probing"). What > I > am trying to understand is whether this is because of the cs35l41 error, and > in > which case I should look into this issue first, or whether this is due to > another problem. > > While unloading and reloading cs35l41 modules (snd_hda_scodec_cs35l41_i2c > snd_hda_scodec_cs35l41_spi snd_hda_scodec_cs35l41 snd_soc_cs35l41_lib > snd_hda_cs_dsp_ctls cs_dsp), there's no indication of the driver being > initialized again in kernel logs, so my guess is that this is triggered by > another sound module. Would you have any hint on a what should be done to > unload/reload the sound subsystem and avoid reboot between each code > modification/build? > > Thank you so far for the help and the patches. Even if I cannot ever hear > sound > from the speakers (and I can perfectly live with this), your work is really > appreciated! > > > (In reply to Cameron Berkenpas from comment #742) >> You have the slim? I don't think I added slim support to the patch. I think >> someone else did and it worked. >> >> It's not that hard to do. The numeric ID you need can be found in your >> alsa-info.
Hello Cameron. Do you think this patch for Slim 7 AMD versions be viable for Yoga Slim 7 Carbon 14ACN6 as well? Subsystem Id: 0x17aa3856 http://alsa-project.org/db/?f=256bbaf062611cf8f537a377104273142f99d2f1 https://psref.lenovo.com/Detail/Yoga/Yoga_Slim_7_Carbon_14ACN6?M=82L0005RMX
(In reply to Pierre Hébert from comment #741) > I'm not too sure that this worked for the slim variant of the legion 7 gen > 7, or at least jmaximusix, who uses a slim 7 too, doesn't seem to have it > working neither (https://bugzilla.kernel.org/show_bug.cgi?id=216194#c49). > Also I get the very same error message regarding CSC3551 (where the serial > multi-instanciate driver fails to get an irq in smi_i2c_probe). > > I applied lenovo-7i-gen7-sound-6.2.0-rc3-0.0.4.patch and I have no doubt > that the path is active in the currently running kernel. Unfortunately this > is the only thing I know for sure, I'm sorry to be quite ignorant in most > other areas regarding sound and amplifiers in Linux :-/ Yes exactly, I have the same laptop and the same issue. If you find any solution, be sure to let me know, and so will I! :D I think I might be able to clear up some confusion around a patch existing or not. Cameron Berkenpas did try to add support for the Slim 7i using some logs I provided, but that didn't turn out fixing the csc3551 error. So thats why, I think, in his patch, the Slim 7i model (16IAH7) is listed, but it's not working, at least I am unaware of any success anybody had with it. I have more or less given up on this for now, because at least with my (nonexistent) knowledge of this stuff, I don't see anything in my power I can do. But if anybody has ideas what to try or where to look, I'll happily try it out.
See https://bugzilla.kernel.org/show_bug.cgi?id=216194 for a new patch. Currently the latest is lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch This latest patch theoretically has support for Blake Lee's machine. A new revision of the 16IAX7. oppsig's Yoga Slim 7 Carbon 14ACN6 Pierre Hébert, I missed that you were getting this error previous: "Serial bus multi instantiate pseudo device driver CSC3551:00: error -ENOENT: Error requesting irq at index 0" That is indeed occurring before any of my code. Some hopefully good news is that this is a Cirrus Logic issue that they might fix if you can report it to them. Once fixed, you'd probably still need a patch such as mine to get you over the finish line. PLEASE READ MY COMMENT HERE AS THIS PATCH IS USE AT-YOUR-OWN-RISK: https://bugzilla.kernel.org/show_bug.cgi?id=216194#c66 From here on out, I will direct people to bug https://bugzilla.kernel.org/show_bug.cgi?id=216194 as there's far too many posts in this thread and it's made things difficult to keep track of.
(In reply to Cameron Berkenpas from comment #746) > Please share the following outputs with me: > uname -a Linux shin 6.2.1-arch1-1-custom #1 SMP PREEMPT_DYNAMIC Tue, 28 Feb 2023 09:19:31 +0000 x86_64 GNU/Linux > And mostly I need this: > dmesg | egrep -i '(csc3551|cs35l41|reset_gpio|short|adev|speaker)' [ 8.047665] Serial bus multi instantiate pseudo device driver CSC3551:00: error -ENOENT: Error requesting irq at index 0 [ 8.052566] Serial bus multi instantiate pseudo device driver: probe of CSC3551:00 failed with error -2 [ 8.331024] input: PC Speaker as /devices/platform/pcspkr/input/input5 [ 11.421129] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker [ 11.421138] snd_hda_codec_realtek ehdaudio0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) I'll ask Cirrus developers about the issue. Agreed, this thread is too long.
Hey Cameron, I did apply the patch against kernel 6.2.2 for the 14ACN6. There was sound from the 2 tweeters as before the patch was applied but still I don't know if the 2 woofers are actually active? Not sure what the best way to find out if woofers are working. Is there anything I can do with speaker-test? But I'll try to compare before and after patch. I was going to try to sniff the verbs for this laptop but the problem is that the audio controllers are on the same IOMMU groups as radeon gpu, pci, usb and psp. So I cannot not passthrough the audio devices without ACL override. Uname -a Linux 6.2.2-273-tkg-cfs #1 SMP PREEMPT_DYNAMIC TKG Sat, 04 Mar 2023 08:30:30 +0000 x86_64 GNU/Linux Alsa info: http://alsa-project.org/db/?f=f1d466ea0cfa556f461b73a529bba4a66d634725 Dmesg: ❯ sudo dmesg | grep -E '(csc3551|cs35l41|reset_gpio|short|adev|speaker)' [ 0.654315] IPI shorthand broadcast: enabled [ 19.026160] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC287: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 19.026199] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 23.866865] wlan0: VHT capa missing/short, disabling VHT/HE/EHT [ 200.121348] wlan0: VHT capa missing/short, disabling VHT/HE/EHT [ 271.290659] wlan0: VHT capa missing/short, disabling VHT/HE/EHT bugid for this laptop: https://bugzilla.kernel.org/show_bug.cgi?id=215632
Looking more closely at your alsa-info... You have: /sys/bus/acpi/devices/CLSA0102:00/status I didn't even know the CLSA0102 existed! Just the CLSA0100 and the CLSA0101. I don't think that's supported at all at this point. You might try reaching out to Cirrus Logic. I think that's your best bet. There's certainly nothing I can do. Sounds like the CLSA0102 's are strictly for your the woofers? CLSA0102 is almost certainly going to fall under cs35l41 and like the CLSA010/1, it would likely need a custom code path. Really wish Lenovo would play more nice with us. Yes, they have Linux specific offerings, but like most of you, I'm not interested in those. And in case anyone from Lenovo is listening... I'm not personally interested in getting ANY Lenovo support for Linux. I just want my hardware to work. On 3/4/23 03:39, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #751 from oppsig (toggiworks@gmail.com) --- > Hey Cameron, I did apply the patch against kernel 6.2.2 for the 14ACN6. > There was sound from the 2 tweeters as before the patch was applied but still > I > don't know if the 2 woofers are actually active? > Not sure what the best way to find out if woofers are working. > Is there anything I can do with speaker-test? > But I'll try to compare before and after patch. > > I was going to try to sniff the verbs for this laptop but the problem is that > the audio controllers are on the same IOMMU groups as radeon gpu, pci, usb > and > psp. > So I cannot not passthrough the audio devices without ACL override. > > Uname -a > Linux 6.2.2-273-tkg-cfs #1 SMP PREEMPT_DYNAMIC TKG Sat, 04 Mar 2023 08:30:30 > +0000 x86_64 GNU/Linux > > Alsa info: > http://alsa-project.org/db/?f=f1d466ea0cfa556f461b73a529bba4a66d634725 > > Dmesg: > ❯ sudo dmesg | grep -E '(csc3551|cs35l41|reset_gpio|short|adev|speaker)' > [ 0.654315] IPI shorthand broadcast: enabled > [ 19.026160] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC287: > line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker > [ 19.026199] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=0 > (0x0/0x0/0x0/0x0/0x0) > [ 23.866865] wlan0: VHT capa missing/short, disabling VHT/HE/EHT > [ 200.121348] wlan0: VHT capa missing/short, disabling VHT/HE/EHT > [ 271.290659] wlan0: VHT capa missing/short, disabling VHT/HE/EHT > > bugid for this laptop: > https://bugzilla.kernel.org/show_bug.cgi?id=215632 >
Hey again, sorry I just now noticed this: on my 2021 Legion 7 16ACHg6, the sound from the left speaker is much quieter than from the right speaker. Is there anything I can tweak to adjust this?
One last note - playing a particular video clip (Star Trek Strange New Worlds S01E10), the opening splash sequence, the maximum loudness in Linux was only 65dB, and 78dB in Windows. Volume control set to 100% in both cases, identical video file.
Here's a thread where people are expressing their dissatisfaction with Lenovo's support of Linux on their Legion series laptops. Maybe if enough people chime in, they'll take us seriously and we'll get somewhere. I personally don't need/want formalized Linux support... I just want the hardware to work: https://forums.lenovo.com/t5/Ubuntu/Ubuntu-and-legion-pro-7-16IRX8H-audio-issues/m-p/5210709
On my Legion Slim 7 Gen 7 16ARHA7 Same issue on Debian 12 Testing on Kernel 6.1.0-7 if this is a kernel issue, i hope it gets fixed soon and the distro maintainers can patch this sooner rather than later. Heres my audio info dump: root@Lavavex-Legion:~# aplay --list-devices **** List of PLAYBACK Hardware Devices **** card 1: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: HDMI [HDA ATI HDMI], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: Generic_1 [HD-Audio Generic], device 0: ALC287 Analog [ALC287 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 root@Lavavex-Legion:~# ls /dev/snd -al total 0 drwxr-xr-x 3 root root 360 Apr 10 22:23 . drwxr-xr-x 19 root root 3800 Apr 10 22:23 .. drwxr-xr-x 2 root root 120 Apr 10 22:23 by-path crw-rw----+ 1 root audio 116, 3 Apr 10 22:23 controlC0 crw-rw----+ 1 root audio 116, 9 Apr 10 22:23 controlC1 crw-rw----+ 1 root audio 116, 10 Apr 10 22:23 controlC2 crw-rw----+ 1 root audio 116, 14 Apr 10 22:23 controlC3 crw-rw----+ 1 root audio 116, 6 Apr 10 22:23 hwC1D0 crw-rw----+ 1 root audio 116, 8 Apr 10 22:23 hwC2D0 crw-rw----+ 1 root audio 116, 13 Apr 10 22:23 hwC3D0 crw-rw----+ 1 root audio 116, 2 Apr 10 22:23 pcmC0D0c crw-rw----+ 1 root audio 116, 4 Apr 10 22:23 pcmC1D3p crw-rw----+ 1 root audio 116, 5 Apr 10 22:23 pcmC1D7p crw-rw----+ 1 root audio 116, 7 Apr 10 22:23 pcmC2D3p crw-rw----+ 1 root audio 116, 12 Apr 10 22:23 pcmC3D0c crw-rw----+ 1 root audio 116, 11 Apr 10 22:31 pcmC3D0p crw-rw----+ 1 root audio 116, 1 Apr 10 22:23 seq crw-rw----+ 1 root audio 116, 33 Apr 10 22:23 timer root@Lavavex-Legion:~# cat /proc/asound/pcm 00-00: DMIC capture dmic-hifi-0 : : capture 1 01-03: HDMI 0 : HDMI 0 : playback 1 01-07: HDMI 1 : HDMI 1 : playback 1 02-03: HDMI 0 : HDMI 0 : playback 1 03-00: ALC287 Analog : ALC287 Analog : playback 1 : capture 1 root@Lavavex-Legion:~# cat /proc/asound/cards 0 [acp6x ]: acp6x - acp6x LENOVO-82UG-LegionS716ARHA7-LNVNB161216 1 [HDMI ]: HDA-Intel - HDA ATI HDMI HDA ATI HDMI at 0xc0b00000 irq 79 2 [Generic ]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xc06c8000 irq 80 3 [Generic_1 ]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xc06c0000 irq 81
(In reply to admin from comment #756) > On my Legion Slim 7 Gen 7 16ARHA7 Same issue on Debian 12 Testing on Kernel > 6.1.0-7 > if this is a kernel issue, i hope it gets fixed soon and the distro > maintainers can patch this sooner rather than later. Heres my audio info > dump: > > > root@Lavavex-Legion:~# aplay --list-devices > **** List of PLAYBACK Hardware Devices **** > card 1: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 1: HDMI [HDA ATI HDMI], device 7: HDMI 1 [HDMI 1] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 2: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 3: Generic_1 [HD-Audio Generic], device 0: ALC287 Analog [ALC287 Analog] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > > root@Lavavex-Legion:~# ls /dev/snd -al > total 0 > drwxr-xr-x 3 root root 360 Apr 10 22:23 . > drwxr-xr-x 19 root root 3800 Apr 10 22:23 .. > drwxr-xr-x 2 root root 120 Apr 10 22:23 by-path > crw-rw----+ 1 root audio 116, 3 Apr 10 22:23 controlC0 > crw-rw----+ 1 root audio 116, 9 Apr 10 22:23 controlC1 > crw-rw----+ 1 root audio 116, 10 Apr 10 22:23 controlC2 > crw-rw----+ 1 root audio 116, 14 Apr 10 22:23 controlC3 > crw-rw----+ 1 root audio 116, 6 Apr 10 22:23 hwC1D0 > crw-rw----+ 1 root audio 116, 8 Apr 10 22:23 hwC2D0 > crw-rw----+ 1 root audio 116, 13 Apr 10 22:23 hwC3D0 > crw-rw----+ 1 root audio 116, 2 Apr 10 22:23 pcmC0D0c > crw-rw----+ 1 root audio 116, 4 Apr 10 22:23 pcmC1D3p > crw-rw----+ 1 root audio 116, 5 Apr 10 22:23 pcmC1D7p > crw-rw----+ 1 root audio 116, 7 Apr 10 22:23 pcmC2D3p > crw-rw----+ 1 root audio 116, 12 Apr 10 22:23 pcmC3D0c > crw-rw----+ 1 root audio 116, 11 Apr 10 22:31 pcmC3D0p > crw-rw----+ 1 root audio 116, 1 Apr 10 22:23 seq > crw-rw----+ 1 root audio 116, 33 Apr 10 22:23 timer > > root@Lavavex-Legion:~# cat /proc/asound/pcm > 00-00: DMIC capture dmic-hifi-0 : : capture 1 > 01-03: HDMI 0 : HDMI 0 : playback 1 > 01-07: HDMI 1 : HDMI 1 : playback 1 > 02-03: HDMI 0 : HDMI 0 : playback 1 > 03-00: ALC287 Analog : ALC287 Analog : playback 1 : capture 1 > > root@Lavavex-Legion:~# cat /proc/asound/cards > 0 [acp6x ]: acp6x - acp6x > LENOVO-82UG-LegionS716ARHA7-LNVNB161216 > 1 [HDMI ]: HDA-Intel - HDA ATI HDMI > HDA ATI HDMI at 0xc0b00000 irq 79 > 2 [Generic ]: HDA-Intel - HD-Audio Generic > HD-Audio Generic at 0xc06c8000 irq 80 > 3 [Generic_1 ]: HDA-Intel - HD-Audio Generic > HD-Audio Generic at 0xc06c0000 irq 81 I have the same laptop model (Legion Slim 7 Gen 7 16ARHA7) and I have the same issue and audio info dump, posting a reply to let the world know I have the same issue. It's a really great laptop that works amazing with the newer kernels, except for this one thing! Sound even works when connected to 3.5mm or a USB sound device. It's just the built-in speakers.
My Yoga 9 14IAP7 was working well since post #733 above. However I recently booted from kernel kernel-6.2.8-200.fc37.x86_64 to 6.2.14-200.fc37.x86_64 and I get no sound.
Please ignore Comment 758. alsaunmute solved the issue, and was (oddly) only required once.
Hi, I have a thinkbook 16p Gen4 using archlinux with 6.3.1 kernel. The sound only works on 2 out of the 4 speakers (No bass, low volume). Accoding to https://psref.lenovo.com/Product/ThinkBook/ThinkBook_16p_G4_IRH, the audio chip is ACL3306-CG. I wonder if this is the same chip as the ACL3306, or it will require another driver? Also, I wonder if my problem is caused by the audio chip or the smart amplifier?
Created attachment 304265 [details] journalctl on a 83BU Yoga Pro 9 14IRP8
(In reply to Thomas Gfeller from comment #761) > Created attachment 304265 [details] > journalctl on a 83BU Yoga Pro 9 14IRP8 I have the same issue on a 83BU Yoga Pro 9 14IRP8. I can see some lines that look suspicious in the logs: skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not yet available, widget card binding deferred I'm running Fedora 38 with 6.2.15-300.fc38.x86_64.
I do have exactly the same issue on a ThinkBook 13x Gen 2 running Ubuntu 23.04 (kernels 6.2.0 and 6.3.3): no sound from the internal speakers, although sound works when using the external 3.5mm jack. The laptop has the same chips: ALC287/3306 codec and CS35L41/CSC3551 amplifier. journalctl displays the following message: "Error: ACPI _DSD Properties are missing for HID CSC3551" I have extracted the DST tables using ACPICA and did not see any reference to the 2 parameters required by the CS35L41 driver: "cirrus" and "dev-index". My conclusion is there is probably some work required from the Lenovo BIOS team :(
Created attachment 304296 [details] attachment-15426-0.html I am currently out of the office on holiday I will be returning on Tuesday May 30, I will be checking email perodically but expect a delay for response.
Alas, you are correct. The good news is that this is being worked on for the Legion... But it seems to be for the latest model of the Legion (which does haven't Cirrus Logic, it has TI smart amps IIRC). I have the 2nd to latest (which I think came out less than a year ago). Hopefully from there they can work on my model... And perhaps Lenovo can begin to branch out from there. It's really too early to guess where things will go, but I'm hopeful. On 5/20/23 5:01 PM, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Alexis Cuglietta (alexis.cuglietta@gmail.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |alexis.cuglietta@gmail.com > > --- Comment #763 from Alexis Cuglietta (alexis.cuglietta@gmail.com) --- > I do have exactly the same issue on a ThinkBook 13x Gen 2 running Ubuntu > 23.04 > (kernels 6.2.0 and 6.3.3): no sound from the internal speakers, although > sound > works when using the external 3.5mm jack. The laptop has the same chips: > ALC287/3306 codec and CS35L41/CSC3551 amplifier. > > journalctl displays the following message: > "Error: ACPI _DSD Properties are missing for HID CSC3551" > > I have extracted the DST tables using ACPICA and did not see any reference to > the 2 parameters required by the CS35L41 driver: "cirrus" and "dev-index". > > My conclusion is there is probably some work required from the Lenovo BIOS > team > :( >
(In reply to Cameron Berkenpas from comment #765) > Alas, you are correct. The good news is that this is being worked on for > the Legion... But it seems to be for the latest model of the Legion > (which does haven't Cirrus Logic, it has TI smart amps IIRC). I have the > 2nd to latest (which I think came out less than a year ago). > > Hopefully from there they can work on my model... And perhaps Lenovo can > begin to branch out from there. > > It's really too early to guess where things will go, but I'm hopeful. > > > On 5/20/23 5:01 PM, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > Alexis Cuglietta (alexis.cuglietta@gmail.com) changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > CC| > |alexis.cuglietta@gmail.com > > > > --- Comment #763 from Alexis Cuglietta (alexis.cuglietta@gmail.com) --- > > I do have exactly the same issue on a ThinkBook 13x Gen 2 running Ubuntu > > 23.04 > > (kernels 6.2.0 and 6.3.3): no sound from the internal speakers, although > > sound > > works when using the external 3.5mm jack. The laptop has the same chips: > > ALC287/3306 codec and CS35L41/CSC3551 amplifier. > > > > journalctl displays the following message: > > "Error: ACPI _DSD Properties are missing for HID CSC3551" > > > > I have extracted the DST tables using ACPICA and did not see any reference > to > > the 2 parameters required by the CS35L41 driver: "cirrus" and "dev-index". > > > > My conclusion is there is probably some work required from the Lenovo BIOS > > team > > :( > > I just found https://superuser.com/questions/1719920/no-sound-from-internal-speakers-on-laptop-but-headphone-jack-and-hdmi-works with the link https://gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff It sounds very much like this problem right here. Can we build a workaround for our machines? Extracting the respective data from Windows and injecting it into our Linux istallations?
I haven't been able to get this working properly. I was able to get sound with this approach a few months ago, but I was getting "AMP short" errors, which I'm sure can't be good. On 6/5/23 06:45, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #766 from Thomas Gfeller (thomas.gfeller+kernel@q-drop.com) --- > (In reply to Cameron Berkenpas from comment #765) >> Alas, you are correct. The good news is that this is being worked on for >> the Legion... But it seems to be for the latest model of the Legion >> (which does haven't Cirrus Logic, it has TI smart amps IIRC). I have the >> 2nd to latest (which I think came out less than a year ago). >> >> Hopefully from there they can work on my model... And perhaps Lenovo can >> begin to branch out from there. >> >> It's really too early to guess where things will go, but I'm hopeful. >> >> >> On 5/20/23 5:01 PM, bugzilla-daemon@kernel.org wrote: >>> https://bugzilla.kernel.org/show_bug.cgi?id=208555 >>> >>> Alexis Cuglietta (alexis.cuglietta@gmail.com) changed: >>> >>> What |Removed |Added >>> >> ---------------------------------------------------------------------------- >>> CC| >> |alexis.cuglietta@gmail.com >>> --- Comment #763 from Alexis Cuglietta (alexis.cuglietta@gmail.com) --- >>> I do have exactly the same issue on a ThinkBook 13x Gen 2 running Ubuntu >>> 23.04 >>> (kernels 6.2.0 and 6.3.3): no sound from the internal speakers, although >>> sound >>> works when using the external 3.5mm jack. The laptop has the same chips: >>> ALC287/3306 codec and CS35L41/CSC3551 amplifier. >>> >>> journalctl displays the following message: >>> "Error: ACPI _DSD Properties are missing for HID CSC3551" >>> >>> I have extracted the DST tables using ACPICA and did not see any reference >> to >>> the 2 parameters required by the CS35L41 driver: "cirrus" and "dev-index". >>> >>> My conclusion is there is probably some work required from the Lenovo BIOS >>> team >>> :( >>> > I just found > > https://superuser.com/questions/1719920/no-sound-from-internal-speakers-on-laptop-but-headphone-jack-and-hdmi-works > with the link > https://gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff > > It sounds very much like this problem right here. Can we build a workaround > for > our machines? Extracting the respective data from Windows and injecting it > into > our Linux istallations? >
Hello guys, have you seen this? https://forums.lenovo.com/topic/findpost/2713/5210709/6004369?random=nZpbsgdmR0RbJdDLI7lLW8H0NabNneIv_1e738b0f207dd4082957db2fd078d035 Apparently there was some progress on the lenovo forum, they marked it as a solution so I decided to send the link here. I hope it helps
I have the Legion S7 16ARHA7 w/ Cirrus amp. I've been patching the kernel using lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch with working sound. However, I'm not able to hibernate my laptop successfully. It will hang after saving to disk but it won't shut off on it's own - just stays on with a black screen with the fan going. Then it drains the battery until it dies. If I turn it on again, it will successfully resume from hibernation. I'm not sure what is causing it. It works find if nothing is open (just gnome-shell), but as soon as I open firefox or chrome the problem recurs if it goes to hibernate. Did anyone else have the same issue?
This is probably the same as an Nvidia driver issue that I've had... Or similar... I had the same issue with the Gen 6, and gave up hibernating completely with the gen7/8. I could hibernate & resume 1-2 times, and then when resuming... the laptop would hang, eventually my desktop session would crash and I'd get the login screen. When not using the Nvidia GPU at all, it worked consistently. This is the error I'd see in dmesg: [ 14.045062] nvidia 0000:01:00.0: PM: failed to quiesce async: error - Seems you can't even shutdown... I don't remember if I encountered that problem. Try uninstalling the Nvidia drivers or blacklisting the nvidia module and see if it still occurs. On 7/12/23 16:24, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #769 from antidense@gmail.com --- > I have the Legion S7 16ARHA7 w/ Cirrus amp. I've been patching the kernel > using > lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch with working sound. However, > I'm not able to hibernate my laptop successfully. It will hang after saving > to > disk but it won't shut off on it's own - just stays on with a black screen > with > the fan going. Then it drains the battery until it dies. If I turn it on > again, > it will successfully resume from hibernation. I'm not sure what is causing > it. > It works find if nothing is open (just gnome-shell), but as soon as I open > firefox or chrome the problem recurs if it goes to hibernate. Did anyone else > have the same issue? >
Thank you for the info. I have AMD graphics, but might still be the same issue. When I look at the dmesg I only see mt7921e errors. I tried unloading the wifi driver but it didn't make a difference.
(In reply to antidense from comment #769) > I have the Legion S7 16ARHA7 w/ Cirrus amp. I've been patching the kernel > using lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch with working sound. > However, I'm not able to hibernate my laptop successfully. It will hang > after saving to disk but it won't shut off on it's own - just stays on with > a black screen with the fan going. Then it drains the battery until it dies. > If I turn it on again, it will successfully resume from hibernation. I'm not > sure what is causing it. It works find if nothing is open (just > gnome-shell), but as soon as I open firefox or chrome the problem recurs if > it goes to hibernate. Did anyone else have the same issue? So, this patch can solve the sound problem, right? Enlighten me pls, I would sacrifice everything to hear my laptop.
Depends on which laptop you have. It will work if you have the Legion 7i Gen 7, but not for the Gen 8 (but there is work to get the Gen 8 working that will be mainlined). Share a link to your alsa-info. (In reply to Linghui Ding from comment #773) > So, this patch can solve the sound problem, right? Enlighten me pls, I would > sacrifice everything to hear my laptop.
(In reply to Cameron Berkenpas from comment #774) > Depends on which laptop you have. It will work if you have the Legion 7i Gen > 7, but not for the Gen 8 (but there is work to get the Gen 8 working that > will be mainlined). > > Share a link to your alsa-info. > > (In reply to Linghui Ding from comment #773) > > > So, this patch can solve the sound problem, right? Enlighten me pls, I > would > > sacrifice everything to hear my laptop. Here is the URL: http://alsa-project.org/db/?f=1ea099cf4369c1547b45eec8f9fefdc2f7cfd892 Thanks a lot, and do you think kernel 6.5.0 will include a method that would solve this sound problem?
Is there any update on the AMD model of the Legion 7 Gen 7? My understanding is it's a different device - but curious if progress has been made there?
Then sounds like your laptop is supported by my patch: https://bugzilla.kernel.org/show_bug.cgi?id=216194 This patch will never make it into the kernel. But if you are able to apply the patch and build your own kernel... This will get you sound. (In reply to Linghui Ding from comment #775) > Here is the URL: > > > http://alsa-project.org/db/?f=1ea099cf4369c1547b45eec8f9fefdc2f7cfd892 > > > Thanks a lot, and do you think kernel 6.5.0 will include a method that would > solve this sound problem?
Created attachment 304764 [details] Amps are working on Yoga Pro 9i 2023 I got my amps working. If your device has a TIAS2781 component inside (http://alsa-project.org/db/?f=45447739750ff897cdc20fd0e98d4f2055beebdf <- note line 71), you can try the following: Install i2ctools first and then run ./2pa-byps.sh with the i2c-bus number where your TIAS2781 is connected. E.g: sudo ./2pa-byps.sh 0 In my case this enabled my subwoofers and the sound was working properly. This change will be included in the kernel in the next couple of weeks / months so no workaround will be necessary anymore.
Hi, I searched this thread for relevant Linux 6.2 references but didn't find anything. My AMD Legion 7 Gen6 that was working on 5.17 kernel + patch just got updates to Linux viola 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 13 16:27:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux and the speakers aren't working now. I don't see much in the way of ACPI error messages either on bootup. Here's some extract from dmesg: [ 4.917409] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.1: Cirrus Logic CS35L41 (35a40), Revision: B2 [ 4.996344] ACPI Warning: \_SB.PCI0.GPP0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20221020/nsarguments-61) [ 5.077457] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.0: DSP1: Firmware version: 3 [ 5.077461] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot-17aa3847.wmfw: Fri 09 Oct 2020 13:07:57 W. Europe Daylight Time [ 5.090052] ideapad_acpi VPC2004:00: DYTC interface is not available [ 6.846680] i2c_designware AMDI0010:03: controller timed out [ 6.872224] i2c_designware AMDI0010:03: timeout in disabling adapter [ 6.872244] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.0: DSP1: cirrus/cs35l41-dsp1-spk-prot-17aa3847.wmfw.6: Failed to write 18640 bytes at 0 in PM_PACKED: -110 [ 6.872267] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.0: Cannot Initialize Firmware. Error: -110 [ 6.892883] i2c_designware AMDI0010:03: timeout waiting for bus ready [ 6.892890] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.0: DSP1: Failed to read SCRATCH0: -110 [ 6.892893] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.0: Cannot Run Firmware, reverting to dsp bypass... [ 6.892903] snd_hda_codec_realtek hdaudioC1D0: bound i2c-CLSA0100:00-cs35l41-hda.0 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41]) [ 6.896626] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.1: DSP1: Firmware version: 3 [ 6.896629] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot-17aa3847.wmfw: Fri 09 Oct 2020 13:07:57 W. Europe Daylight Time [ 6.916884] i2c_designware AMDI0010:03: timeout waiting for bus ready [ 6.916890] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.1: DSP1: cirrus/cs35l41-dsp1-spk-prot-17aa3847.wmfw.1: Failed to write 60 bytes at 0 in XM_PACKED: -110 [ 6.916898] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.1: Cannot Initialize Firmware. Error: -110 [ 6.937994] i2c_designware AMDI0010:03: timeout waiting for bus ready [ 6.938000] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.1: DSP1: Failed to read SCRATCH0: -110 [ 6.938003] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.1: Cannot Run Firmware, reverting to dsp bypass... [ 6.938011] snd_hda_codec_realtek hdaudioC1D0: bound i2c-CLSA0100:00-cs35l41-hda.1 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41]) [ 6.938477] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC287: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker [ 6.938480] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 6.938483] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 6.938485] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 6.938486] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 6.938488] snd_hda_codec_realtek hdaudioC1D0: Mic=0x19 [ 6.938490] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 [ 7.883053] input: HD-Audio Generic Mic as /devices/pci0000:00/0000:00:08.1/0000:06:00.6/sound/card1/input19 [ 7.883109] input: HD-Audio Generic Headphone as /devices/pci0000:00/0000:00:08.1/0000:06:00.6/sound/card1/input20 Then this just repeats endlessly: [ 22.856752] i2c_designware AMDI0010:03: timeout in disabling adapter [ 22.876890] i2c_designware AMDI0010:03: timeout waiting for bus ready [ 22.897999] i2c_designware AMDI0010:03: timeout waiting for bus ready [ 22.898007] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.0: Regmap access fail: -110 [ 22.918668] i2c_designware AMDI0010:03: timeout waiting for bus ready [ 22.939805] i2c_designware AMDI0010:03: timeout waiting for bus ready [ 22.939813] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.1: Regmap access fail: -110 [ 22.983802] i2c_designware AMDI0010:03: timeout waiting for bus ready [ 22.983809] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.0: Regmap access fail: -110 [ 23.004890] i2c_designware AMDI0010:03: timeout waiting for bus ready [ 23.004904] cs35l41-hda i2c-CLSA0100:00-cs35l41-hda.1: Regmap access fail: -110
Here on my Lenovo Legion 7 Slim the audio never worked and the microphone worked until 6.4, now in 6.5 nothing works anymore. Does anyone know how I can resolve this? I'm a bit of a beginner Alsa: http://alsa-project.org/db/?f=24e78ce46f588c8a681c092c24e05811a4f42f77 Kernel: 6.5.2-arch1-1
(In reply to Christian G. Semke from comment #780) > Here on my Lenovo Legion 7 Slim the audio never worked and the microphone > worked until 6.4, now in 6.5 nothing works anymore. Does anyone know how I > can resolve this? I'm a bit of a beginner > > Alsa: http://alsa-project.org/db/?f=24e78ce46f588c8a681c092c24e05811a4f42f77 > Kernel: 6.5.2-arch1-1 I've submitted this patch which should fix it: https://lore.kernel.org/all/20230911213409.6106-1-git@augustwikerfors.se/
(In reply to August Wikerfors from comment #781) > (In reply to Christian G. Semke from comment #780) > > Here on my Lenovo Legion 7 Slim the audio never worked and the microphone > > worked until 6.4, now in 6.5 nothing works anymore. Does anyone know how I > > can resolve this? I'm a bit of a beginner > > > > Alsa: > http://alsa-project.org/db/?f=24e78ce46f588c8a681c092c24e05811a4f42f77 > > Kernel: 6.5.2-arch1-1 > > I've submitted this patch which should fix it: > https://lore.kernel.org/all/20230911213409.6106-1-git@augustwikerfors.se/ Looking at the patch this looks like a microphone quirk patch. It does not look like it patches the audio output side of things. Do you know of a patch or patch submission that is for audio out on the Legion 7 Slim AMD edition (16ARHA7)?
Created attachment 305139 [details] attachment-30610-0.html I am currently out of the office on holiday I will be returning on Tuesday September 26, I will not be checking email.
(In reply to greg from comment #782) > Looking at the patch this looks like a microphone quirk patch. It does not > look like it patches the audio output side of things. Correct, I should have made that more clear. > Do you know of a patch or patch submission that is for audio out on the > Legion 7 Slim AMD edition (16ARHA7)? Unfortunately not.
I was wondering how do I apply any patches? I'm on a legion 7i gen 7 and was wondering how to add patches because I wanted to try out if any patch works for my system, thank you.
What about Lenovo Legion Slim 7 Gen 8 2023 ? does sound works ? i've seen that work will be mainlined as said in the comment 774 but when ?
Is there some way I can help to get Realtek/tas working for the Lenovo Slim Pro 9i (named Yoga Slim 9i outside of the US)? On my Manjaro install, the top speakers work (although I don't think they're amplified?) and the bottom subwoofers are off. I've managed to get qemu working for sniffing following this guide: https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver At one point, Win10 in qemu had sound working similar to Linux (only top-firing, maybe unamplified), and I saw event logs, but I don't remember the driver. I might need to do a clean install at this point. When I try to install the driver in qemu in win10 or win11, I get a bluescreen. Windows is using Realtek Semi Corp ver 6.0.9553.1. uname: Linux andrew-slim 6.6.2-1-MANJARO #1 SMP PREEMPT_DYNAMIC Mon Nov 20 13:00:47 UTC 2023 x86_64 GNU/Linux lspci shows: 00:1f.3 Multimedia audio controller: Intel Corporation Device 51cf (rev 01) Subsystem: Lenovo Device 3802 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 16 IOMMU group: 16 Region 0: Memory at 6203190000 (64-bit, non-prefetchable) [size=16K] Region 4: Memory at 6203000000 (64-bit, non-prefetchable) [size=1M] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME- Capabilities: [80] Vendor Specific Information: Len=14 <?> Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Kernel driver in use: vfio-pci Kernel modules: snd_hda_intel, snd_sof_pci_intel_tg From lsmod: snd_soc_tas2781_fmwlib 53248 1 snd_hda_scodec_tas2781_i2c snd_soc_tas2781_comlib 24576 2 snd_soc_tas2781_fmwlib,snd_hda_scodec_tas2781_i2c From dmesg (1f.3 is the device, I think): [ 0.709119] pci 0000:00:1f.0: [8086:519f] type 00 class 0x060100 [ 0.709450] pci 0000:00:1f.3: [8086:51cf] type 00 class 0x040100 [ 0.709492] pci 0000:00:1f.3: reg 0x10: [mem 0x6203190000-0x6203193fff 64bit] [ 0.709546] pci 0000:00:1f.3: reg 0x20: [mem 0x6203000000-0x62030fffff 64bit] [ 0.709651] pci 0000:00:1f.3: PME# supported from D3hot D3cold [ 0.709735] pci 0000:00:1f.4: [8086:51a3] type 00 class 0x0c0500 [ 0.709756] pci 0000:00:1f.4: reg 0x10: [mem 0x620319c000-0x620319c0ff 64bit] [ 0.709778] pci 0000:00:1f.4: reg 0x20: [io 0xefa0-0xefbf] [ 0.710013] pci 0000:00:1f.5: [8086:51a4] type 00 class 0x0c8000 [ 0.710035] pci 0000:00:1f.5: reg 0x10: [mem 0xfe010000-0xfe010fff] I have a separate grub entry to boot without sound (for qemu sniffing) using these flags: modprobe.blacklist=snd_hda_intel,snd_sof_pci_intel_tgl pci-stub.ids=8086:51cf iommu=pt intel_iommu=on I'm not sure if that's enough. Happy to help in any way!
Andrew, the verb approach doesn't work here as smart amps are being used. The tas2781 smart amp is generally supported as of kernel 6.6... but now it's a question of if firmware for your laptop is available. Without your alsa-info, I can't tell if your laptop is supported... But you can just try the firmware for yourself from here: https://neo-zeon.de/~hiryu/tas/firmware-6.6.tar.bz2 Just copy the files into /lib/firmware/ and reboot. Hopefully you have sound. A number of Lenovo laptops with tas2781 are supported, but I don't think the list is anywhere near comprehensive so we'll see..? Good luck! I'm not sure if these firmware files are yet in the pipeline to be commonly redistributed at this time... I'll see if there's something I can do to get that process started. (In reply to Andrew from comment #787) > From lsmod: > snd_soc_tas2781_fmwlib 53248 1 snd_hda_scodec_tas2781_i2c > snd_soc_tas2781_comlib 24576 2 > snd_soc_tas2781_fmwlib,snd_hda_scodec_tas2781_i2c > > From dmesg (1f.3 is the device, I think): > [ 0.709119] pci 0000:00:1f.0: [8086:519f] type 00 class 0x060100 > [ 0.709450] pci 0000:00:1f.3: [8086:51cf] type 00 class 0x040100 > [ 0.709492] pci 0000:00:1f.3: reg 0x10: [mem 0x6203190000-0x6203193fff > 64bit] > [ 0.709546] pci 0000:00:1f.3: reg 0x20: [mem 0x6203000000-0x62030fffff > 64bit] > [ 0.709651] pci 0000:00:1f.3: PME# supported from D3hot D3cold > [ 0.709735] pci 0000:00:1f.4: [8086:51a3] type 00 class 0x0c0500 > [ 0.709756] pci 0000:00:1f.4: reg 0x10: [mem 0x620319c000-0x620319c0ff > 64bit] > [ 0.709778] pci 0000:00:1f.4: reg 0x20: [io 0xefa0-0xefbf] > [ 0.710013] pci 0000:00:1f.5: [8086:51a4] type 00 class 0x0c8000 > [ 0.710035] pci 0000:00:1f.5: reg 0x10: [mem 0xfe010000-0xfe010fff] > > I have a separate grub entry to boot without sound (for qemu sniffing) using > these flags: modprobe.blacklist=snd_hda_intel,snd_sof_pci_intel_tgl > pci-stub.ids=8086:51cf iommu=pt intel_iommu=on > > I'm not sure if that's enough. Happy to help in any way!
Created attachment 305523 [details] alsa-info.txt Thanks Cameron! Adding those files to /lib/firmware didn't work (I copied the files directly), so I'm probably out of luck for now. I've attached my alsa-info.txt in case it helps. On Thu, Nov 30, 2023 at 10:45 AM <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #788 from Cameron Berkenpas (cam@neo-zeon.de) --- > Andrew, the verb approach doesn't work here as smart amps are being used. > > The tas2781 smart amp is generally supported as of kernel 6.6... but now > it's a > question of if firmware for your laptop is available. > > Without your alsa-info, I can't tell if your laptop is supported... > > But you can just try the firmware for yourself from here: > https://neo-zeon.de/~hiryu/tas/firmware-6.6.tar.bz2 > > Just copy the files into /lib/firmware/ and reboot. Hopefully you have > sound. > > A number of Lenovo laptops with tas2781 are supported, but I don't think > the > list is anywhere near comprehensive so we'll see..? > > Good luck! > > I'm not sure if these firmware files are yet in the pipeline to be commonly > redistributed at this time... I'll see if there's something I can do to get > that process started. > > (In reply to Andrew from comment #787) > > > From lsmod: > > snd_soc_tas2781_fmwlib 53248 1 snd_hda_scodec_tas2781_i2c > > snd_soc_tas2781_comlib 24576 2 > > snd_soc_tas2781_fmwlib,snd_hda_scodec_tas2781_i2c > > > > From dmesg (1f.3 is the device, I think): > > [ 0.709119] pci 0000:00:1f.0: [8086:519f] type 00 class 0x060100 > > [ 0.709450] pci 0000:00:1f.3: [8086:51cf] type 00 class 0x040100 > > [ 0.709492] pci 0000:00:1f.3: reg 0x10: [mem 0x6203190000-0x6203193fff > > 64bit] > > [ 0.709546] pci 0000:00:1f.3: reg 0x20: [mem 0x6203000000-0x62030fffff > > 64bit] > > [ 0.709651] pci 0000:00:1f.3: PME# supported from D3hot D3cold > > [ 0.709735] pci 0000:00:1f.4: [8086:51a3] type 00 class 0x0c0500 > > [ 0.709756] pci 0000:00:1f.4: reg 0x10: [mem 0x620319c000-0x620319c0ff > > 64bit] > > [ 0.709778] pci 0000:00:1f.4: reg 0x20: [io 0xefa0-0xefbf] > > [ 0.710013] pci 0000:00:1f.5: [8086:51a4] type 00 class 0x0c8000 > > [ 0.710035] pci 0000:00:1f.5: reg 0x10: [mem 0xfe010000-0xfe010fff] > > > > I have a separate grub entry to boot without sound (for qemu sniffing) > using > > these flags: modprobe.blacklist=snd_hda_intel,snd_sof_pci_intel_tgl > > pci-stub.ids=8086:51cf iommu=pt intel_iommu=on > > > > I'm not sure if that's enough. Happy to help in any way! > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
It seems the sound no longer works for the legion 7 16achg6 on kernel 6.6. It's been working great for the last year on all kernels, but 6.6 just doesn't work. I'm not sure if anyone else is having similar issues? Manjaro Linux here.
(In reply to Miggy from comment #790) > It seems the sound no longer works for the legion 7 16achg6 on kernel 6.6. > It's been working great for the last year on all kernels, but 6.6 just > doesn't work. > > I'm not sure if anyone else is having similar issues? Manjaro Linux here. I had no luck with sound on Ubuntu's 6.2 either. I dropped back to 5.19 to get sound working again.
I'm on 6.6.4 on a Lenovo Yoga S940-14IIL cat /sys/class/sound/hwC1D0/subsystem_id 0x17aa3819 Same subsystem_id as for Lenovo 13s Gen2 ITL (https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c#L10193) Sound works, but it is high-pitched since the base is missing.
For add info about the laptop Legion S7 16ARHA7 ( https://psref.lenovo.com/Detail/Legion/Legion_S7_16ARHA7?M=82UG0029SP ) cat /sys/class/sound/hwC1D0/subsystem_id 0xaa0100 Alsainfo in the comment 700
(In reply to m from comment #792) > I'm on 6.6.4 on a Lenovo Yoga S940-14IIL > > cat /sys/class/sound/hwC1D0/subsystem_id 0x17aa3819 > > Same subsystem_id as for Lenovo 13s Gen2 ITL > (https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek. > c#L10193) > > Sound works, but it is high-pitched since the base is missing. The C940 also has alc298 and tas2770. Please try this: sudo nano /etc/modprobe.d/alsa-base.conf add this line: options snd-hda-intel model=17aa:3818 save: ctrl+o ctrl+x sudo reboot
(In reply to Gergo K from comment #794) > (In reply to m from comment #792) > > I'm on 6.6.4 on a Lenovo Yoga S940-14IIL > > > > cat /sys/class/sound/hwC1D0/subsystem_id 0x17aa3819 > > > > Same subsystem_id as for Lenovo 13s Gen2 ITL > > (https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek. > > c#L10193) > > > > Sound works, but it is high-pitched since the base is missing. > > The C940 also has alc298 and tas2770. > Please try this: > sudo nano /etc/modprobe.d/alsa-base.conf > > add this line: > options snd-hda-intel model=17aa:3818 > > save: > ctrl+o ctrl+x > > sudo reboot The file didn't exist and therefore was empty. I added the line and saved the file. There was no change after rebooting. I still get sound, but the same as before, only high-pitched with no base. Does there need to be something additional in the file or some other configuration? Is there some configuration to enable the speakers that give the base?
Hey it looks like Lenovo has released a new BIOS version for the Legion S7 16ARHA7 Slim model (the one I have that still has no sound). I'm curious if anyone has updated to this BIOS yet and if that's resolved any issues or if this would allow further development on the audio issue.
Created attachment 305664 [details] attachment-13865-0.html I am currently out of the office on holiday I will be returning on Tuesday January 2, I will not be checking email.
(In reply to zacherytapp from comment #796) > Hey it looks like Lenovo has released a new BIOS version for the Legion S7 > 16ARHA7 Slim model (the one I have that still has no sound). I'm curious if > anyone has updated to this BIOS yet and if that's resolved any issues or if > this would allow further development on the audio issue. i got the sound working on my 16APH8 (Slim 7 AMD Gen 8 2023). I mainly followed this guide https://gist.github.com/masselstine/8fe9634b4c31cef07b8dfab089e4eb38 . Just check if the Cirrus chip is connected in I2C. You can know that by putting kernel in log level 7 and seeing logs in dmesg. Just make sure to shutdown and unplug power, wait about 10s and boot up again to test the sound everytime
(In reply to Andrew from comment #789) > Created attachment 305523 [details] > alsa-info.txt > > Thanks Cameron! Adding those files to /lib/firmware didn't work (I copied > the files directly), so I'm probably out of luck for now. I've attached my > alsa-info.txt in case it helps. Hey, try to run the script from Thomas from comment 778. I have the same model and it worked for me. (In reply to Thomas Gfeller from comment #778) > This change will be included in the kernel in the next couple of weeks / > months so no workaround will be necessary anymore. Thomas, can you give more details about how did you find the values used on the script and the current status of merging it to the kernel?
(In reply to zacherytapp from comment #796) > Hey it looks like Lenovo has released a new BIOS version for the Legion S7 > 16ARHA7 Slim model (the one I have that still has no sound). I'm curious if > anyone has updated to this BIOS yet and if that's resolved any issues or if > this would allow further development on the audio issue. I checked new BIOS version on my legion S7 16ARHA7. Nothing changed unfortunately
Same no audio problem on this laptop: Legion Slim 7 16APH8 https://psref.lenovo.com/Detail/Legion/Legion_Slim_7_16APH8?M=82Y4001UMZ OS: Fedora 39 Kernel: 6.6.9-200.fc39.x86_64 alsa-info.sh http://alsa-project.org/db/?f=dc0275d1836faea7ddf81a990b07e4a86313bf9a Bios: Version: M1CN36WW Release Date: 09/21/2023 cat /sys/class/sound/hwC1D0/subsystem_id 0xaa0100
``` aplay -l ... card 2: Generic_1 [HD-Audio Generic], device 0: ALC287 Analog [ALC287 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 ``` According to laptop's specs: https://psref.lenovo.com/Product/Legion_Slim_7_16APH8?tab=spec Audio Chip High Definition (HD) Audio, Realtek® ALC3306 codec It seems like Linux reports ALC287 instead of ALC3306. According to a reddit post, ALC3306 is just a name change of ALC287.
(In reply to August Wikerfors from comment #781) > (In reply to Christian G. Semke from comment #780) > > Here on my Lenovo Legion 7 Slim the audio never worked and the microphone > > worked until 6.4, now in 6.5 nothing works anymore. Does anyone know how I > > can resolve this? I'm a bit of a beginner > > > > Alsa: > http://alsa-project.org/db/?f=24e78ce46f588c8a681c092c24e05811a4f42f77 > > Kernel: 6.5.2-arch1-1 > > I've submitted this patch which should fix it: > https://lore.kernel.org/all/20230911213409.6106-1-git@augustwikerfors.se/ Hey! Looks like this acp6x-mach/yc_acp_quirk_table workaround would also be needed for Yoga Slim 7 Pro 14ARH7 (LENOVO/82UU). I have one, and the microphone does not works. ALSA info: https://alsa-project.org/db/?f=77e94edfeb14c5e3bf3ffb9524fb5d8390e1b722 From the kernel logs looks like snd_pci_acp6x detects and enables a device: ``` [ 7.120140] snd_pci_acp6x 0000:32:00.5: enabling device (0000 -> 0002) ``` but then there is nothing acp_yc_mach related in the logs. I would appreciate if you could make a patch. Thanks!
(In reply to Howard Chu from comment #791) > (In reply to Miggy from comment #790) > > It seems the sound no longer works for the legion 7 16achg6 on kernel 6.6. > > It's been working great for the last year on all kernels, but 6.6 just > > doesn't work. > > > > I'm not sure if anyone else is having similar issues? Manjaro Linux here. > > I had no luck with sound on Ubuntu's 6.2 either. I dropped back to 5.19 to > get sound working again. I have been lurking on this thread for a while. This thread has been up and still active since 2020, I don't even know where / which suggestions I need to start following. I have 16ACHg6 too, (Alsa says that) it's running Realtek ALC287. I have a fresh install of Ubuntu 22.04 with kernel 6.5.0-14-generic, I have updated my BIOS and internal speakers hasn't been working at all since the first day. External speakers (headphone, Bluetooth speakers) work just fine though. Still no luck with 16ACHg6 then ?
I believe support for the 16ACHg6 was added quite a ways back. On 1/18/24 05:36, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > shenanigans@duck.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |shenanigans@duck.com > > --- Comment #804 from shenanigans@duck.com --- > (In reply to Howard Chu from comment #791) >> (In reply to Miggy from comment #790) >>> It seems the sound no longer works for the legion 7 16achg6 on kernel 6.6. >>> It's been working great for the last year on all kernels, but 6.6 just >>> doesn't work. >>> >>> I'm not sure if anyone else is having similar issues? Manjaro Linux here. >> I had no luck with sound on Ubuntu's 6.2 either. I dropped back to 5.19 to >> get sound working again. > I have been lurking on this thread for a while. This thread has been up and > still active since 2020, I don't even know where / which suggestions I need > to > start following. > > I have 16ACHg6 too, (Alsa says that) it's running Realtek ALC287. I have a > fresh install of Ubuntu 22.04 with kernel 6.5.0-14-generic, I have updated my > BIOS and internal speakers hasn't been working at all since the first day. > External speakers (headphone, Bluetooth speakers) work just fine though. > Still > no luck with 16ACHg6 then ? >
(In reply to Cameron Berkenpas from comment #805) > I believe support for the 16ACHg6 was added quite a ways back. Yes, it was added in 5.18. It is broken in 6.x. That's why I still only run 5.19 on my machine. The comment below says it actually stopped working in 6.6. I can't confirm that it worked in any earlier 6.x kernels, I had no luck with it. > > On 1/18/24 05:36, bugzilla-daemon@kernel.org wrote: > > --- Comment #804 from shenanigans@duck.com --- > > (In reply to Howard Chu from comment #791) > >> (In reply to Miggy from comment #790) > >>> It seems the sound no longer works for the legion 7 16achg6 on kernel > 6.6. > >>> It's been working great for the last year on all kernels, but 6.6 just > >>> doesn't work. > >>> > >>> I'm not sure if anyone else is having similar issues? Manjaro Linux here. > >> I had no luck with sound on Ubuntu's 6.2 either. I dropped back to 5.19 to > >> get sound working again. > > I have been lurking on this thread for a while. This thread has been up and > > still active since 2020, I don't even know where / which suggestions I need > > to > > start following. > > > > I have 16ACHg6 too, (Alsa says that) it's running Realtek ALC287. I have a > > fresh install of Ubuntu 22.04 with kernel 6.5.0-14-generic, I have updated > my > > BIOS and internal speakers hasn't been working at all since the first day. > > External speakers (headphone, Bluetooth speakers) work just fine though. > > Still > > no luck with 16ACHg6 then ? > >
Probably time to bisect and then report back to Cirrus Logic. On 1/18/24 16:53, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #806 from Howard Chu (hyc@highlandsun.com) --- > (In reply to Cameron Berkenpas from comment #805) >> I believe support for the 16ACHg6 was added quite a ways back. > Yes, it was added in 5.18. It is broken in 6.x. That's why I still only run > 5.19 on my machine. The comment below says it actually stopped working in > 6.6. > I can't confirm that it worked in any earlier 6.x kernels, I had no luck with > it. >> On 1/18/24 05:36, bugzilla-daemon@kernel.org wrote: >>> --- Comment #804 from shenanigans@duck.com --- >>> (In reply to Howard Chu from comment #791) >>>> (In reply to Miggy from comment #790) >>>>> It seems the sound no longer works for the legion 7 16achg6 on kernel >> 6.6. >>>>> It's been working great for the last year on all kernels, but 6.6 just >>>>> doesn't work. >>>>> >>>>> I'm not sure if anyone else is having similar issues? Manjaro Linux here. >>>> I had no luck with sound on Ubuntu's 6.2 either. I dropped back to 5.19 to >>>> get sound working again. >>> I have been lurking on this thread for a while. This thread has been up and >>> still active since 2020, I don't even know where / which suggestions I need >>> to >>> start following. >>> >>> I have 16ACHg6 too, (Alsa says that) it's running Realtek ALC287. I have a >>> fresh install of Ubuntu 22.04 with kernel 6.5.0-14-generic, I have updated >> my >>> BIOS and internal speakers hasn't been working at all since the first day. >>> External speakers (headphone, Bluetooth speakers) work just fine though. >>> Still >>> no luck with 16ACHg6 then ? >>>
Canonical occasionally breaks sound compatibility between kernel release (but I yet to figure out why). However, the XanMod kernel quite rarely breaks Lenovo sound compatibility, thus I suggest you give that kernel a whirl: https://xanmod.org/ (It's quite easy to install and remove if needed).
(In reply to Cameron Berkenpas from comment #805) > I believe support for the 16ACHg6 was added quite a ways back. > > On 1/18/24 05:36, bugzilla-daemon@kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > > > shenanigans@duck.com changed: > > > > What |Removed |Added > > > ---------------------------------------------------------------------------- > > CC| |shenanigans@duck.com > > > > --- Comment #804 from shenanigans@duck.com --- > > (In reply to Howard Chu from comment #791) > >> (In reply to Miggy from comment #790) > >>> It seems the sound no longer works for the legion 7 16achg6 on kernel > 6.6. > >>> It's been working great for the last year on all kernels, but 6.6 just > >>> doesn't work. > >>> > >>> I'm not sure if anyone else is having similar issues? Manjaro Linux here. > >> I had no luck with sound on Ubuntu's 6.2 either. I dropped back to 5.19 to > >> get sound working again. > > I have been lurking on this thread for a while. This thread has been up and > > still active since 2020, I don't even know where / which suggestions I need > > to > > start following. > > > > I have 16ACHg6 too, (Alsa says that) it's running Realtek ALC287. I have a > > fresh install of Ubuntu 22.04 with kernel 6.5.0-14-generic, I have updated > my > > BIOS and internal speakers hasn't been working at all since the first day. > > External speakers (headphone, Bluetooth speakers) work just fine though. > > Still > > no luck with 16ACHg6 then ? > > Yes, I tried a few patches including the last one : linux-legion-sound-0.0.13. I can confirm it is not working on my 16ACHg6 with kernel 6.5.0-14. Thank you so much by the way for all of your help with so many patches !
Hey, I have a Lenovo Yoga 7 16IAP7 with Fedora Workstation 39 installed. Kernel Verion: Linux 6.6.11-200.fc39.x86_64 alsa-lib version: alsa-lib-1.2.10-3.fc39.x86_64 I installed alsa-tools and went into hdajackretask to see what is going on. Then I noticed that my System is telling me that I have an ALC287 installed but actually it is a ALC3306. Sound is horrible and several fixes with ALC 287 for Legion Models did nit work. In the Settings I can see as well, that only 2 of the 4 integrated speakers are getting noticed. I have had this Problem for a while now. Comment #806 said that this should have worked till 6.6 and then it broke again. I had a fresh install of Fedora 38 back then with the Kernel 6.4.6-200.fc38.x86_64. It did not work form me with this Kernel either. Are there any news or is there hope of fixes?
Don't mention it, I've already given up. At first, I thought maybe some patches would "heal" this problem, then I believed the new kernel would work, now I solved this problem by ignoring it and wearing my earphone.
I use a Lenovo Slim 7 Carbon with a ALC287 as well. We have an issue page open for this device/issue as well, and I think we nailed it down to the pin configurations. https://github.com/milkovsky/Linux-on-Lenovo-Slim-7-Carbon-AMD/issues/2#issuecomment-1615152518 I welcome your thoughts on this. hdajackretask seems to be the software for this solution.
I have a "Lenovo Legion Slim 7i 16", and several days ago, out of nowhere, the speaker started working. I have no idea how -- I did not change anything manually. I suspect it's a new kernel version that did it. I'm on Arch Linux, and I can't remember which kernel version I have installed (but I can update when I get home later today). Anyway, good news!
(In reply to Jacob Garby from comment #813) > I have a "Lenovo Legion Slim 7i 16", and several days ago, out of nowhere, > the speaker started working. I have no idea how -- I did not change anything > manually. I suspect it's a new kernel version that did it. > > I'm on Arch Linux, and I can't remember which kernel version I have > installed (but I can update when I get home later today). > > Anyway, good news! Amazing I would like to reproduce this. You can find out your current kernel version with the command "uname -r". The installed sound packages/libs would also be interesting. What I know of would be to look at the alsa version. Someone else surely has more information on what to specificly look for and how.
(In reply to Lukas from comment #814) > (In reply to Jacob Garby from comment #813) > > I have a "Lenovo Legion Slim 7i 16", and several days ago, out of nowhere, > > the speaker started working. I have no idea how -- I did not change > anything > > manually. I suspect it's a new kernel version that did it. > > > > I'm on Arch Linux, and I can't remember which kernel version I have > > installed (but I can update when I get home later today). > > > > Anyway, good news! > > Amazing > > I would like to reproduce this. You can find out your current kernel version > with the command "uname -r". The installed sound packages/libs would also be > interesting. What I know of would be to look at the alsa version. > Someone else surely has more information on what to specificly look for and > how. Yep! I'll post this kind of info before the end of today, check back in a few hours. I can tell you now that the speakers first started working when using pulseaudio as my sound server, but soon after (in order to get bluetooth working nicer) I switched to pipewire.
(In reply to Lukas from comment #814) > (In reply to Jacob Garby from comment #813) > > I have a "Lenovo Legion Slim 7i 16", and several days ago, out of nowhere, > > the speaker started working. I have no idea how -- I did not change > anything > > manually. I suspect it's a new kernel version that did it. > > > > I'm on Arch Linux, and I can't remember which kernel version I have > > installed (but I can update when I get home later today). > > > > Anyway, good news! > > Amazing > > I would like to reproduce this. You can find out your current kernel version > with the command "uname -r". The installed sound packages/libs would also be > interesting. What I know of would be to look at the alsa version. > Someone else surely has more information on what to specificly look for and > how. Okay, so my kernel version is 6.7.2-arch1-1 These are some (maybe all) of the audio related packages I have installed: kpipewire 5.27.10-1 libpipewire 1:1.0.1-2 pipewire 1:1.0.1-2 pipewire-alsa 1:1.0.1-2 pipewire-audio 1:1.0.1-2 pipewire-jack 1:1.0.1-2 pipewire-pulse 1:1.0.1-2 libpulse 17.0-3 pipewire-pulse 1:1.0.1-2 projectm-pulseaudio 3.1.12-4 But I can verify that my speaker did also work _before_ I switched from Pulseaudio to Pipewire, seems both should work. The result of running alsa-info is here: http://alsa-project.org/db/?f=07a1fdaf34a424adc27dbb6be3f417995df6994f Good luck!
(In reply to Jacob Garby from comment #816) > (In reply to Lukas from comment #814) > > (In reply to Jacob Garby from comment #813) > > > I have a "Lenovo Legion Slim 7i 16", and several days ago, out of > nowhere, > > > the speaker started working. I have no idea how -- I did not change > > anything > > > manually. I suspect it's a new kernel version that did it. > > > > > > I'm on Arch Linux, and I can't remember which kernel version I have > > > installed (but I can update when I get home later today). > > > > > > Anyway, good news! > > > > Amazing > > > > I would like to reproduce this. You can find out your current kernel > version > > with the command "uname -r". The installed sound packages/libs would also > be > > interesting. What I know of would be to look at the alsa version. > > Someone else surely has more information on what to specificly look for and > > how. > > Okay, so my kernel version is 6.7.2-arch1-1 > > These are some (maybe all) of the audio related packages I have installed: > kpipewire 5.27.10-1 > libpipewire 1:1.0.1-2 > pipewire 1:1.0.1-2 > pipewire-alsa 1:1.0.1-2 > pipewire-audio 1:1.0.1-2 > pipewire-jack 1:1.0.1-2 > pipewire-pulse 1:1.0.1-2 > libpulse 17.0-3 > pipewire-pulse 1:1.0.1-2 > projectm-pulseaudio 3.1.12-4 > > But I can verify that my speaker did also work _before_ I switched from > Pulseaudio to Pipewire, seems both should work. > > The result of running alsa-info is here: > http://alsa-project.org/db/?f=07a1fdaf34a424adc27dbb6be3f417995df6994f > > Good luck! atm i did not get it to work. i habe all the same packages or newer installed. hoping newer verions did not brick it again this means it would have to be the kernel. fedora 39 stabe only gets access to 6.6.13. tests for 6.7 are beeing done. i even tired to switch to pulse and back. no changes. will provide mor info when new kernel is here. maybe someone can provide info on weather fedora and arch kernel are vastly different as yours specificly says arch in the version. mine does not
Legion Slim 7 16IRH8 quirk added with this commit: https://github.com/torvalds/linux/commit/99af5b11c57d33c32d761797f6308b40936c22ed This is in 6.7.1+.
I am running an 14IRP8 (Yoga Pro/Slim 9i), specifically this model (https://psref.lenovo.com/Detail/Yoga/Yoga_Pro_9_14IRP8?M=83BU0024AU). I have the laptop running Ubuntu 23.10 and I run mainline kernels from Ubuntu. I have tried almost every recent kernel build up until 6.8-rc5 today (I had read that 6.8 was supposed to fix this issue). Audio is still running only the tweaters, zero bass. I've tried many things, notably the snd.conf (options snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin) to no avail. Also tried noble's firmware-sof-signed package, manually tweaking the amixer configuration. My alsa info -> https://alsa-project.org/db/?f=634d31445ad5a7c4a023cdb15a07dea2a4048437 Thanks!!
(In reply to thornley.david from comment #819) > I am running an 14IRP8 (Yoga Pro/Slim 9i), specifically this model > (https://psref.lenovo.com/Detail/Yoga/Yoga_Pro_9_14IRP8?M=83BU0024AU). Not sure what the cause of this is, but there is no specific mention of "14IRP8" in any of the kernel code, so I guess there is still no specific support for your issue, unfortunately. Possibly the fix would be as simple as the commit which fixed it for the 16IRH8 (just several lines of code https://github.com/torvalds/linux/commit/99af5b11c57d33c32d761797f6308b40936c22ed), but I don't know enough about any of this to say for sure.
Based on alsa-info, its subsystem ID is: 0x17aa38be It's here in the patch_realtek.c: SND_PCI_QUIRK(0x17aa, 0x38be, "Yoga S980-14.5 proX YC Dual", ALC287_FIXUP_TAS2781_I2C), snd_hda_scodec_tas2781_i2c loaded. Could you run this as well? dmesg|grep 2781
I noticed that patch is present in the kernel I am running... "dmesg | grep 2781" yields nothing. "lsmod" indicates snd_hda_scodec_tas2781_i2c is loaded. I'm quite green with the audio subsystem in linux, so pretty overwhelmed and suprised how complicated it is :) I'm not 100% sure, but it sounds like there is firmware and associated tuning values present in the EFI system that are also required. One other thing I noticed, running "i2cdetect -r 3" doesn't report any probed addresses. -r 1 has one at 0x14, -r 2 has at 0x2c, less that I think expected based on other similar posts.
Could you share your acpidump output?
(In reply to thornley.david from comment #819) > I am running an 14IRP8 (Yoga Pro/Slim 9i), specifically this model > (https://psref.lenovo.com/Detail/Yoga/Yoga_Pro_9_14IRP8?M=83BU0024AU). > > I have the laptop running Ubuntu 23.10 and I run mainline kernels from > Ubuntu. I have tried almost every recent kernel build up until 6.8-rc5 today > (I had read that 6.8 was supposed to fix this issue). Audio is still running > only the tweaters, zero bass. > > I've tried many things, notably the snd.conf (options > snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin) to no avail. > Also tried noble's firmware-sof-signed package, manually tweaking the amixer > configuration. > > My alsa info -> > https://alsa-project.org/db/?f=634d31445ad5a7c4a023cdb15a07dea2a4048437 > > Thanks!! Do you have full volume sound? I have a similar model (https://psref.lenovo.com/Detail/Lenovo/Lenovo_Slim_Pro_9_14IRP8?M=83BV0002US) and had to do a few things to make the amplifier work in the first place, but I still don't have any bass. To get sound on linux 6.7 I had to update the firmware files and use `options snd-sof-intel-hda-common hda_model=17aa:38be`, which had a different effect to alc287-yoga9-bass-spk-pin (not sure why). I described with more details at https://github.com/PJungkamp/yoga9-linux/issues/11#issuecomment-1899400594 I didn't try a lot on 6.8 but my current config doesn't fix the bass there too.
I do now :) You're right the hda_model=17aa:38be definitely forces the tas driver to load properly (it is in dmesg) and the firmware link seemed to fix a NULL error when I first tried it. [ 5.770034] snd_hda_codec_realtek ehdaudio0D0: bound i2c-TIAS2781:00 (ops tas2781_hda_comp_ops [snd_hda_scodec_tas2781_i2c]) I tried both 6.8.0-rc5 and then fell back to 6.7.5 because in both of these the volume control didn't work at all (seems to be at full volume), even in "alsamixer -c 1". Note that originally, the sound was low/quiet but volume control did work.
Could someone please test if changing this fixup in the sound/pci/hda/patch_realtek.c fixes the volume control? [ALC287_FIXUP_TAS2781_I2C] = { .type = HDA_FIXUP_FUNC, .v.func = tas2781_fixup_i2c, .chained = true, .chain_id = ALC269_FIXUP_THINKPAD_ACPI, }, to this: [ALC287_FIXUP_TAS2781_I2C] = { .type = HDA_FIXUP_FUNC, .v.func = tas2781_fixup_i2c, .chained = true, .chain_id = ALC285_FIXUP_THINKPAD_HEADSET_JACK, }, It worked for ALC287_FIXUP_YOGA7_14ARB7_I2C.
(In reply to Gergo K from comment #826) > Could someone please test if changing this fixup in the > sound/pci/hda/patch_realtek.c fixes the volume control? > > [ALC287_FIXUP_TAS2781_I2C] = { > .type = HDA_FIXUP_FUNC, > .v.func = tas2781_fixup_i2c, > .chained = true, > .chain_id = ALC269_FIXUP_THINKPAD_ACPI, > }, > > to this: > > [ALC287_FIXUP_TAS2781_I2C] = { > .type = HDA_FIXUP_FUNC, > .v.func = tas2781_fixup_i2c, > .chained = true, > .chain_id = ALC285_FIXUP_THINKPAD_HEADSET_JACK, > }, > > It worked for ALC287_FIXUP_YOGA7_14ARB7_I2C. Just tried it and it indeed works, nice! Do you know if this will be merged soon (hopefully before 6.8 release)? It still requires `options snd-sof-intel-hda-common hda_model=17aa:38be` (doing nothing or using `hda_model=alc287-yoga9-bass-spk-pin` doesn't work). But now I can control the volume using the default "Play HiFi quality Music" without janky work around.
Great to hear! I can create a patch, and it can be included in 6.6 and 6.7. Can you test whether the headset jack works also? And could you run alsa-info.sh? I think your model needs to be added to the patch_realtek.c to make it work without the module parameters.
(In reply to Gergo K from comment #828) > Great to hear! > I can create a patch, and it can be included in 6.6 and 6.7. > > Can you test whether the headset jack works also? > > And could you run alsa-info.sh? I think your model needs to be added to the > patch_realtek.c to make it work without the module parameters. I can confirm that headset jack works perfectly with this patch. With 6.7 it didn't even detect the headset plugged (didn't test it on 6.8 without the patch). Here is the alsa-info after the patch: http://alsa-project.org/db/?f=4bdd25202b2329c03bef10d0f6f0b4781987aa49 Thank you for your attention!
I don't know why it won't pick up your model. Could you please run alsa-info after the patch and without the module parameter?
=(In reply to Gergo K from comment #830) > I don't know why it won't pick up your model. > Could you please run alsa-info after the patch and without the module > parameter? Yeah, I have no idea, I decided to use specifically the model of my speaker through trial and error. http://alsa-project.org/db/?f=93ba55541edee13c680039a8c00ff85930f37ad8 I don't know how but the bass on Windows is still much better and I always hear a strong beep from both speakers when I get past the sddm lock screen when I turn on the laptop.
The strong beep suggests you might have the older firmware. If you have the old firmware, you might also notice your sound for your left and right speakers are swapped. On 2/22/24 12:06, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #831 from Willian (kernel@willian.wang) --- > =(In reply to Gergo K from comment #830) >> I don't know why it won't pick up your model. >> Could you please run alsa-info after the patch and without the module >> parameter? > Yeah, I have no idea, I decided to use specifically the model of my speaker > through trial and error. > http://alsa-project.org/db/?f=93ba55541edee13c680039a8c00ff85930f37ad8 > > > I don't know how but the bass on Windows is still much better and I always > hear > a strong beep from both speakers when I get past the sddm lock screen when I > turn on the laptop. >
(In reply to Cameron Berkenpas from comment #832) > The strong beep suggests you might have the older firmware. > > If you have the old firmware, you might also notice your sound for your > left and right speakers are swapped. The speakers are not swapped but how can I check the current version and update these firmwares? I moved the firmwares from https://neo-zeon.de/~hiryu/tas/firmware-6.6.tar.bz2 to /usr/lib/firmware, so not sure if this affected something.
Then that's the latest firmware as far as I know (that's my server lol). Not sure why you're getting the beep then. On 2/22/24 13:31, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #833 from Willian (kernel@willian.wang) --- > (In reply to Cameron Berkenpas from comment #832) >> The strong beep suggests you might have the older firmware. >> >> If you have the old firmware, you might also notice your sound for your >> left and right speakers are swapped. > The speakers are not swapped but how can I check the current version and > update > these firmwares? > > I moved the firmwares from > https://neo-zeon.de/~hiryu/tas/firmware-6.6.tar.bz2 > to /usr/lib/firmware, so not sure if this affected something. >
The latest firmware is probably in the linux-firmware package. Do you still hear a difference when you disable Dolby in Windows? Do you hear the beep after hibernation also?
Could you please comment out this line from patch_realtek.c and rebuild the kernel and start it without the module parameters? SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
(In reply to Cameron Berkenpas from comment #834) > Then that's the latest firmware as far as I know (that's my server lol). > > Not sure why you're getting the beep then. Oh, didn't know the server was yours, thank you lol. Unfortunately, the firmwares are not up to date compared to kernel-firmwares. Specifically the files TAS2XXX3881.bin, TAS2XXX38CB.bin, TAS2XXX38CD.bin, TIAS2781RCA2.bin. Updating the firmwares fixed the loud beep (which also sounds like something really broken) and my bass is much better than before. As a very subject comparison, the working bass at low volume makes my table shake a little, the old firmware sounds flat and doesn't move anything even at the highest volume. Windows is still a little better but probably because of the tuning than anything else. I tested the new firmware without the module parameter just in case it also fixes that, but it still doesn't work without it. (In reply to Gergo K from comment #836) > Could you please comment out this line from patch_realtek.c and rebuild the > kernel and start it without the module parameters? > > SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), I will test it right now.
Sounds like I should try this new firmware... kernel-firmware... Is that the repo? On 2/22/24 6:56 PM, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #837 from Willian (kernel@willian.wang) --- > (In reply to Cameron Berkenpas from comment #834) >> Then that's the latest firmware as far as I know (that's my server lol). >> >> Not sure why you're getting the beep then. > Oh, didn't know the server was yours, thank you lol. Unfortunately, the > firmwares are not up to date compared to kernel-firmwares. Specifically the > files TAS2XXX3881.bin, TAS2XXX38CB.bin, TAS2XXX38CD.bin, TIAS2781RCA2.bin. > > Updating the firmwares fixed the loud beep (which also sounds like something > really broken) and my bass is much better than before. As a very subject > comparison, the working bass at low volume makes my table shake a little, the > old firmware sounds flat and doesn't move anything even at the highest > volume. > Windows is still a little better but probably because of the tuning than > anything else. > > I tested the new firmware without the module parameter just in case it also > fixes that, but it still doesn't work without it. > > > (In reply to Gergo K from comment #836) >> Could you please comment out this line from patch_realtek.c and rebuild the >> kernel and start it without the module parameters? >> >> SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", >> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), > I will test it right now. >
(In reply to Gergo K from comment #836) > Could you please comment out this line from patch_realtek.c and rebuild the > kernel and start it without the module parameters? > > SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS), http://alsa-project.org/db/?f=8d9465f9d22c4efdc3655373f1d32416516afacd Yeah, it works! I'm curious what was the issue, can you give an overview of it? (In reply to Cameron Berkenpas from comment #838) > Sounds like I should try this new firmware... > > > kernel-firmware... Is that the repo? https://gitlab.com/kernel-firmware/linux-firmware
There is an ID collision. Your audio controller's PCI SSID (17aa:3802) is the same as the "Lenovo Yoga DuetITL 2021" Codec SSID. The snd_hda_pick_fixup() function searches the PCI SSID before the Codec SSID in the same table. So it picks the ALC287_FIXUP_YOGA7_14ITL_SPEAKERS fixup not the ALC287_FIXUP_TAS2781_I2C. !!PCI Soundcards installed in the system !!-------------------------------------- 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device [8086:51cf] (rev 01) Subsystem: Lenovo Device [17aa:3802] I think a common fixup can be figured out, or a better solution from someone who knows this subsystem well.
(In reply to Gergo K from comment #840) > There is an ID collision. > > Your audio controller's PCI SSID (17aa:3802) is the same as the "Lenovo Yoga > DuetITL 2021" Codec SSID. The snd_hda_pick_fixup() function searches the PCI > SSID before the Codec SSID in the same table. So it picks the > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS fixup not the ALC287_FIXUP_TAS2781_I2C. > > > !!PCI Soundcards installed in the system > !!-------------------------------------- > > 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device > [8086:51cf] (rev 01) > Subsystem: Lenovo Device [17aa:3802] > > I think a common fixup can be figured out, or a better solution from someone > who knows this subsystem well. Hm I see, not sure if this is the right place to talk about the code, but is there a reason for the fixup table to be the same for PCI and Codec SSIDs? (I know it's not like it could be separated at this point). Also, is there a reason to match by PCI before Codec? A few ideas I thought: 1. Just check if the PCI and Codec SSID match the exact SSIDs of this device (not elegant) 2. For every lookup, check with both
(In reply to Gergo K from comment #840) > There is an ID collision. > > Your audio controller's PCI SSID (17aa:3802) is the same as the "Lenovo Yoga > DuetITL 2021" Codec SSID. The snd_hda_pick_fixup() function searches the PCI > SSID before the Codec SSID in the same table. So it picks the > ALC287_FIXUP_YOGA7_14ITL_SPEAKERS fixup not the ALC287_FIXUP_TAS2781_I2C. > > > !!PCI Soundcards installed in the system > !!-------------------------------------- > > 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device > [8086:51cf] (rev 01) > Subsystem: Lenovo Device [17aa:3802] > > I think a common fixup can be figured out, or a better solution from someone > who knows this subsystem well. Hm I see, not sure if this is the right place to talk about the code, but is there a reason for the fixup table to be the same for PCI and Codec SSIDs? (I know it's not like it could be separated at this point). Also, is there a reason to match by PCI before Codec? A few ideas I was thinking: 1. Just check if the PCI and Codec SSID match the exact SSIDs of this device - not elegant 2. For every lookup, check with both PCI and Codec SSID and see if they match the same entry, add a debug to these cases and use the Codec entry - not sure how common this is and if this will break other cases Depending on how hard this problem is I may want to help with the code if possible. (sorry for the dupe, I pressed the save changes by mistake before)
I don't know the reasons, but this code has been working in this way for 10+ years, so this type of collision can not be common. I sent the ALC285_FIXUP_THINKPAD_HEADSET_JACK patch to the lists: https://lore.kernel.org/all/7ffae10ebba58601d25fe2ff8381a6ae3a926e62.1708687813.git.soyer@irl.hu/ And I sent a question about how to handle this collision: https://lore.kernel.org/all/d5b42e483566a3815d229270abd668131a0d9f3a.camel@irl.hu/ If you are interested in linux sound development, you can subscribe to the linux-sound list: http://vger.kernel.org/vger-lists.html#linux-sound
I also tried the two changes above to 6.7.6, it took a bit for me to work out how to compile a custom kernel in ubuntu (easy once you know). Mine is a slightly different 14IRP8 device Yoga Pro rather than Slim Pro (same underlying hardware). Alsa-info -> https://alsa-project.org/db/?f=3adac42b53db18376ea17cd5ab008c247a4039a5 Applied the latest firmware to /lib/firmware from https://gitlab.com/kernel-firmware/linux-firmware.git (branch main). Confirmed no options are now required, overall sound is considerably better, volume works, headphones also work. Subjectively audio doesn't seem quite as good as in Windows, where the bass seems to get dynamically adjusted depending on the volume (maybe some fancy DSP effects, not sure - I am only guessing). Either way, it is now light-years better than what it was before the changes. Many thanks Gergo K. :)
FYI, this looks to have been improved in Ubuntu's 6.8.1 mainline (https://kernel.ubuntu.com/mainline/v6.8.1/).
FYI, broken again in 6.8.4, 6.8.3 (not sure about 6.8.2).
Hm, I installed Ubuntu's 6.8.4 and the speakers work on my Legion 7 16achg6. But suspend doesn't wake up, so I'm back on 5.17.
After I upgrade to Linux 6.8.5, the speakers work well on my laptop. LOL, btw the machine can wake up from suspend, so this is also fixed. My laptop hardware model is Lenovo Legion R9000X ARHA7. Thanks everyone.
Working fine again for me in 6.8.5 :) Sorry for the spam!
(In reply to Linghui Ding from comment #848) > After I upgrade to Linux 6.8.5, the speakers work well on my laptop. LOL, > btw the machine can wake up from suspend, so this is also fixed. My laptop > hardware model is Lenovo Legion R9000X ARHA7. Thanks everyone. Confirm. Lenovo Legion 7 slim (R9000X) 16ARHA7. Speakers start working since upgrading to 6.8.5 kernel. But internal microphone doesn't. But maybe it's some local problem, I have never checked it before.
Can confirm on Endeavour 6.8.5 that my Legion Slim 7 16arha7 has working speakers now! yay! Lets hope they don't break again...
(In reply to admin from comment #851) > Can confirm on Endeavour 6.8.5 that my Legion Slim 7 16arha7 has working > speakers now! yay! Lets hope they don't break again... Does internal microphone work in your OS ?
Hi, just confirming that on: Lenovo Legion Pro 7i (Gen 8 / 2023) the no sound issue has regressed again on 6.8.5. Last working version without any issues is 6.7.9 - which is odd considering the original post lists this as not a regression? alsamixer shows ALC287 under system info. 6.8.2-6.8.4 have no audio for me. 6.8.5 has audio on reboot, but after a seemingly random amount of time the audio will no longer function until next reboot. 6.7.9 works at all times for me.
(In reply to dreamsyntax from comment #853) > Hi, just confirming that on: > Lenovo Legion Pro 7i (Gen 8 / 2023) the no sound issue has regressed again > on 6.8.5. > > Last working version without any issues is 6.7.9 - which is odd considering > the original post lists this as not a regression? > > alsamixer shows ALC287 under system info. > > > 6.8.2-6.8.4 have no audio for me. > 6.8.5 has audio on reboot, but after a seemingly random amount of time the > audio will no longer function until next reboot. > > 6.7.9 works at all times for me. I also have the Legion Pro 7i Gen 8 16IRX8H, sound worked through all those kernel versions for me... But I do have another problem I wonder if it's related... Occasionally, my sound will just stop working. I can't get it working until I reboot... This tends to happen at a rate of less than once per day. Last time it happened was yesterday. This time I decided to enable hibernate to see if resume from that would restore my sound (resuming from sleep doesn't work). Anyway, the issue didn't happen to me for about a month... and then happened to me twice recently. Maybe it started around 6.8.4 or 6.8.5? When it happened yesterday, I was on 6.8.6. The problem is so intermittent it's hard to pin it down to it starting with a specific kernel version... But it makes me think maybe our problems are symptoms of the same issue. How are you getting recent kernels? Are you self compiling? Are you using the Ubuntu mainline repo? Something else and/or some other distro entirely? I'm compiling my own. When this happens, audacious gives me some ALSA input/output error. I suspect some hook to tell the amps to wake up and play audio through the speakers hangs, but that's all I've got so far. But sound issues related to TI's smart amps are definitely unrelated to this bug we're posting in. Someone should start a new bug for these issues if we hope to get more support.
Created attachment 306161 [details] attachment-31010-0.html > ...it makes me think maybe our problems are symptoms of the same issue I agree. I am using endeavour os, but I've also verified my scenario on nobara (fedora based). I found I can somewhat reliably get the audio to fail on 6.8.5 by leaving the system muted for a few minutes. Additionally something I noticed on 6.8.0 is running a video in a Firefox based browser (I used Librewolf), pausing and unpausing could lead to the sound being permanently disabled for the whole system until reboot. I am not self compiling, just using the arch linux and linux-headers packages. If this bug tracker is for debian/ubu based distros only, my bad. The issue is reproducible regardless. I can only confirm that I experience no issue on 6.7.9 on fedora based distros and arch. I think I had no luck using 6.7.9 on linux mint (using mainline kernel), but I assume it is because of an outdated linux-firmware package. If it isn't a pain for you to test, could you try 6.7.9 and see if you experience no issues as well?
I can try 6.7.9 and 6.7.12. What you described vaguely sounds like the stuff I'm doing when it breaks on me so I'll try that too! I might have some time to do this tomorrow night. I've wondered if this is a firmware issue as well. Here are my md5sums for my files: af5adf85ef96839ae1aa79bc916f1b91 TAS2XXX387D.bin 951a483a58b1b41e5114f0c0746f583a TAS2XXX387E.bin f7f319ba68ab37e093381360e2bdefff TAS2XXX3881.bin dfb907ce0135030182704cabb1223465 TAS2XXX3884.bin a7ebbd19c73cd6fea005bcab025f4921 TAS2XXX3886.bin f1f0486569020316a7b3253db17c6b94 TAS2XXX38A7.bin b796beae38a02fa27426560742a829b6 TAS2XXX38A8.bin 830cf65b0d6e2355b70b9ed364b4819d TAS2XXX38B8.bin 2a4d57199bc04ebc2dd9880f7afee4a7 TAS2XXX38B9.bin fcaa167bb712cbe7829ae41f9ea7bfa0 TAS2XXX38BA.bin 9a6089a79ef6038691733a18c94c1005 TAS2XXX38BB.bin 0ace13d455c64d5043ac2ee066555f20 TAS2XXX38BE.bin a90c1c801076cf6f2acfd6edf83e7575 TAS2XXX38BF.bin 3723cbf4848c3df69cd870314817aada TAS2XXX38C3.bin dfb907ce0135030182704cabb1223465 TAS2XXX38CB.bin a7ebbd19c73cd6fea005bcab025f4921 TAS2XXX38CD.bin 33c27f3eec9e46e1e487b0fc4b781725 TIAS2781RCA2.bin 4824e06b5919b577d4671a3dd40fbda4 TIAS2781RCA2.json 61dcfeb8c3dd4c5b922dbbe8d826d2ef TIAS2781RCA4.bin 38f473162f7dd3546db9ee561fb560bf TIAS2781RCA4.json I've considered and looking at the latest files in the linux-firmware git repo, but haven't had time yet. On 4/15/2024 10:19 PM, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #855 from dreamsyntax@gmail.com --- >> ...it makes me think maybe our problems are symptoms of the same issue > I agree. I am using endeavour os, but I've also verified my scenario on > nobara (fedora based). > > I found I can somewhat reliably get the audio to fail on 6.8.5 by leaving > the system muted for a few minutes. Additionally something I noticed on > 6.8.0 is running a video in a Firefox based browser (I used Librewolf), > pausing and unpausing could lead to the sound being permanently disabled > for the whole system until reboot. > > I am not self compiling, just using the arch linux and linux-headers > packages. If this bug tracker is for debian/ubu based distros only, my bad. > The issue is reproducible regardless. > I can only confirm that I experience no issue on 6.7.9 on fedora based > distros and arch. I think I had no luck using 6.7.9 on linux mint (using > mainline kernel), but I assume it is because of an outdated linux-firmware > package. > > If it isn't a pain for you to test, could you try 6.7.9 and see if you > experience no issues as well? >
The firmware files have not changed. I think it's possible that this commit is the culprit: https://github.com/torvalds/linux/commit/bec7760a6c5fa59593dac264fa0c628e46815986 Sorry about that, it works fine with tas2563, but I couldn't test it with tas2781. Something related to power management can cause this also. Please try the following and report if it fixes the issue: amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1 It is possible that the -c 1 and the numid parameters are not exactly these, they can be obtained from `amixer -c 1 contents` or `amixer -c 0 contents`. Thanks, Gergo
I had some time this morning to try and repeat the issue.. I couldn't do it. So until I can find a way to repeat it, it's not worth testing other kernel releases. I will try Gergo's command once it happens again and report back.
What else came to mind, the driver currently writes the calibration data to one of the wrong registers of tas2781, which can also cause problems. If anyone wants to know what fixes the problem, please try this patch as well: https://lore.kernel.org/all/20240406132010.341-1-shenghao-ding@ti.com/
On 4/16/24 16:54, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #859 from Gergo K (soyer@irl.hu) --- > What else came to mind, the driver currently writes the calibration data to > one > of the wrong registers of tas2781, which can also cause problems. If anyone > wants to know what fixes the problem, please try this patch as well: > > https://lore.kernel.org/all/20240406132010.341-1-shenghao-ding@ti.com/ > Pretty good find/catch! I checked the source of my current kernel (6.8.6) and it didn't have that patch installed... So I applied it. We'll see how this goes...
> Please try the following and report if it fixes the issue: > amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1 What is the expected result of the above? > I had some time this morning to try and repeat the issue.. I couldn't do it I can reproduce in < 5 mins on average. I played a video and paused / resumed after a while, until the issue kicked in. Ran: `amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1` No effect, sound still broken. The output looked ok. Checked both `amixer -c 1 contents` or `amixer -c 0 contents`. - there are a lot of entries, what exactly am I looking for? Here's the interesting part though: In that same session, I made the laptop close lid action + sleep On wake, audio was working again.
(In reply to Gergo K from comment #857) > The firmware files have not changed. > > I think it's possible that this commit is the culprit: > https://github.com/torvalds/linux/commit/ > bec7760a6c5fa59593dac264fa0c628e46815986 > > Sorry about that, it works fine with tas2563, but I couldn't test it with > tas2781. > Something related to power management can cause this also. > > Please try the following and report if it fixes the issue: > > amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1 > > It is possible that the -c 1 and the numid parameters are not exactly these, > they can be obtained from `amixer -c 1 contents` or `amixer -c 0 contents`. > > Thanks, > Gergo Hi, I had this issue for some time but thought it was because of bad setup in my part. This command seems to fix the issue without having to rewake the laptop. I'm testing your patch and will report back soon.
Hi, > there are a lot of entries, what exactly am I looking for? Find the card with 'Speaker Force Firmware Load' control, then change the -c and numid parameters accordingly. > What is the expected result of the above? It reloads the program of the amplifiers before powering up the amplifiers. (amplifiers (software) shutdown occurs after 3 idle seconds) If you set it to 0, the program will only be reloaded after module init and after wakeup/rewake. you can check the value of the control with: amixer -c 1 cget numid=3,name='Speaker Force Firmware Load' Before bec7760a6c5fa59593dac264fa0c628e46815986 ("ALSA: hda/tas2781: do not reset cur_* values in runtime_suspend"), the driver reloaded the program and configuration every time, and this control wasn't effective. Reloading the program and config takes 0.3 second or more, that's why I wanted to remove that behavior. It's annoying to wait every time you start anything. I can only guess what could be wrong with tas2781 setups. Probably the amps will go into failure state or reset state after a while. It would help if someone dumps the registers as root, when the amplifiers are not working: rmmod snd_hda_scodec_tas2781_i2c i2cset -y 3 0x70 0x00 0x00 i2cset -y 3 0x70 0x7f 0x00 i2cdump -y 3 0x70 modprobe snd_hda_scodec_tas2781_i2c first line unloads the module second line changes the page to 0x00 third line changes the book to 0x00 fourth line dumps the page fifth line loads the module The bus number (3) may be different. The address of the second amplifier is 0x72. Here is the data sheet, if anyone wants to dig :) https://www.ti.com/lit/ds/symlink/tas2781.pdf
A few things since I last posted: After having done the below command... `amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1` Every subsequent reboot the audio never broke. I had multiple 2+ hour sessions with no issue. I never re-ran the above command. Adjusting the volume would have a noticeable 'delay' (around 0.5 seconds to 3 seconds) before the audio mixer related GUI would respond. As a test I did a fresh install of endeavour-os (on kernel 6.8.7) and sure enough, the issue is back and I can break the audio in less than 5 minutes of use. > It would help if someone dumps the registers as root, when the amplifiers are not working Unfortunately, the result of the below command are as follows once audio breaks: $ su root # rmmod snd_hda_scodec_tas2781_i2c # i2cset -y 3 0x70 0x00 0x00 Error: Write failed # i2cset -y 3 0x70 0x00 0x00 Error: Write failed # i2cset -y 3 0x70 0x7f 0x00 Error: Write failed # i2cdump -y 3 0x70 No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX 90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX After modprobe snd_hda_scodec_tas2781_i2c is run, audio actually works again, for a few minutes. I will note I get the same result above even if I do it while audio works, so if I'm doing something wrong please let me know. For testing purposes, if I want to enable/disable your workaround solution, would changing the 1 at the end to 0 be sufficient? `amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1` -> `amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 0`
> I never re-ran the above command. The alsactl restores all audo controls after boot, including this one. > Unfortunately, the result of the below command are as follows once audio > breaks: Please try 0x38 instead of 0x70, and if still not found, try 0,1,2,4 instead of bus 3. If you still not found, please send your acpidump output. > For testing purposes, if I want to enable/disable your workaround solution, would changing the 1 at the end to 0 be sufficient? Yes, setting it to 0 disables always reloading.
(In reply to Gergo K from comment #865) > Please try 0x38 instead of 0x70, and if still not found, try 0,1,2,4 instead > of bus 3. > > If you still not found, please send your acpidump output. # i2cset -y 1 0x38 0x7f 0x00 Error: Write failed # i2cset -y 2 0x38 0x7f 0x00 # i2cset -y 2 0x38 0x00 0x00 # i2cset -y 2 0x38 0x7f 0x00 # i2cdump -y 2 0x38 No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 00 00 02 28 21 41 00 20 09 02 2a 28 10 93 02 00 ..?(!A. ??*(???. 10: 84 00 00 08 0a 00 44 80 00 8d 00 62 36 40 00 01 ?..??.D?.?.b6@.? 20: 2e 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .?.............. 30: 00 00 00 00 06 bd ad a8 00 00 00 fc bb dd ff ff ....????...???.. 40: f6 14 00 00 80 80 00 00 00 00 02 99 80 00 1c 00 ??..??....???.?. 50: 00 00 a2 78 85 13 78 ff c7 c8 40 88 d9 81 00 00 ..?x??x.??@???.. 60: 21 08 3c 48 84 88 b2 00 04 09 12 7b 00 1a 03 00 !?<H???.???{.??. 70: 96 02 00 08 00 e0 00 00 00 00 20 00 a0 00 74 00 ??.?.?.... .?.t. 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Above is after the sound is broken. Immediately after doing the above, where sound is working, and then re-dump # modprobe snd_hda_scodec_tas2781_i2c # rmmod snd_hda_scodec_tas2781_i2c # i2cset -y 2 0x38 0x00 0x00 # i2cset -y 2 0x38 0x7f 0x00 # i2cdump -y 2 0x38 Results in the exact same output.
While audio working, and content is playing (actively outputting to device) Output is different: i2cset -y 2 0x38 0x00 0x00 i2cset -y 2 0x38 0x7f 0x00 i2cdump -y 2 0x38 No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 00 00 00 28 21 41 00 20 09 02 2a 28 10 93 02 00 ...(!A. ??*(???. 10: 84 00 00 08 0a 00 44 80 00 8d 00 62 36 40 00 01 ?..??.D?.?.b6@.? 20: 2e 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .?.............. 30: 00 00 00 00 06 bd ad a8 00 00 00 fc bb dd ff ff ....????...???.. 40: f6 14 00 02 19 00 00 00 00 04 02 19 80 00 5c 00 ??.??....????.\. 50: 00 06 a3 3c 85 08 81 da 87 84 00 97 d9 81 01 00 .??<??????.????. 60: 21 08 3c 48 84 88 b2 00 04 09 12 63 00 1a 03 00 !?<H???.???c.??. 70: 96 02 00 08 00 e0 00 00 0f 00 20 00 a0 00 25 00 ??.?.?..?. .?.%. 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Unfortunately, my sound finally did fail again... But the symptoms seem different. Audacious just hangs for a while before ultimately giving up (and it stops hanging and stops trying to play). But this is a new type of failure so perhaps this patch did make a bit of a difference? https://bugzilla.kernel.org/show_bug.cgi?id=208555#c863 But this happened immediately after resuming from suspend. My laptop went to sleep with mute enabled, I started playing sound after resuming, noticed I was muted, and resumed... And sound was no longer working. Could bec7760a6c5fa59593dac264fa0c628e46815986 be the issue? This did not fixed my count: amixer -c 0 cset numid=3,name='Speaker Force Firmware Load' 1 (-c 1 is incorrect for my laptop.)
kindly run #i2cdetect -r 2 and run following command during no sound issue dmesg -c > kernel-mute.log
To confirm... You want my dmesg output when there's no issue, but you want me to clear it after reading it? On 4/22/24 03:23, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > Tintin (shenghao-ding@ti.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |shenghao-ding@ti.com > > --- Comment #869 from Tintin (shenghao-ding@ti.com) --- > kindly run > #i2cdetect -r 2 > and run following command during no sound issue > dmesg -c > kernel-mute.log >
(In reply to Tintin from comment #869) > kindly run > #i2cdetect -r 2 > and run following command during no sound issue > dmesg -c > kernel-mute.log Forgot to get the dmesg even though I did look at the dmesg output (*facepalm*). There are no messages related to this in dmesg when this occurs. But next time it happens, I'll get this to you to be thorough and Just In Case. i2cdetect -r 2 # When it's working: i2cdetect -y -r 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- 3f 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- # When it's not working: i2cdetect -y -r 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- 3f 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- I tried on i2cbus 0 and 1, no changes there either. This time I finally remembered to try hibernating (suspend to disk). Resuming didn't fix the issue.
Save following as tas2781-2dev-on.sh run ". tas2781-2dev-on.sh" in root mode during no sound, and check whether to work? ################Start################### #!/bin/sh # echo Turn on log! # set -x clear function clear_stdin() ( old_tty_settings=`stty -g` stty -icanon min 0 time 0 while read none; do :; done stty "$old_tty_settings" ) if [ $# -ne 1 ]; then echo Kindly specify the i2c bus number. The default i2c bus number is 3. echo Command as following: echo $0 i2c-bus-number i2c_bus=3 else i2c_bus=$1 fi echo i2c bus is $i2c_bus i2c_addr=(0x3f 0x38) count=0 for value in ${i2c_addr[@]}; do val=$((${count} % 2)) i2cset -f -y $i2c_bus $value 0x00 0x00 i2cset -f -y $i2c_bus $value 0x7f 0x00 i2cset -f -y $i2c_bus $value 0x01 0x01 i2cset -f -y $i2c_bus $value 0x0e 0xc4 i2cset -f -y $i2c_bus $value 0x0f 0x40 i2cset -f -y $i2c_bus $value 0x5c 0xd9 i2cset -f -y $i2c_bus $value 0x60 0x10 if [ $val -eq 0 ]; then i2cset -f -y $i2c_bus $value 0x0a 0x1e else i2cset -f -y $i2c_bus $value 0x0a 0x2e fi i2cset -f -y $i2c_bus $value 0x0d 0x01 i2cset -f -y $i2c_bus $value 0x16 0x40 i2cset -f -y $i2c_bus $value 0x00 0x01 i2cset -f -y $i2c_bus $value 0x17 0xc8 i2cset -f -y $i2c_bus $value 0x00 0x04 i2cset -f -y $i2c_bus $value 0x30 0x00 i2cset -f -y $i2c_bus $value 0x31 0x00 i2cset -f -y $i2c_bus $value 0x32 0x00 i2cset -f -y $i2c_bus $value 0x33 0x01 i2cset -f -y $i2c_bus $value 0x00 0x08 i2cset -f -y $i2c_bus $value 0x18 0x00 i2cset -f -y $i2c_bus $value 0x19 0x00 i2cset -f -y $i2c_bus $value 0x1a 0x00 i2cset -f -y $i2c_bus $value 0x1b 0x00 i2cset -f -y $i2c_bus $value 0x28 0x40 i2cset -f -y $i2c_bus $value 0x29 0x00 i2cset -f -y $i2c_bus $value 0x2a 0x00 i2cset -f -y $i2c_bus $value 0x2b 0x00 i2cset -f -y $i2c_bus $value 0x00 0x0a i2cset -f -y $i2c_bus $value 0x48 0x00 i2cset -f -y $i2c_bus $value 0x49 0x00 i2cset -f -y $i2c_bus $value 0x4a 0x00 i2cset -f -y $i2c_bus $value 0x4b 0x00 i2cset -f -y $i2c_bus $value 0x58 0x40 i2cset -f -y $i2c_bus $value 0x59 0x00 i2cset -f -y $i2c_bus $value 0x5a 0x00 i2cset -f -y $i2c_bus $value 0x5b 0x00 i2cset -f -y $i2c_bus $value 0x00 0x00 i2cset -f -y $i2c_bus $value 0x02 0x00 count=$((${count} + 1)) done; clear_stdin ################End###################
(In reply to dreamsyntax from comment #867) > While audio working, and content is playing (actively outputting to device) > Output is different: > i2cset -y 2 0x38 0x00 0x00 > i2cset -y 2 0x38 0x7f 0x00 > i2cdump -y 2 0x38 > No size specified (using byte-data access) > 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef > 00: 00 00 00 28 21 41 00 20 09 02 2a 28 10 93 02 00 ...(!A. ??*(???. > 10: 84 00 00 08 0a 00 44 80 00 8d 00 62 36 40 00 01 ?..??.D?.?.b6@.? > 20: 2e 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .?.............. > 30: 00 00 00 00 06 bd ad a8 00 00 00 fc bb dd ff ff ....????...???.. > 40: f6 14 00 02 19 00 00 00 00 04 02 19 80 00 5c 00 ??.??....????.\. > 50: 00 06 a3 3c 85 08 81 da 87 84 00 97 d9 81 01 00 .??<??????.????. > 60: 21 08 3c 48 84 88 b2 00 04 09 12 63 00 1a 03 00 !?<H???.???c.??. > 70: 96 02 00 08 00 e0 00 00 0f 00 20 00 a0 00 25 00 ??.?.?..?. .?.%. > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Kindly follow Comment 872 to force tas2781 to work
# . tas2781-2dev-on.sh 2
Created attachment 306213 [details] kernel-mute.log (In reply to Tintin from comment #874) > # . tas2781-2dev-on.sh 2 Sorry if this is a bit long, but trying to include info to help debug the issue. Well, it has finally happened again... It seems like the script hasn't really helped... But I'll have to try it again next time this happens to determine what, if any, role it had. So far it looks like it hasn't helped. I was able to get my sound working by running this: "killall pipewire-pulse" and quitting/killing audacious (audacious usually but not always hangs when this starts happening), and quitting firefox, thought not necessarily in that order? But even that isn't enough to completely fix it. Likely, it would come back as soon as I start playing audio from more than one application at a time. When playing audio from another application, it would work for a few seconds, and then one of the applications would stop working. Almost like the audio device had become usable by one application at a time (like in the early ALSA days prior to pulseaudio becoming common). And probably if I stopped the other application, it usually wouldn't stop working again until repeating the above steps. But playing with it some more (with both quitting applications, killing pipewire-pulse over and over), I was eventually able to get audio to consistently work again (ie, normally) for about the last 30 minutes or so. I tried logging out and back at one point... That didn't seem to fix it either. It wasn't until several (or a bunch more) killing pipewire-pulse, restarting firefox and audacious a few times (I could try other software too!) that it started working again. I'm leaning toward this being a pipewire-pulse issue at this point... but it's possible that there's a driver issue that causes pipewise-pulse becoming wedged, and that running tas2781-2dev-on.sh and killing pipewise-pulse I'm eventually able to get things into a good state. If this happens again, I will conduct more testing... And I say if, because I think Ubuntu 24.04 is out today, and if it is... I will likely upgrade. If this is a software issue, good chance 24.04 won't have this problem. I'll report back with my results either way. Anyone else tried killing pipewire-pulse when having issues? I didn't see any sort of run away processes, I simply did "ps paux | grep pulse" and that was the only process that showed up so I tried killing it. It was just a guess from remembering all the early pulseaudio issues from over a decade ago. :D Here's my info for convenience: Kernel 6.8.7 Kubuntu 23.10 Running with KDE+Wayland My pipewire-pulse info: apt policy pipewire-pulse pipewire-pulse: Installed: 0.3.79-2 Candidate: 0.3.79-2 Version table: *** 0.3.79-2 500 500 http://us.archive.ubuntu.com/ubuntu mantic/main amd64 Packages 100 /var/lib/dpkg/status I didn't have this problem with the older kernel 6.7.x series, but maybe there was a pipewire-pulse update that happened? Or and update to a package it depends on? Finally, I've attached the requested dmesg output. My audio problems started after 10:30 (maybe around 10:40-ish?) and my audio had been completely working for around 15 minutes as of the time I'd captured that dmesg output. Seems like nothing really relevant, but maybe there's something helpful?
> Kindly follow Comment 872 to force tas2781 to work I had been using 6.7.9 for the last week with no issues. I upgrade to 6.8.7, and within 3 minutes audio broken. I save your script and run it -- su root -- ./tas2781-2dev-on.sh Sound works again, however: - sound is notably louder compared to 6.7.9 - right inside / right speaker? (not sure if there's 1 or 2) is louder than on 6.8.7 with your script. After a few minutes, once again audio will break again, until I re-run your script. Interestingly, after second run of script the audio balance is fixed. Both left/right speakers sound correct instead of being right-side balanced. Unfortunately, breaks soon after. For me audio never lasts more than ~3min. I also notice that the audio levels will oscillate occasionally on 6.8.x kernels, where this does not occur on 6.7.9. If there is anything more I can do to help, please advise. I can try any combination of kernel/patches if needed. I just want to resolve this issue without beings stuck on 6.7.9 kernel. Again for my posts, model is: Lenovo Legion Pro 7i (Gen 8, 2023) - and alsamixer shows ALC287 under system info.
Created attachment 306214 [details] attachment-10825-0.html I am currently out of the office on holiday I will be returning on Tuesday April 30th, I will not be checking email.
In my case, there seems to be an issue with pipewire using too many file descriptors: systemctl status --user pipewire ● pipewire.service - PipeWire Multimedia Service Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: enabled) Active: active (running) since Fri 2024-04-26 07:53:43 PDT; 11h ago TriggeredBy: ● pipewire.socket Main PID: 3468 (pipewire) Tasks: 3 (limit: 38161) Memory: 12.6M CPU: 38.400s CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service └─3468 /usr/bin/pipewire Apr 26 18:53:58 hostname pipewire[3468]: mod.client-node: 0x60925302fed0: error seq:13 -9 (set_activation: Bad file descriptor) Apr 26 18:53:58 hostname pipewire[3468]: pw.core: 0x609252c77940: error -9 for resource 2: node_set_io failed: Bad file descriptor Apr 26 18:53:58 hostname pipewire[3468]: mod.client-node: 0x60925302fed0: error seq:14 -9 (node_set_io failed: Bad file descriptor) Apr 26 18:53:58 hostname pipewire[3468]: mod.protocol-native: connection 0x609252e5f710: can't DUP fd:1021 Too many open files Apr 26 18:53:58 hostname pipewire[3468]: mod.protocol-native: connection 0x609252e5f710: can't DUP fd:1020 Too many open files Apr 26 18:53:58 hostname pipewire[3468]: pw.core: 0x609252c77940: error -9 for resource 2: set_activation: Bad file descriptor Apr 26 18:53:58 hostname pipewire[3468]: mod.client-node: 0x609252d7cdf0: error seq:23 -9 (set_activation: Bad file descriptor) Apr 26 18:54:06 hostname pipewire[3468]: mod.protocol-native: connection 0x609252e5f710: can't DUP fd:579 Too many open files Apr 26 18:58:00 hostname pipewire[3468]: mod.client-node: 0x609252fc1b70: unknown peer 0x609252fc2050 fd:98 Apr 26 18:58:15 hostname pipewire[3468]: mod.protocol-native: 0x609252c9c030: connection_data: client 0x609252fc29c0 error -71 (Protocol error) I was able to get my sound working by logging out and back in. After I got it working, I ran this: lsof -p3468 | wc -l 1013 I wonder if it was around 1024 before I logged out..? The open file limit for the process is: 1024 This explains why "killall pipewire-pulse" would get my sound working again for a single application... It was freeing up one file descriptor. Is this a pipewire bug, a tas2781 driver bug, or a bit of both? I think if this were a general pipewire issue, we'd be hearing a lot more complaints... After logging in, I tried this: systemctl restart --user pipewire This resulted in a new pipewire process and only 25 open file descriptors. Wonder if this would have fixed the issue without logging out? Something else to try next time. Next time this happens, I'll see if I can figure what all the file descriptors are for. For others having this or similar trouble, see if you're having similar issues with pipewire (or perhaps even pulse) and file descriptors. /var/log/syslog is another valid place to check for these messages (at least on Ubuntu).
(In reply to Cameron Berkenpas from comment #749) > See https://bugzilla.kernel.org/show_bug.cgi?id=216194 for a new patch. > Currently the latest is lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch > > This latest patch theoretically has support for Blake Lee's machine. > > A new revision of the 16IAX7. > > oppsig's Yoga Slim 7 Carbon 14ACN6 > > Pierre Hébert, > > I missed that you were getting this error previous: "Serial bus multi > instantiate pseudo device driver CSC3551:00: error -ENOENT: Error requesting > irq at index 0" > > That is indeed occurring before any of my code. Some hopefully good news is > that this is a Cirrus Logic issue that they might fix if you can report it > to them. Once fixed, you'd probably still need a patch such as mine to get > you over the finish line. > > PLEASE READ MY COMMENT HERE AS THIS PATCH IS USE AT-YOUR-OWN-RISK: > https://bugzilla.kernel.org/show_bug.cgi?id=216194#c66 > > From here on out, I will direct people to bug > https://bugzilla.kernel.org/show_bug.cgi?id=216194 as there's far too many > posts in this thread and it's made things difficult to keep track of. Hey all, I'm on the Lenovo Legion Slim 7 Gen 7 AMD version from 2022, and all of a sudden, after upgrading my Fedora install to 6.8.6-200.fc39.x86_64 my audio works! Not sure what happened on that front, but figured I'd stop back in and update.
After continued use of 6.8.7 and later 6.8.8, I can confirm using the `./tas2781-2dev-on.sh 2` in my case as root regularly whenever audio goes out works fine. What needs to happen at the kernel level / in a patch to resolve this?
I tested this script on my Lenovo Legion S7 16IAH7 with a fresh installation of Fedora Linux 40 with Kernel 6.8.8-300.fc40.x86_64. After installing i2c-tools the script return a lot of "Error: Write failed" errors. Pipewire version is: Compiled with libpipewire 1.0.5 Linked with libpipewire 1.0.5 Regards
(In reply to Markus from comment #881) > I tested this script on my Lenovo Legion S7 16IAH7 with a fresh installation > of Fedora Linux 40 with Kernel 6.8.8-300.fc40.x86_64. After installing > i2c-tools the script return a lot of "Error: Write failed" errors. Pipewire > version is: > Compiled with libpipewire 1.0.5 > Linked with libpipewire 1.0.5 > > Regards That script is for TI 2781 smart samps. The 16IAH7 has Cirrus logic, so the script definitely won't work there.
(In reply to Markus from comment #881) > I tested this script on my Lenovo Legion S7 16IAH7 with a fresh installation > of Fedora Linux 40 with Kernel 6.8.8-300.fc40.x86_64. After installing > i2c-tools the script return a lot of "Error: Write failed" errors. Pipewire > version is: > Compiled with libpipewire 1.0.5 > Linked with libpipewire 1.0.5 > > Regards https://patchwork.kernel.org/project/alsa-devel/list/?submitter=212831 Please try this patchset, that works for Lenovo Legion S7 16IAH7. I got sound myself for the first time a couple of days ago with it (tested on 6.8.7). although the volume is quite low (I cannot compare with windows, never ran it), it seems to work flawlessly. The missing part is really tiny, maybe this will land in mainline soon. Regards.
Related: https://bugzilla.suse.com/show_bug.cgi?id=1223462 https://github.com/torvalds/linux/commit/39815cdfc8d46ce2c72cbf2aa3d991c4bfb0024f Now with Kernel 6.9.0 the issue should be fixed for devices with Cirrus. Unfortunately for me on TI TAS2781 kernel 6.9.0 and 6.9.1 still have the same behavior as all kernels after 6.7.9. (Lenovo Legion Pro 7i Gen 8 2023) The `./tas2781-2dev-on.sh 2` has been my workaround, having to run it usually every time media stops outputting to the audio out.
Created attachment 306307 [details] attachment-8402-0.html I am currently out of the office on holiday I will be returning on Tuesday May 28th, I will not be checking email.
(In reply to dreamsyntax from comment #884) > Related: > https://bugzilla.suse.com/show_bug.cgi?id=1223462 > https://github.com/torvalds/linux/commit/ > 39815cdfc8d46ce2c72cbf2aa3d991c4bfb0024f > > Now with Kernel 6.9.0 the issue should be fixed for devices with Cirrus. > > Unfortunately for me on TI TAS2781 kernel 6.9.0 and 6.9.1 still have the > same behavior as all kernels after 6.7.9. (Lenovo Legion Pro 7i Gen 8 2023) > > The `./tas2781-2dev-on.sh 2` has been my workaround, having to run it > usually every time media stops outputting to the audio out. Are you the one that filed this bug? https://bugzilla.suse.com/show_bug.cgi?id=1223462 If that's not you, did you try the workaround in that ticket? If so, you have the 16ARX8H, and it sounds like there's an overlap with a laptop with the same ID that uses Cirrus Logic instead of TI. I looked through the thread and didn't see a link to your alsa-info. Did you share it and I just missed it in this very long thread? :D
> If that's not you, did you try the workaround in that ticket? Hi, that is not me, my handle is same across bug reports. That computer has a Cirrus Logic. Mine has TI. For that model 6.7.9 is the kernel that broke support. For me 6.7.9 is the last *working* kernel. Everything after it - 6.8.0+ has audio stopping unless re-running TAS script periodically after media source stops. I think there is a lot of confusion because of the same PCI SSID despite using Cirrus Logic or TI TAS2781. My laptop is "Legion Pro 7 16IRX8H / 82QW" - its the Gen 8 2023 model with Intel CPU and NVIDIA GPU. This laptop has the TI TAS2781. This is not the same as Gen 7 nor the Gen 8 'Slim 7i' - which has Cirrus. --- Regarding alsa-info: https://alsa-project.org/db/?f=bca5f20c2e21730fb686902076414069c94295e6 On Sat, May 18, 2024 at 9:57 PM <bugzilla-daemon@kernel.org> wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=208555 > > --- Comment #886 from Cameron Berkenpas (cam@vasteel.io) --- > (In reply to dreamsyntax from comment #884) > > Related: > > https://bugzilla.suse.com/show_bug.cgi?id=1223462 > > https://github.com/torvalds/linux/commit/ > > 39815cdfc8d46ce2c72cbf2aa3d991c4bfb0024f > > > > Now with Kernel 6.9.0 the issue should be fixed for devices with Cirrus. > > > > Unfortunately for me on TI TAS2781 kernel 6.9.0 and 6.9.1 still have the > > same behavior as all kernels after 6.7.9. (Lenovo Legion Pro 7i Gen 8 2023) > > > > The `./tas2781-2dev-on.sh 2` has been my workaround, having to run it > > usually every time media stops outputting to the audio out. > > Are you the one that filed this bug? > https://bugzilla.suse.com/show_bug.cgi?id=1223462 > > If that's not you, did you try the workaround in that ticket? > > If so, you have the 16ARX8H, and it sounds like there's an overlap with a > laptop with the same ID that uses Cirrus Logic instead of TI. > > I looked through the thread and didn't see a link to your alsa-info. Did you > share it and I just missed it in this very long thread? :D > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
Forgot to mention, yes I've also created this modprobe file. per https://bugzilla.suse.com/show_bug.cgi?id=1223462 It caused system crash initially (for some reason), but in reboots after, asound would work on startup until media plays / stops playing - then it would be back in broken state again. So a slight improvement I guess?
Update on behavior observed with kernel 6.9.2: Right speaker will sometimes work on boot, the left speaker will not. Running TAS script (tas2781-2dev-on.sh 2) restores both speakers (needing to be run periodically). Otherwise behavior is identical to every kernel after 6.7.9
hi all, I have a new 2024 gen9 Yoga 14AHP9 Yoga Pro 7 14.5", Gen 9 (AMD 8845HS) Fedora 40 Kernel 6.9.4 it has the usual 2x2 dolby speaker setup and ALC3306 which Linux detects as ALC287 the main issue i have is crackling/distortion when it tries to play low notes and this seems like a new issue? originally the volume control didnt work but that was fixed by adding element master config to analog-output.conf I tried 2pa-byps.sh but every number seems to say invalid / no difference the sound is ok most of the time, I cant tell if the sub speakers are working properly or not seems ok but not much bass, stupidly i didn't try the speakers in windows. but when the laptop tries to produce certain low tones, even if the volume is almost off there will be this nasty crackle any ideas here or is this problem getting worse on newer machines? happy to try any fixes or get more info just let me know
Created attachment 306538 [details] alsa-info.txt of Lenovo Legion Pro 7 16ARX8H (AMD Ryzen variant) alsa-info.sh of a of Lenovo Legion Pro 7 16ARX8H (AMD Ryzen variant), of which /sys/class/sound/hwC1D0/subsystem_id reports 0x17aa38a7 instead of 0x17aa38a8 reported by others and sound does not work on kernel 6.9.7.
Created attachment 306539 [details] attachment-9580-0.html I am currently out of the office on holiday I will be returning on Monday July 8th, I will not be checking email
Slightly different from dreamsyntax in comment 887, I have a Lenovo Legion Pro 7 16ARX8H (which is the AMD Ryzen variant, so not an Intel CPU). I see quirks already exist in patch_realtek.c for subsystem ID 0x17aa38a8 (which seems to be commented as being a 16ARX8H), but mine has subsystem ID 0x17aa38a7 instead (with a 7 at the back). As a result, at least in kernel 6.9.7 so far, no sound is being played back from the speakers. I was able to work around this by using the solution proposed in the link of adding options snd-hda-intel model=,17aa:38a8 ... to /etc/modprobe.d/60-hda.conf to force it to be detected as the one specified in the quirks. I'm not sure why my model receives a different subsystem ID than the one already added to the quirks; my BIOS is the latest available in any case. tl;dr: I think perhaps 0x17aa38a7 needs the same quirk applied as 0x17aa38a8?
Attempting comment #872 for me leads to ./audiofix.sh: 6: Syntax error: "(" unexpected in my shell (/bin/bash). If I comment out the usage of clear() then line 27 also uses ( in a way I don't know how to avoid: i2c_addr=(0x3f 0x38)
Yoga 9 14IAP7 has been working properly from post 683 above until recently. I use "options snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin". Sound is normal on Fedora kernel 6.9.11-200.fc40.x86_64. Sound volume is low, and bass is absent on all 6.10 kernels I've tried including 6.10.3-200.fc40.x86_64, 6.10.5-200.fc40.x86_64, 6.9.11-200.fc40.x86_64. The alsa-infos are at (working) http://alsa-project.org/db/?f=8ba5ee42e7a3b9e8ef06c953db7e3dee5640bc91 (fails) http://alsa-project.org/db/?f=142a7f4fd40e07f061ac96bcabdfb36753c00518
I'm not really sure why it was the case, but I able to temporarily (10 minutes or so) fix the audio problem in my Lenovo Legion Pro 7 16IRX9H following the comment here: https://bbs.archlinux.org/viewtopic.php?pid=2142917#p2142917 Quoting from the shared link, here's the solution that worked briefly (wasn't really worth it as I had to restart and it didn't last enough 😭): > I simply renamed/backed up the folder ~/.local/state/wireplumber to > ~/.local/state/wireplumber.bak. Then, after rebooting, the wireplumber folder > and its configuration files were recreated and the sound was working. I'm running Ubuntu 24.04.1 LTS with 6.8.0-41-generic kernel.
quick post to say that further to my comment 980, A hero added Yoga 14AHP9 to the list of laptops that get the bass spk driver/workaround and now speakers are good apart from low volume on headphones
(In reply to Steve Alexander from comment #895) > Yoga 9 14IAP7 has been working properly from post 683 above until recently. > I use "options snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin". > Sound is normal on Fedora kernel 6.9.11-200.fc40.x86_64. > Sound volume is low, and bass is absent on all 6.10 kernels I've tried > including > 6.10.3-200.fc40.x86_64, 6.10.5-200.fc40.x86_64, 6.9.11-200.fc40.x86_64. > > The alsa-infos are at > (working) > http://alsa-project.org/db/?f=8ba5ee42e7a3b9e8ef06c953db7e3dee5640bc91 > (fails) > http://alsa-project.org/db/?f=142a7f4fd40e07f061ac96bcabdfb36753c00518 I've notice the same missing bass in archlinux kernels as well starting 6.10 , right now i keep downgrade the kernel to the 6.9. Look around for a fix..
I'm having a similar-but-not-same problem with a Yoga Pro 7 14IMH9 Cannot control volume except mute or full blast, unless I go in alsamixer and change the "Pre Mixer Analog" or "Post Mixer Analog" volume controls. 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Meteor Lake-P HD Audio Controller [8086:7e28] (rev 20) Subsystem: Lenovo Device [17aa:3847] This subsystem ID matches the ALC287_FIXUP_LEGION_16ACHG6 quirk. I'm testing on 6.10.7
There is a known problem for some those 4-speaker configurations with only two DACs. In the realtek driver code, it expected to assign all 4 speakers to a single stereo DAC while a headphone is bound to another stereo DAC. However, the actual behavior is to bind the main speaker to one DAC and both the bass speaker and the headphone to another DAC. In short, the volume for both bass speaker and headphone are tied, so the volume control can go weirdly upon plugging/unplugging. I submitted a fix for those misbehavior today to the upstream: https://lore.kernel.org/20241001121439.26060-1-tiwai@suse.de Let me know if this gives improvements in some cases or cause another trouble. Note that, with the patch applied, the individual "Bass Speaker" volume will disappear. That's intended behavior.
Hi, there seems to be a regression for the Thinkpad Z13 Gen 2 which uses the Realtek ALC287 with the CS35L41 speaker amp, and has an existing quirk to load the CS35L41 side codec. I'm using Alpine, and the distribution 6.6 LTS kernel works fine, but the -edge kernel (6.11.5 currently) doesn't even after enabling all the side codecs in my Kconfig. I note the message [ 7.615333] snd_hda_codec_realtek hdaudioC1D0: realtek: Enable default setup for auto mode as fallback When dyndbg is enabled for the snd_hda_codec_realtek module, so I assume there is a regression in the detection code for this laptop. Relevant Cirrus DSP firmware is installed and the headphone jack works fine.
Anyone with Legion Pro 7i Gen 8 or TAS2781 with audio broken after kernel 6.7.9, you can install this which automatically calls the tas2781 script on the events that would lead to no audio. https://github.com/DanielWeiner/tas2781-fix-16IRX8H
Re the fix Takashi Iwai mentioned in comment 900. This had no impact on my Lenovo Yoga 9 14IAP7 problem. Sound volume is low and there is no bass. Alsa-info here for the 6.11.4 kernel w/the 'fix'. https://alsa-project.org/db/?f=c0661f14371bf07d30f9b68f05c831ceeef57b98
I discovered a work-around, suggesting a bug. While sound was working correctly (6.9.x kernels) I had a modprobe option: >> options snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin however that parameter was refactored out of the snd-sof-intel-hda-common module. The quirk list sound/pci/hda/patch_realtek.c ~ line 10847 contains: >> SND_PCI_QUIRK(0x17aa, 0x3801, "Lenovo Yoga9 14IAP7", >> ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), however the sub-ident " 0x3801" does not match my Yoga9 14IAP7 ! My subsystem is [17aa:381c], and my codec is [17aa,3863] See the alsa-info links for verification. So I find that including the modprobe option: >> options snd_sof_intel_hda_generic hda_model=17aa:3801 results in: >> $ cat /sys/module/snd_sof_intel_hda_generic/parameters/hda_model >> 17aa:3801 And then sound works as expected (6.11.4 kernel).
(In reply to Steve Alexander from comment #904) > I discovered a work-around, suggesting a bug. > > While sound was working correctly (6.9.x kernels) I had a modprobe option: > >> options snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin > however that parameter was refactored out of the snd-sof-intel-hda-common > module. > > The quirk list sound/pci/hda/patch_realtek.c ~ line 10847 contains: > >> SND_PCI_QUIRK(0x17aa, 0x3801, "Lenovo Yoga9 14IAP7", > >> ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), > however the sub-ident " 0x3801" does not match my Yoga9 14IAP7 ! > My subsystem is [17aa:381c], and my codec is [17aa,3863] > See the alsa-info links for verification. > > So I find that including the modprobe option: > >> options snd_sof_intel_hda_generic hda_model=17aa:3801 > results in: > >> $ cat /sys/module/snd_sof_intel_hda_generic/parameters/hda_model > >> 17aa:3801 > And then sound works as expected (6.11.4 kernel). This work around with options snd_sof_intel_hda_generic hda_model=17aa:3801 I confirm is available for 16IAP7 model as well Thank you Steve...(i was trying this option "#options snd-hda-intel model=,17aa:3801" and i gave up cause it didn't work)
> Occasionally, my sound will just stop working. Yes, that is what the issue is. Most of the time audio playback stops, the speakers will no longer work. Sometimes one speaker will stop working (L or R only). Running the TAS script or alternatively the below 'permanent' fix resolves the problem. There is a fix here, I've been using it for a week now. https://github.com/DanielWeiner/tas2781-fix-16IRX8H
(In reply to cris223 from comment #905) > (In reply to Steve Alexander from comment #904) > > I discovered a work-around, suggesting a bug. > > [...] > This work around with > options snd_sof_intel_hda_generic hda_model=17aa:3801 > > I confirm is available for 16IAP7 model as well > > Thank you Steve...(i was trying this option "#options snd-hda-intel > model=,17aa:3801" and i gave up cause it didn't work) It might helps the devs if you posted the 16IAP7 sub-idents ... like the output of this command for a Lenovo (17aa). I suspect the SND_PCI_QUIRK idents are either incomplete or incorrect. $ alsa-info.sh --no-upload --output ./X 2>/dev/null 1>&2 ; grep -A4 "Manufac" ./X ; grep 17aa ./X
(In reply to Steve Alexander from comment #907) > (In reply to cris223 from comment #905) > > (In reply to Steve Alexander from comment #904) > > > I discovered a work-around, suggesting a bug. > > > > [...] > > This work around with > > options snd_sof_intel_hda_generic hda_model=17aa:3801 > > > > I confirm is available for 16IAP7 model as well > > > > Thank you Steve...(i was trying this option "#options snd-hda-intel > > model=,17aa:3801" and i gave up cause it didn't work) > > It might helps the devs if you posted the 16IAP7 sub-idents ... like the > output of > this command for a Lenovo (17aa). I suspect the SND_PCI_QUIRK idents are > either > incomplete or incorrect. > > $ alsa-info.sh --no-upload --output ./X 2>/dev/null 1>&2 ; grep -A4 > "Manufac" ./X ; grep 17aa ./X Manufacturer: LENOVO Product Name: 82QG Product Version: Yoga 7 16IAP7 Firmware Version: J1CN45WW System SKU: LENOVO_MT_82QG_BU_idea_FM_Yoga 7 16IAP7 Subsystem: Lenovo Device [17aa:380f] snd_sof_intel_hda_generic: hda_model=17aa:3801 Subsystem Id: 0x17aa386a Components : 'HDA:8086281c,80860101,00100000 HDA:10ec0287,17aa386a,00100002 cfg-dmics:2'
(In reply to Steve Alexander from comment #907) > (In reply to cris223 from comment #905) > > (In reply to Steve Alexander from comment #904) > > > I discovered a work-around, suggesting a bug. > > > > [...] > > This work around with > > options snd_sof_intel_hda_generic hda_model=17aa:3801 > > > > I confirm is available for 16IAP7 model as well > > > > Thank you Steve...(i was trying this option "#options snd-hda-intel > > model=,17aa:3801" and i gave up cause it didn't work) > > It might helps the devs if you posted the 16IAP7 sub-idents ... like the > output of > this command for a Lenovo (17aa). I suspect the SND_PCI_QUIRK idents are > either > incomplete or incorrect. > > $ alsa-info.sh --no-upload --output ./X 2>/dev/null 1>&2 ; grep -A4 > "Manufac" ./X ; grep 17aa ./X Here is the X file https://github.com/322sirc/nemesis/blob/main/X