Beiträge von BlvckBytes

Vielleicht ganz interessant:

Man möge mal die Daten des ersten Quadranten im Split-Screen betrachten. Das Intel sofsoundwire-device steuert *gleichzeitig* die Speakers, den Jack sowie alle verfügbaren HDMI-Ausgänge. Das Gerät läuft bei mir unter macOS und betreibt das Video-Out Audio auch erfolgreich. Die Frage ist nun: Gibt es noch weitere Codecs zu finden? Ich glaube nämlich nicht... Ist wohl n all in one.

// Edit: Files angehangen.

Auch von mir einen guten Rutsch an Euch alle, auf ein weiteres erfolgreiches Jahr des Hackintoshens! :).

5T33Z0

Verfügbar war er ja schon längst, bloß Werte wurden keine emittiert. Der Grund wieso ich das behaupten kann ist ja, weil bereits ACPI debugging betrieben wurde.

Ich sehe aktuell keine weiteren Lösungen für das Problem und melde mich daher eventuell später mal wieder, wenns was neues gibt. Sieht generell so aus, als würde zu diesem Nischenthema nicht sonderlich viel Wissen bzw. Erfahrung im Hackintoshbereich bestehen.

5T33Z0

Verstehe ich das richtig: Dein Vorschlag ist es, den variablen Wert der Umgebungsbeleuchtungsstärke auf einen statischen bzw. festen Wert zu setzen?

Waren das nicht genau die Reihe, die nur mit der AMD-GPU ein Videosignal lieferte? Hatte auch mal so einen, bei dem ich die GPU baken musste.

Mal ganz davon abgesehen, dass der USB-Stick nicht gefunden wird, glaub ich kaum dass die HD-2000 von der iGPU oder die dedizierte GT-420 auf Monterey laufen. Könnt mir denken dass Sierra oder maximal HighSierra die höchste Stufe des Möglichen sind. Hab aber gerade bei diesen Komponenten davon gelesen, dass es extrem aufwendig sein kann, sie zum Laufen zu bekommen. Nur als Vorwarnung, bevor Du dann schon zu tief im Build steckst, :p.

MacPeet

Yep, auf Ubuntu 21.10 funktioniert mein Audio einwandfrei, weshalb es mich wirklich sehr wundert, dass man dort nicht mehr dumpen kann. Aber Du hast recht, da werd ich wohl abwarten müssen. Danke auf jeden Fall für deine bisherige Hilfe, ich werd das Thema im Auge behalten und mich melden, wenn es was neues gibt!

msart

Also ich muss zum Beispiel keine neue App bauen, xD. Hängt ja letztendlich alles vom Shebang im ProperTree.command ab, und somit vom user-environment. Man könnte auch das neueste python in pyenv linken, und als new global-standard setzen, damit /usr/bin/env auf das neueste binary zeigt.

Wie dem auch sei, freut mich dass es wieder geht!

Wie launchst Du das Tool, über CLI oder als packaged app? Über die CLI bräuchtest Du lediglich ProperTree.command mit der neuesten python-Version von python.org auszuführen. Ich habs' bei mir so in der .zshrc:

Ist mir lieber als eine App zu bauen, nachdem man so ja auch gleich den Pfad zur plist als Argument übergeben kann. Übrigens, die Versionen die von pyenv kommen haben noch das alte TKinter dabei, weshalbs auch dort wieder zu einem Blackscreen kommt.

5T33Z0

Danke dass Du mich zum Thema der PNLF aufmerksam gemacht hast!

Hab ich mal erneuert, Auswirkungen hatte es soweit keine, in Gesamtheit gesehen.

