danielosx86

Skalowanie działa okej, renderowanie interfejsu w 5K dla skalowania 1440p, w 4K dla 1080p. Jest tak jak powinno być. Podepnij monitor 2 kablami - jeden do iGPU, drugi do dGPU i zmieniaj tylko sygnał wejściowy w monitorze. Nic lepszego nie wymyślisz w tym przypadku.

A nie masz czasem monitora HiDPI (np. 4K) i nie używasz skalowania interfejsu do 1440p? Jeśli tak, to macOS renderuje UI w 5K, a następnie skaluje do 1440p.

Po pierwsze - jeśli używasz integry, to Nvidia powinna być ubita przez SSDT albo (łatwiej) przez Whatevergreen. Jeśli masz monitor podpiety pod GPU, to IGPU powinna być headless. Po drugie - najpierw wczytujesz pluginy do VirtualSMC, a dopiero później samo VirtualSMC - kolejność wpisów ma znaczenie.

Gotowców możesz sobie poszukać sam, natomiast w przypadku OC to nie jest dobra droga, bo przy każdej aktualizacji i tak trzeba zapoznać się ze zmianami i zaktualizować config, więc warto poczytać i zrozumieć co jest czym. Sprawę ułatwia fenomenalna dokumentacja, której nie ma w przypadku Clovera. Licencji nie stracisz, jeśli przeniesiesz aktualne numery seryjne. W Twoim przypadku konieczna jest zmiana SMBIOS, a co za tym idzie, zmiana numerów.

Sporo do nadrobienia przed Tobą. W skrócie - jeśli chcesz instalować Big Sur to powinieneś przejść na OpenCore. Tylko najnowszy Clover potrafi podnieść Big Sur, tyle, że samego Clovera w nim niewiele od czasu niedawnej integracji z OpenCore. Nowy Clover na starym configu i tak nie zadziała, więc skoro i tak musisz się bawić w konfigurowanie od nowa, to lepiej już to robić na OpenCore.

Czy ktoś natknął się na problemy z uruchamianiem niepodpisanych aplikacji w Big Sur? Zdaje się, że ominięcie Gatekeepera jest trudniejsze niż w poprzednich macOS-ach, lub jest to bug systemowy. Przy próbie odpalenia aplikacji pojawia się komunikat "You do not have permission to open the application". Otwieram aplikację oczywiście przez PPM => Open, w systemie ustawione dopuszczanie aplikacji z dowolnego źródła. Bez znaczenia czy SIP i AMFI są włączone czy nie. Przetestowane bez rezultatu: 1) sudo xattr -rd com.apple.quarantine /Applications/my_app.app 2) sudo chmod 755 -R Path\ to\ app\ file.app 3) xattr -cr <paste the app here> sudo chown -R your_user_name:admin <paste the app here> sudo chmod -R a+x <paste the app here> Ponoć da się to ominąć instalując homebrew: sudo upx -d /Applications/my_app.app/Contents/MacOS/my_app Na razie jednak nie chcę instalować narzędzi trzecich, bo jako admin systemu powinienem mieć możliwość decydowania czy ryzykuję czy nie, to (jeszcze) nie iOS. Może ktoś ma jeszcze jakiś pomysł? Problem opisany jest m.in.: https://stackoverflow.com/questions/64842819/cant-run-app-because-of-permission-in-big-sur https://developer.apple.com/forums/thread/666611

Bo używasz niewspieranego SMBIOS? Sądząc po sygnaturze, masz iMac14,X, który oficjalnie już odpadł. Zmień na oczko wyżej.

Jak na zmianę architektury, przejście na własne procesory, pierwszy system wspierający je, w dodatku wyposażony w jednak sprawny emulator X86, to błąd z recovery nie jest jeszcze najgorszy. Wad wieku dziecięcego nie da się uniknąć, kiedy w firmie marketingowcy są nad inżynierami (bo w której technologicznej korpo nie są?), w dodatku w czasie pandemii, a sprzęt musi się ukazać przed Bożym Narodzeniem. Sprzęt jest nowy, na gwarancji, więc zawsze można zwrócić albo oddać do serwisu. Kto ogarnięty i korzysta ze sprzętu profesjonalnie, ten wie, żeby nie zamawiać pierwszych rewizji, a już na pewno nie w przedsprzedaży, kiedy świat nie miał okazji tego komputera nawet dotknąć. Po prostu aktualni klienci poprzeglądają sobie social media na jakimś innym urządzeniu do czasu wydania poprawki.

