HDMI audio problem

#1

Hi,

We’ve bought several notebooks for schools and we’re struggling to make HDMI sound work with the latest release of Endless OS. These are HP devices based on AMD processors and video cards, here is the excerpt from lspci:

Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] (rev 83)
Subsystem: Hewlett-Packard Company Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445]

The video works flawlessly, the display is mirrored to the external TVs immediately once HDMI is plugged in. I even can see the digital HDMI device in sound output options, but there is no sound, unfortunately. What can be done to troubleshoot the issue?

#2

@leshik
Something that would help us a lot to understand the problem would be this:

  1. Open the application called ‘Terminal’
  2. In this application run the command:

eos-diagnostics

  1. The above command will create a file with the information of your system (example: eos-diagnostic-160614_111731_UTC + 0100.txt); Send us this file so we can analyze and see a possible solution
#3

Yeah, a diagnostics would be helpful here.

#4

@leshik I’ve checked internally and we believe that it’s very likely this bug should be fixed in Endless OS 3.4. If you’re able, we’d appreciate it if you could update one of these machines to the beta channel to test: Endless OS 3.4 Beta is ready for testing! are the instructions to do that.

#5

Yes, you’re right, updating to 3.4 beta helps (maybe 4.15 kernel with its new AMDGPU DC additions is helping). There are some glitches though – e.g. when using mirror mode if you reboot with HDMI connected, after reboot the internal display doesn’t work. What can we do here?

#6

@leshik
Something that would help us a lot to understand the problem would be this:

  1. Open the application called ‘Terminal’
  2. In this application run the command:

eos-diagnostics

  1. The above command will create a file with the information of your system (example: eos-diagnostic-160614_111731_UTC + 0100.txt); Send us this file so we can analyze and see a possible solution
#7

Yes, I’ve got it, but at which moment? After I just plugged HDMI? Or after the reboot with HDMI plugged in and the screen isn’t working, when?

#8

@leshik
After the reboot with HDMI plugged

#9

Aside from the described issue, Endless OS doesn’t remember that screens should be in the mirror mode. Every time I plug HDMI in, the internal screen turns off and the external one turns on with full resolution.

Here are two separate logs.

The first one was taken using VNC. After the boot, I opened the VNC session and saw that the external display was set up as a second screen with huge resolution (it’s a 4k Samsung TV), i.e. Endless OS doesn’t remember that I’ve set it to mirror before the reboot. Once I touched the mouse, the external screen turned on, then I was able to switch it to mirror with F4 button, but the internal display didn’t switch on. Besides that, the desktop was unusable – Google Chrome hung so I had to reboot.

eos-diagnostic-180513_173643_UTC 0700.txt (290.1 KB)

This second one was taken through SSH. No action helped to turn on any of screens, F4 button wasn’t working.

eos-diagnostic-180513_174747_UTC 0700.txt (205.8 KB)

#10

So, HDMI audio now works? But you have issues with hotplug? I’ve opened the an issue with your helpful feedback internally.

#11

Yes, starting v3.4beta (kernel 4.15) HDMI audio works. The problem is with hotplug, I would fix it with udev rules on Ubuntu, but don’t know how to proceed on Endless…

#12

If you have some kind of workaround using udev rules you can put your rules in /etc/udev/rules.d just like on Ubuntu.

When you get into a state where the internal panel is off (against your expectations), are you able to turn it on again by reconfiguring it in Settings->Devices->Displays?

#13

If I boot with HDMI plugged in, I have no way to turn on any of the screens, except by means of VNC, F4 button doesn’t work. I didn’t try the Settings->Devices->Displays through VNC, though, but I can tell that after VNC “revive” the external display, F4 doesn’t help to turn on the internal one. Plus, the system becomes unstable (e.g. Google Chrome hangs).

#14

It sounds like you can also reproduce the internal display turning off if you hotplug the HDMI one?

In either of those cases it would be useful to know if the Settings panel can turn on the display. I would not trust the F4 key to be working properly, we have some known issues there e.g. https://gitlab.gnome.org/GNOME/mutter/issues/129

#15

In my case F4 cycles ok through all 4 configurations. In case when I plug HDMI in after boot, it helps turning internal display on and to mirror mode, everything else is ok then, except the little inconvenience that it doesn’t remember the last configuration (mirror).

The problem arises when I plug HDMI before boot. In this case, the only way to turn on the display (only the external one) is VNC, and the system is unstable. I will try to turn on the internal display through Settings with the help of VNC but I’m pretty sure it won’t work.

#16

As expected, turning on the internal display through Settings didn’t help. Then I played with the xrandr tool a bit. Turned out, there is no way you can turn on the internal display on this hardware after booting with HDMI plugged in unless you disable its output completely beforehand. I don’t know it’s an AMDGPU driver bug or some hardware incompatibility, but I ended up with the following workaround script that I’ve put in autostart:

#!/usr/bin/env bash

HDMI_STATUS=$(</sys/class/drm/card0/*HDMI*/status)

if [[ $HDMI_STATUS == connected ]]
then
  xrandr --output eDP --off --output HDMI-A-0 --mode 1920x1080 --rate 60
  xrandr --output eDP --same-as HDMI-A-0 --mode 1920x1080 --rate 60
fi

The key here is --output eDP --off in the first command, without it no matter what you do after, the internal display won’t turn on. Hope this helps to troubleshoot the issue.

#17

Thanks for sharing your workaround.

My personal recommendation would be to stick with that. It’s far from ideal but we have a history of reporting amdgpu bugs and them not getting any useful response (if any) - even when we have offered to ship the hardware to AMD.

If you do want to follow up a better solution though, and have sufficient time and patience, you can file a bug on https://bugzilla.kernel.org/. You will be asked to reproduce on a newer kernel, and since building your own kernel is not yet supported on Endless you’d have to install another linux distro to do that.

#18