Ist das wohl der Ursprung der Xhci Port Limit Patches und des XhciPortlimit Quirks?
USB mittels SSDT deklarieren
- apfelnico
- Erledigt
-
-
-
-
Er möchte jeden Ausgang seine Position in IOReg mittel Comment zeigen lassen.
Ich habe zu den anderen Methoden UPC und PLD noch die bekannte DSM Methode hinzugefügt aber leider wird nicht gezeigt.
-
Dafür ist PLD da. Dort kann auf den Millimeter genau mit welcher Form und welche Farbe, zu welchem Subset etc. zugehörig exakt definiert werden. Wozu auch immer sich das ausgetüftelt wurde und was auch immer diese Infos darstellen kann. Mir erscheinen dort zwei Infos wichtig: Visable und Ejectable.
-
apfelnico N0b0dy
Hab mir die Beschreibung für _PLD durchgelesen:
https://uefi.org/specs/ACPI/6.…tml#buffer-0-return-value
Das Codesnippet scheint mir ein wenig veraltet. "Visible" scheint sich auf die Sichtbarkeit des Physischen Ports zu beziehen, nicht auf die Sichtbarkeit im Betriebssystem selbst. Der Wert heißt eigentlich "User Visible" – also das es einen physischen Port gibt, den man erreichen kann: "set if the device connection point can be seen by the user without disassembly."
Mir scheinen nur relevant:
- Revision: 0x02 (im Snippet noch 0x01)
- Ejectable (Set if the device is ejectable. Indicates ejectability in the absence of _EJx objects.)
Für die Position könnte man es versuchen mit:
- Group Token
- Group Position und evtl
- Group Orientation
Aber mir scheint das eher ne Spielerei zu sein im Privatbereich. Ich glaube, das Macht nur Sinn, für irgendwelche großen Anlagen mit etlichen Ports, um den Port überhaupt erstmal zu finden, weil es so viele gibt.
-
Ich spiel mal bissl rum mit deinem beispiel nachher Nico.
Es wäre schön gewesen wenn man das wie beim Kext "Comment" definieren könnte dachte ich mir.So wichtig ist das ja jetzt auch nicht.
Gruss Coban -
Es wäre schön gewesen wenn man das wie beim Kext "Comment" definieren könnte dachte ich mir.
Das könnte ja so aussehen:
-
Code
Verstehe ich richtig Nico das das Info eben nur für den SSDT ist und nicht im Ioreg auftaucht wie mit der Kext & Comment lösung?
-
Das war nur mal so ein Gedanke, auf jeden Fall APCI-konform. Bin immer noch unterwegs und habe keinen Zugang zu meinem Rechner, kann nichts testen.
-
Ich habe es getestet, wird nicht gezeigt
-
Kein Problem Nico, das eilt nicht, wie gesagt das ist nur ne test und soll informativ beitragen.
Hab mal deine "Name Info" mit meinem ssdt bestückt, wäre halt schon bissl luxus gewesen wenn die infos`s auch im Ioreg auftauchen würden
Dank N0b0dy und dir hab ich jetzt auch ein lupenrein funktionierendes ssdt für diesen Board.Hier hab ich noch ein paar Kleinigkeiten korrigiert auf dem SSDT.
-
-
-
apfelnico ST33Z0
Aus eure verlinkte Webseiten könnte ich die Method GPLD entziffern. zum Beispiel nehme ich sie aus Coban's SSDT
Code- Method (GPLD, 2, Serialized)
- {
- Name (PCKG, Package (0x01)
- {
- Buffer (0x10){}
- })
- CreateField (DerefOf (Index (PCKG, Zero)), Zero, 0x07, REV)
- Store (0x02, REV)
- CreateField (DerefOf (Index (PCKG, Zero)), 0x07, One, RGB)
- Store (One, RGB)
- CreateField (DerefOf (Index (PCKG, Zero)), 0x40, One, VISI)
- Store (Arg0, VISI)
- CreateField (DerefOf (Index (PCKG, Zero)), 0x57, 0x08, GPOS)
- Store (Arg1, GPOS)
- Return (PCKG)
- }
1-CreateField (DerefOf (Index (PCKG, Zero)), Zero, 0x07, REV) beschreibt "Revision", daher stehet REV und hat 8 bits von null bis 7
Store (0x02, REV) dann gibt immer Revision 2
2-CreateField (DerefOf (Index (PCKG, Zero)), 0x07, One, RGB) beschreibt "Ignore Color", daher steht auch RGB und ha nur ein Bit.
Store (One, RGB) dann gibt immer eins, das heißt inaktive
CreateField (DerefOf (Index (PCKG, Zero)), 0x40, One, VISI) beschreibt "User Visible", daher steht VISI und ebenfalls hat ein Bit also aktive oder inaktive.
Bei "Store (Arg0, VISI)" steht erstes Argument für die Methode entweder 0 invisible oder 1 visible
CreateField (DerefOf (Index (PCKG, Zero)), 0x57, 0x08, GPOS)
Store (Arg1, GPOS) hier beschreibt "Group Position" an den Bit 87, daher steht auch GPOS
Bei "Store (Arg1, GPOS) ist das zweite Argument für die Methode, die eben falls hier ändern können
In diesem Beispiel
gibt uns GPLD zurück (Revesion=2, RGB=0, Visible=Yes, Postion=1)
das in Buffer nicht anders als so sehen würde
-
Hab gerade mal QtiASL ausprobiert:
https://github.com/ic005k/QtiASL/releases
Sieht nicht so schick aus, aber es ist cross-platform und man hat gestrichelte Linien zwischen den Klammern, wodurch man die Hierarchie leichter erkennt.
cobanramo Wenn man in "GPLD" 4 von diesen "createfield" Funktionen drin hat, warum brauch man dann nicht unter "Return" nicht auch 4 werte, sondern trotzdem nur 2?
-
ST33Z0
Ich vermute mal das du den N0b0dy fragen wolltest warum das so ist,Ich bin wirklich absolut nicht fit im Bereich Acpi, denke aber das es bei den returns eben nur das angegeben wird was nötig ist und bei denen wo es nötig wird die fehlenden auch mitgegeben wird.
Gruss Coban
EDIT: vielleicht lieg ich auch völlig falsch aber ich könnte mir noch vorstellen das man eben über diesen "Visible=Yes, Postion=1" genau die Ports die am Board (interne header oder fest verdrahtet und herausgeführte Usb Ports) darstellt oder steuert.
-
-
GPLD gibt immer diese 4 Werte zurück aber der erste und zweite sind immer gleich für alle Ports daher müssen sie nicht geändert werden.
Dritte und vierte müssen nun ja angepasst werden daher sind sie variabel
Wie oben schon geschrieben bei dem dritte handelt es sich um den Ausgang, ob er für uns sichtbar ist oder nicht, wenn _UPC deaktiviert dann _PLD ist irrelevant also für uns nicht sichtbar daher null aber wenn aktiviert ist dann muss sichtbar sein, dass heißt eins
beim vierten Wert entspricht USB Position und ist gleich wie USB Nummer 1, 2, 3, ....
-
Genau, das ist mir mit der 4. wert auch aufgefallen, die entspricht immer den _ADR wert.
Die 3. wert mit visible ist in dem fall die Interne header Port oder Real Port nehm an.