Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1818129 - Lenovo P1 gen2: HDMI audio not working. Video only working with nouveau and wayland
Summary: Lenovo P1 gen2: HDMI audio not working. Video only working with nouveau and w...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: wayland
Version: 32
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Lyude
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1816645 F32FinalBlocker 1816768
TreeView+ depends on / blocked
 
Reported: 2020-03-27 19:42 UTC by Mark Pearson
Modified: 2020-08-12 13:02 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-12 13:02:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Mark Pearson 2020-03-27 19:42:49 UTC
Description of problem: I reproduced this on the Lenovo P1 Gen2 but it's also seen on the X1 Carbon 8 . HDMI audio is not working at all - I've not found any combo that works. There are four HDMI audio ports that show up in settings but none of them work. Interestingly after trying them the internal speaker stops working as well
HDMI video only seems to work with the nouveau driver under wayland. I tried with the Nvidia proprietary drivers and the i915 (no signal found, display not detected under settings). Nouveau under xorg also doesn't work interestingly
Side note - the first time I got video working there was a lot of flickering on the local display, but I've not been able to reproduce that since

Version-Release number of selected component (if applicable): NA


How reproducible: Very


Steps to Reproduce:
1. Connect HDMI cable to suitable device (I used my TV)
2. If connection seen (nouveau /w wayland) play a video or use test options in audio settings. 


Actual results: No audio. Video only working in limited cases


Expected results: Connection detected and both audio and video working


Additional info: Reproduced by our test team on other units.
Let me know if there is any useful data I can collect - I didn't see anything useful in dmesg so haven't attached that

Comment 1 Mark Pearson 2020-03-27 19:44:35 UTC
The comment on X1G8 might be misleading - that issue was related to the lack of SOF firmware. I'll check but this might only be affecting the P1G2

Comment 2 Hans de Goede 2020-04-15 14:50:24 UTC
So I've just checked this on the X1C8 and both video output and audio (*) output overt the HDMI connector on the laptop work fine.

*) when selecting HDMI1/DP1 as output

Comment 3 Mark Pearson 2020-04-15 14:53:52 UTC
OK - sounds like I should retest with my P1G2. Thanks
Mark

Comment 4 David Ober 2020-04-30 12:31:16 UTC
When I test on the GA release and the P1 Gen2 in Discreet mode I do not get the HDMI as a selectable device in the GNOME sound settings screen, in Hybrid mode I do get devices as available but no sound from any of the 4 available devices.  When Testing on the P53 I have 4 HDMI devices available in the sound settings but none of them actually have any sound output.  On the P53 this is the same in either discreet or hybrid mode.  To verify my setup I did test on the X1C8 and yes the sound is output on that machine

Comment 5 Mark Pearson 2020-05-04 18:50:40 UTC
Hi Hans - is the above useful? Looks like a potential nouveau problem? 
My P1G2 is tied up with another OS right now - I'll retest there as soon as possible. Does anybody with graphics/audio experience in RH have either the P1G2 or P53 who can look at this? 
Let us know if any logs or details would be particularly useful.

THanks
Mark

