Jump to content

AppleALC — dynamic AppleHDA patching

vit9696

By vit9696,
in AppleALC

 Share
5,371 posts in this topic

Recommended Posts

LockDown
LockDown
Posted
Posted

Here

https://www.dropbox.com/s/2vvizizwkc6s1c7/ResourceConverter.zip?dl=0


I see no HDEF detection in the log, did something happen to your DSDT? I do not see a reason for something like to fail specifically for some build. Did you check the latest revision?

thats what always happen every time ALC won't load. OS X change something to it when everything is ok

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

10.7.5 compilation

error: -fobjc-arc is not supported with fragile abi
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1

if I choose only 64bit then ResourceConverter is successfully compiled

but kext no

 

%D0%A1%D0%BD%D0%B8%D0%BC%D0%BE%D0%BA+%D1

 

 

PS. I also can't attach files

Link to comment
Share on other sites
LockDown
LockDown
Posted
Posted

There is something in that source which doesn't want to load in Lion & ML. I mean, i can now compile from Xcode 4.6.3 to 7 with no errors at all. But the kext just refuse to load in Lion & ML. 

 

 

With vit9696 & now Slice on it, I'm sure they will find a solution to this :)

Link to comment
Share on other sites
vit9696
vit9696
Posted
  • Author
Posted

Here

https://www.dropbox.com/s/2vvizizwkc6s1c7/ResourceConverter.zip?dl=0

 

thats what always happen every time ALC won't load. OS X change something to it when everything is ok

This tool does not crash for me. Neither on 10.11, nor on 10.8.

 

AppleALC must be compiled for 64-bit architecture.

It must also be built with c++11 complaint compiler (formerly c++14 complaint).

 

Xcode 4.6/5 should be capable of building it. However, I do not know why the kext is not loaded. I will recheck the IOKit docs, perhaps, I forgot something vital which was important in 10.7.

  • Like 1
Link to comment
Share on other sites
vit9696
vit9696
Posted
  • Author
Posted

Alright, I fixed 10.7/10.8 loading.

One needs a 10.7(10.8) SDK and the latest Xcode (well, something newer than 4.4, I used 7.3) to build for these OSes.

 

Please check that the kext still works on 10.9+ in -alcpolicy (default) and -alciokit (needs to be passed via boot-args) modes.

IOResourceMatch property which seems to be required by 10.7/10.8 may cause an undesired effect on other systems.

  • Like 1
Link to comment
Share on other sites
toleda
toleda
Posted
Posted

Excellent work; Maximus VII Impact/ALC1150/layout-id: 1 working

Comments/Suggestions:

  1. appleALC/Resources
    1. 892/Info.plist/Author: toleda 
    2. 898/Info.plist/Author: toleda 
    3. Missing: 269/BRIX, 283/NUC, 885, 887, 888, 889 (all present in PinConfigs.kext)
    4. Missing/1150: layout3.xml.zlib, Platforms.xml.lib (updated)
  2. appleALC/Resources/PinConfigs.kext/Info.plist - not current
  3. appleALC/Resources/Controllers.plist - Default/Not recommended
    1. Suggest user selectable for specific required patch(s)
    2. HD4600 HDMI audio
      1. Delete HD4600 controller/Patches/Item 2, 3 and 4
      2. Credit: TimeWalker75a Post #118, Intel HD Graphics 4600 (Haswell) working displayport
      3. disables 0A0C controller HDMI audio
      4. framebuffer edits: 3 HDMI connectors unlikely, avoid HDMI patch on physical DP connector
      5. requires ACPI edits (dsdt/ssdt) as well as kext edits
    3.  x99 onboard audio
      1. disables 8C20/8 series controller/8 series onboard audio
    4. HD4000 HDMI audio
      1. add framebuffer/desktop:  0x0166000A (current patches are laptop)
      2. framebuffer edits: usually native
      3. requires ACPI edits (dsdt/ssdt/clover)
  • Like 1
Link to comment
Share on other sites
vit9696
vit9696
Posted
  • Author
Posted

Thank you :)

 

I do not maintain the resources and patches, there are other people who do, so I will mostly comment on design details.

 

- Currently the codec lists are heavily revised and cleaned up. Unfortunately it is not going to be possible without thoughtful pull-requests.

- Authors generally stand for maintainers, i.e. whom to blame for the issues. Credits are put to readme files.

- Missing codecs, well, they are to be added at some time if somebody contributes and tests stuff.

- Pinconfigs contain lots of other addition, I am afraid they need to be carefully revised by someone.

- User selectable patches are possible if there are good reasons for them. At this point most are pretty much the only possible ones to be applied, plus they can be overriden by a bootloader. Well, there are lots of design questions in this case as well.

  • Like 1
Link to comment
Share on other sites
vit9696
vit9696
Posted
  • Author
Posted

@toleda,

 

I had a brief talk considering other questions:

