Beiträge von Maddeen

    ich werde es einfach mal versuchen... aber nur zur Sicherheit, damit ich gleich nichts falsch mache, weil ich ja erstmal wieder auf "Anfang" muss :)


    1) Ich entferne bzw. disable meine selbsterstellte SSDT-USB und entferne die Bootflags bzgl. uia_exclude.

    2) Danach setze ich den XHCIPortLimit auf YES und starte das System neu.

    3) Jetzt habe ich quasi den Ursprungszustand, um dann der Anleitung (in jeden Port einen USB2 und USB3-Stick einstecken, deklarieren usw.) zu folgen.


    Passt das?



    EDIT: Der o.a. Ablauf war korrekt. Somit erfolgreich auf die USBPorts.kext umgestellt. Funktioniert tadellos inkl. Sleep (keine Info bzgl. "nicht korrekt getrennt")

    Aber dann ist die Beschreibung irreführend.... nur mal zur Sicherheit, was ich verstehe...


    Use the “Export” button to generate files to your Desktop

    Drücke Export zum generieren der Files


    Copy SSDT-EC.aml (if created) to EFI/CLOVER/ACPI/patched

    Kopiere die SSDT-EC.aml (sofern generiert) ...


    Choose one of the following two:

    Entscheide dich für eine von beiden (Lösungen)

    1. Copy USBPorts.kext to EFI/CLOVER/kexts/Other or;
      Kopiere USB.Ports.kext nach .... oder
    2. Copy SSDT-UIAC.aml and SSDT-USBX.aml (if created) to EFI/CLOVER/ACPI/patched
      Kopiere SSDT-UIAC.aml und SSDT-USBX.aml (sofern generiert) nach ....

    Ergo würde man bei allen "ifs" insgesamt 4 Dateien erhalten..

    einmal die SSDT-EC (die, sofern generiert, in jedem Fall genutzt werden musst)

    einmal die USBPorts.kext - die man dann nutzten KANN ODER

    man nutzt die SSDT-UIAC.aml (die es immer gibt) UND die (optionale) SSDT-USBX.aml


    Die SSDT-EC habe ich sowieso schon.. eben genau, wie du ja schon sagst, ohne die gar nichts geht :)

    mhaeuser

    Hatte es mit insg. drei versucht. EInmal meine Logitech G110, dann eine Dell (so ne billig-Standard-Tastatur die man zu jedem Dell-PC dazu bekommt) und eine no-Name.


    Ich meinte damit auch nicht dich - sondern die Antwort zu dem Ticket auf Github:

    Zitat


    We did some quick research on the matter, and believe it is a limitation of your host firmware. You can try tuning KeyForgetThreshold, KeyMergeThreshold, TimerResolution values (see Configuration.pdf). If that does not help, we are afraid there is no possible workaround for you to provide.

    Mit den drei Parametern könnte ich zwar noch rumspielen, aber um ehrlich zu sein, verstehe ich die Parameter nicht bzw. ob jeweils ein höherer oder niedriger Wert Sinn macht (jetzt im Bezug zu meinem Verhalten) :wacko:

    Maddeen Hast du jetzt den Ausschnitt nicht verstanden oder habe ich jetzt gerade Tomaten auf den Augen?

    Ggf. hast du was überlesen --- hier mal kurz im Spoiler :)


    Aber eigentlich ging es mir eh nur darum eine verifizierte Aussage zu bekommen, welcher Lösungsweg der Beste ist -- im Sinne von der sauberste, schnellste Weg.

    Hierbei dann auch weniger subjektive Meinungen, sondern ggf. eine objektive weil z.B. SSDTs immer besser als KEXT sind... oder es ohne Bootflags "sauberer" wäre.. oder oder ... :/


    Ich kenne jetzt insgesamt vier Varianten für das USB-Thema

    1) USBinjectall --> schlechteste Lösung, ohne Patches bei jedem OS-Upgrade Probleme usw.

    2) SSDT + Bootflag uia_exclude=USR1;USR2;HS01;HS02;usw --> das ist meine aktuelle Lösung

    3) USBPort.kext --> Lösung 1 via Hackintool

    4) SSDT-USBX und SSDT-UIAC --> Lösung 2 via Hackintool

    Das "one of the following" bezieht sich aber nur auf die Punkte 1 oder 2 -- nicht auf den Inhalt von Punkt 2. 8o

    Sprich entweder nutzt man:


    1) NUR die USB.kext


    ODER


    2) SSDT-USBX und SSDT-UIAC


    Wobei es dann ja noch meine Lösung gibt, mit einer SSDT-USB (keine Ahnung ob die identisch zur SSDT-USBX vom Hackintool ist) und in den Bootflags mit dem Parameter "UIA_EXCLUDE="

    Edit by al6042 -> Bitte keine Vollzitate von Beiträgen die direkt über deiner Antwort stehen...


    Ja klar - hab ich jetzt gar nicht mehr erwähnt, weil es ja nach den vielen Versuchen schon "logisch" ist :)


    Der Austausch hat jedenfalls ansatzlos funktioniert. VirtualSMC läuft direkt ohne besondere Einstellungen/Bootflags.

    Habe lediglich die FakeSMC.kext aus dem Kext-Ordner und die SMCHelper.efi aus dem Drivers-Ordner gelöscht.

    Dank dir... liest sich ja durchaus positiv. Also werde ich es wohl auch mal probieren.


    @foalan - SMCHelper muss auch weg sein --> Zitat: SMCHelper-64.efi is not compatible with VirtualSMC.efi and must be removed.

    Ich hätte da noch mal eine generelle Frage, da ich ich jetzt auch das Video von KayKun bzgl. USB Patching gesehen habe. An dieser Stelle auch direkt mal ein Danke dafür!! :thumbup:


    Macht es eigentlich einen relevanten Unterschied, ob man wie ich SSDT + UIA_exclude nutzt oder es via Hackintool und dann mit Kext oder SSDT-USBX.aml + SSDT-UIAC.aml umsetzt?

    Ein zusätzliche .efi sehe ich aber gar nicht - siehe Screen.

    Ich hätte jetzt auch gedacht bzw. gehofft, dass man die Kext einfach nur in den Driver-Ordner packt und fertig - also ohne was "einstellen zu müssen" :)


    Hi,

    mich würde mal interessieren, ob ihr VirtualSMC oder FaceSMS bevorzugt.

    Bisher habe ich mich damit nicht beschäftigt, aber durch den Umstieg auf OpenCore überlege ich, ob die VirtualSMC (die ja auch von acidanthera kommt) ggf. besser mit OC harmoniert, als die FakeSMC von Rehabman.


    Oder ist es eh Jacke wie Hose und es nur eine Geschmackssache?

    Wobei FakeSMC ja schon seit fast zwei Jahren kein Update mehr bekommen hat.


    Schönes Wochenende

    kuckkuck - hier mal der Output von deinem Command. Was sagt uns das jetzt? :/8o

    Code
    1. 2020-02-15 00:26:20.055401+0100 localhost powerd[134]: [powerd:sleepWake] Wake reason: "<private>" identity: "<private>"
    2. 2020-02-15 00:26:52.073983+0100 localhost powerd[134]: [powerd:sleepWake] Wake reason: "<private>" identity: "<private>"
    3. 2020-02-15 00:26:59.197793+0100 localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI
    4. 2020-02-15 00:26:59.197794+0100 localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI

    Dank dir... leider hat weder der SupportMode noch die BIOS Einstellung "USB Legacy Mode" etwas gebracht.

    Ich versuche es morgen mal mit einer anderen Tastatur, damit ich die als Fehlerquelle ausschließen kann.


    Ich melde mich dann morgen noch mal. Schönen Abend noch


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

    Was zu ca. 75% funktioniert, ist das triggern von ESC oder ALT. Interessanterweise geht es mal nur mit ESC und beim nächsten Mal nur mit ALT. :/

    Leider wurde ein Ticket zu dem Thema schon bereits ungelöst geschlossen - aus meiner Sicht aber leider nicht zufriedenstellend.

    https://github.com/acidanthera/bugtracker/issues/564


    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...


    Ich habe es derweil auch schon mit zwei anderen Tastaturen versucht - das unzuverlässige Verhalten bzw. das gedrückt halten nie funktioniert, bleibt leider.



    kuckkuck

    Kannst du mir noch mal bei der Analyse bzgl. Sleep helfen.

    Ich habe zwar den Befehl log show --style syslog | fgrep "Wake reason" eingegeben -- aber irgendwie passiert dann nichts... oder muss ich danach dann in den Ruhestand gehen, damit er was loggt?

    Der Fehler ist nämlich, seit dem ich diesen "Fix Sleepimage" wieder zurück gedreht habe, natürlich direkt wieder da.. Sprich max. 1 Sekunde nach dem Tastatur usw. ausgegangen sind, springt der Rechner wieder an.

    Wie man sieht, zeigt das Hackintool jetzt auch den Hibernatemode als "rot" an ... wobei ich bei dem Tool nicht verstehe, ob rot als "falsch", "Hinweis" oder sonst was gelten soll :)


    Bildschirmfoto-2020-02-15-um-10-11-44.png

    mhaeuser - Ist mir auch lieber, wenn dem so ist, da ich den bisher auch nicht brauchte..

    Ich habe es tatsächlich vorhin zwei Mal geschafft ins Bootmenü zu kommen. Allerdings habe ich ESC so schnell/oft gedrückt, dass ich gedacht habe, ich hätte Parkinson.

    Den delay habe ich mittlerweile auf 10.000.000 hochgesetzt - sodass er eigentlich jeden Tastendruck tausendfach erkennen müsste. Nichts.

    Ich habe es weder hinbekommen, dass er noch ein drittes mal auf ESC reagiert oder überhaupt mal auf ALT.


    Wenn ich die Doku richtig verstehe, wären meine letzten Optionen jetzt diese zwei:


    KeySwap  aktivieren.

    Lt. Doku --> This option may be useful for keyboard layouts with Option key situated to the right of Command key. / Was ja bei mir der Fall wäre, sofern man die "Windows-Taste" mit der "Command-Taste" gleich setzt


    KeySupportMode von AUTO auf AMI ändern

    Lt. Doku --> Set internal keyboard input translation to AppleKeyMapAggregator protocol mode. / Hier würde ich mal AMI hinterlegen, weil ich ja ein AMI BIOS habe, oder?


    Kann es ggf. auch damit was zu tun haben, dass ALT nicht erkannt wird, weil ich den falschen Wert unter prev-lang:kbd eingegeben habe?

    Ich habe da 64653A33 für de:3


    P.S Ich habe ne ganz normale, betagte Logitech G110 Tastatur...

    JimSalabim / mhaeuser - keine chance. Im Bios war auch alles richtig.

    Gibt nur einen Booteintrag und der ist auf UEFI OS gesetzt. Habe jetzt in Windows showpicker wieder auf true gestellt - läuft.

    Habe jetzt noch mal in die Doku geguckt... werde es gleich mal mit dem Parameter TakeOffDelay versuchen.

    Der steht bei mir auf 0 (default) - aber es gibt einen Hinweis, dass man den ggf. auf 5000-10000ms stellen muss, damit die Information mit dem Hotkey überhaupt ankommt. Hoffe jetzt mal nicht, dass ich 5000ms brauche sondern nur 1000ms-2000ms.

    Ich werde berichten, wie es gelaufen ist :)


    UPDATE:

    Keine Chance. Selbst wenn ich 10.000ms einstellen komme ich nicht in den Picker :( Wobei ich auch nicht das Gefühl habe, dass er irgendwas deutlich "verzögert".

    Von 0 auf 5000ms kam das Windows-Logo etwas später-.- aber jetzt auf 10.000 fast genauso schnell. Immerhin reden wir hier von 10 Sekunden. Das müsste eine Ewigkeit sein.


    Drücke ich vielleicht auch im falschen Moment?

    Erst kommt ja der typische Post-Boot-Screen -- mit dem riesigen American Megatrend Schriftzug und wo alle Festplatten und USB-Devices aufgezählt werden.

    • Wenn ich hier z.B. ESC gedrückt lasse, verschwindet das Bild sofort und er bootet Windows.
    • Wenn ich ab da ALT gedrückt lasse -- nichts.
    • Wenn ich warte bis der Post-Boot-Screen weg ist und dann ALT oder ESC gedrückt lasse --> auch nichts ;(

    Damit bin ich jetzt mit meinem Latein am Ende.

    JimSalabim und Doctor Plagiat - ich habe das jetzt entsprechend umgestellt. Das doofe ist nur, dass er jetzt direkt ins Windows bootet und ich die ALT-Taste bis nach China drücken kann, aber nichts passiert.

    Oder geht das mit der gedrückten ALT-Taste nur mit dem Fork? :(

    Wie komme ich denn jetzt wieder in mein Bootmenü? :)

    Ok -- einfach die EFI in Windows mounten und die plist wieder bearbeiten.. soweit so gut.

    Trotzdem wüsste ich gerne, warum das mit der gedrückten ALT-Taste bei mir nicht funktioniert. Ich möchte ja gerne ohne bootpicker arbeiten .. das ist für die Frau daheim auch nicht verwirrend, wenn immer direkt ins macos gebooted wird.

    Wann drückt ihr die denn? Noch während ihr die Post-Info vom BIOS bzgl. Festplatten usw. seht? Oder danach? Oder oder oder :)


    Dank euch