Comment 6 Hans de Goede 2020-05-05 10:05:40 UTC
(In reply to Mark Pearson from comment #5)
> Hi Hans - is the above useful? Looks like a potential nouveau problem? 

Yes I _guess_ that on both the P1G2 and the P53 the external connectors are always hooked up to the NVidia GPU and the discrete / hybrid switch only selects which GPU drivers the internal panel. So for audio to work we need to have audio support for the generation of NVidia 
GPUs which is used on these models and I'm not sure if that is in place yet. So yes this seems to be a nouveau (related) problem.

> My P1G2 is tied up with another OS right now - I'll retest there as soon as
> possible. Does anybody with graphics/audio experience in RH have either the
> P1G2 or P53 who can look at this? 

I do not know if anyone in Red Hat has access to either of these models.

Comment 7 Mark Pearson 2020-05-05 12:44:26 UTC
Thanks Hans,

Strange - I thought we made sure you guys had all the HW that was part of the Fedora release project. I'll track down with Vamshee where they went.

The Nvidia cards for these platforms are over a year old at this point - do we have good contacts at Nvidia who can have a look at this? It would be good to at least make sure it's fully understood and have a plan for a fix - this is the last "big" issue from the Fedora testing exercise.

Thanks
Mark

Comment 8 Tomas Popela 2020-05-05 12:48:26 UTC
(In reply to Mark Pearson from comment #7)
> Strange - I thought we made sure you guys had all the HW that was part of
> the Fedora release project. I'll track down with Vamshee where they went.

The P1 should be in possession of Karol, P1 and P53 is supposed to be with Ben Skeggs and the P53 now with Tom Pelka I think.

Comment 9 Tomas Popela 2020-05-05 12:48:42 UTC
(In reply to Mark Pearson from comment #7)
> Strange - I thought we made sure you guys had all the HW that was part of
> the Fedora release project. I'll track down with Vamshee where they went.

The P1 should be in possession of Karol, P1 and P53 is supposed to be with Ben Skeggs and the P53 now with Tom Pelka I think.

Comment 10 Hans de Goede 2020-05-05 12:58:22 UTC
(In reply to Mark Pearson from comment #7)
> Strange - I thought we made sure you guys had all the HW that was part of
> the Fedora release project.

Right, I was not trying to deny that we have access. What I was trying to say when I said "I do not know if anyone in Red Hat has access to either of these models", was simply that I did not know. I was trying to neither deny nor confirm that we have access, sorry if I was unclear.

Comment 11 Mark Pearson 2020-05-05 13:02:31 UTC
No worries :) I realised that right after I hit save too. Sounds like we know where they are now but if you need help tracking down where they got sent just let me know

Mark

Comment 12 Karol Herbst 2020-05-05 14:05:50 UTC
(In reply to Tomas Popela from comment #8)
> (In reply to Mark Pearson from comment #7)
> > Strange - I thought we made sure you guys had all the HW that was part of
> > the Fedora release project. I'll track down with Vamshee where they went.
> 
> The P1 should be in possession of Karol, P1 and P53 is supposed to be with
> Ben Skeggs and the P53 now with Tom Pelka I think.

yeah.. I have the P1 and I actually also have a display which supports audio over HDMI.. I never thought about testing this here. Will give it a try later and see whats up

Comment 13 Mark Pearson 2020-05-14 18:26:54 UTC
Hi Karol,
Where you able to reproduce this one?  I'm intrigued if it's going to be a tough one to solve or not
Thanks
Mark

Comment 14 Karol Herbst 2020-05-14 18:50:57 UTC
(In reply to Mark Pearson from comment #13)
> Hi Karol,
> Where you able to reproduce this one?  I'm intrigued if it's going to be a
> tough one to solve or not
> Thanks
> Mark

sorry for not replying earlier, but I was not able to reproduce it yet as I am running into another bug Lyude was working on in the past. As it turns out we have an issue with interlaced modes and the HDMI display with audio is an old TV with interlaced modes.

But we also have some patches already which might address the audio issue, I just can't verify it with the interlaced stuff in the way.

Comment 15 Karol Herbst 2020-05-14 18:52:52 UTC
ohh, seems like I missed those getting merged, will test the audio stuff until the end of this week then.

Comment 16 Mark Pearson 2020-05-14 19:24:29 UTC
Magic - thanks for the update
Mark

Comment 17 Karol Herbst 2020-05-15 11:48:45 UTC
tested with the patches applied and it does seem to fix the issue. So I guess we probably want to get those backported, otherwise users will have to wait until linux 5.8 gets released.

Comment 18 Mark Pearson 2020-05-15 12:03:59 UTC
Thanks Karol,

Just for the update - great there is a fix. Can you include details of the relevant patches, I try and keep a little bit of track of things like this (emphasis on try :P).

If we can get them backported that would be great.

Do you want me to raise a corresponding bug for RHEL 8.2 so it gets tracked there too?

Mark

Comment 19 Karol Herbst 2020-05-15 12:31:18 UTC
(In reply to Mark Pearson from comment #18)
> Thanks Karol,
> 
> Just for the update - great there is a fix. Can you include details of the
> relevant patches, I try and keep a little bit of track of things like this
> (emphasis on try :P).
> 

sadly those are only in bens nouveau tree, so it's hard to give definite commits ids as those could change.

anyway, there are two kinds of fixes I needed on the P1 Gen2:
1. supporting interlaced modes on Turing
2. fix HDMI audio

for 1. Lyude wrote patches to support this and additionally to reject interlaced modes on connectors not being able to support those, like we have that with DisplayPort generally. I don't have any kind of USB-C to DP adapter though, so I can't test those on the P1 Gen2 specifically.

for 2. Ben fixed that and the general issue I think was that we messed up doing the proper routing of the Audio channel. It's a regression since Volta, so that should be relevant for all Turing GPUs as well.

you can see the patches here, but the link might become invalid in the far future: https://github.com/skeggsb/nouveau/compare/c0d1c26336ef419fd3ba7fd7efaf79c085b006c5...0ea6b94989478f905e54871b3e1502c11a260d42

> If we can get them backported that would be great.
> 
> Do you want me to raise a corresponding bug for RHEL 8.2 so it gets tracked
> there too?
> 

If you think it's important to have those backported to 8.2 then yes. Having partner bugs here always helps.

> Mark

Comment 20 Mark Pearson 2020-05-15 13:30:00 UTC
I think it would be good to have these in 8.2 so I'll get that bug created.

Just for my learning/understanding - what is the process for getting these pulled in? I assumed I'd need to wait until they had landed in Linus's tree before they can go into Fedora - or is Ben's tree considered official enough that it counts? (still finding my way around the different repositories and how they tie in).

Mark

Comment 21 Hans de Goede 2020-05-15 14:01:18 UTC
(In reply to Mark Pearson from comment #20)
> Just for my learning/understanding - what is the process for getting these
> pulled in? I assumed I'd need to wait until they had landed in Linus's tree
> before they can go into Fedora - or is Ben's tree considered official enough
> that it counts? (still finding my way around the different repositories and
> how they tie in).

Since Ben is the official upstream nouveau maintainer patches being in his tree are pretty much guaranteed to end up in Linus' tree as is. So in this case it should be fine to add these patches as downstream fixes to the Fedora kernels for now.

I'll take a look at adding them coming Monday.

Comment 22 Hans de Goede 2020-05-18 13:10:41 UTC
Ok, so backporting these was kinda tricky, for one the list of commits from the link in comment #19 was incomplete, e.g. it was lacking this one which seems to be necessary for at least the interleaved mode bits:

https://github.com/skeggsb/nouveau/commit/bee602c794537c79b42a47c9dfcae4c60c46ac82

And there were some others too.

Anyways I've completed a backport to the 5.7-rc6 kernel. 5.7 will be out soonish, so I'm not sure if it will be worth the trouble to also backport this to 5.6 (and figure out which if any additional patches are needed).

Mark, I have a test-build of the 5.7 kernel with the backported patches added building here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44650359

This should be done in about 2 hours from now.

See here for some generic instructions for directly installing a kernel from koji:

https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Note since this is not an official build you need to disable secure-boot to boot it.

Mark, if you can let me know if this fixes HDMI audio on the P1 Gen 2 for you that would be great. Once I have confirmation that the backport actually works I can add it to the rawhide kernels and then it will also be in the F32 update for moving F32 over to the 5.7 series in approx. 6-7 weeks from now.

p.s. koji (our buildsystem) throws away test-builds after a couple of days to save diskspace. So please download the kernel rpms from the koji link soon-ish.

Comment 23 Hans de Goede 2020-05-20 16:13:36 UTC
Note, the test kernel is long ready now. Mark and/or Karol if either one of you could give this kernel:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44650399

A test spin on your P1 Gen 2 and test if HDMI audio now works, then that would be great.

Comment 24 Mark Pearson 2020-05-20 16:20:03 UTC
Yeah - sorry, it's been on my todo list and I *almost* started it yesterday but got sidetracked. I'll get it done ASAP
Mark

Comment 25 Mark Pearson 2020-05-20 22:24:59 UTC
Hi Hans,
Tested and it works! Thank you.
Only minor quibble - audio doesn't switch automatically to the HDMI output when it's plugged in. Had to go to the sound settings and switch it manually. Tweak in pulseaudio? That part is much more minor though :)

Mark

Comment 26 Hans de Goede 2020-05-21 14:19:34 UTC
(In reply to Mark Pearson from comment #25)
> Tested and it works! Thank you.

That is great, thank you for testing.

> Only minor quibble - audio doesn't switch automatically to the HDMI output
> when it's plugged in. Had to go to the sound settings and switch it
> manually. Tweak in pulseaudio? That part is much more minor though :)

Maybe, it is probably best to file a new big for this against pulseaudio.

Comment 27 Christian Fredrik Kalager Schaller 2020-05-21 14:59:51 UTC
The switching issue has been an open question for a long time. The response I got when I brought it up was that just because someone plugs in an HDMI plug does that mean we know that they want to move their
audio to it? Is that truly the expected behavior? Personally I know I have had cases where I wished the audio got moved automatically, but I also had cases where that behaviour would be really annoying. I have pondered though if we should ask the user somehow though. Like 'hey, we noticed you just connected a HDMI output that has audio support, do you want to move audio playback to that device?' Not sure where such a question should appear though as in general people, myself included, hate random global pop-ups.

Comment 28 Karol Herbst 2020-05-21 15:43:09 UTC
(In reply to Christian Fredrik Kalager Schaller from comment #27)
> The switching issue has been an open question for a long time. The response
> I got when I brought it up was that just because someone plugs in an HDMI
> plug does that mean we know that they want to move their
> audio to it? Is that truly the expected behavior? Personally I know I have
> had cases where I wished the audio got moved automatically, but I also had
> cases where that behaviour would be really annoying. I have pondered though
> if we should ask the user somehow though. Like 'hey, we noticed you just
> connected a HDMI output that has audio support, do you want to move audio
> playback to that device?' Not sure where such a question should appear
> though as in general people, myself included, hate random global pop-ups.

this is about a different issue though. With HDMI you usually have various configurations on the HDMI audio device and only one of those actually works. Usually they are called something with "HDMI 1", "HDMI 2", and so on...

Comment 29 Mark Pearson 2020-05-21 18:42:07 UTC
As an aside on my TV I got only one HDMI option...so if there's only one option can it be selected by default?

I created a separate bug for the audio switching item - suggest further comments go there though I did reference this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1838772

Let me know if anything else is needed on my side. I'm not going to raise a bug for the audio switching against RHEL - doesn't seem an issue worth duplicating and double tracking (for now). 

Thanks
Mark

Comment 30 Hans de Goede 2020-05-25 08:22:43 UTC
I've created a merge-request to get these added to the Fedora 5.7 kernel. Once this is merged these patches will be part of the next F33/rawhide kernel build:

https://gitlab.com/cki-project/kernel-ark/-/merge_requests/384

Comment 31 Hans de Goede 2020-05-27 13:53:04 UTC
As discussed per email I'm making this bug public (removing the private group from the group list).

Comment 32 Mark Pearson 2020-06-22 10:59:40 UTC
Hi Lyude,

Could I get an update on how this is progressing for getting into F32 please? 
I wasn't sure if these were in F32 yet and how long that would take. Please let me know how the process works - if there's a way I can check myself that would be cool. I looked at the merge request and that looks complete but I wasn't sure how that then filtered through the rest of the process

Thanks
Mark

Comment 33 Hans de Goede 2020-06-22 11:31:45 UTC
Mark,

The patches are part of the Fedora 5.7.x kernel builds such as this one:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1525073

If you can give that build a test that would be great, also on other models.

The Fedora kernel team usually waits a few weeks after a new upstream release before dropping the latest kernel into updates-testing. As you can see the Fedora kernel team is already doing Fedora 32 5.7 builds. I guess it will show up in updates-testing in 1-3 weeks from now and then depending on how the testing goes moves to the normal updates repo 1-2 weeks after that.

Comment 34 Mark Pearson 2020-06-22 17:45:36 UTC
Hi Hans,

I tried the images (core and modules) and am not able to boot (failed to Load kernel modules).
Did I mess up in the install or is it a build issue? 

Mark

Comment 35 Hans de Goede 2020-06-23 11:32:14 UTC
(In reply to Mark Pearson from comment #34)
> I tried the images (core and modules) and am not able to boot (failed to
> Load kernel modules).
> Did I mess up in the install or is it a build issue? 

I've just given the build I linked to a try on the X1C8 and it works fine for me, what I always do is download both kernel-core-xxx.x86_64.rpm and kernel-modules-xxx.x86_64.rpm and then from a dir with bot files run:

sudo rpm -ivh kernel-*.rpm

Note that the -core and -modules both have normal varients and debug variants:

Normal:
kernel-core-5.7.4-200.fc32.x86_64.rpm
kernel-modules-5.7.4-200.fc32.x86_64.rpm

Debug:
kernel-debug-core-5.7.4-200.fc32.x86_64.rpm
kernel-debug-modules-5.7.4-200.fc32.x86_64.rpm

Could it be that you downloaded the normal core and the debug modules and thus do not have modules (for the normal core), or perhaps the other way around?

Comment 36 Mark Pearson 2020-06-23 17:29:52 UTC
Weird - I'm definitely loading those two rpm's and I've removed, re-downloaded and reinstalled them and I still get "Failed to start Load Kernel Modules". The initramfs seems to be wrong but I've not figured out why yet. I tried adding in the other modules (mostly for the heck of it).

Mark

Comment 37 Hans de Goede 2020-06-24 10:32:03 UTC
(In reply to Mark Pearson from comment #36)
> I still get "Failed to start Load Kernel Modules".

Ah that comes from modules which are marked to be loaded "manually" with a .conf file in /lib/modules-load.d/ or /etc/modules-load.d maybe you have something installed which needs the modules-extra package through a conf file dropped there?

You say you are not able to boot, typically a failure to load a module listed in /lib/modules-load.d/ is not fatal. Since you see the error, the system does partially boot, what happens after the error?

Also have you perhaps installed the nvidia binary driver? That can very well break when doing a kernel upgrade.

Comment 38 Mark Pearson 2020-06-24 17:53:34 UTC
Problem found - my fault...sorry! 
I'd been testing systemd changes for the energy cert stuff and the kernel update was for some reason making systemd blow up. I didn't get to the bottom of it - I ended up just reinstalling Fedora.
I updated the kernel to the test images and they are working great - audio and video.
Thanks 
Mark


Note You need to log in before you can comment on or make changes to this bug.