RevisionID in IOHDACodecDevice ändern (PropertyInjector.kext)

Es geht schon mal damit los, dass die Struktur falsch ist.

Wenn du einen Eintrag namens Audio erzeugst, musst du dessen Untereinträge auch "unter" bzw. "in" den Audio Eintrag legen.

Der PropertyInjector ändert das Property eines "Gerätes".

Bei welchem Gerät lässt du den propertyInjector die Eigenschaft ändern ?

Bei welchen Gerät soll die Eigenschaft geändert werden ?

0xa3488086 müsste es sein, wenn du Properties in das Device HDEF injizieren möchtest.

HDEF - High Definition (HD Audio)

Gerät bedeutet nicht zwangsweise ein Gerät im Umgangssprachlichen Sinne.

Um genau zu sein hätte ich den Audruck Service verwenden sollen.

Bei welchem Service (Eintrag im IORegistry Baum im Anzeigemode Service) kommt das Feld, das du ändern willst, vor ?

Wenn du den kennst, brauchst du seinen Klassennamen. Den zeigt dir der IORegistryexplorer auch an.

Du hast einen IORegistry-Auszug gepostet. Indem kommt der Eintrag IOHDACodecRevisionID vor.

Das ist der der geändert werden muss.

In welchem Service kommt er vor und wie heisst die Klasse ?

Wo im Fenster des IORegistryExplorers steht der Service ?

Wo im Fenster des IORegistryExplorers steht die Klasse ? Du weisst wie die Klassen eines PCIDevices heisst, also könntest du ein PCI Device anwählen und schauen wo die Klasse im Fenster zu finden ist.

Richtig verstehen: “Service”

Service, Programm, Treiber…

Dummerweise ist der Sprachgebrauch nicht eineindeutig. Wenn man von einem Service spricht kann es sein, dass man den Service im allgemeinen oder im Besonderen spricht.

Vergleichen wir ihn mit einem Programm, was ganz gut passt, denn letztendlich ist er eins.

Pages im allgemeinen ist ein Schreibprogramm mit folgenden Möglichkeiten ....... Es liegt in meinem Programme Ordner.

Sobald ich Pages starte wird es geladen und ausgeführt und dieser laufende Code ist eine Instanz von Pages. Mit etwas Getrickse kann ich das Programm mehrmals starten und die Kopien parallel laufen lassen. Dann habe ich mehrere Instanzen von Pages gleichzeitig laufen.

So ist es auch mit Services. Es gibt den Service im Allgemeinen und dann gibt es Instanzen davon, also Code der ausgeführt wird. Es kann mehrere Instanzen des selben Service gleichzeitig geben.

Services werden programmtechnisch als Klassen realisiert. Entsprechend ist eine Instanz eines Service eine Instanz seiner Klasse.

Eine Instanz eines Service kann unter einem anderen Namen laufen, als dem Klassennamen.

IOProviderClass = Name eines Services als Startsignal

D.h. wird ein Service dieses Namens oder eine Subklasse davon geladen, dann startet die Überprüfung.

Ja, aber. Genau genommen ist es der Name der Klasse die den Service realisiert. Es ist denkbar, dass der Service und Klassenname sich unterscheiden. Und Instanzen eines Service müssen auch nicht den gleichen Namen haben wie der Service. Also muss man darauf bestehen, dass dies der Name der Klasse ist.

CFBundleIdentifier = Programmcode des Service

"zB. com.apple.driver.usb.AppleUSBXHCIPCI"

kann mehrere Services enthalten..

Richtig

IOClass = “spezifiziert den Service im Bundle”

Wieder das Namen-Problem. Es handelt sich um den Namen der Klasse, die den Service realisiert.

Richtig verstehen: “Klasse”

Gerät, Klasse, Art…

Ergibt sich aus dem Zusammenhang. Eine PCI Klasse ist etwas anderes als eine Klasse (Konzept in der Object-orientierten-Programmierung) die einen Service realisiert.

IOPCIClassMatch = “GeräteKLASSE”

-> GeräteKLASSE = Name d. (PCI) Gerätes

