Beiträge von kuckkuck

    Ich benutze zwar kein USBInjectAll mehr, aber wenn ich mir die commits so anschaue, hat sich da eigentlich nicht viel verändert... Die Bezeichnungen HS... sind sowieso ACPI und damit Hardware gebunden, sprich eine Bezeichnung wie HS04 ändert sich nicht mal eben (höchstens BIOS Update). Wieso sollte der PortLimit Patch noch/nicht mehr Sinn machen? Der macht genauso wenig/viel Sinn wie eh und jeh, funktioniert aber soweit ich weiß unter der neuesten Mojave immernoch nicht ;)

    Du kannst ja sagen, dass nicht nur SSDT*.aml, sondern alle Tables aus einem bestimmten Ordner berücksichtigt werden...


    Aber ich bezweifle, dass aus den weiteren Tables noch wichtige Referenzen kommen, die sind größtenteils eigenständig oder noch nicht mal ACPI Tabellen im klassischen Sinne... ;)

    Mit grep alle mal durchgesucht, konnte nichts finden... Vielleicht hab ich was vergessen.


    Ich denke man muss die ganzen Tabellen einfach nur einmal richtig dekompilieren, dann passts. Richtig heißt mit Terminal Befehl und unter Einbezug aller anderen vorhandenen ACPI Tabellen. Dann sollte auch irgendwo die Method (MDBG) erscheinen.

    Hatte das Problem bezüglich MDBG, wobei MDBG weder als Integer, noch als Methode im ganzen ACPI überhaupt existiert... Da müsste man dann schauen wo MDBG überhaupt herkommt. Die danebenliegenden M64B und M64L sind zumindest Integer :/

    Ich denke mal so tragisch wird's nicht sein, hat ja schon häufig funktioniert. Sinnvoll ist es aber sicherlich trotzdem das ganze möglichst original zu belassen. Die Fehler in den OEM DSDTs entstehen ja meistens durch unterschiedliche ACPI Versionen. Versucht zB eine ältere ACPI Version ein Table zu dekompilieren, dass mit einer neueren ACPI erstellt wurde, gibts Fehlinterpretationen.


    Ich denke mal bei den ArgX Problemstellen verhält sich das ganze so ähnlich wie bei den festen Werten, sprich ein (Return (GPRW)           ArgX), wird zu (Return (GPRW (ArgX))), solange das entsprechende GPRW eine Methode und kein Integer ist...


    Hier hat Thogg Niatiz mal was dazu geschrieben: DSDT Sammelthread (Hilfe und Diskussion)

    Die RadeonSensors sind teil der FakeSMC_GPUSensors...




    Wenn du die FakeSMC Plugins entfernst, sollte die Message im Verbose auch nicht mehr kommen. Check mal kextstat | grep -v apple ab, dass die GPUSensors sicher nicht mehr laden.

    grt Eigentlich relativ unwichtig, aber nur zu unser beider Verständnis, ich habe mir das ganze auch mal angeschaut und hätte es wie folgt gelöst:


    Das Problem tritt bei GPRW auf. GPRW ist in der SaSsdt selbst nicht definiert, sondern kommt aus der DSDT und sieht wie folgt aus:

    GPRW ist also eigentlich eine Methode, kein Integer Object. In der SaSsdt wird GPRW jedoch als External (GPRW, IntObj) definiert. Hieraus entsteht wahrscheinlich das Problem, denn der decompiler interpretiert folglich die Return (GPRW... falsch und decodiert sie somit falsch. Dadurch kommt der problematische Code zustande:

    Code
    1. Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
    2. {
    3. Return (GPRW)
    4. 0x09
    5. 0x04
    6. }


    Was ich jetzt machen würde, wäre External (GPRW, IntObj) zu External (GPRW, MethodObj) zu korrigieren. Damit hat der compiler dann erstmal kein Problem mehr mit Ganzzahlen nach dem Return, diese müssen jetzt nur noch richtig umformatiert werden. Somit korrigiere ich die GPRW Calls zu:

    Code
    1. Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
    2. {
    3. Return (GPRW (0x09, 0x04))
    4. }

    Die Methode GPRW erhält somit auch seine gewollten Werte beim Aufruf einer entsprechenden _PRW Methode.

    Jetzt habe ich gesehen, wie du das ganze gelöst hast, und frage mich, was die bessere Lösung ist :/ Was meinst du?