Suchergebnisse

(Zitat von Pexa)dann funktioniert die akkuanzeige zumindest schon mal normal. was ist mit cpu-powermanagement? taktet die cpu rauf&runter?für den airportitlwm.kext muss ggf. die originale io80211family.kext zum laden "gezwungen" werden. geht in der config im punkt "kernel" wenn ich mich recht erinnere.

z.b. mit dem intel-powergadget. kann aber auch sein, dass der rechner jetzt direkt nach der installation noch mit "sortieren" (spotlight z.b.) beschäftigt ist. erstmal abwarten würde ich vorschlagen.

usb-mapping ist notwendig, wenn der rechner aus dem sleep direkt wieder aufwacht, oder wenn BT oder webcam nicht erkannt werden. bei läptops gehts mit den wenigen usbs gelegentlich auch ohne (wenn nix ihn vorzeitig weckt und alle usbgeräte funktionieren).und wenns mit deep-sleep probleme gibt, ist das eher nicht auf die usb's zurückzuführen.

ist eine app und hängt dran.

tuts. dass der akku sich so schnell entlädt liegt zumindest mal nicht an der cpu. die benimmt sich korrekt.

da gibts doch irgendwo eine einstellung "bei tastatureingabe trackpad deaktivieren" - aber wo.... *kopfkratz*

das weiss ich leider nicht mehr... an einen haken "versehentliche *was auch immer* eingaben ignorieren" kann ich mich auch dunkel erinnern. aber das alles könnte sogar linux gewesen sein

dochdoch... den ersten hab ich schon entdeckt:(Zitat von Pexa)kann beides sein...

wird das trackpad als solches in den einstellungen erkannt?

hmmm.... ich werd mal meine läptops inspizieren, ob einer von denen auch so eine meise hat. yoga nicht, bei den anderen weiss ich das nicht.aber warte mal... warum drückst du eigentlich cmd, wenn du auf dem trackpad herumhantierst?

ich nutz als rechtsklick einfach 2 finger... funktioniert auch. und tippen = klicken.

ist verständlich. wird bei der grafik (apfel -> systembericht) 15xx oder 2048 als speicher angezeigt? wenn 2048 würde ich den patch in den deviceproperties abschalten, das mag nämlich nicht jede grafikkarte.und ein paar kleinigkeiten in der config sind mir aufgefallen:von den ssdt-ec... brauchts definitiv nur eine, und die ersten 2 renames in der acpi-patch-liste sind unsinnig, die sollten weg. ausserdem werden IPIC und TIMR _CRS methoden umbenannt (ob das greift, müsste man gucken), die ssdt-hp…

(Zitat von HackBook Pro)laut deviceproperties ja. und der IRQ/HPET-patch ist aus meiner sicht nicht sauber: HPET hat die fehlenden interrupts per ssdt verpasst bekommen, die entweder auch weiterhin in den anderen devices vorhanden sind, oder aber den devices fehlt die _CRS komplett.

will heissen, statt einzuschlafen kriegt er kernelpanik. kannst du mal den panikbericht aufrufen -> details in dem "dein mac wurde..." -fenster, speichern (nicht an apple senden, sondern copy-paste in eine txt) und hochladen? dann kann ich gucken, was dem armen angst macht, wenn der deckel zugeht

könntest du mal ins terminal eingeben:log show --style syslog --start "2021-5-31" | fgrep "Wake reason"und gucken, was den klapptopf als letztes aufgeweckt hat? wie es aussieht, geht er brav schlafen, wird direkt wieder geweckt, und erschreckt sich dann ganz heftig

grmpfff... warum "privat"schreib mal ein sudo und danach ein leerzeichen vor den befehl.. vielleicht erzählt er uns dann was sinnvolles...

mistviech....das ist bigsur? vielleicht liegts an den restriktionen?dann mal ein pmset -g ins terminal

das bildschirmschoner/displayabschalte problem ist aber wieder gut?

und wenn sich das display dann nach einer weile ganz abschaltet, kommt er auch wieder in gang?

gut. dann ist das zumindest schon mal nicht die ursache. dann bereinigen wir erstmal die efi/config ein wenig.- eine von den SSDT-EC... kann weg. die sind identisch - warum die SSDT-HPET doppelt in der liste steht?? ein eintrag kann gelöscht werden.- die ersten beiden renames (acpi > patch) heci to imei.. und mei to imei... auch weg. die brauchts nicht.- von den beiden HPET _CRS .... würde ich den ersten, der disabled ist, bevorzugen. also den ersten enabled, den danach disabled (den aber sicher…