Nein. Das ist eine PCI-Geräte spezifische Klasseneinteilung. Sie dient dazu PCI Geräte einer Gruppe zuzuordnen. Grafikkarten, Kommunikationskarten etc.. Gibt es für eine Klasse von Geräten verbindliche Vorschriften für die Funktion und wie sie bereit gestellt wird, so kann man Treiber schreiben, die dann an Hand der Geräte Klasse geladen werden ohne dass man einen Treiber für jedes Gerät schreiben muss. man muss nicht einmal die Geräte-Id jedes einzelnen Gerätes kennen und eintragen.

IOPCIPrimaryMatch = “GeräteID”

Produkt und Hersteller ID eines PCI Gerätes. Wieder etwas was nur für PCI Geräte bzw. Services die PCI Geräten zugeordnet sind Bedeutung hat. Das gleiche Konzept gibt es u.a. bei USB Geräten.

IORegistry, verstehen..

IOService (Plane): Auflistung der installierten Services! (Die an Geräte gebunden sind)

Jein. Für gewöhnlich schon, aber ein Service kann auch einfach nur ein Programmstück sein, das nicht an ein Gerät gebunden ist.

Jede Zeile auf der linken Seite ist also ein "Service"?

Ja

IOACPIPlane: Geräte..

Die Einträge in der linken Spalte, sind Einträge, die macos in der DSDT gefunden hat. Das können auch Einträge sein, für die später keine Services geladen werden.

AppleALC verwendet die Eigenschaft IOHDACodecRevisionID um Patches zu identifizieren.

Deren Wert wollen wir anpassen.

Wir kennen den Namen der Eigenschaft.

Nun müssen wir rausfinden in welcher Instanz die Eigenschaft vorkommt.

Dann legen wir einen PropertyInjector Eintrag, der gestartet wird sobald diese Instanz erzeugt wird, an.

Dazu müssen wir wissen, welche Instanz die Eigenschaft enthält und von welcher Klasse es eine Instanz ist - denn wir verwenden IOProviderClass um das Erzeugen der Instanz zu erkennen und IOProviderClass will den Klassennamen haben.

Wie gesagt eine Klasse kann alles mögliche sein z.B. ein Gruppenname, aber die Klasse die einen Service realisiert ist eine Klasse im Sinner der Object Orientierten Programmierung.

Ich habe über Stunden hinweg ohne auf Programmierkenntnisse zurückzugreifen versucht zu beschreiben was eine Klasse ist und ich bin gescheitert.

Letztendlich ist eine Klasse ein Programmstück, das Instanzen von sich erzeugen kann und definiert was die Instanzen können (Interface) und wie sie es tun (Implementation).

Da Klassen Programmstücke sind, werden sie von einem Programmierer erstellt, mit dem Ziel eine bestimmte Aufgabe zu erfüllen.

Andere Klassen oder Programmstücke können auf Instanzen einer Klasse zugreifen und mit ihnen arbeiten, denn wie das geht sagt ihnen das Klassen Interface.

Weiss man welcher Klasse eine Instanz angehört, weiss man wie man mit ihr arbeiten kann ohne zu wissen zu müssen wie sie es genau tut.

Es gibt Mechanismen in macos, die Treiber laden. Die Treiber sind Instanzen von Treiberklassen.

Die Instanzen werden erzeugt und melden dann dem Betriebssystem, dass sie da sind.

Hat man nun ein Gerät, dass eine Instanz einer Klasse lädt, die macos nicht kannte als es erstellt wurde, sieht man alt aus, denn macos kennt ja das Klasseninterface nicht, da es die Klasse noch nicht gab als es erstellt wurde.

Da kommt die Vererbung ins Spiel. Man erzeugt Klassen, die aufeinander aufbauen. Die erste Klasse ist zum Beispiel vom Typ Treiber und beschreibt in ihrem Interface alles was ein beliebiger Treiber kennen muss.

Nun legt man für bestimmte Gerätegruppen Unterklassen an. Die Unterklasse (Subclass) erbt das Interface ihrer Superklasse(Superclass).

Die Subclass erbt auch die Implementation (den Programmcode) ihrer Superklasse, kann die aber durch eigens auf sie angepassten Code ersetzen.

