Beiträge von RenStad

Hat tatsächlich niemand eine Idee?

So schnell wird ja noch nicht das Handtuch geworfen. Ich habe heute begonnen, mich in das Thema GPIO-Pinning einzuarbeiten und mich hierzu damit befasst.

Jedoch stecke ich bereits im Schritt 1 fest, denn ich kann das in Windows identifizierte Gerät:

TPD0 über den IO-Registry-Explorer überhaupt nicht finden. TPD0 ist also nirgends angeschlossen. Die Suche nach I2C0 ergibt dieses Bild:

i2C0 offenbar ohne angeschlossenes Gerät. Nun sagt die Anleitung von voodoo:

"Wenn das Gerät nicht angezeigt wird, haben Sie wahrscheinlich den Windows-Patch nicht angewendet".

Mit Windows-Patch ist wohl die SSDT-XOSI und die das Patch _OSI to XOSI gemeint. Da ich die SSDT-XOSI korrekt eingebunden und die Umbenennung enabled habe, muss es eine andere Ursache geben. Wenn ich das Gerät nicht finde, kann ich auch die anderen Schritte der Voodoo-Anleitung nicht anwenden.

Schaue ich mir meine DSDT an, finde ich das Gerät TPD0 - wie in Windows-Geräte-Manager gezeigt - unter PCI0.I2C0 angezeigt.

Jedoch wird das gleiche Gerät auch unter I2C1 - i2C3 angezeigt und ist so also vier mal vorhanden. Könnte das die Ursache sein, oder mache ich einen grundsätzlichen Denkfehler?

EDIT:

voodoo hängt sich zwar an richtiger Stelle an, jedoch fehlt eben das Gerät und somit kann ich die APIC-Pin-Nummer nicht prüfen.

Nein, keine Funktion, weder Tasten noch Pad.

EDIT: soweit ich mich jetzt belesen habe, scheint das Problem wohl zu sein, dass SSCN in meiner DSDT nicht vorkommt. Kann das jemand bestätigen? Und wenn ja, was könnte ich tun?

Da das Pad nun gar nichts macht, ist Deine Überlegung sicher nachvollziehbar. Aber das wäre wirklich zu einfach. Dies hat zwar auch zwei Tasten, aber Einschalten muss man das Touchpad nicht, weder in Windows, noch in Linux.

EDIT:

Ich habe mal die Meldung beim Booten in Ruhe angeschaut. VoodooI2C meldet folgendes:

• VoodooI2CPCILakeController::pci8086,34e8 Startıng I2C Controller
  
• VoodooI2CPCILakeController::pci8086,34e8 Set PCI power state D0
• VoodooI2CPCILakeController::pci8086,34e8 Current CPU is Comet lake or Ice Lake, patching…
• VoodooI2CPCILakeController::pci8086,34e8 Publishing nub
• VoodooI2CControllerDriver::pci8086,34e8 Probing controller
• VoodooI2CControllerDriver::pci8086,34e8 Found valid Synopsys components, continuing with initialisation
• VoodooI2CControllerNub::pci8086,34e8 SSCN not implemented in ACPI Tables
  
• VoodooI2CControllerNub::pci8086,34e8 FNCN not implemented in ACPI Tables

• VoodooI2CControllerDriver::pci8086,34e8 Warning: Error getting bus config, using defaults where necessary
• VoodooI2CControllerDriver::pci8086,34e8 Publishing device nubs

Weiß jemand, was SSCN und FNCN hier bedeutet.?

cobanramo : Ich ging in der irrigen Annahme an das Projekt, dass die EFI meines HP-Probook´s mit angepassten IGPU-Einstellungen halbwegs laufen sollte. Was sich schnell als Irrtum herausstellte. Ist doch ein völlig anderes Gerät. (Nicht mal der SATA-Adapter für eine SSD passt. Hatte noch einen übrig und nun muss man wieder suchen.)

Die EC0-Rename und der Kernel-Patch sind da noch übrig geblieben. Habe ich nun herausgenommen.

Bei den andern beiden Patches handelt es sich um die verzweifelte Übernahme irgendwo aufgeschnappter Hinweise, die ebensowenig zum Erfolg führten, aber nach dem Motto: "Versuch macht klug" in die Config gelandet sind. Sind natürlich meist Blödsinn und sind im jetzigen Stand auch nicht mehr drin.

Die "SSDT-PNLF-CFL.aml" habe ich dank Deines Hinweises gegen die neue ersetzt.

Zitat von cobanramo

Inject VoodooInput located within VoodooI2C, not VoodooPS2.

Das leuchtet ein - habe ich geändert. XhciPortLimit - wie schon geschrieben - deaktiviert.

Die neuste Whatevergreen.kext nutze ich bereits, die Grafik läuft auch problemlos und wie gesagt, das anfängliche Flackern ist dank der Dokumentation von Whatevergreen und den gesetzten Properties-Einträgen und Boot-Args auch verschwunden.

