-
-
macht nix
irgendwann demnächst finde ich bestimmt mal die zeit mir das live anzugucken...
-
Wir hatten gestern nur Zeit für genau einen Versuch. Ich habe mir diesen Beitrag angeschaut (OC-config) Lenovo Thinkpad T450 Bluetooth und Soundprobleme wobei mir aufgefallen ist, dass es an der HDEF injection hapert. Daraufhin wollte ich erstmal primär die Injektion nach HDEF über _DSM testen und habe ein Testproperty hinterlegt. Zudem habe ich mir die noch vorhandenen Unterschiede im ACPI zwischen der Clover und OC EFI angeschaut, auf den schnellen Blick sah es mir so aus als würden unter OC bisher keine IRQ Fixes injected werden (unter Clover HPET, TMR, IPIC...). Deswegen habe ich als ersten test Obst-Terminator dazu geraten die bestehende ACPI Struktur (teilweise) zu deaktivieren (Damit sich nichts in die Quere kommt, diese Angst hat sich später bestätigt) und habe eine DSDT schnellerhand mit den HPET fixes aus einer deiner SSDTs grt + IRQ Fixes und "alc-layout-id" (letzteres wahrscheinlich nicht nötig) ausgestattet. Daraufhin funktionierte bereits die Injektion, Audio aber nur, wenn große Teile der restlichen vorhandenen ACPI Struktur (kommt wohl von irgendeinem Github) deaktiviert waren.
Daraufhin meine Zusammenfassung der gestrigen Erkenntnisse im Discord:
ZitatAlso ich denke es gibt mehrere Probleme, erstmals wurde bei vielen Zwischenergebnissen im Thread (nur schnell überflogen) garnicht mehr die layout-id injected. In dem Fall macht es keinen Sinn an etwas anderem zu arbeiten (wie der Injektion eines anderes layouts), als daran die layout-id korrekt zu injecten. Und in den Fällen in denen die layout-id korrekt injected wurde war es wahrscheinlich eins von 2 Problemen: 1. zu viel Zeug im ACPI was sich in die Quere kommt, injection von Werten die AppleALC/WEG selber fixt, inkonsistente Renames etc. oder 2. der altbekannte IRQ Fix, unter Clover angehakt und beim Übertragen zu OC übersehen und per OC-Hotpatch ein wenig tricky zu implementieren.
-
den ganzen igpukram kann man weglassen bzw vereinfachen. insbesondere die gfx0>igpu renames aus der config könnte weg übernehmen. dann einfach statt igpu in der entsprechenden ssdt gfx0. hat unter clover so beim yoga auch funktioniert.
aber wie gesagt, oc steht bei mir auch auf der liste...
-
Ist für mich jetzt nicht so ganz klar. Hast Du nun Audio mit AppleALC? Mit welcher Id und welchen Ergebnissen/Geräten?
Ferner wurde hier gesagt, dass die DSDT nicht komplett gepatcht ist und Du die nicht benutzen solltest.
Habe auch nie behauptet, dass ich diese komplett gepatcht hätte. Habe nur HDEF eingefügt und einige IRQ´s entfernt (IRQ-Patch).
Ich kann die auch nicht komplett Patchen, denn dafür kenne ich den Rechner zu wenig.
Meine DSDT für meine Rechner sind komplett gepatcht. Dat ist halt der Unterschied, wenn man den Rechner vor sich hat.
Quatsch ist aber, dass man diese nicht verwenden darf, wenn sie doch geht. Wenn man keine gepatchte einträgt, dann wird immer die Clean geladen, welche auch nicht gepatcht ist.
Diese von mir ist quasi die Clean mit den kleinen Änderungen.
Ich glaube hier verstehen einige den Sachverhalt noch nicht richtig.
Auch nach Biosupdate lässt sich auf Grund der bereits gemachten Erfahrungen schnell wieder eine DSDT patchen und warum überhaupt ein Biosupdate, sofern alles super läuft.
Macht man ja ohnehin nun wirklich nicht täglich. Ich verstehe diese Einwände absolut nicht.
Sorry, aber ich bin kein Freund von 20 SSDT´s, wenn auch alles in der DSDT zu regeln geht. Muss alles nur geladen werden, auch wenn es nur Millisekunden sind (je nach Rechner).
-
Sorry, aber ich bin kein Freund von 20 SSDT´s, wenn auch alles in der DSDT zu regeln geht. Muss alles nur geladen werden, auch wenn es nur Millisekunden sind (je nach Rechner).
20 kleine mit je 1 1/2 zeilen finde ich auch nicht gerade prickelnd, aber man kann ja auch alles, was zu tun ist, in einer ssdt unterbringen.. das ziehe ich dann der dsdt doch vor
-
Ich muss mal ein paar Sachen, u.a Missverständnisse richtigstellen. Also eins nach dem anderen:
Hast Du nun Audio mit AppleALC? Mit welcher Id und welchen Ergebnissen/Geräten?
Ja, er hat jetzt (wenn auch rauschendes) Audio mit AppleALC. Wie gesagt, wir haben da nur ganz kurz dran arbeiten können, aber ich habe dir mal den letzten IOReg angehängt, den ich von Obst-Terminator erhalten habe, sowie die "proof-of-concept" DSDT, die ich ihm bereitgestellt hatte.
Ferner wurde hier gesagt, dass die DSDT nicht komplett gepatcht ist und Du die nicht benutzen solltest.
Habe auch nie behauptet, dass ich diese komplett gepatcht hätte.
Erstmal bezog sich das nicht auf deine, sondern auf meine DSDT. Ich habe nicht deine DSDT überarbeitet, sondern mir die Arbeit gespart nachzuvollziehen, was du gemacht hast, und eine neue gepatcht. Diese DSDT ist die "proof-of-concept" DSDT von der ich rede (im Anhang).
Habe nur HDEF eingefügt und einige IRQ´s entfernt (IRQ-Patch).
Dann haben wir also praktisch das Gleiche gemacht. Ich habe ebenfalls nur verschiedene _DSM Properties zu HDEF hinzugefügt und verschiedene IRQs überarbeitet. Ich habe diesen Beitrag verlinkt bekommen und gesehen, dass unter OC die alc-layout-id wohl nicht auf IO Ebene erscheint und zudem mitbekommen, dass verschiedene Versuche die ID zu injecten scheitern. Daraufhin habe ich mich daran gemacht analog zum anscheinend funktionierenden Clover Ordner+IOReg die ID 28 zu injecten. Um zu sehen, ob es überhaupt funktioniert direkt mehrfach (wie gesagt wir hatten keine Zeit) nach folgendem Schema: https://github.com/acidanthera…ppleALC/kern_alc.cpp#L173
Sprich inject von layout-id (wie eh und je, wird zu alc-layout-id gecastet) und alc-layout-id über _DSM, sowie global override durch "alcid" bootarg. Schon hier sieht man, dass die DSDT nur proof-of-concept ist.
Wenn man keine gepatchte einträgt, dann wird immer die Clean geladen, welche auch nicht gepatcht ist.
Ich verstehe nicht genau was du damit sagen willst. Klar wird die in die FW gegossene (dynamische) DSDT geladen, wenn kein Override per Bootloader erfolgt, aber die Idee ist ja die dynamische Struktur der Main-System-Table (DSDT) beizubehalten und diese durch SSDTs zu erweitern...
Diese von mir ist quasi die Clean mit den kleinen Änderungen.
Die von mir ebenfalls, aber hier liegt ja bereits das Problem. Die von uns bereitgestellten DSDTs sind marginal, nicht "komplett" gepatcht und somit nicht als "gepatchtes ACPI" zu bezeichnen. Das heißt es bedarf entweder noch einigen Erweiterungen der DSDT damit auf dem Laptop alles läuft, oder die ACPI Struktur muss noch anderweitig erweitert werden, zB mit SSDTs und Hotpatches. Besonders Renames werden hier problematisch, da OC Hotpatch-Renames vor dem Laden der hinterlegten Tabellen ausführt "Perform binary patches in ACPI tables before table addition or removal.". Vor diesem Hintergrund & wegen den doppelten Injections in meiner HDEF Methode & aufgrund meiner allgemeinen Ablehnung gegenüber gepatchten DSDTs (siehe unten) habe ich dazu geraten meine halb gepatchte proof-of-concept DSDT nicht zu benutzen und stattdessen eine sinnvolle ACPI Struktur aufzusetzen.
Auch nach Biosupdate lässt sich auf Grund der bereits gemachten Erfahrungen schnell wieder eine DSDT patchen und warum überhaupt ein Biosupdate, sofern alles super läuft.
Eine DSDT ist was Device-States und besonders OperationRegions und die darin enthaltenen MMIO Adressen angeht weitaus dynamischer als das, nicht nur Biosupdates, sondern besonders BIOS-Settings und Boot-environments (OS), sowie Hardware-Veränderungen und BIOS-Patches haben Einfluss auf die DSDT und verändern dieses dynamische Konstrukt. In dem Moment wo wir eine DSDT (über zB MaciASL) auslesen sehen wir den aktuellen Machine-State, das ist ein Snapshot aber nicht mehr und im Falle MaciASL sogar bereits durch das Boot-environment modifiziert. Wenn wir diesen Snapshot als Basis für eine DSDT nutzen, die allgemeingültig sein soll und unter OC selbst mit Windows kompatibel sein muss, sind wir meiner Meinung nach auf dem Holzweg. Der beste Weg sollte deshalb sein die bestehende ACPI Struktur höchstens zu ergänzen und diese Ergänzungen möglichst dynamisch zu gestalten, und das passiert am allerbesten indem man ACPI Patches umgeht und IO-Patches (siehe WEG & AppleALC) benutzt und wenn es doch ACPI sein muss, dann auf SSDTs zurückgreift und diese mindestens Boot-environment-abhängig gestaltet (_OSI-abhängige Konstrukte um zB Windows-Kompatibilität zu sichern). Und ob das jetzt 20 oder 2 SSDTs sind ist erstmal Präferenz des Users (Übersicht etc.) und der Injection-Zeit-Unterschied von 20 SSDTs gegenüber von 2 sollte erstens marginal sein und zweitens zu vernachlässigen sein gegenüber der Zeit die es braucht den Inhalt der SSDT-Tabellen zu Parsen ganz zu schweigen vom Blocken und Parsen einer kompletten DSDT. Und was Renames angeht, sollten globale Hotpatch-Renames benutzt werden, denn beim Durchführen von Renames in einer DSDT, müssten ohne Hotpatch alle anderen Tabellen, die auch die umbenannten Devices enthalten, ebenfalls gepatcht und explizit gepatcht injected werden, da es sonst zu Device-Name Inkonsistenzen kommen würde, aber ich glaube das ist klar.
Ich hoffe es fühlt sich niemand angegriffen, ich wollte nur meine Gedanken zu dem Thema loswerden und wenn es andere Erkenntnisse gibt lasse ich mich auch gerne eines besseren belehren
Ansonsten angenehme Weihnachtsferien an alle! -
Guten Morgen an alle Leser,
da ich speziell im Bereich DSDT nicht besonders fit bin, sei gesagt, dass ich zu dem was kuckkuck sagt nichts hinzufügen kann.
Wir haben gestern nochmal etwas rumexperimentiert und laden jetzt deine DSDT in Kombination mit den SSDT's die bereits für die Batterie und ACPI-Tasten, sowie für das Touchpad vorhanden waren. Die Renames und HotPatches die wir unter ACPI --> Patch eingetragen haben, waren nicht mehr nötig, also haben wir die nach und nach rausgenommen, bis halt keiner mehr übrig war. Der Rechner bootet und AppleALC arbeitet.
Die internen Lautsprecher, sowie das Mikrofon arbeiten korrekt, über die Klinke erhalte ich ein kontinuierliches Rauschen.
Bei Interesse, kann ich den aktuellen Stand heute Mittag nach meiner Schicht hochladen. IOREG kann ich auch gerne nochmal erstellen, falls da nochmal wer reinzuschauen mag.
Danke nochmal an alle die bis jetzt mitgewirkt haben, ich finds klasse, anregende Diskussion motivieren mich 😊
Hoffentlich ist der EFI Ordner am Ende anderen ebenso dienlich 😊
-
das mit der nicht funktionierenden klinke hatte ich ebenfalls, sowohl beim T440(s), als auch beim T450. wenn da überhaupt was rauskommt, dann rauschen.
-
Naja, es wird wohl eine Geschmacksfrage bleiben und Ihr könnt dat auch machen wie Ihr wollt, allerdings werden seit vielen Jahren schon DSDT´s gepatcht und dass ohne Probleme, auch mit Kompatibilität für Windows.
al6042 hat dafür auch mal eine schöne Anleitung geschrieben.
Auch die von MaciASL ausgelesene ist durchaus gebräuchlich zum Weiterpatchen, was auch nicht neu ist.
Falls man überhaupt ein Bios-Patch braucht, dann spielt man ein MOD-Bios in der Regel nur einmal auf und lässt ohnehin die Finger von den normalen Updates.
Ferner ändern sich mit einem Bios-Update evtl. auch die ganzen External-Einträge zu den SSDT´s und ggf. müssen dann auch diese überarbeitet werden.
Aber auch egal jetzt.
Zum Thema:
Sind die gemachten Erkenntnisse denn auch anwendbar auf die ID32, die ja für den T450 gedacht war, bzw. auf 15/16 mit den Versionen von mir?
Die ID 28 scheint ja noch nicht optimal zu sein.
-
kann ich leider nicht mittesten, T450 waren besuchsläptopps, die wieder bei ihren besitzern sind. und T440s ist im moment stillgelegt...
-
In der DSDT steht die Nummer 28 als layout-ID und als ALC inject. Die 32 hatte ich getestet sowie die layout-ID 55 bei beiden hatte ich kein Gerät.
Die Arbeiten an deinen angepassten layout ID's habe ich noch nicht aufgenommen, werde ich aber, sobald ich von der Schicht Zuhause bin noch einmal in Angriff nehmen und dort berichten.
Zur Vorgehensweise: Ich nehme deine angepasste AppleALC und Lilu wieder in meinen EFI Ordner auf, und teste dann die ID's 15 und 16 und berichte dir was geht, was nicht richtig, oder nur teilweise funktioniert, richtig?
-
Obst-Terminator Hast du auch die zweite DSDT getestet, die ich dir noch gesendet hatte? Da taucht auch kein Audio-Gerät im Systembericht auf?
Abgesehen davon sollte der Inject von verschiedenen Layout-IDs ja jetzt funktionieren. Häng dich also am besten einfach an unseren AppleALC Spezialisten MacPeet an, ich bin mir sicher ihr werdet irgendetwas finden
MacPeet Was unsere Offtopic Diskussion angeht: Es mag in Teilen eine Geschmacksache sein, in den allermeisten aller Fälle ist die SSDT- und Hotpatch-Methode aber schlichtweg die bessere, sauberere und zuverlässigere Methode und der beste Weg dirty ACPI Relocate-Patches (wie FixRegions) oder gar -Konflikte zu umgehen und das ist ebenfalls seit langem bekannt. Ich weiß wie man eine DSDT patcht und welche Patches dabei allgemein verwendet werden, ich weiß auch wie das ACPI funktioniert und deswegen sind mir auch die Probleme von DSDT Injections bekannt, sowie dass allerhand User von iASL ausgelesene DSDTs patchen und benutzen. Ich sage auch nicht, dass letzteres pauschal falsch ist, aber wie oben genauestens erklärt ist diese Vorgehensweise nicht zukunftssicher und Allem voraus nicht Windows-Kompatibel, siehe Operating System Interface Level und ACPI Interface im ACPI Spec, und somit mindestens für OpenCore nicht geeignet.
ändern sich mit einem Bios-Update evtl. auch die ganzen External-Einträge zu den SSDT´s
Du meinst komplette Device-Names wie sie in Add-On SSDTs meist innerhalb von External-Deklarationen vorhanden sind? Das wäre mir neu, diese sind sogar fast immer innerhalb aller Boards eines Herstellers, eines Chipsatzes, konsistent...
-
Hallo zusammen! Bin endlich zum Testen bekommen. Ich habe zwischen jedem layout-ID und alc-ID-layout Wechsel einen NVRAM Reset gemacht um Unstimmigkeiten zu vermeiden. Anbei der ZIP-Ordner mit allen IOREG's und was funktioniert und was eben nicht.
Spoileralarm: Warum auch immer habe ich überall exakt das selbe Ergebnis.
-
Es ist alles ok kuckkuck , hat alles seine Berechtigung was Du schreibst.
SSDT´s sind ja nix weiter wie ausgelagerte Erweiterungen der DSDT, welche am Anfang der DSDT mit External-Einträgen verlinkt werden. Im Prinzip modulare Softwareentwicklung.
Unsere modernen Bootloader sind ja auch in der Lage andere selbst erstellte SSDT´s einzubinden, fern ab von den Originalen.
Wenn jedoch die originalen SSDT´s bearbeitet werden, dann kannst Du Dich niemals darauf verlassen, dass der Hersteller diese nicht bei einem Biosupdate auch mal ändert und dann wäre dort auch diese ganze Dynamik hin, so wie Du sie für die DSDT beschreibst.
Ich persönlich habe halt keine Lust 16 Dateien öffnen zu müssen um mir halbwegs einen Überblick zu verschaffen (letztes gepostetes EFI ACPI/patched). Wie ich schon schrieb, eine Geschmacksfrage.
Auf die Tests mit den anderen ID´s bin ich auch gespannt. Hat sich hier der Name geändert? Habe ich nicht vorher mit irgendeinem Gemüse geschrieben?
-
-
Wir hatten wohl gedoppelt, also zeitgleich geschrieben. Alles gut soweit.
Du hast jetzt mit allen ID´s (15/16/28/32) Audio, jedoch die Problem mit den Kopfhörern? Habe ich dat so richtig verstanden?
-
Nicht ganz richtig verstanden.
layout 15, 16, Audio, kein Mikro, Klinkenrauschen
layout 28, 32, Audio, Mikro, Klinkenrauschen.
Edit: Ist ein Klinken-Mikro-Headphone Kombianschluss habe ich gerade mal so festgestellt.
-
Mit layout 28, 32, Audio, Mikro, Klinkenrauschen ist internes Mic gemeint?
Ist schon klar, dass es ein Kombianschluss ist. Diese machen ja gerade die Probleme unter OSX.
Toll wäre aber zumindest eine Konfiguration Speaker und Kopfhörer sauber und internes Mic, dat wäre für einen Laptop völlig ausreichend unter OSX.
Externes Mic von dem Kombi braucht auf dem Laptop eigentlich keiner. Nur schade, dass gleichzeitiges Kombi-Device (Kopfhörer/ext.Mic) scheinbar zu Störungen führt.
-
Richtig, damit meinte ich das intere Mic. Was meinst du, ist da was zu machen?
