Und kriege immer ein bischen mehr Durchblick bei OC
weiter so. mach doch eigentlich spass, oder?
Beiträge von grt
-
-
beim voodoo.xyz vor allem mal die ganzen auf false stehenden einträge aus der config.plist rauslöschen. da sieht mal vor lauter unnötigem voodoo den rest nicht mehr..
und broadcombluetooth braucht genau 3 kexte. den injector, wenn system neuer als catalina ist das der bluetool... und dann patchram3.irgendwas und noch einen (muss ich gucken). 2 injectoren sind einer zuviel.
was ist denn eigentlich verbaut an wlan/bt?
-
ich würde ja das durcheinander in der kextabteilung mal gründlich ausmisten.. da stecken mehrere bluetooth-kexte drin, die sich eigentlich widersprechen (injector und, bluetool oder so) und auch noch in mehreren versionen, aktiv, mal dann doch nicht.. die voodoo...kext abteilung würde ich auch straffen, das kann echt fehler nach sich ziehen, wenn da gleich mal mehrere eingetragen sind.
was der xhci-unsupported.kext macht, ist mir bislang verborgen geblieben. früher mal schien der in seltenen fällen bei exotischen controllern sowas wie die letzte möglichkeit gewesen zu sein, aber inzwischen behaupte ich mal dass man den getrost weglassen kann.
der cardreader rennt auch nur, wenn sich beide kexte drum kümmern?
utb/usbtoolbox wurden explizit für diesen läppi erstellt oder kommen die aus dem netz?
ansonsten fällt mir erstmal nix weiter auf.
die olarilassdt würde mich ja mal interessieren.. schieb die doch bitte mal hoch.
-
da müsste noch ein ordner patch in acpi sein? öhm... neee nicht ordner, sondern in der config in der abteilung acpi -> patch
-
was mir da direkt ins auge springt: im normalfall brauchts für die SSDT-XOSI.aml doch den _OSI -> XOSI rename, damit die weiche greift? der ist aber nicht drin.
EDITH:
in clover/acpi/origin landen die originalen ungepatchten acpi-tabellen, wenn man beim cloverboot mit F4 die dateien "anfordert". in einem bereits gepatchten system kann man die originalen acpitabellen ja nun nicht mehr extrahieren, ubuntu (linux im allgemeinen) ist kein wirklich guter anlaufpunkt fürs ziehen der originalen tabellen, da kanns zu seltsamen fehlern kommen. eine extraktion der tabellen noch bevor irgendein system sich evtl. daran irgendwie vergriffen haben könnte ist einfach mal die sauberste sache. daher ist clover dafür mindestens noch sehr brauchbar
-
überhaupt nicht angezeigt wird
das hatte ich schon genauso verstanden, und das kann (bei einer neuinstallation zumindest) durchaus auch daher kommen, dass das installationsprogramm die platte eben manchmal gerne in hfs+ serviert bekommen möchte, und apfs komplett ignoriert. daher meine frage.
und die vergessenen bzw. nicht aktivierten apfs- und hfs+ treiber sind einfach mal eine ziemlich häufige und gerne übersehene fehlerquelle...
-
Habe ich das jetzt richtig verstanden?
jein....
alle anderen OS via OC holen sich die ACPI dann nicht wie sonst selbst sondern greifen auch in den ACPI-Ordner von OC
das machen sie nur dann, wenn oc den bootvorgang angestossen hat. auch, wenn oc dann an grub oder windosendingens weitergeleitet hat. in dem fall werden die acpi-tabellen (gepatchte/bearbeitete dsdt.aml sowie die vorhandenen ssdt-irgendwas.aml) an den booter des anderen systems weitergereicht. ebenso wird ohne den oben von griven erwähnten haken (smbiosirgendwas) auch das "behauptete" macmodell mitgegeben, so dass das andere system mit dem läptop so umgeht, als wärs tatsächlich ein macbook.xyz. was auch zu verwirrungen führen kann...
wenn das andere system per F12 mit seinem booter direkt gestartet wurde, dann bleiben die anpassungen von oc aussen vor.
das weitergeben des fake-smbios an andere systeme lässt sich ja noch einfach umgehen, die ssdt-anpassungen sind hartnäckiger: da muss vereinfacht bei jeder anpassung dazugesagt werden: wenn (if ...) du dich auf einem macos wiederfindest { mach mal bitte folgendes..... *hier die manipulation beschreiben* }, wenn nicht { einfach bleiben lassen/ das hier ignorieren...}.
oft läuft das auf umbenennungen (find/replace in der acpi-abteilung) einer originalen methode in kombination mit einer ssdt hinaus, deren inhalt dann (ganz grob!) in etwa so aussieht:
methode BLA_originalername - wenn macos: mach dies/jenes/welches/. wenn nicht (aufruf der umbenannten originalmethode (BLA_umbenannt) mit originalem inhalt)
-
manchmal sollte das ziellaufwerk hfs+-formatiert sein statt apfs - hast du das mal probiert? und hast du sowohl den hfs....efi treiber, als auch den apfs....efi an bord inkl. aktivierung in der config?
ich nehm an, du machst kein direktes update, sondern eine neuinstallation?
-
worauf hast du das system denn installliert? gibts ein weiteres laufwerk? ich dachte, die installation wär durchgelaufen *kopfkratz..
-
über i2c
wie kommst du darauf?
-
nein, aktuell nicht..
-
und bitte im alten thred weitermachen, nicht fürs gleiche problem einen weiteren erstellen. das verwirrt nur, und ist unordentlich.
-
Zu alles was du mit ## siehst ist als Kommentar
ist mir klar. ich geh aber mal davon aus, dass die einträge dringeblieben sind, weil sie evtl. doch passen könnten, getesten werden sollten... etc. auf jeden fall, dass du dir was dabei gedacht hattest, als du sie nur deaktiviert, aber nicht gelöscht hast. destawegen hab ich dazu auch was gesagt.
und ja, auch das mit dem spoofen kenne ich. aber muss da nicht die igpu komplett wie eine kbl. anstatt einer skl behandelt werden? also sind die skylakekexte noch da? insbesondere der framebuffer.kext für skylake? dann kann man natürlich die id's daraus nutzen. aber das weiss ich nicht und kann ich auch nicht gucken mangels ventura.
-
eigentlich sollte der dvi keine probleme bereiten. was mir bei den deviceproperties auffällt:
bei dem abgeschalteten ersten ## gibts nur die igplatform. die wäre richtig, wenn nicht skylake bei ventura rausgefallen ist. soweit ich weiss, sind damit auch die skylake-igpu-kexte nicht mehr dabei (müsste mal wer gucken, ich hab selbst kein ventura), und damit auch die skylake-igplatformid's.
beim 2. ist wieder die skylake-id angegeben. würde ich mal prüfen, ob da nicht besser eine für desktop aus der kbl-reihe angebracht wäre.
und beim dritten sind mir zuviele connectoren angegeben. im normalfall brauchts die nicht. und bei der id bin ich gerade nicht ganz sicher? skl oder kbl?
interessant könnte an der stelle auch mal ein ioreg sein. und ich brauchte bei meinem skylake damals eins von den agdpmod-args, damit die grafik ordentlich lief.
-
eldxmgw ich würde dich doch sehr inständig bitten, deinen tonfall und deinen umgang mit den anderen ganz gründlich zu überdenken. unterstellungen wie
Bitte komm von den Irrglauben ab, dass Menschen für dich das Denken übernehmen. Die Leistung musst Du schon selbst übernehmen
(nur ein beispiel rausgepickt..) gehen einfach mal gar nicht. ab sofort mässigen, oder urlaub. ist deine entscheidung.
-
nee... der stammtisch liegt aktuell auf eis. es gab einiges an umstrukturierungen im maxfish, wo der stammtisch stattfand, ausserdem war die resonanz bei den letzten 3 oder 4 stammtischen sehr überschaubar (nennt man monolog oder so... ), so dass ich erst mal pause eingelegt hab.
-
hmmm... ich hab doch im hardwarecenter einen bis bigsur getesteten oc-ordner hinterlegt: KLIKK
den anderen, der unten angefügt ist, nicht von mir, den hab ich bisher nicht inspiziert und getestet...
-
ich schliess mich mal an: frohes, glückliches, gesundes, erfolgreiches ... (liste darf je nach gusto individuell ergänzt werden) 2023 wünsche ich euch allen.
-
ich schrub "csm enabled", was bei allen haswell igpus, die mir bisher in die finger kamen - desktop, laptop, hd4400, hd4600 - notwendig war.
dass man bzgl. uefi und legacy darüber hinaus auch noch mehr einstellen kann/muss ist mir bekannt bluebyte .
die vorherige (3.) igpu-generation benötigt kein csm, broadwell danach schon. skylake dann wieder nicht mehr. jeweils bezogen auf die nutzung der igpu.
-
csm sollte bei den haswell-igpus hd4400 und hd4600 auf enabled stehen.
