Beiträge von Holz_Michel

Kann man das auslesen oder muss ich das Gehäuse knacken um die ID vom Chip lesen zu können?

Dankeschön, sehr interessant - ich habe noch kein 14.4, vielleicht ist es bei mir umgekehrt und es klappt in der neuen Version wieder.

Ich wollte dieser Anleitung möglichst 1:1 folgen, hier wird eine bestehende Verbindung als Grundvoraussetzung angeführt Anleitung WLAN Sonoma

Die Idee mit dem Android/IOS Device als Tethering Gerät ist gut, vom Grundsatz her wäre mir aber schon auch wichtig, dass ich weiterhin Ethernet über USB-Docks nutzen kann und nicht auf WLAN angewiesen bin.

Hallo zusammen,

ich versuche aktuell auf dem ZenBook UX310UAK Sonoma zum Laufen zu bekommen. Um nun den OCLP nutzen zu können, um WLAN aktivieren zu können, benötige ich ja eine alternative Internetverbindung. Unter Monterey funktioniert Ethernet über meinen USB-C Dongle einwandfrei.

Unter Sonoma funktionieren die meisten Funktionen meines USB-C Dongles ebenfalls einwandfrei, ich bekomme Bild an den externen Monitoren, meine USB-Geräte werden erkannt und funktionieren usw.
Nur Ethernet will nicht.
Wenn ich versuche, in den Systemeinstellungen den Bereich "Netzwerk" zu öffnen, bleibt die Seite weiß. Es erscheint auch keine Fehlermeldung.

Ist das Problem bekannt? Habe nicht wirklich etwas brauchbares finden können bisher.

Vielen Dank schon einmal im Voraus!

Hallo zusammen,

das Thema ist für Sonoma nach wie vor relevant. Gibt es mittels OCLP mittlerweile evtl. die Möglichkeit, die entfallenen alten Treiber für die Skylake-Chips zurück ins System zu spielen?
Ich meine wir benötigen jetzt wohl ohnehin Root-Patches allein um WLAN zum Laufen zu bekommen (bin gerade dran das alles zu verstehen bzw. nachvollziehen zu können), dann wäre das für die Leute mit Color Banding bestimmt nicht verkehrt, wenn wir weiterhin die alten Grafiktreiber nutzen könnten. Hab dazu leider im Netz bisher nichts gefunden, weiß jemand hier zufällig etwas in die Richtung?

Hallo iPhoneTruth

Beides hat nichts gebracht, v. a. bezüglich EDID habe ich auch in der Vergangenheit schon sehr viel experimentiert - leider auch immer ohne Erfolg.

Alles klar, das werde ich dann nochmal im Detail durchgehen und entsprechend berichten.

Besten Dank

Hi, vielen Dank. Das werde ich mal noch durcharbeiten. Ich hatte in der Vergangenheit schon mit diversen EDID-Tools & Co. gearbeitet. An der o. g. Anleitung gefällt mir, dass es hier um die Connector-Types geht. Ich glaube nämlich auch, dass es nicht am Display liegt, sondern irgendwas am KabyLake Grafiktreiber dafür sorgt, dass das Signal verkehrt ankommt. Mal sehen, ob es funktioniert, ist zumindest ein ganz anderer Ansatz als das sonst im Netz diskutierte Vorgehen

Also das bringt mich jetzt auch nicht weiter, dass das Display korrekt als Laptop Display erkannt wird war mir auch ohne IOReg schon klar. Oder meintest du ich soll mal versuchen das interne Display auf einen anderen Connector-type umzustellen?

Im Anhang die aktuelle EFI. Habe die Ressourcen weggelassen sowie die Seriennummern rausgelöscht.

Habe soeben noch eine interessante Erkenntnis gehabt:
Wird ein externer Monitor per HDMI angeschlossen, ist auf diesem das Bild einwandfrei. Nur der integrierte Monitor ist vom Color Banding Problem betroffen.

Also nochmal zusammengefasst, um Missverständnisse zu vermeiden:

• Mein Laptop hat ganz normal nur eine Grafikkarte, die HD620, die zum i5-7200U gehört
• Ja, die Grafik funktioniert einwandfrei, tut sie schon mindestens seit Mojave auf der Maschine.
• Die Grafikfehler habe ich auch schon immer, nur war es in der Vergangenheit möglich, in OC einen Eintrag zu machen, der dem System vorgaukelte es sei eine HD520. Dadurch konnte der Grafikfehler in allen bisherigen macOS Versionen behoben werden.
• Ventura hat jetzt keine Treiber mehr für die HD520, deshalb kann ich mit meinem bisherigen "Spoof" nicht mehr arbeiten

Würde mich über jeden weiteren Hinweis sehr freuen. Danke!