Deine XOSI habe ich eingebaut. Soweit danke für Deine Hinweise. Ich hänge mal den aktuellen Stand für Interessierte hier ran (soweit also aufgeräumt).

Was dennoch bleibt, ist das Touchpad. Ich lese nun die Hinweis von grt - das scheint mir der entscheidende Hinweis zu sein. Mal schauen.

P.S. Ich muss ja bei der Gelegenheit mal den Web-Admins hier danken. Das Hochladen von Dateien ist ja wirklich ein Kinderspiel. Da will man den ganzen Tag nur Dateien hochladen.

EDIT: Na das ist ja jetzt peinlich: LetsGo hat völlig recht. Es handelt sich nicht um ein HP-850 G8 sondern um ein HP-250 G8, und das steht auch auf dem Boden und - was soll ich sage - auch auf der Rechnung - (mein Gott, die Augen werden auch nicht besser). Sorry, ich ändere die Überschrift - aber das Problem bleibt.

EDIT2: Der Hinweis mit dem Ausschließen von 2 Apple-Kexts hat es auch nichts gebracht.

Ich habe analog zu Deiner config grt , die beiden Apple-kexts in Kernel/Block aufgenommen. Leider auch kein Erfolg (Zur Sicherheit NVRAM-Reset und nochmals in den Installer fahren - keine Funktion des Touchpads).

OSX-Einsteiger : Danke für den Hinweis, habe ich übersehen, das muss natürlich auf no/false stehen.

Korrigiert, aber erwartungsgemäß keinen Einfluß auf das Touchpad.

LetsGo: Das wäre natürlich lustig. Aber HP-850 G8 steht auf dem Gehäuseboden, wie auch auf der Rechnung und im Support von HP. Als Produkt-ID wird 27J99EA#ABD angegeben. Ist schon irgendwie nicht ganz verständlich, warum die Hersteller mit soviel verschiedenen Geräten auf dem Markt kommen. Und das Verrückte ist, die haben alle tatsächlich zahlreiche Unterschiede.

Noch immer kein Erfolg. Der Reihe nach:

OSX-Einsteiger: Egal welche Reihenfolge ich versuche, es ändert sich nichts. Die Reihenfolge, die Du vorgeschlagen hast, passt im Wesentlichen mit der in meinem HP-Probook 440 G6 überein und funktioniert dort. Ohne irgendwelche speziellen aml-Datein.

Bandit : Die Anbindung über USB schließe ich aus. Das wird unter Linux angezeigt:

Die USB-Ports wurden bereits gemappt. Dort hätte ich das Touchpad nicht übersehen.

LetsGo : Habe die Anleitung mehrmals durch aber hier fehlt mir noch etwas an der Umsetzung. So wie ich das verstanden habe, sollte alles passen, oder interpretiere ich das hier falsch:

grt : Danke für Deine Rückmeldung. Zum Glück ist ja morgen schon bald heute. Auszug aus der ioregistryexplorer oben.

LetsGo : Ich habe Deine SSDT-GPIO eingebunden, jedoch auch keine Veränderungen. Wobei ich denke, dass Du ja Device GPI0 in meiner DSDT gefunden hast.

Inzwischen habe ich noch weiter kexts aus der Voodoo-Familie getestet (VoodooI2CELAN.kext, VooddooSMBus.kext, VoodooI2CSynaptics.kext), wobei mir hierbei noch nicht ganz klar ist, welche diese Kexts sich gegenseitig "beißen" bzw. ob und wie diese mit den "Haupt-Kexts" VoodooPSController.kext und VoodooI2C.kext zusammen arbeiten oder nicht. Man findet auch zahlreich Widersprüchliches.

Also danke schon mal bis hierhin für Eure Mühe. Ich glaube noch immer an den Erfolg. So jedenfalls ist die Kiste für alle Alltagsaufgaben ein sehr preiswertes Gerät.

Habe ich durch, ob ich alles genauso verstanden habe, muss ich wohl vor dem Hintergrund, dass das Touchpad noch immer keinen "Ton" von sich gibt, bezweifeln.

Habe mal mit einer alten Clover-EFI die DSDT gezogen. Vielleicht sollte ich nach etlichen Stunden erstmal kurz etwas anderes machen und wenn ich Glück habe, findet sich ein Laptop Experte - z. B. unsere grt die mal einen geschulten Blick in die DSDT werfen. Ich finde das Touchpad dort nicht. Aber es muss da sein, denn es befindet sich gerade unter meinen Händen.

Danke Dir für die schnelle Antwort. Das hatte ich aber auch schon versucht, aber bei den vielen Kexts und dann noch den Plugins gibt es ja ausreichend viele Varianten.

Habe jetzt Deinen Vorschlag so wie im Bild umgesetzt, aber das Ergebnis ist leider das gleiche.

Nach wie vor keine Reaktion des Touchpads.

