DSDT Connector-Patch

  • Hey,


    @kuckkuck und ich wollten ganz gern mit der DSDT den Connector patchen, haben uns dazu auch bereits die SSDT von mit angeschaut, hierbei ist uns dieser Ausschnitt aufgefallen:


    Code
    1. // Only use this if you need special connectors that are incompatible with the automatic connector detection
    2. "connectors",
    3. Buffer ()
    4. {
    5. 0x00, 0x04, 0x00, 0x00, 0x04, 0x03, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x12, 0x04, 0x04, 0x01,
    6. 0x00, 0x08, 0x00, 0x00, 0x04, 0x02, 0x00, 0x00, 0x00, 0x01, 0x02, 0x00, 0x22, 0x05, 0x01, 0x03,
    7. 0x04, 0x00, 0x00, 0x00, 0x14, 0x02, 0x00, 0x00, 0x00, 0x01, 0x03, 0x00, 0x10, 0x00, 0x05, 0x06,
    8. 0x04, 0x00, 0x00, 0x00, 0x14, 0x02, 0x00, 0x00, 0x00, 0x01, 0x04, 0x00, 0x11, 0x02, 0x06, 0x05
    9. },


    Deshalb wollte ich jetzt mal einen Thread eröffnen, um das jetzt gemeinsam anzugehen :)



    Dabei ist mir schon aufgefallen, dass sicher der Code/Patch kompiliert immer in 8er Blöcke aufteilt!



    Mein Patch oder verwechsel ich hier grad was? :


    Code
    1. Chutoro:
    2. 000400000403000000010000000000001204000100000000
    3. 000400000403000000010000000000002205000200000000
    4. 000800000402000000710000000000001102000300000000
    5. 040000001402000000010000000000000000000600000000
    6. 000200001402000000010000000000002103000500000000



    Ich hab grad ne Idee... Vllt kann man ja die letzten 8en und 8 aus der Mitte entfernen, so käme man ja auch auf 16:


    Code
    1. Chutoro:
    2. 00040000040300000001000012040001
    3. 00040000040300000001000022050002
    4. 00080000040200000071000011020003
    5. 04000000140200000001000000000006
    6. 00020000140200000001000021030005


    Ich glaube wir kommen dem Ende näher:

    Code
    1. 0x00, 0x04, 0x00, 0x00, 0x04, 0x03, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x12, 0x04, 0x00, 0x01
    2. 0x00, 0x04, 0x00, 0x00, 0x04, 0x03, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x22, 0x05, 0x00, 0x02
    3. 0x00, 0x08, 0x00, 0x00, 0x04, 0x02, 0x00, 0x00, 0x00, 0x71, 0x00, 0x00, 0x11, 0x02, 0x00, 0x03
    4. 0x04, 0x00, 0x00, 0x00, 0x14, 0x02, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06
    5. 0x00, 0x02, 0x00, 0x00, 0x14, 0x02, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x21, 0x03, 0x00, 0x05


    Ich glaube das sieht schon mal ganz gut aus ;) :



    Tja so einfach ist es dann leider doch nicht, weiß jmd weiter? Wenn ich das so in meiner DSDT hinzufüge, laufe ich in einen Blackscreen und kann nur noch mit VNC an den Rechner. Grafikbeschleunigung funktioniert dabei leider auch nicht...


    UPDATE: Habe ma einen IOREG-Auszug angehängt!

  • Soll das denn den selben Effekt bewirken, wie ein Kext-Patch für den AMDXXXXController.kext, oder ist das eine spezielles Viech für WhateverGreen?


    Und "deinen Patch" hast du mit dem AMD Framebuffer Utility erstellt?


    Die FAQ dazu sind lustig, die versteht glaube ich niemand außer vit.

  • Ich hab du gerade glaube ich des Rätsels Lösung bei den Verrückten gefunden! :love:


    Schau mal hier: http://www.insanelymac.com/for…b-clover-injection/page-1


    Das ganze interessiert mich so, weil ich bei meiner Karte nicht beid DVI Ports gleichzeitig benutzen kann... Mit einem DSDT Patch lässt sich der default Framebuffer benutzen, aber gleichzeitig die Anzahl der Ports definieren:

    Code
    1. "connector-count",
    2. Buffer ()
    3. {
    4. 0x04, 0x00, 0x00, 0x00
    5. },


    Und daraufhin noch sagen welcher Connector welche Art von Port ist. Dazu muss also die Hex Folge, wie in obigem Link beschrieben, erstellt werden und in den Eintrag "connectors" gesetzt werden.


    Weiter im Code:


    "AAPL,slot-name": Slot-1 entspricht dem ersten PCI Steckplatz für eine GPU von oben gezählt, Slot-2 wäre der zweite, sehe ich das richtig? Nur nötig wenn mehrere GPUs installiert?


    "@0,AAPL,boot-display": Coole Sache, aber woher weiß ich welches Display welche Nummer hat?


    "device-id": Aus DPCIManager mit ByteSwap


    "model": Steht dat dann auch unter "Über diesen Mac"? :huh:


    "hda-gfx": Wenn die iGPU aktiv ist, dann wird eine der beiden zu "onboard-2"... Spielt es wohl eine Rolle ob IGPU oder GFX0 " onboard-2" bzw. 1 ist?

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    2 Mal editiert, zuletzt von kuckkuck ()

  • Das klingt interessant. Der Framebuffer ATY,AMDRadeonFramebuffer wird ja auch mit Whatevergreen genutzt. "connector-count" in der SSDT ohne Framebuffer (bei mir Hamachi oder Futomaki) werde ich später mal antesten...

  • 1. Ja der Slot Buffer gibt nur an wo das Gerät liegt, kannst also auch wenn das deine einzige Karte ist, Slot-3 nehmen oder so.


    2. Das hab ich auch noch nicht hundertprozentig durchblickt... Aber ich glaube das kannst du mit der prirority festlegen. Dann muss der erste aus dieser Liste dann 0 sein und somit das boot-display


    3.Ja tut es :)


    4. Kann ich leider nicht sagen, da mein Xeon keine IGPU hat :D Aber ich nutze dennoch onboard-2 und dat läuft wunderbar.



    @kuckkuck ja genau das möchte ich auch, aber irgendwie würde ich das mit dem FB ConnectorPatch hinbekommen :whistling::cursing:


    @Harper Lewis Ja richtig, der Einfachkeithalber hab ich das nette kleine Tool genutzt! :D Aber mein Ziel ist es primär auf das manuelle patchen des AMD7000Controllers zu verzichten (nutze ja OZM)! Daher versuche ich möglichst alle Parameter mit der DSDT zu injecten... und der WEG Kext ist ja nichteinmal mehr nötig, denn Mieze hat passend zum Thema ein DSDT Patch entwickelt, der das gleiche tut!

    VFIO FTW

    :hackintosh:

    2 Mal editiert, zuletzt von modzilla ()

  • Check ich nicht, hast du die verlinkte Anleitung gelesen? Das kommt doch einfach nach GFX0 in die DSDT, da musst du doch nichts am Controller patchen...

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • Funktioniert das denn bei dir, @kuckkuck? Wenn ich in meiner SSDT die vier Einträge für den Framebuffer Hamachi weglasse, wird der Default-Framebuffer geladen. Dafür wird der Gerätename "Sapphire R9 280 Dual-X" nicht aus der SSDT übernommen. Die Connector-Types sind aber identisch: DP, DP, DDVI, HDMI. Jetzt ist die Frage ob es irgendwie zielführend ist, das auf die Ausgänge der R9 umzubiegen: DP, HDMI, DDVI, DDVI

  • Ich habs noch nicht probiert...


    Wird der Name denn bei Hamachi übernommen?
    Default ist doch Futomaki, dann trag doch in die SSDT mal Futomaki ein und dann aber mit Custom Namen etc. und schau obs funzt :)

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • Hamachi und Futomaki funktionieren beide und dann wird auch der in der SSDT eingetragen Gerätename ("model") angezeigt. Ich habe jetzt mal folgende connectors eingetragen (und wieder die Framebuffer weggelassen):



    Ergebnis:


    wie gehabt model: AMD Radeon HD 7xxx, Framebuffer: ATY,AMD,RadeonFramebuffer


    Dafür hat sich aber der connector-type bei den vier Anschlüssen geändert:


    0x400, 0x800, 0x4, 0x4 = DP, HDMI, DVI, DVI (vermute ich, passt aber auch zu den Ausgängen der R9)


    Mit Hamachi oder Futomaki:
    0x400, 0x400, 0x4, 0x800 = DP, DP, DDVI, HDMI (vermute ich)


    Unter 10.12.6 hat eh alles funktioniert. Egal ob ich WhateverGreen oder wie jetzt aktuell den Patch von Mieze genutzt habe. Unter 10.13 sieht es da wieder ganz anders aus.

  • Warum versucht ihr einen Connectorspatch über die DSDT zu lösen und nicht via "KextsToPatch" ala:



    was dann dem hier entspräche:

    Bilder

    ASUS WS X299 SAGE/10G • Intel Core i9-7920X 12-Core 2.9GHz • 128GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 980 NVMe M.2 SSD 1 TB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x SAMSUNG 49" @ 5120 x 1440 (100Hz) via DP • LG OLED 55" TV @ 3840 x 2160 (100Hz) via HDMI
    WINDOWS 11 ENTERPRISE INSIDER (PRO950 NVMe) • macOS BIG SUR und MONTEREY latest Build (jeweils auf Samsung 980 NVMe) • OpenCore always latest

  • Ja das wäre ja was für Anfänger ;) , nein Spaß... Ich würd es gern so machen, da ich nicht nach jedem Update den Controller mit nem perl Befehl patchen möchte und ich gleichzeitig nicht genügend Platz im ROM habe für den KernextPatcher!


    Und außerdem ist meine Interesse geweckt XD



    @Harper Lewis ich vermute, dass bei dir der Name nicht übernommen wird, liegt daran, dass die Buffergröße nicht mehr stimmt und er es deshalb verkackt den zu injecten. Deshalb: Entfern einfach immer nach ner Änderung die Zahl in der Klammer entfernen! Dann wird die Größe neu berechnet

  • Ist doch nur Rumspielerei :) Wobei das, was ich da oben geschrieben habe, Unsinn ist: 0x400, 0x800, 0x4, 0x4 gibt's immer, wenn ich keinen Framebuffer angebe.


    @modzilla: Das mache ich bei jeder Änderung, funktioniert aber trotzdem nicht. Der Gerätename ändert sich nur mit Framebuffer Hamachi oder Futomaki.

  • @"Spielerei"


    Wenn es klappt, hat man die komplette Kontrolle über seine GPUs ohne sich sorgen zu machen, ob es beim nächsten Update schief läuft.


    Vielleicht auch interessant für problematische QuickSync&Co Kandidaten, falls dies in der iGPU Sektion ebenso realisierbar ist.


    @modzilla: Vielen Dank für die Detektivarbeit!

  • Ja prinzipiell kannst du alle Grafikprobleme mit der DSDT lösen :)
    Hat denn jetzt noch jmd ne Idee bzgl des Connector Eintrages in der DSDT?

  • Hat denn jetzt noch jmd ne Idee bzgl des Connector Eintrages in der DSDT?


    Kannst du das mal konkret formulieren? Ich verstehe das Problem nicht so ganz ?(:D

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • Wie gesagt, ich möchte gern den Framebuffer otf patchen mit der DSDT, wie oben mit dem "connectors" Eintrag, aber immer, wenn ich meine eigenen Werte eintrage, dann bleiben die Bildschirme schwarz und QE/CI geht verloren...

  • Verstehe... Was ist der erste Wert den du injectest und zu welchem Port genau gehört er?

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.


  • Ich weiß jetzt noch nicht genau was du damit meinst, aber die Ports sind wie folgt injected: DP, DP, HDMI, DVI-DL, DVI-SL

  • Die Werte bestehen immer aus 16 EinzelWerten. Der erste Wert ist bei dir also:

    Code
    1. 0x00, 0x04, 0x00, 0x00, 0x04, 0x03, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x12, 0x04, 0x00, 0x01


    Diese Reihenfolge lässt sich zerlegen, wobei jeder teil einen bestimmten Sinn hat.


    Die ersten vier Werte sind beschreiben den Typ des Connectors:
    0x00, 0x04, 0x00, 0x00 entspricht einem DisplayPort.




    Die nächsten vier sind die ATY,ControlFlags
    0x04, 0x03, 0x00, 0x00 entspricht einem Display Port


    Danach kommen die ATY,Features:
    0x00, 0x01, 0x00, 0x00
    Aufgesplittet in:

    • 0x00 <-- DP port
    • 0x01 <-- Internal
    • 0x00 <-- Reihenfolge der Connector Aktivierung: 01 wäre erster aktiver Connector, hier 00???
    • 0x00 <-- unknown


    Die letzten vier kommen aus dem ROM der GPU:
    0x12, 0x04, 0x00, 0x01
    Aufgesplittet in:

    • 0x12 <-- Transmitter
    • 0x04 <-- Encoder
    • 0x00 <-- Hotplug ID
    • 0x01 <-- Sense ID

    Die Werte erhält man wenn man das ROM mit redsock_bios_decoder und redsock_bios_decode dekompiliert.
    Beispiel für einen Teil der Outputs der beiden:
    03 (HOTPLUG ID) [DVI_I]
    redsock_bios_decoder :
    enc obj 0x1e transmitter 0x10 (TRANSMITTER) dual link 0x0 enc 0x0 (ENCODER)
    radeon_bios_decode:
    Connector at index 2
    Type [@offset 43542]: DVI-I (2)
    Encoder [@offset 43546]: INTERNAL_UNIPHY (0x1e)
    i2cid [@offset 43696]: 0x95, OSX senseid: 0x6 (SENSE ID)


    Daraus lässt sich also insgesamt ein Custom Konstrukt für jeden Port der GPU bilden...

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    Einmal editiert, zuletzt von kuckkuck ()

  • Jap, exakt! Genau das tat ich ja auch! Der Patch aus dem ersten Post funktioniert auch super, jedoch nicht die abgeänderte Version von vit's connectors Eintrag...


    Das Zitat ist meine abgeänderte Version ;)