Suchergebnisse

man müsste die SSDT-XOSI irgendwie so bearbeiten, dass sie die "richtige" OS-(windows?)version "reportet", analog zu ubuntu, was das ja inzwischen brav macht. an der baustelle bin ich dran, kapier aber noch nicht so recht, was XOSI zurückgibt, und was zurückgegeben werden müsste, damit der controller dauerhaft im HDA-modus bleibt. aber ich denk mal, das dürfte machbar sein...

ubuntu gaukelt ja selbst...das ganze wird auf try-and-error hinauslaufen, und dafür muss ich erstmal ein wenig hintergrundwissen sammeln gehen...

ubuntu "reportet" ohne manipulationen "windows 2013", was zur folge hat, dass audio nicht im HDA-modus läuft. bringt also nix, wenn macos jetzt irgendwie ubuntu -> win2013 behaupten soll. interessant wärs zu wissen, wie man die SSDT-XOSI anpasst, damit sie ebenfalls ein OS "reportet", was das audio-device im HDA-modus belässt:(Quelltext, 27 Zeilen) die rote (grmpfff.. in der vorschau war sie eben noch rot.. - ich mein if (_osi (darwin) .... ) zeile scheint mir die entscheidende zu sein. und über…

naja... das problem ist ja, dass macos irgendwas reportet, was audio wieder in den dingsdamodus versetzt. ubuntu ist nicht das problem. wir müssen den report von macos gezielt setzen, so das der hda-modus erhalten bleibt.ob eine "umgekehrte bootreihenfolge" was bringt, kann ich nicht sagen. mag sein, vielleicht auch nicht. ich guck mir morgen mal die einzelpatches aus den repositories an. vielleicht versteh ich das doch mal...

das macht ja die ssdt-xosi. die gaukelt irgendein os vor: if (_osi darwin) erzähl irgendwas... so ähnlich. das wird dann wohl reportet, und müsste angepasst werden. früher, beim nutzen einer kompletten dsdt wurde das als patch eingebaut, und die patches waren gezielter, als die ssdt.ich guck mir das nachher an, und auch den link.

probier statt der SSDT-HPET in deiner efi mal die vom anhang aus.

was sagt der ioregistryexplorer? könntest du mal eine ioreg-datei vom rechner hochladen bitte?voodooHDA ist keine gute lösung, und ein paar sachen könnten wir noch probieren, bevor der zum einsatz kommt. ist deine AppleHDA.kext original? oder wurde die mal gepatcht?

nicht screenshot. die ganze ioreg-datei gezippt bitte.edit:teste bitte die angehängte SSDT-HPET mit der angehängten config.plist (ich hab 3 patches in acpi/patch ergänzt, und 3 vorhandene deaktiviert)wenn du gestartet hast, schick mir bitte eine aktuelle system-dsdt

was für eine OC-version ist das? die renames greifen nicht, das ist bei älteren versionen der fall. sollte wenigstens auf 0.6.9 aktualisiert werden, dann würden die patches auch greifen.

in der system-dsdt nachgucken. in den devices HPET, IPIC und TIMR sollte statt _CRS XCRS stehen.

(Zitat von MacPeet)hab ich in der letzten SSDT-HPET gemacht: _CRS-methoden (aus der originalen DSDT) in eine ssdt kopiert, die IRQNoFlag-zeile entfernt, den HPET-BUF0 ebenfalls in die SSDT kopiert, die irgs eingefügt, und im hinblick auf den dualboot das ganze per if (OSI "Darwin" .... differenziert.dazu dann die renames _CRS to XCRS in den jeweiligen devices, ohne die es halt nicht funktioniert. und die sind in der letzten systemdsdt nicht aufgetaucht. das sollte als erstes gefixt werden.

unten in der config stehen die einträge, die ich eingefügt hab. die sollten eigentlich greifen. enable die mal. und dafür alle anderen HPET, IPIC, TIMR disablen.

du nutzt einen opencore-configurator zum erstellen und bearbeiten der config?den punkt "Base" gibts bei dir anscheinend nicht, der gibt an, wo (in welchem device) der rename stattfinden soll:ich bearbeite die configs mit xcode. plist-editor ginge auch.