Mal wieder ein neues Projekt übernommen. Diesmal geht es um ein HP-850 G8 HP-250 G8 Notebook mit Intel i5-1035G1. Das Gerät hat eine kompatible WLAN-Bluetooth-Karte bekommen. Für das USB-Mapping habe ich mit Catalina angefangen, später soll Monterey drauf.

Die iGPU hat ein wenig Probleme gemacht, aber nun läuft sie und das ca. 5 Sekunden lange Flackern nach dem Start ist nun auch behoben. Soweit funktioniert erstmal fast alles.

Lediglich am Trouchpad beiße ich mir die Zähne aus. Mit Linux habe ich ein ELAN 0709 (Vendor 04F3, Produkt 31bf), das physisch am i2c bus hängt (pci0000:00/0000:00:15.0/). Es ist nicht mein erstes HP-Laptop, das ich zum Laufen bringen konnte. Der in meiner Signatur läuft nach wie vor völlig problemlos. Nach stundenlanger Beschäftigung und das Studieren zahlreicher Beiträge gehen mir langsam die Ideen aus.

Das Touchpad wil garnicht, nicht mal die einfachen "Mousefuntionen". In Windows oder Linus läuft es aber.

Ist jemand hier, vielleicht sogar auf den ersten Blick erkennt, wo hier mein Fehler liegt bzw. ob ich um die Beschäftigung mit speziellen DSDT´s ein Weg vorbei führt? Ich hänge mal die bisherige EFI ran.

Ok, habe ich wohl den Grund Deiner Fragen nicht richtig verstanden. Dann hoffen wir mal, dass Mac-Mini-Besitzer diese beantworten können.

Meinst Du nicht, dass Du beide Fragen Dir auch leicht selbst beantworten könntest:

1. Ist das Gerät noch zu haben?

2. 4K-Displays an MacMini

griven das Stimmt, da habe ich ins Schwarze getroffen.

Ok dann hier:

4, 11, 19, 26, 29, 38 Superzahl 8

Zitat von KMac

naja der 22.03. 20Uhr kommt erst noch... oder lebst du oin der Zukunft?

Ist mir dann heute auch aufgefallen. Möchte jemand die Lottozahlen von morgen?

Probleme sind offenbar ausgeblieben. Nichts gemerkt vom Update. Die Seite lief problemlos weiter. Da waren offenbar Profis am Werk.

Nur der Versuch macht klug. Ich habe die Einstellungen von @schmalen übernommen und siehe da - deutliche Verbesserung.

Mit Geekbench 5 - ohne die Properties-Einträge:

OpenCL Score = 34488

Metal Score = 33251

Mit Geekbench 5 - mit den Properties-Einträgen:

OpenCL Score = 42440

Metal Score = 43504

Schon die Dauer der Tests hat sich deutlich unterschieden, von mehr als 2.5 Minuten auf unter 40 Sekunden.

Na dann erstmal danke für Eure Antworten. Dann mache ich mal an die Arbeit.

Bei den "zerschossenen" Hintergrundbildern hat mich besonders überrascht, dass die für die dynamischen Hintergrundbilder im Ordner "system/library/desktop picture" liegenden heic-Dateien selbst in "Vorschau" angezeigt, diese Fehler hatten. Aber eben auch nur die. D. h. offenbar haben die Betroffenen hier nicht nur ein "Darstellungsproblem" beim Aufrufen der Bilder vom System, sondern die Dateien müssten beim Update dieser Fehler erhalten haben. Das wäre dann irgendwie schwer nachvollziehbar. Vielleicht waren hier aber auch die Beobachtungen nicht ganz korrekt.

Ich teste mal die Properties und melde mich wieder.

EDIT:

Den Hinweis von ozw00d zu spät gelesen. D. h. für die RX5500 XT werden die Properties keinen Erfolg bringen?

Ich höre wiederholt von Grafikproblemen für Nutzer von AMD-GPU nach dem Update auf 12.3. Auch im Netz findet man Berichte darüber. Ich selbst konnte es an meinem Gigabyte-Board mit ADM RX5500 XT nur bedingt nachvollziehen. Die zerschossenen Hintergrundbild-Datei hatte ich jedenfalls nicht. Andere schon.

Darüber hinaus wurde mir berichtet, dass die Rechner dann z. B. bei der Wiedergabe von Videos plötzlich ins "Stocken" geraten. Auch bei Nutzung von Google-Earh kam es zum Stocken. Meist half allenfalls ein Neustart, wobei der auch nur mit Reset möglich war.

Habt Ihr ähnliche Erfahrungen machen müssen und wenn ja, gibt es vielleicht Erklärungen bzw. Lösungsverschläge.

Das wäre ja toll, weißt Du welche Eigenschaften injiziert werden sollten / müssen?

Würde mich auch interessieren. Wir haben hier jetzt so ein Fall, dass nach dem Abmelden, SMIOS-Wechsel, Neuinstallation (Monterey) und Wiederanmelden alles funktioniert, jedoch kein Synch mit der iCloud Drive.

Hat jemand eine Idee?