Ich glaub den "einfachen" Patch den du meinst ist jetzt genau die Zwickmühle: Um die Skylake Grafik zum laufen zu bekommen, muss man sie als KabyLake spoofen. Um jedoch meine Color Banding Probleme loszuwerden, muss ich meine KabyLake als Skylake spoofen.
Ich hoffe die missliche Lage wird so etwas klarer.

apfel-baum
Ich bitte um Verzeihung, habe deine Nachricht komplett übersehen. Ich habe das eben probiert, bei mir sagt der OCLP, dass es nichts zu patchen gibt - Macht auch auf seine Art Sinn, ich habe ja physikalisch eine "unterstütze Karte" in meinem Laptop verbaut, die HD620.
Ist es möglich, den OCLP irgendwie dazu zu bringen, trotzdem die Skylake Treiber ins System zu installieren? Das ist echt eine blöde Sache. Ich habe Ventura auf einem eigenen APFS Container, kann es nicht produktiv nutzen aufgrund der Grafikfehler.

Danke für die Antwort.
Hmmm, ich habe ja Grafik Output und auch HW-Beschleunigung, Metal und alles. Nur eben dieses Anzeigeproblem mit dem Color Banding, das bei den HD620 mit FHD Panels im Netz recht weit verbreitet zu sein scheint.
(z. B. auch hier: https://www.reddit.com/r/hacki…_on_the_internal_display/)

Bisher war die einzige funktionierende bekannte Lösung eben dieser "Skylake-spoof", der aber jetzt durch Ventura nicht mehr funktioniert. Ich kann mal ein anderes SMBios probieren, kann mir aber nicht vorstellen, dass das etwas bringt bei dem spezifischen Problem.

Gibt es eine Möglichkeit, die Skylake Treiber wieder in Ventura "reinzuwürgen"? Der OC Legacy Patcher ist mir bekannt, jedoch weiß ich nicht wie man den zu diesem Zweck missbrauchen könnte.

Hallo zusammen,

ich habe nun einmal versucht, auf meinem Asus UX310UAK mit KabyLake i5-7200u und HD620 Ventura zu installieren.

Sowohl Installation als auch Nutzung funktionieren, aber unter folgenden Einschränkungen:

• Der von mir bisher verwendete Spoof von KabyLake zurück auf SkyLake (siehe hier) muss deaktiviert werden, da in Ventura die Kexts für Skylake herausgefallen sind.
• Mit dem Spoof ist ein Booten nicht möglich
• Ohne den Spoof habe ich wieder das extreme Color-Banding - System nahezu nicht nutzbar

Hat hier jemand einen Lösungsansatz? Wäre schade, wenn aufgrund dieses Problems Ventura auf dem UX310UAK nicht genutzt werden kann...
Vielen Dank im Voraus!

Ich habe nirgends in den ACPI tables etwas gefunden, das die Fan-Kurve setzt. Ich denke das kommt irgendwie schon vorher vom BIOS, sprich der EC-RAM wird mit Werten vorbefüllt, die dann in der DSDT und auch in SSDTs nicht mehr explizit gesetzt werden.
Sprich die SSDT ist komplett selber erstellt.

Ich weiß ja welche Werte ich wo hinschreiben möchte und ASUS gibt mir sogar eine Function dazu -> WRAM.

Ich habe gerade mit der gleichen OC-Config testhalber mal ein Live-Linux gestartet. Interessanterweise scheinen die Änderungen hier zu greifen, wenn ich die EC-RAM Werte auslese bekomme ich genau das, was ich in der SSDT gesetzt habe (und der Lüfter ist still).
Ob das nur Zufall war möchte ich noch prüfen, werde einfach mal andere Zahlen in die SSDT schreiben und schauen, was Linux ausliest.

EDIT: Es ist wohl tatsächlich so, dass meine SSDT funktioniert - zumindest unter Linux. Ich habe in der SSDT nun testhalber andere Zahlen eingetragen, mit OC wieder Linux gebootet und die Werte per acpi_call ausgelesen - Meine eingetragenen Werte wurden angezeigt.

Die Frage wäre dann immer noch: Was macht macOS hier anders?

UPDATE:
Habe es finally hinbekommen

Anscheinend hat das mit der SSDT alleine für MacOS nicht ausgereicht. Ich habe jetzt von RehabMan den ACPIDebug.kext zusammen mit IOIO im Einsatz. Jetzt kann ich wie in Linux über die Befehlszeile einen ACPI Call auf Methoden innerhalb der SSDT für ACPIDebug machen. Deshalb musste ich meine Calls noch zusätzlich in die SSDT-RMDT.aml mit aufnehmen.
Mit dem call

ioio -s org_rehabman_ACPIDebug dbg0 1

kann ich jetzt ein sofortiges Schreiben meiner in der SSDT-RMDT definierten Kennline erreichen.
Bei Gelegenheit und nach einer gewissen Testphase folgt eine ausführliche Doku

Hallo zusammen und frohe Ostern.

Ich habe jetzt folgende SSDT erstellt, in OC unter ACPI gelegt und natürlich auch in der config.plist auf "enabled" gestellt.

Allerdings sieht es so aus, als würde das Ganze nicht funktionieren. Compilen lies die SSDT sich mit 0 Errors. Kann es sein, dass die Calls nicht "aufgerufen" werden? Brauche ich noch irgendetwas "drum-herum"? Mein Werk sieht auch fast etwas zu einfach aus

Ich hänge noch eine SSDT an, in der die WRAM Methode ebenfalls genutzt wird.

Vielen Dank im Voraus

Hallo und erstmal herzlichen Dank für eure Antworten. Das geht wirklich in die Richtung, die Ich mir vorgestellt habe.

Mit dem „einfach in die SSDT kopieren“ hört es bei mir auf, denn mir fehlt jetzt die Ahnung, wann welcher Code in einer SSDT ausgeführt wird. Ich glaube was ihr sagt passt zu dem Gedanken von mir, dass ich noch irgend ein Init-Event oder sonst etwas brauche. WRAM ist für mein Verständnis einfach nur ein allgemeiner „Write RAM“ (es gibt auch RRAM ) und wird nur glaube ich 2 mal sonst in der DSDT verwendet.

Hatte mir schon überlegt, einen der Fn-Keys zu opfern und den als „set Fan Kennlinien Button“ zu verwenden, wenn es kein Init- oder „On Boot“ Event gibt. Auch sowas müsste doch machbar und relativ einfach sein, oder?

Wie kann ich euch den vollständigen ACPI Tabellensatz zur Verfügung stellen? Die DSDT habe ich mit einem Linux Tool ausgeschrieben, dessen Name mir gerade nicht mehr einfällt.

Zur Info für alle Studierenden, die auf offiziellem Weg (den Beschiss würde ich mich nicht trauen und moralisch verantworten wollen…) das Bundle haben wollen:

Über Unidays (offiziell über deutsche Uni) wird das Bundle aktuell für 240 € angeboten.

Wie läuft das denn ab, wenn ich das jetzt erwerbe. Gehört mir die Lizenz für immer oder ist es nach Ende des Studiums mit der Nutzung vorbei?

Hi,

habe leider erst nächstes Wochenende wieder Zugriff auf den Laptop.

Genau, ich sehe es ebenfalls so, dass nur die Kurve anders eingestellt werden muss. Nichts anderes mache ich in Linux über die oben genannten Calls, denn die WRAM Methode von Asus erlaubt ein Überschreiben der Kennlinie.

Die Kurve wird über die Werte im EC RAM definiert und zwar ab Adresse 0x537. Die Werte entsprechen der HEX Schreibweise der jeweiligen Temperatur. In 0x537 steht standardmäßig z. B. 35 Grad als unterster Punkt, wird der Wert höher gesetzt, wird das Verhalten sofort besser.
Ich finde das so eigentlich recht elegant gemacht, denn damit kann man das Management zu hoher Temperaturen einfach der Programmierung von Asus überlassen und nur „untenrum“ etwas nachjustieren.

Vielen Dank

Guten Abend griven ,

vielen Dank für die Antwort. Ich muss glaube ich dazu sagen, dass die Lüftersteuerung durchaus temperaturabhängig funktioniert. Und das mit exakt gleichen Kennlinien in Windows, Linux und MacOS.

Daher fällt es mir sehr schwer zu verstehen, dass der EC hier außer Gefecht ist.

In der DSDT gibt es keine explizite Funktion zum direkten Setzen einer Drehzahl. Da die "hardwareseitige" Steuerung grundsätzlich funktioniert und ich nur einen „Offset" der Kennline brauche, würde ich gerne einmal probieren, ob es mit macOS nicht vielleicht auch ausreicht, wenn ich diese 5 Werte im EC RAM setze.

Ein einmaliges Setzen z. B. beim oder nach dem Systemstart würde völlig ausreichen.

Ich würde das wirklich gern experimentell ausprobieren, mach dann natürlich auch eine Doku davon. Jedoch fehlt mir das letzte Puzzlestück: Wo und wie kann ich diese Calls als „Init“ in eine SSDT oder sonst wohin einbinden, sodass sie beim Start gesetzt werden?

Vielen Dank noch einmal!

Hallo zusammen,
hier ein kleines Update:

Unter Linux kann ich einfach diese Befehle als Script ausführen und habe dann mit Hilfe des acpi_call Pakets eine perfekte Lüftersteuerung.

Wenn jemand eine Idee hat, wie ich diese funktionierenden ACPI Calls in MacOS, OC oder in eine SSDT einbauen kann, wäre ich sehr glücklich.

Ich kann mir sehr gut vorstellen, dass diese Vorgehensweise für eine Vielzahl von Asus Notebooks funktionieren wird.

Wenn noch weitere Infos benötigt werden, kann ich diese natürlich sehr gern nachliefern.
Vielen Dank!