Posts by Download-Fritz

    Maddeen Auch da steht nichts von einer Hardware-Limitation, sondern, dass die Firmware verkorkst ist. Natürlich kann es dafür ein Workaround geben (Windows? Läuft Recovery überhaupt über UEFI?), kann sich aber niemand wirklich anschauen. Bzgl. der Parameter, die ersten beiden nicht, TimerResolution vielleicht... höher könnte ggf nicht unterstützt sein (Hardware-Limitation), niedriger ggf. zu geringe Granularität ("übersehene" Tastendrücke). Ich bin auch etwas überfragt, aber ohne die Hardware lässt sich in einem Einzelfall nicht viel machen.

    Also das mit den Hotkeys funktioniert leider nicht wirklich zuverlässig. Gedrückt halten geht bei mir nie - egal mit welchen Einstellungen.

    Also mit einer anderen Tastatur?

    Wenn die Tastatur im BIOS geht bzw. im Postscreen - und auch z.B. wenn Windows bootet in den Recoverymode geht, liegt aus meiner Sicht das Problem nicht an der Hardware...

    Das hat auch niemand behauptet - PRs sind offen.

    Maddeen Wie gesagt, die Hotkeys werden nur *nach* der Verzögerung registriert, also bringt viel mehr Verzögerung nichts - die ist "nur" dazu da, einen Abstand nur "Hotkey-Zeit" der Firmware zu haben und Zeit für den Tastaturtreiber, sich zu fangen (wieder irgendwelche Bugs, aber da stecke ich grad nicht drin). KeySwap ist nur dazu da, auf ein Apple-style Layout anzupassen. KeySupportMode=Auto sollte AMI so oder so präferieren, aber teste es bitte trotzdem mal


    EDIT: Manche Tastaturen haben einen BIOS-Modus. Grad kaum Zeit, aber sowas gefunden: https://ubuntuforums.org/showthread.php?t=1843969

    und lädt dann beim Start die Daten ohne große Verifikation (die passiert soweit ich weiß größtenteils davor) aus diesem Cache.

    Das *kann* sogar nur davor passieren, weil durch das Linken die Daten unwiederherstellbar verändert werden - jede Signaturverifikation oder so *muss* also vor dem Linken passieren. Wir sind vor dem ganzen Quatsch relativ sicher :)

    ozw00d Hab das schon mehrfach erklärt, könnte vielleicht mal ins Wiki oder so...


    Der Kernel hat direkt nach dem Start keinen FS-Zugriff, weil er keinen FS-Treiber (oder Schnittstellentreiber, der Baum geht ja noch weiter) hat, braucht aber trotzdem die Erweiterungen. Dazu gibt es den prelinkedkernel, bei dem die Kexts schon gegen den Kernel gelinkt zusammen mit diesem im selben Image verpackt sind und zusammen mit diesem geladen werden. Über ein Offset im eigenen Header kann er dann die Kexts im Speicher finden und starten (Linken geschieht nicht, da *pre*linked). OpenCore modifiziert den prelinkedkernel direkt und fügt die selbst gelinkten Kexts an - im Endeffekt das selbe wie der Cache-Aufgbau im OS (kextcache).


    Damals konnte man den prelinkedkernel (bzw. den Vorgänger MKEXT) noch umgehen, indem man mit "no cache boot" gestartet hat. Das funktioniert, indem der Booter (boot.efi) die Kexts in den Speicher lädt und eine Tabelle mit Adressen aufbaut, die dem Kernel via DeviceTree bereitgestellt wird. Der Kernel lädt und linkt(!) dann die Kexts selbst gegen sich selbst (KXLD), sodass er sie starten kann. Diesen Mechanismus, der seit Yosemite nicht mehr unterstützt wird, nutzt Clover aus, um die Kexts zu laden - und der steht auf der Abschussliste.

    griven SLIC ist kein Thema (bereits erfolgte Aktivierung angenommen), die (bestehende) Aktivierung hängt glaube ich nur von der UUID ab - mit leerem Feld wird die originale beibehalten und Windoes sollte aktiviert bleiben.

    Bei "Device Properties" stehe ich gerade auf dem Schlauch - das Dict "DeviceProperties"? Weil die dortigen Daten werden eigentlich nur von macOS abgefragt... oder MS bedient sich unerwartet doch des Protokolls? Kannst du das testen (also sicherstellen, dass es wirklich an den DevProps liegt und nicht an ACPI oder SMBIOS)?

    Es muss ja kein harter Bruch sein. Windows will auch schon seit Jahren auf ARM, weil diese Chips *jetzt* energiesparend sind und nicht in 30 Jahren, wenn Intel und AMD ihre Initiativen durchhaben. Für ein MacBook für den Ottonormalverbraucher ist das bestimmt eine super Sache

    Maddeen

    * Ja, das Fehlverhalten folgt aus der Implementierung des Features... es ist absolut sinnlos, weil man Einträge einfach auf dem Apple-Weg umbenennen kann (Festplatte umbenennen bzw .contentDetails-Datei nutzen) und zerhechselt nach aktueller Verwendung Apple bless (dynamische Änderung des Boot-Pfades, z.B. nach IABootFiles bei Upgrades)


    * Als Addon würden mW nur das ACPI- und SMBIOS-Gedöns nicht funktionieren. GUI mit Screenshotfunktion, eigener Sortierung usw. ist gar kein Thema


    * "Bootcamp-Windows" gibt es nicht, OpenCore patcht nur SMBIOS und ACPI für alle Systeme - wenn man für macOS irgendeinen Unfug (ohne Ausnahme für Windows) patcht, leidet dann auch Windows darunter, anders kann ich mir Performanceeinbußen nicht erklären

    Ihr schafft es nicht Mal, danke zu sagen, ohne mit ausgestreckten Ellenbogen und Zeigefingern, wie seit fast einem Jahr, immer und immer wieder die selbe absolut unproduktive Leier zu zupfen und den Leuten, die nicht mit so viel Motivation wie ein apfelnico oder ein karacho dabei sind, ans Bein zu pissen. Leute, ihr seid der absolute Wahnsinn, und das meine ich beim besten Willen nicht positiv.


    Hier könnten jetzt ein paar Namen stehen, auch genannte... tun sie aber nicht.

    Stattdessen steht hier DSM2 und nicht wegen seinen Beiträgen zum Forum, die eigentlich auch gelobt gehören. Wir hatten uns schon oft in den Haaren, und wir sind beide nicht immer die nettesten... jeder hat so seine Macken. Statt wie Forentradition in Kleinkindmanier bei jeder Gelegenheit zu Bashen und irgendwelche Fronten zu bilden oder sich bestehenden anzuschließen, inklusive Like-Kreiswichs aller Parteien, kann man Sachen auch einfach aus der Welt schaffen, sogar ohne 6-monatige Paartherapie, und die Zeit sinnvoll investieren. Ist doch besser, eine störrische Maschine zum Laufen zu bekommen und an Thunderbolt zu werkeln, als den ganzen Tag sinnlosen Quark in irgendwelchen Foren zu schreiben.


    Danke DSM2 , mit einer der (menschlich) Korrektesten im Forum.