Bezüglich der SSDT-ALSD muss ich leider davon ausgehen, dass du meinen initialen Beitrag hier nicht vollständig durchgelesen hast, da ich diesen Patch schon längst ohne jegliche Dokumentationen implementiert habe - ist logisch und eigentlich Grundverständnis. Mein Problem liegt ja ganz wo anders. Klar, das Gerät registriert sich (Status 0xB), wodurch sich der LMUController daran mounted, aber das Ganze ist recht nutzlos, wenn die _ALI-Methode - wie in meinem Debug gezeigt - ständig einen Wert von 0 retourniert.

Mir kommt's so vor, als würde der Sensor einfach nicht in die nötigen Speicheradressen schreiben, weil er entweder A) nicht aktiviert oder B) nicht dazu aufgefordert wird.

MacPeet

Ich hab nochmal zwei Bilder von den Prefpanes angehangen, leider wirklich nur das was auch vorher schon zu sehen war, :/. Zum Thema SoundWire-Bus sind auch einige Bilder mit dem WIN_ prefix dabei. Ich denke halt, dass das eine andere Technologie ist, als beim XPS 9500 oder 9300. Eine Art Abstraktion, ein standardisiertes Gerät, welches als middleman zu anderen Codecs agiert, so ähnlich hab ich das in einem PDF gelesen.

Denke irgendwie immer noch drüber nach, was man sehen würde, wenn man den win-driver disassembled. Probably nur gibberish.

5T33Z0

Soweit mal nichts neues dort gefunden, außer:

Zitat

If there is an ambient light sensor device in the original ACPI and you want to force it to be enabled by the preset variable method, you need to pay attention to the existence of _SB.INI in the original ACPI. If it exists, please use method 2 to impersonate ALS0.

Und ja, diese Methode existiert in der Tat:

Verstehe den Zusammenhang aber noch nicht so ganz, weshalb ich jetzt ein fake ALS device erstellen soll, wenn doch ein natives vorhanden ist.

Hey!

Ich weis, das ist eigentlich bloß eine Spielerei... aber ich hätte echt gerne einen funktionierenden Ambient Light Sensor, nachdem dieser auf Windoof 10 auch sehr gute Dienste leistet. Mein System ist das Dell XPS 9700 mit i7-10875H und 4K-Display. Hab' mal den aktuellen EFI-folder angehangen.

Um mal kurz meinen bisherigen Ansatz zu beschreiben, zitiere ich das zu patchende Gerät aus meinen ACPI tables:

Damit das Gerät in der IOReg aufscheint, musste ich natürlich ALSE auf 0x02 setzen, mittels SSDT. Gesagt getan, und schon mounted auch der LMU-Controller von Apple sowie der Eintrag in den Bildschirmeinstellungen (siehe Anhänge). Leider bewegt sich der Slider nicht, weshalb ich kurzerhand das Repo "VirtualSMC" geklont habe, um weitere Debugs einzufügen. Und zwar wollte ich wissen, was _ALI zurückgibt, nachdem diese Schnittstelle von SMCLightManager gepollt wird.

Danach konnte ich mittels dmesg den Wert auslesen, welcher recht enttäuschend ausfällt:

Nun machte ich mich auf die Suche nach LHIH und LLOW, nachdem diese zwei Variablen den Output bestimmen.

Die Variablen befinden sich in einer OperationRegion auf dem SystemMemory, im globalen Scope. Ansonsten gibts wohl keine weiteren Zugriffe mehr darauf...

Und nun steh ich an. Die Werte werden wohl von einer ganz anderen Stelle im System über ihre bekannten Speicheradressen beschrieben (oder auch nicht, wie die 0 zeigt...). Hat jemand von Euch Ideen, wie ich weitermachen könnte?

MacPeet

Leider auch hier kein Erfolg. Ich hab mal zwei Screenshots angehangen, aber auch dort wieder nur HDMI Audio. Langsam frag ich mich wirklich, ob das mit dem Dump überhaupt getan wäre... Sieht ja so aus, als wäre das mit dem SoundWire-Bus generell anders als das gewohnte audio-setup.

MacPeet