- PinConfigs.kext is currently clean, and contains no redundant data. Perhaps you were checking a release version.

- BRIX/NUC stuff is nice but nobody can test them, if you do — make a p/r, or pass the resources at least.

- ALC1150 indeed might miss certain new changes, once again if somebody makes a p/r and tests it I can imagine it to be merged.

From what I can tell ALC1150 is left like that because I do use your layouts, the rest of the codecs are packed with less duplication and generally have one generic config subset: either yours or Mirone's. In most cases such configs do about the same thing, so it is not reasonable to provide more especially for cases when AppleALC is flashed to UEFI.

- regarding ACPI/kext edits — each case is to be discussed concretely. ACPI edits are needed indeed (that's mentioned in FAQ), unrelated to sound patches may also be needed (e. g. framebuffer patches), but we assume that the bootloader is capable of making them.

 

Delete HD4600 controller/Patches/Item 2, 3 and 4

You will have to explain what's wrong with them, I think… They have different counts and are for different OS X versions.

disables 0A0C controller HDMI audio

it does in case it finds a 0xC0C controller. See Device → 3084 (0xC0C) that's a device-id-based match.

framebuffer edits: 3 HDMI connectors unlikely, avoid HDMI patch on physical DP connector

that's a bit out of my sound interest, I got a feeling the patch makes sure that the sound is routed (via both HDMI and DVI), there were no connector patches. But I may ask the person providing it if you name the corresponding AAPL,ig-platform-id.

disables 8C20/8 series controller/8 series onboard audio

Are you sure you understand the logic? The patches are applied on per-device basis. If matching h/w is found they are applied.

add framebuffer/desktop: 0x0166000A (current patches are laptop)

The maintainer says it is also used for laptops and requires an extra LVDS connector patch, that's why he did not add it. I guess the workarounds are discussible.

 

 

———

Uhm... does this thing work for Skylake, HD530, el Capitan systems ?

 

We have been using VooDooHDA but its got some iGain buzzing bug in it. Although it can be worked around by modifying the Kext's Info.plist file.

Everything is in your hands :)
Link to comment
Share on other sites
cecekpawon
cecekpawon
Posted
Posted

No doubt, this is super project (cant make it work with ozmosis though, clover run just cool). But during time its look hard to maintain as i predicted before. Project going large with lot of codecs revision.

 

If i was you, i would like to take out all codecs (leave one as an example) from main project to new sub project as "plugin" things.

 

You may include codecs, pin & patches plus readme / instruction & license (if available) from known distributor like toleda & mirone into main project, and move the other stuffs like above from others to sub project.

 

Main purpose is to easy for maintenance, full support from known contributor. Please take a look my fork https://github.com/cecekpawon/AppleALC/tree/master/ResourcesKeep them update from your repo, swap other codecs before commit to my master.

 

Just my opinion )))

Link to comment
Share on other sites
vit9696
vit9696
Posted
  • Author
Posted

I understand your point, however, I have an opposing view on the topic.

Allowing people to make their own plugins and resources will be more chaotic and uncontrolled than it is now. Such projects may get abandoned, may have no recent changes, will be spread all over the internet with their contents being random and unverified.

I totally discourage any forks made without the intentions to be merged into master, and I do expect that only a centralised approach could lead to a reliable and healthy product in this particular case.

Thanks :)

  • Like 9
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

I totally discourage any forks made without the intentions to be merged into master

 

That is how it should be for any OSS project, except if the goal of the fork is different from the original and there are enough people to properly support it. :)

  • Like 1
Link to comment
Share on other sites
toleda
toleda
Posted
Posted

- PinConfigs.kext is currently clean, and contains no redundant data. Perhaps you were checking a release version.

- BRIX/NUC stuff is nice but nobody can test them, if you do — make a p/r, or pass the resources at least.

- ALC1150 indeed might miss certain new changes, once again if somebody makes a p/r and tests it I can imagine it to be merged.

From what I can tell ALC1150 is left like that because I do use your layouts, the rest of the codecs are packed with less duplication and generally have one generic config subset: either yours or Mirone's. In most cases such configs do about the same thing, so it is not reasonable to provide more especially for cases when AppleALC is flashed to UEFI.

