Closed ReddestDream closed 4 years ago
Fixed via IGD OpRegion for Ivy Bridge and Haswell.
Broadwell has a different "chipmunk" issue.
edited title to reflect working state of HDMI audio under Windows as of 11/16 UEFI firmware release
I'll test soon on OS X to see if it has been fixed as well.
Confirmed. Still broken on OS X. HSW and BDW.
This is a non-issue in the firmware. HDMI audio in macOS doesn't work on my non-chromebook Lenovo Flex 3 hackintosh either (Intel HD 520 with Phoenix UEFI firmware). macOS just needs extra configuration and possibly patches.
If we can find a way to make it work w/o any changes to the firmware, and there's nothing to be gained by adding anything to the firmware (too OS X specific, as with the graphics, and makes more sense in an SSDT), then I will gladly close this issue.
@ReddestDream I recently figured out the reason. Basically pci device 8086:160c
was not named as HDAU
in DSDT. So I named that device as HDAU and HDMI audio works now.
You can use this dsdt with AppleALC.
https://github.com/xjbhenry/asus-chromebox-cn62-hackintosh/blob/master/ACPI/dsl/SSDT-HDAU.dsl
@xjbhenry The fix was not that simple originally. Tho it is good to know that maybe AppleALC fixes this problem now . . .
@coolstar I think we need to add HDAU
in SSDT.
@xjbhenry The fix was not that simple originally. Tho it is good to know that maybe AppleALC fixes this problem now . . .
@ReddestDream Yes, AppleALC can add hda-gfx
and layout-id
for you, and make these values consistent between HDEF
and HDAU
. So you don't need to manually set them.
Oh lol I forgot about this issue, but yes I can confirm.
I’ve been using OpenCore to add HDAU via SSDT for an eternity and had HDMI audio working in macOS on my C720, but I forgot about it lol
Guess we can close this then?
Well might be a good idea to add HDAU to Coreboot's ACPI tables
Ah. Maybe . . .
Well might be a good idea to add HDAU to Coreboot's ACPI tables
for what device(s)? There's maybe 1-2 that can run MacOS passably? and if one can work around it in OpenCore, same as one would on a normal PC, then I'm not sure how much of an issue this is
Coreboot could have the HDAU for HSW/BDW devices with the ADR set. Then the opencore SSDT only needs to add the DSM rather than the entire device (or clover can add the macOS properties without SSDT with HDAU added)
On Sun, May 17, 2020 at 8:40 PM MrChromebox notifications@github.com wrote:
Well might be a good idea to add HDAU to Coreboot's ACPI tables
for what device(s)? There's maybe 1-2 that can run MacOS passably? and if one can work around it in OpenCore, same as one would on a normal PC, then I'm not sure how much of an issue this is
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MrChromebox/firmware/issues/5#issuecomment-629928509, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK5P7G2YLOGJ7ZGRLGVKL3RSCU2ZANCNFSM4COQX4MQ .
For Asus Chromebox 2 (CN62) GUADO, I think potentially we could add HDAU for all Haswell/Broadwell
Coreboot could have the HDAU for HSW/BDW devices with the ADR set.
sure, I can do that. Just need the snippet and where to add it
Something like this could work
Device (HDAU)
{
Name (_ADR, 0x00030000) // _ADR: Address
}
Could probably add it to src/northbridge/intel/haswell/acpi/haswell.asl and src/soc/intel/broadwell/acpi/systemagent.asl underneath the include for drivers/intel/gma/acpi/pch.asl
(Don't stick it in drivers/intel/gma/acpi/ though because Skylake+ does not have a separate HDAU device. They run HDMI audio through the normal HDEF as a 2nd codec)
done
confirmed working in 4.12 release; closing
HDMI Audio is broken on HSW/BDW on both Windows and OS X. On Windows, CS has found a workaround using a third party program to get the EDID data and then use that to start HDMI audio. This has to be done on a per-display basis.
https://www.reddit.com/r/chrultrabook/comments/4j42ln/tutorial_enable_hdmi_audio_in_windows_no_linux/
Thanks!