Zresetuj NVRAM. Szary ekran z kursorem pojawia zamiast okna wyboru języka.

Zamień <key>prev-lang:kbd</key> <data>AGVuLVVTOjA=</data> na <key>prev-lang:kbd</key> <data></data> Na 99% przejdzie bez ustawionego na sztywno języka.

To wygląda na przypadłość najnowszej Cataliny i Big Sur. U mnie na Gigabyte Z390 Gaming X lekarstwem było darkwake=0, ale możliwe, że darkwake w ogóle został porzucony (kilka jego stanów porzucono w poprzednich macOS) i zastąpiony jakimś innym rozwiązaniem. W każdym razie aktualnie znane metody nie dają sobie z tym rady.

Poczekać, serwery nie ogarniały.

Na papierze to wszystko wygląda bardzo ciekawe - w końcu coś nowego, a nie tylko kolejne Intel x Lake z marginalnym wzrostem wydajności. Rozsądek każe jednak poczekać na 2, może 3. generację Apple Silicon.

Sapphire są polecane przez Apple jako eGPU, więc nie powinny sprawiać problemów (mój RX580 od nich nie sprawia).

Przyganiał user odpowiadając na post miesiąc po, w dodatku nie mając nic sensownego do napisania na ten temat.

A z jakim urządzeniem chcesz się połączyć?

Wygląda ok, możesz próbować jeszcze z 0B001204. Popatrz jakie opcje masz w biosie przy iGPU.

Wyślij to co masz w configu Clovera/OpenCore dot. iGPU. Na niektórych płytach w bios jest jeszcze opcja Multimonitor i powinna być włączona.

Airplay działa, jeśli iGPU ma poprawne ig-platform-id, a ikona wyświetla się na pasku menu, jeśli jest zaznaczona "Pokazuj opcje klonowania..." w ustawieniach monitora.

Ale zrobiłeś dokładnie taki sam test, że miałeś do MBP podłączoną zarówno wieżę jak i klawiaturę? Bo to istotne.

Najpierw wykluczyłbym problem z samą klawiaturą - nie ufałbym jej, bo to oem chińczyk, więc może być z tym różnie. Sprawdź najlepiej na innym kompie albo pod Windows bootowanym bez OpenCore czy problem też występuje. Jeśli tak, klawiatura do niczego. Jeśli masz dual boot to problem z parowaniem BT będzie pojawiał się praktycznie za każdym razem po przejściu między systemami, choć to podobno można obejść dodając wpis do rejestru Windows (można wygenerować takowy hackintoolem, ale nigdy tego nie sprawdzałem). O wejściu do biosu za pomocą dongla BT możesz zapomnieć, bo 99,9% nie obsługuje tzw. HID proxy. Oryginalne applowskie moduły i te z Fenvi to potrafią.

Działa wybudzanie, automatyczne łączenie itd. Wg mnie nie ma to żadnej różnicy, w popularnym poradniku nie sprecyzowano o jaki BT chodzi i tak powstał szum informacyjny.

Te pare słów kompletnie nic nie wnosi, bo dalej nie ma informacji co to zmienia i jakie są korzyści, o ile w ogóle jakieś są. Ustawienie internal ma sens, kiedy wpina się kartę Wi-Fi np. Fenvi, gdzie wpina się BT do wewnętrznego USB na stałe i wtedy np. hot-plug nie jest potrzebny. Od zawsze na rynku są też dongle BT na USB, które działają z macOS i w prawdziwych Makach nikt żadnych kextów czy hacków do nich nie robi - po prostu działają. Wg mnie to niepotrzebny krok przy mapie USB, ale jeśli ktoś ma inne doświadczenia, to chętnie się dowiem.

Od zawsze mam BT dongle podpięty pod port zewnętrzny (do huba klawiatury Apple) i nigdy nie było z nim problemów, a działa od czasów 10.9 z Magic Mouse i każdym innym sprzętem. Co daje zmiana na internal? Czy to przypadkiem nie dotyczy tylko kart WiFi z BT?

Możesz pobrać z Releases. W necie krąży też zmodyfikowana wersja ze wsparciem dla Z490 (pewnie dopisane ID, nie zagłębiałem się) USBInjectAll_v0.7.5_z490-p.kext.zip