Posts by apfelnico

    schmalen

    Erst mal die ACPI anschauen, oft ist in der DSDT das "Grundgerüst" beschrieben (XHCI, sämtliche Ports des Chipsatzes), in einer weiteren SSDT dann dieses näher. Wenn letzteres der Fall, lässt sich diese sehr einfach per Bootloader "dropen", sowohl Clover wie auch OpenCore können bestimmte Tables deaktivieren. Diese kann man als Vorlage für eine eigene SSDT nutzen, jeden Port mittels "_UPC" beschreiben:



    Dabei steht:


    0xFF, (Port aktiv; nicht aktiv wäre 0x00)

    0x03, (USB3; USB2 wäre 0x00, intern 0xFF, USB-C je nach "verdreht" oder nicht 0x09 oder 0x0A)

    Zero,

    Zero


    Das ist schnell gemacht, vor allem, wenn man eh schon mal eine Kext dafür gemacht hat und somit weiß, welcher Port aktiv und als was deklariert wird.


    Da gibt es hier doch schon einen Thread für, komme gerade nicht auf den Namen …

    USB Port Mapping über Hackintool gemacht (auf Catalina - heute morgen ganz frisch) und eingetragen, samt .kext und SSDTs

    Entweder "SSDT-UIAC.aml", welche ausschliesslich in Verbindung mit "USBInjectAll.kext" funktioniert, oder die erstellte "USBPorts.kext" nutzen. Beides zusammen ist nicht vorgesehen. Bei weiteren SSDTs die "Hackintool" auswirft, würde ich vorsichtig sein, hier erst mal schauen ob diese überhaupt notwendig sind. Bei mir wird zum Beispiel grundsätzlich eine "SSDT-EC-USBX.aml" mit ausgeworfen, obwohl die Devices "EC" wie auch "USBX" in der ACPI enthalten sind.

    ABER:

    Hackintool ist schon länger nicht mehr gewartet worden und die erzeugte "USBPorts.kext" ist deutlich veraltet. Etliche Parameter greifen bei aktuellem "Big Sur" nicht mehr.


    Wenn man es "wasserdicht" machen möchte und weder mit neuen macOS, Kexts die plötzlich nicht funktionieren sich rumärgern möchte, dem kann ich nur empfehlen, das Ganze direkt per ACPI zu beschreiben. Dann wird keine Kext gebraucht und macOS weiß frühzeitig, wie die USB-Ports aussehen. Das alles ist definiert und hat nichts mit macOS zu tun, es ist in der ACPI spezifiziert. Leider interessiert das die wenigsten Mainbord-Hersteller und so steht da oft nur allgemeiner Krempel drin.

    Statt "SMBIOS" lieber den "Computername". Beide meine Rechner haben als SMBIOS "iMacPro1.1", obwohl ich beide nie als solche bezeichnen würde, es muss nur eben so sein.

    Statt dessen heißen die beiden ganz individuell "Brumsumsel" und "EditSuite1". Fände ich somit besser, das auch im Dateinamen wiederzufinden. :)

    Was spricht gegen folgendes?

    Code
    1. EFI_Backup_2021.05.06_OC(0.6.9)_MacBookPro10,1.zip

    Entweder ohne das "_SMBIOS" hinten dran (würde mir reichen), oder als Unterscheidungsmerkmal für diejenigen, die mehrere Rechner haben, hinten dran den "_Computername" (fmm-computer-name). Das fände ich praktischer.


    Würde bei mir so aussehen:

    EFI_Backup_2021.05.06_OC(0.7.0)_Brumsumsel.zip


    :)


    Edit:

    Wobei auch das "_Backup" entfallen könnte:

    EFI_2021.05.06_OC(0.7.0)_Brumsumsel.zip

    Ist ja keine Raketenwissenschaft. Man kann auch direkt in eine solche Kext schauen und das händisch machen. Ohne das Board weiter zu kennen, ist die Syntax doch oft gleich, die möglichen Ports des Chipsatzes sind:


    HS01

    HS02

    HS03

    HS04

    HS05

    HS06

    HS07

    HS08

    HS09

    HS10

    HS11

    HS12

    HS13

    HS14

    USR1

    USR2

    SS01

    SS02

    SS03

    SS04

    SS05

    SS06

    SS07

    SS08

    SS09

    SS10


    Sind insgesamt 26 Ports. Da sein Board sechsmal USB3.0 hat,

    sind es


    HS01-HS06 (HS=HighSpeed=USB2) plus die dazugehörenden

    SS01-SS06 (SS=SuperSpeed=USB3)


    dann sind da noch sechs USB2,

    das sind dann die Ports


    HS07-HS12. Hier also drei weglassen, schon passt das.


    Die endgültige Belegung kann also so aussehen:


    HS01 port 01000000 UsbConnector 3

    HS02 port 02000000 UsbConnector 3

    HS03 port 03000000 UsbConnector 3

    HS04 port 04000000 UsbConnector 3

    HS05 port 05000000 UsbConnector 3

    HS06 port 06000000 UsbConnector 3


    HS07 port 07000000 UsbConnector 0

    HS08 port 08000000 UsbConnector 0

    HS09 port 09000000 UsbConnector 0


    SS01 port 11000000 UsbConnector 3

    SS02 port 12000000 UsbConnector 3

    SS03 port 13000000 UsbConnector 3

    SS04 port 14000000 UsbConnector 3

    SS05 port 15000000 UsbConnector 3

    SS06 port 16000000 UsbConnector 3


    Sollte einer von den USB2 für eine interne Bluetooth genutzt werden, so ist der Wert von "0" (USB2) auf "255" (USB2, intern) zu ändern.

    Eigentlich logisch und komisch, dass er vorher mehr FPS anzeigte, obwohl das Ausgansmaterial das ja eigentlich gar nicht hergibt.

    Logisch oder komisch? :)

    Zur Laufzeit, während des Editings, ist es sinnvoll, das zumindest die FPS erreicht werden, die die Timelinesettings vorgeben. Gemeinhin wird damit "Echzeit" bezeichnet. Darüberhinaus ist es nicht unwesentlich, wie schnell bestimmte Arbeitsschritte erfolgen, wie zum Beispiel "tracking". Und die schlussendliche Ausgabe darf dann – wenn nicht vom Nutzer anderweitig limitiert – gern so schnell erfolgen, wie das System in der Lage ist. Das sind dann gern mal 600fps und mehr …

    DoodleBoyDieter

    15 Ports beträgt dieses Limit. Un dein Mainbord benutzt von den theoretisch 26 möglichen Ports des Chipsatzes exakt 18 Ports. Also drei über dem Limit.


    Es hat 6 USB3.0-Schnittstellen (vier hinten, zwei auf dem Board für Frontanschlüsse), die sich in 12 Ports aufteilen (je ein USB3- und USB2-Anteil). Dann noch sechs weitere USB2-Schnittstellen, zwei hinten und vier auf dem Board.


    Es ist also sinnvoll, diese insgesamt 18 Ports auf maximal 15 zu limitieren, damit du selbst entscheiden kannst, welche Ports du gern nutzen möchtest.


    Das geschieht mit einem sogenannten "PortMapping".

    Nograx


    Wenn vorher alles gut war und erst durch den NVRAM-Reset die Probleme losgingen, dann schaue mal bitte in dein BIOS, bzw BIOS-Einstellungen.


    Denn je nach dem, wie "groß" der Bereich in der ACPI definiert ist (welcher sich patchen lässt), kann ein "NVRAM-Reset" empfindliche Auswirkungen auf Einstellungen aus dem BIOS haben, wenn diese im gleichen Speicherbereich untergebracht sind.


    Besser ist es, einzelne Variablen bzw deren Werte gezielt zu löschen, anstatt die Holzhammermethode zu wählen.

    Hier sieht man welche Effekte enthalten sind.

    Hab ich schon gesehen (Piktogramme am unteren Rand der Nodes) und mich dazu geäussert …


    Wo kann ich sehen wie die Timelineauflösung ist?

    An vielen Stellen. Im "Media Pool" siehst du oben links (von den vieren) die "Timeline" (im Vorschaubild links unten ein "Timelinesymbol"). Auch siehst du, dass diese (einzige) Sequenz auch die derzeit aktive ist (orange Binde links oben). Rechtsklick drauf und du findest weitere wichtige Einträge.

    DoodleBoyDieter


    ein paar Sachen, die mir aufgefallen sind


    1. Entferne "SSDT-EC.aml", sowohl in EFI\OC\ACPI, wie auch in der "config.plist" (redundant mit "SSDT-EC-USBX-DESKTOP.aml", bezogen auf das hinzugefügte Device "EC")


    2. Setze den Quirk "XhciPortLimit" auf "NO" (Kernel, in der "config.plist")


    3. Entferne die Kexts "XHCI-unsupported.kext" und "USBInjectAll.kext", beide werden nicht benötigt. Und selbstverständlich auch aus der "config.plist" austragen.


    4. welcher Kext für dein Ethernet zuständig ist, weiß ich nicht, kann erstmal vernachlässigt werden


    5. Damit sollte USB grundsätzlich gehen, du läufst zwar ins "PortLimit", aber zumindest der erste USB3.0 (SS01) sollte voll funktionieren, alle USB2.0 (SS01-SS14) ohnehin.

    hackmac004

    Das sagt wenig aus. Der Clip mag 6K sein (welcher Codec, welche Framerate), die Timelineauflösung ist? Die Nodes sind zwar aktiv, ich sehe es sind in jedem eine Farbkorrektur, ein Maskierung und ein Blur/Sharpen. Die Maskierung scheint nicht zu greifen, da die Vorschauen der Nodes alle "grau" sind. Somit ist höchst fragwürdig, was da genau passiert – denn wenn per Maske _ALLES_ abgewählt wird und dann aber innerhalb der aktiven Fläche Effekte berechnet werden sollen – na da kann man sich vorstellen, was letztendlich übrig bleibt. Die "Temporal Noise Reduction" sollte aber Node-unabhängig laufen.


    Insgesamt also wenig aus der Praxis …