Bei Treibern wären das z.B. Klassen für USB, Netzwerk, Grafik. Jeder dieser Treiber hätte wieder Unterklassen, bei den USB Klassen z.B. für verschieden Chipsätze unterschiedliche Treiber.

Hat man nun einen Computer mit einem macos unbekannten USB Chipsatz und einem passenden Kext dazu, so wird über den vorhin erwähnten Mechanismus eine Instanz der Klasse erzeugt, die macos nicht kennt. Aber da es sich um einen USB Chipsatz Treiber handelt, ist er eine Unterklasse der USB Klasse und davon kennt macos das Interface und kann also damit arbeiten.

Im IORegistryExplorer kann man die Superklassen einer Klasse sehen.

Die Klasse AppleACPIPCI basiert auf IOPCIBridge das auf IOService basiert usw.

Alle Treiber sind Unterklassen von IOService, das eine Unterklasse von IORegistryEntry, das eine Unterklasse von OSObject ist.

OSObject stellt Standardfunktionalität für Objekte im Kernel zur Verfügung. Das betrifft hauptsächlich die Speicherverwaltung, also wie man Objekte anlegt und löscht.

IORegistryEntry erweitert OSObject um Funktionen die ein Verwalten der Objekte in der IORegistry erlauben. Anlegen, verschieben und Löschen von Einträgen uä.

IOService fügt dann alles hinzu was jeder Service können muss. das ist ein A-voll Zeug wens interessiert, der kann's googeln.

Wir wissen das die Eigenschaft die wir ändern wollen IOHDACodecRevisionID heißt.

Diese kommt in IOHDACodecDevice vor.

Es besteht die Möglichkeit, dass die Eigenschaft von einem anderen Service übergeben wird. Aber das interessiert und erst, wenn das Ändern an der Stelle nicht funktioniert.

So an der Stelle haben wir die Instanz und die Klasse.

Die Klasse lautet ........... ?

Verwendet man IOProviderClass für das matching so wird man über jeden Service informiert, der der Klasse oder eine Unterklasse davon entspricht.

Gibt es mehrere Instanzen einer Klasse z.B. IOService, kann man die "Matches" weiter einschränken. Das ist dann der Schritt nachdem wir die Klasse bestimmt haben haben.

Ich verstehe die IORegistry Frage nicht.

HDEF@1F,3 und AppleHDAController@1F,3 sind unterschiedlicher Services.

Was meinst du mit unterschiedlichen Ansichten ? Service vs. ACPI ?

Alles gut.

Das Prinzip hast du erfolgreich umgesetzt.

Wenn du dir im IORegistryExplorer anschaust welchen Datentyp IOHDACodecRevisionID hat, wirst du feststellen, dass du einen anderen verwendest.

Ändere den Datentyp in den Properties entsprechend und poste dann was IORegistryExplorer für das IOHDACodecDevice anzeigt.

Das ist das falsche Device. Ich wollte das IOHDACodecDevice unter HDEF sehen.

Um deine Frage zu beantworten.

PropertyInjector versucht den Wert für alle Services auf die die Match Bedingungen zutreffen zu ändern. Doof wenn man mehrere hat, aber nur einen ändern will.

Die Einschränkung an Hand von IOHDACodecVendorID macht Sinn, damit man nur das eine IOHDACodecDevice ändert .

Da wie aber keine Subklasse von IOPCIDevice haben funktioniert IOPrimaryMatch nicht.

Es gibt aber die Möglichkeit auf einen beliebigen Eintrag zu matchen.

Man legt zusätzlich zu IOProviderClass einen Eintrag Namens IOPropertyMatch an. Dieser muss vom Typ Dictionary sein.

In diesem Dictionary listet man alle Eigenschaften mit dem Wert auf, den man erfüllt haben will.

In unserem Fall IOHDACodecVendorID und der Wert 0x10ec1220. Den Datentyp beachten.

Das sieht dann so aus:

XCode macht aus der Hexzahl eine Dezimalzahl, deshalb steht da 283906592.

Eine einfache Methode zu testen ob das Matching klappt ist es eine zusätzliche Eigenschaft zu definieren.

Z.B.

Name: Frank

Typ: String

Data: "was here"

Wenn das matching funktioniert wird der Eintrag im IOHDACodecDevice zu sehen sein.