- regarding ACPI/kext edits — each case is to be discussed concretely. ACPI edits are needed indeed (that's mentioned in FAQ), unrelated to sound patches may also be needed (e. g. framebuffer patches), but we assume that the bootloader is capable of making them.

 

You will have to explain what's wrong with them, I think… They have different counts and are for different OS X versions.

it does in case it finds a 0xC0C controller. See Device → 3084 (0xC0C) that's a device-id-based match.

that's a bit out of my sound interest, I got a feeling the patch makes sure that the sound is routed (via both HDMI and DVI), there were no connector patches. But I may ask the person providing it if you name the corresponding AAPL,ig-platform-id.

Are you sure you understand the logic? The patches are applied on per-device basis. If matching h/w is found they are applied.

PinConfigs.kext - OK

BRIX/NUC - tested, same as all my supported codecs.

ALC1150 - not current, layout3 and new Platforms required: 1150.zip

Configs - layout2 (3 port) and layout3 (HD3000/HD4000/HD5xx HDMI audio) are unique with specific pathmaps

0x0C0C - Item 0 and Item 1 are correct, remove Item 2, Item 3 and Item 4 (redundant, no OS X version differences; see TimeWalker post)

No connector patches - actually the Azul and Capri framebuffer patches are connector patches (usually DP2HDMI).

Framebuffers - HD4600/Desktop/0x0d220003 and HD4000/Desktop/0x0166000a

HDMI audio has little in common with onboard audio.

Suggestion: Implement a user selectable Resources folder by developer.

 

AppleALC - matches controller device-id in 1. IOReg, 2. kext or 3. both?

Link to comment
Share on other sites
FredWst
FredWst
Posted
Posted

Hello,

 

PinConfigs.kext can't be inject by OZ on some hack, why don't know... Oz himself, other things ???  (i've one working H97WifiN, not working Z77DS3H)

Like said Crusher install in /S/L/E works.

 

Other ways working for OZ.

 

Recompile AppleALC without pinconfig and dependency.

Put Pincconfig in dsdt.

Put AppleALC in bios rom.

 

Tested this morning works on my Z77-DS3H.

 

 

Fred

  • Like 1
Link to comment
Share on other sites
vit9696
vit9696
Posted
  • Author
Posted
ALC1150 - not current, layout3 and new Platforms required: 1150.zip

Configs - layout2 (3 port) and layout3 (HD3000/HD4000/HD5xx HDMI audio) are unique with specific pathmaps

 

Alright, I included these.

​0x0C0C - Item 0 and Item 1 are correct, remove Item 2, Item 3 and Item 4 (redundant, no OS X version differences; see TimeWalker post)

 

This is not correct. If you look closely, these controller patches are OS X version dependent and the number of replaced entries (Count) differs from version to version.

 

patch #1 is not needed for 10.11

patch #0 does not fit to 10.11 due to count (10.11 AppleHDAController has 6 such entries, and only 5 should be replaced, and 10.9 has only 4)

The latter patches are added to avoid any conflicts with other data in the new OS X versions.

 

AppleALC - matches controller device-id in 1. IOReg, 2. kext or 3. both?

 

Unsure what you mean, but AppleALC resources are applied if and only their device-id, vendor-id, revision-id (AAPL,ig-platform-id, platform type (MacBook or not), etc) match with the ones in IOReg.

Analog codecs also use codec ids and layout-id instead of controller's device-id/vendor-id.

 

​No connector patches - actually the Azul and Capri framebuffer patches are connector patches (usually DP2HDMI).
HDMI audio has little in common with onboard audio.

 

This is correct.

 

​Framebuffers - HD4600/Desktop/0x0d220003 and HD4000/Desktop/0x0166000a

 

Unsure what you mean, there are controller patches with explicit Model → Desktop/Laptop params to apply them only in Desktop/Laptop cases. Do these ones need any changes?

If a specific framebuffer is not used on laptops it is probably useless to specify model property, since it won't be matched anyway. 

(Not the case with 0x0166000A, which has two different patches for Laptops and Desktops).

 

​Suggestion: Implement a user selectable Resources folder by developer.

 

Sounds useless.

 

 

Hello,

 

PinConfigs.kext can't be inject by OZ on some hack, why don't know... Oz himself, other things ???  (i've one working H97WifiN, not working Z77DS3H)

Like said Crusher install in /S/L/E works.

 

Other ways working for OZ.

 

Recompile AppleALC without pinconfig and dependency.

Put Pincconfig in dsdt.

Put AppleALC in bios rom.

 

Tested this morning works on my Z77-DS3H.

 

 

Fred

 

This has to be Oz bug. You could try splitting AppleALC.kext and PinConfigs.kext. I. e. take it out of plugins and put as a separate kext. Will this work?

Link to comment
Share on other sites
FredWst
FredWst
Posted
Posted

This has to be Oz bug. You could try splitting AppleALC.kext and PinConfigs.kext. I. e. take it out of plugins and put as a separate kext. Will this work?

 

 

At the moment, we can say that : those who get AppleALC working with injection in common. Yes it will work in flash with separate kext, but need to recompile AppleAlc to remove dependency. (I think)

For others, will work if do what i explain one post upper.

 

Fred

Link to comment
Share on other sites
vit9696
vit9696
Posted
  • Author
Posted

Well, there is no need in recompilation.
Just take "as.vit9696.PinConfigs" entry out of Info.plist OSBundleLibraries in AppleALC.kext and remove the Plugins folder.
 
If you put a plugin-less AppleALC.kext and PinConfigs.kext to /EFI/OZ/Darwin/Extensions/Common separately, will they work? (Currently not interested in BIOS flashing).

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...