Hab gerade gesehen, dass der Controller anscheinend auch ohne FakePCIID registriert wird, nachdem HDEF bei Pci(0x1F,0x3) registriert wird, und nicht HDAS. Einige Repos mit Comet Lake haben das auch schon als "obsolete" rausgeschmissen.

Leider geht das mit dem codec-dump bei mir nicht so einfach. Ich hab in /proc/asound zwei Karten, beide mal hier angehangen. Recht generisch, dieses "Realtek XXX" krieg ich einfach nicht. Ich frag mich ob dieses Linux header file eventuell meinen codec darstellt, dann wär die Codec-ID 0x10ec1300.

Wenn man mal den hw-probe vom XPS 9500 mit dem vom XPS 9700 vergleicht, haben die eigentlich recht genau den selben PCH cAVS controller. Dort läuft der Sound aber, und laut diff von AppleALCs Resources hat der Ersteller des 9500er-Repos einfach das Layout vom 9300er 1:1 kopiert. Die benutzen ALC289, trotz anderem PCH cAVS, was bei mir nicht ging, also muss sich wirklich was geändert haben. Schade.

Hast Du sonst noch eine Idee, wie ich den codec dumpen kann? Krieg' ja nur diese dämlichen HDMI codecs.

Hey!

Gibts schon Neuigkeiten zum ALC711 in Verbindung mit macOS? Anscheinend dürften ja einige Unterschiede zum 9500er vorliegen... An sich wärs denk ich machbar, dem AppleALC ein neues custom layout hinzuzufügen, wie es in diesem Commit auch schon gemacht wurde. Ist zwar unglaublich viel zum einlesen, aber ich würd's mir antun. Mein größtes Problem aktuell ist, dass ich auf Linux den Realtek-Codec nicht so richtig ausgelesen bekomme. Mit dem neuesten Ubuntu 21.10 läuft der Sound auch perfekt, hab mal einen alsa info dump angehangen.

Interessanter Auszug:

Der folgenden Zeile nach:

dürfte es sich ja wirklich um einen 711er handeln, siehe RT711. Was auch immer HS bedeutet, speakers sind dann wohl RT1308 und microphone RT715. Kenne mich leider mit dem ganzen Thema kaum aus, bis jetzt wars immer nur eine Frage der layout-id in AppleALC, so tief musste ich nie gehen, ^^".

Ein kurzes LSHW zur Kategorie Sound brachte mir folgendes:

Wobei TU106 von der Nvidia stammt, und das pci@0000:00:1f.3 zu PciRoot(0x0)/Pci(0x1F,0x3) korrespondiert.

Das XPS 9500 sollte ja meines Wissens nach mit dieser Konfiguration Sound von sich geben, selbst wenn nicht perfekt:

Da wärs wiederum interessant, wie man auf C89D0000 kommt, was in little endian 9DC8 wäre, und vom Hersteller Intel (8086) das Gerät hier darstellt:

Ist das eine Art PCIID-Spoof, weil Cannon Point bei echten MacBooks eingesetzt wird? Soweit ich das verstehe, ist ja der Controller am PCIe-Bus angeschlossen, und am Controller dann der Chipsatz, in dem Falle der RT711. Also muss macOS den Controller laden, und AppleALC fixt dann den Chipsatz, denk ich.

Würde mich sehr freuen wenn da was passiert, ich bleibe jetzt auf jeden Fall auch dran. Ist wirklich eine top Maschine der 9700, und mit Sound wäre das für mich perfekt.

Übrigens: Hat jemand einen dump bzw. weitere Audio-Informationen vom 9500er vorliegen? Würd mich mal interessieren, wie das dort aussieht. Hab gerade gesehen, dass AppleALC den Controller {8086:06c8] patchen kann, hier ganz unten.

Gibt's hier irgendwas neues, bezüglich dem Thema? Hängt bei mir gute 5-10 Sekunden...

War das vor BigSur auch schon? Kann mich garnicht mehr erinnern.