FakeSMC.kext vs VirtualSMC.kext

Na, weil man davon wohl Abstand halten sollte, wenn man noch Tomaten auf den Augen hat.

Zitat

... dass VirtualSMC nicht mehr weiter entwickelt wird ....

Leute macht mich nicht schwach, ich dachte genau anders herum. FakeSMC-Version liegt ein Jahr zurück und VirtualSMC von diesem Jahr - wie muss man das denn Verstehen? FakeSMC liest auf jeden Fall die Temp. der VII aus.

Hallo knollsen ,

so wie du es schreibt passt das.

https://github.com/acidanthera/VirtualSMC

Die Antwort kam ja schnell!

... gefährlich dann sowas zu schreiben ... Bloß sollte man auch sagen, das Neu nicht unbedingt besser ist!

Wenn man den Ausschnitt wie du knollsen aus dem Zusammenhang rauslöst, kann man da alles mögliche draus schließen...

Im Kontext lese ich da aber etwas komplett anderes heraus!

Zitat

...Was die Entwicklung von VirtualSMC angeht so ist das mit Nichten so, dass VirtualSMC nicht mehr weiter entwickelt wird es wird lediglich nicht mehr für Clover getestet und auf Clover optimiert. ...

Schön das Du aufpasst! Bedeutet aber, das der Fall eintreten könnte, wo VirtualSMC nicht mehr (irgendwann) mit Clover funktionieren könnte. Also sollte man jetzt schon aufpassen oder wissen, wenn der KextUpdater die neue SMC anbietet. mmm

Es sei denn, man beschäftigt sich jetzt schon mit OpenCore! Hat bei mir leider noch nicht funktioniert, aber das in anderen Thema

Zitat von knollsen

das der Fall eintreten könnte, wo VirtualSMC nicht mehr (irgendwann) mit Clover funktionieren könnte

Halte ich für extrem unwahrscheinlich. VSMC interagiert ja hauptsächlich mit macOS und nicht mit dem Bootloader. Das einzige was sein könnte ist, dass FileVault die Grätsche macht bei Kombination von VSMC und Clover.

In dem Fall dürfte dann aber jemand um die Ecke kommen und einen neuen EFI Treiber für VSMC + Clover bauen, ähnlich wie es ja mit dem Aptiofix von OpenCore geschehen (OcQuirks von ReddestDream).

guter Vergleich - Danke! Denk mal, das dies auch jeder versteht.

Die Problematik hat sich doch mit OC-Quirks und damit einhergehend mit dem Einsatz von FWRuntimeServices.efi auch unter Clover eh in Wohlgefallen aufgelöst

Der EFI Treiber aus dem VirtualSMC Paket ist doch in FWRuntimeServices.efi aufgegangen und steht damit auch unter Clover zur Verfügung sofern man eben OC-Quirks und FWRuntimeServices.efi im Einsatz hat (was aufgrund der AptioFix Situation unter Clover eh empfehlenswert ist). Ist unterm Strich mal wieder viel Wind um rein gar nüscht der hier gemacht wird *gg*

What? FwRuntimeServices ersetzt VirtualSMC.efi? Das ist mir neu. Quelle?

griven  CMMChris ist falsch, der Code ist direkt in OC

griven Die letzten Wochen habe ich nun nur mit VirtualSMC gearbeitet und konnte in der tatsächlichen Laufzeit keinen Unterschied feststellen. Was an Restzeit berechnet wird unterscheidet sich aber in jedem Fall, wobei du auch hier voll ins Schwarze getroffen hast, denn zum Auslesen der Stats verwendete ich mit FakeSMC den ACPIBatteryManager, nun mit VirtualSMC die mitgegebenen Boardmittel.

Ah okay mhaeuser mir war so als wäre es in die FWRuntimeServices aufgegangen was dann wohl ein Irrtum war also in dem Sinne weiter Wind machen an der Clover Front *gg*

mhaeuser zumindest ohne VirtualSMC.efi kommt Clover ganz gut klar.

VirtualSMC.efi war und ist seit Anfang an nur für FileVault wirklich relevant. Gleiches gilt für SMCHelper (der nur mit Clover kompatibel ist, correct me if i'm wrong).

kuckkuck das heißt: FwRuntimeServices ersetzt VirtualSMC.efi?

nichts ersetzt VirtualSMC.efi, der Code ist in OC

ich nutze kein OC und FileVault funktioniert ohne VirtualSMC.efi

dann sollte 1) boot.efi Fehler werfen und 2) Authenticated Reboot nicht funktionieren

woran würde ich das erkennen?

habe schon mal nachgeschlagen. Kann ich nicht testen.