Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 10/13/19 in all areas

  1. 3 points
    Pierwsza przymiarka do bazy nowego UniBootX bazującego na OpenCore. Wersja ta bazuje na oficjalnej wersji OpenCore 0.5.2 + AppleSupport 2.1.2 + VirtualSMC 1.0.9 - kexty są aktualne na dzień 6.11.2019r. Z góry proszę o wyrozumiałość i zgłaszanie uwag - tylko z głową - to jest nie dość, że wczesna wersja OpenCore, to też jest to moja pierwsza przymiarka aby dać Wam z grubsza config pozwalający odpalić macOS na Haswellu Z87 Z97 bez względnie doktoryzowania się. Są 2 configi: config HD4600.plist - użyć jak korzystamy tylko z iGPU HD4600 config dGPU plus HD4600.plist - użyć jak korzystamy z dGPU i chcemy odpalić z HD4600 bez wyjść aby działał poprawnie np Quick Sync lub VDADecoder Wybrać stosowny config i zmienić jego nazwę na: config.plist Bez poprawienia nazwy configu NIE odpalimy w ogóle OpenCore. Domyślny Timeout ustawiony na 30s Do zestawu dodatkowo dodane: USBMap - skrypt do generowania tabeli SSDT dla portów USB - do opisania w innym poradniku. macinfo 2.0.8 w wersji na macOS jaki i Windows - jest to pakiet pozwalający wygenerować POPRAWNĄ parę SystemSerialNumber i MLB - to SĄ PARY i potem je dodać do w/w configu! Przed opaleniem należy w configu odnaleźć poniższą sekcję: <key>PlatformInfo</key> <dict> <key>Automatic</key> <true/> <key>Generic</key> <dict> <key>MLB</key> <string>M000000000001</string> <key>ROM</key> <data>ESIzAAAA</data> <key>SpoofVendor</key> <true/> <key>SystemProductName</key> <string>iMac14,2</string> <key>SystemSerialNumber</key> <string>W0000000001</string> <key>SystemUUID</key> <string>00000000-0000-0000-0000-000000000000</string> </dict> <key>UpdateDataHub</key> <true/> <key>UpdateNVRAM</key> <true/> <key>UpdateSMBIOS</key> <true/> <key>UpdateSMBIOSMode</key> <string>Create</string> </dict> I uzupełnić numery generując np w macinfo lub przenosząc z swojego configu clovera. Do uzupełnienia są od góry MLB, ROM, SystemSerialNumber, SystemUUID. Przygotowanie pendrive: sformatować na Fat32 wypakować do głównego folderu tak aby w nim był folder EFI. Działać i pisać wrażenia. UniBootX_OpenCore_Haswell_Z87_Z97_-_pre_Alpha_0.1.zip
  2. 2 points
    danielosx86

    Problem z Clover Configurator

    Opierając się na Twoim obszernym opisie problemu, spoglądając na Twoją konfigurację sprzętową, wersję systemu i zaglądając zdalnie w Twój katalog EFi, śmiało można z całą pewnością stwierdzić, że to jakiś błąd typu Kernel Panic.
  3. 1 point
    Dobra, pobiera się. Jutro to wszystko ogarnę, bo ten plik na pena to się będzie z 2 godziny wgrywał xD Dzięki!
  4. 1 point
    314TeR

    OpenCore - dyskusja ogólna

    Rozumiem idee i co masz na myśli, i ją bardzo mocno wyznaję. Z takiego powodu właśnie powstał UniBootX, nie po to aby było skomplikowanie, ale po to aby skomplikowaną czynność jak tworzenie zestawu startowego sprowadzić do paru niezbędnych czynności. Moja wypowiedź jest tożsama tylko do tego szczególnego wypadku OC i OCC. W obu wypadkach i tak aby cokolwiek wprowadzić, musisz wiedzieć co wprowadzasz. W OpenCore jeszcze większy jest na to położony nacisk, ale ułatwia to świetna dokumentacja. Taki konfigurator to front end do jakiegoś configu. Tu aby cokolwiek zrobić i tak musisz mieć bazę i to najlepiej zbliżoną do posiadanego sprzętu wypadku. W obu konfiguratorach NIE da się zbudować configu od zera. D;atego uważam, że te programy są świetne, ale w praktyce ułatwiają głównie początkującym użytkownikom zapoznanie się i wprowadzenie zmian. Zaawansowany użytkownik szybciej okiełzna taki config wspomagając się zwykłym edytorem pilnującym składni XML jak np PlistEdit, niż w CC/OCC. OC i OCC to klikacz, żeby np zdublować jakiś wpis, musisz wpierw dodać wiersz (+), potem wpisać w kolumnę A, potem B, potem C, potem D... ufff następny wiersz, kiedy to w PlistEdit robisz CMD+C-->CMD+V i zmieniasz tylko to co potrzeba. Nie wierzysz, spróbuj wpisać "z ręki" chociaż 3, 4 wiersze w patchach do USB jak wyjdzie nowy system i będziesz musiał dodać wpisy dla nowej wersji kernela. Ale żeby nie tylko narzekać a coś sprawdzić odpaliłem przed chwilą OCC i sprawdziłem co robi. Ogólnie nie jest źle, aczkolwiek niestety są drobne błędy. Najpoważniejszy to samodzielna zamiana wpisu: <key>ConsoleBehaviourOs</key> <string>ForceGraphics</string> na <key>ConsoleBehaviourOs</key> <string>ForceText</string> Druga rzecz - to zrobienie lekkiego bałaganu w sekcji PlatformInfo - Oprócz istniejącej sekcji Generic jak jest pokazane w dokumentacji, OCC pododawał sam z siebie sekcje DataHub, PlatformNVRAM, SMBIOS z zdublowanymi danymi z Generic. Tu zaznaczam, że trzeba się zapoznać z dokumentacją co te sekcje robią, bo są powielone SNy czy MLB, etc... trzeba się dowiedzieć, która sekcja za co odpowiada, bo być może te działanie ma sens którego obecnie ja nie znam. Poza tym nie podoba mi się, że OCC usuwa wszystkie klucze których wartość jest NULL. Ja osobiście wolę mieć klucz i wartość NULL, ponieważ jak będę potrzebował dodać wartość do klucza, to nie muszę wpierw dodawać klucza, szukać gdzie on powinien być, jak się nazywa itp itd. Jak jakiś klucz w configu jest to niech on zostanie. Tu widać, że autor/autorzy OCC stawiają na swoją logikę i do takiego zachowania CC i OCC najbardziej mam zastrzeżenia.
  5. 1 point
    314TeR

    OpenCore - dyskusja ogólna

    Inaczej - bo faktycznie moja wypowiedź wygląda jakbym siał jakimś defetyzmem. Jeszcze raz od początku. OpenCore i Clover Configurator to narzędzie ułatwiające początkującym użytkownikom ogarnięcie skomplikowanych configów w formacie XML. Zwalniają one przede wszystkim z znajomości składni XML a wiec i popełnienie potencjalnych błędów technicznych składni jak i merytorycznych. Niestety te programy obsługują parametry takie jakie zaprogramuje im autor tej aplikacji. Jeśli składnia jakiegoś parametru się zmieni, zostanie dodana lub usunięta to OCC/CC musi te zmiany uwzględniać. Tu niestety nie jest tak pięknie. Nawet dla znanego od lat Clovera CC nie wspiera wszystkich parametrów. Podobnie może być dla OpenCore o czym uprzedzają autorzy którzy testowali tę aplikację. Nie mniej autor OC Configuratora wciąż nad nim pracuje i jest dynamicznie rozwijany. Jakiś miesiąc temu OC Configurator wspierał wersje 0.0.x kiedy były już 0.5.0 i 0.5.1. Dziś widzę, że wspiera już 0.5.2. Być może już moje słowa i autorów OC dotyczące psucia składni są nieaktualne. Nie mniej OpenCore się dynamicznie rozwija i paradoksalnie bezpieczniej wziąć przykładowy config i go poprawić ręcznie. I to najlepsze wyjście i paradoksalnie takie podejście jest o wiele prostsze niż z Cloverem. Zasadniczą różnicą takiego podejścia jest to, że przykładowy config z clovera jest sieczką, a przykładowy config z OpenCore jest bardzo logicznie poukładany i paradoksalnie dostosowanie do naszych potrzeb sampla OpenCore jest o wiele prostsze niż sampla Clovera. Na dziś najlepiej edycję configu z OpenCore polecam robić jakimś edytorem XML podpierając się dokumentacją dostarczoną z OpenCore. Przed użyciem OCC zrobić kopie, sprawdzać, czy coś nie uciekło. Szybko i wygodnie porównać 2 pliki można w np BBEdit.
  6. 1 point
    314TeR

    OpenCore - dyskusja ogólna

    OC Configurator nie jest w pełni kompatybilny z aktualnymi wersjami OpenCore - nawet autorzy OpenCore ostrzegają! W większości wypadków psuje config.plist. Uważajcie co robi!
  7. 1 point
    314TeR

    OpenCore - dyskusja ogólna

    Szukam... gdzieś mi się jak na złość zapodział testowy pendrive z OpenCore. EDIT - Znalazłem - dajcie mi z pół godzinki, zaktualizuję do obecnej wersji, abyście mieli najświeższą wersje.
  8. 1 point
    314TeR

    OpenCore - dyskusja ogólna

    Plusy Bardziej przemyślana konstrukcja. To czy dany sterownik czy kext jest ładowany czy nie decyduje wpis w configu, dzięki temu nie trzeba mieć osobnych katalogów dla kextów, np osobnych w 10.13 i 10.14, tylko wszystko definiuje się w configu. Świetna, wręcz rewelacyjna dokumentacja - naprawdę wystarczy RTFM aby wedzieć co i do czego służy. Każda wersja też ma informacje o zmianach. Prawidłowa obsługa BLESS - wreszcie macOS instalując czy aktualizując NIE trzeba pilnować aby wybierać "Install macOS from XYZ". W Cloverze w ogóle to nie działa prawidłowo już od paru wydań macOS i nie da się zainstalować automatycznie aktualizacji. Aktualizacje i instalacja wymaga wybierania właściwej opcji, tu OC sam to robi, a w Cloverze trzeba pilnować ręcznie. Inaczej zrealizowane ładowani kextów, wg autorów lepiej - są dwa zasadnicze aspekty na plus, pierwszy to jak ładuje się kext do LANu to nie trzeba wymuszać popychać IONetworkFamily, drugi to NIE trzeba wyłączać SIP, oba te aspekty to spory plus. Szybsze ładowanie systemu i mniej sterowników EFI Obsługa prawidłowa wyboru startu przez dysk startowy z preferencji. Obsługa skrótów klawiszowych podczas startu jak na maczku - CMD + V, ALT, CMD + R itd. Ponoć lepsza obsługa FileVault2 - nie wiem nie korzystam, ciężko mi się wypowiedzieć. Wbudowane patche na limit portów - nie trzeba podawać pierdyliarda wpisów, a włącza się tylko 1 opcję. Minusy - to zakładam, że będzie poprawione Dla mnie najistotniejszy to ładowanie poprawek do tabel ACPI, czy też customowych tabel SSDT nie tylko w macOS ale też i w wszystkich pozostałych systemach, w tym i Windows. Dla jednych "future" - tak to autorzy OC przedstawiają - dla mnie potęzny minus, bo wystarczy np załadować tabelę SSDT z funkcją wyłączania kontrolerów EHCI od USB i bum - wylatuje aktywacja Windows i trzeba ponownie aktywować. Sęk w tym, że jak mamy klucz no to OK, można przeboleć i zainstalować, ale jak mamy np licencję elektroniczną już w fabryce przypisaną do komputera (np każdy nowy notebook) to takiej licencji nie popchniemy. Ja bym chciał aby wymuszanie ładowania poprawek do DSDT, SSDT i innych tweaków dla wszystkich systemów było opcjonalne i żeby można było to wyłączyć. Mocno rozbudowany config w XLM i miejscami może być dla wielu konfudujący. Wiele opcji kluczowych, jest na początku "dziwnie" rozlokowanych, np Boot Argsy ukryte pod kluczem UUID odpowiadającego wpisu w NVRAM. Jak się tego nie wie, to można sobie poszukać. Generalnie okiełzanie OpenCore wymaga poświęcenia czasu, nie ma wyjścia i trzeba parę godzin poświęcić na zapoznanie się z dokumentacją. Jak ktoś to zrobi, to wiedza potem procentuje, bo trzeba wyprostować i poukładać sobie logikę OC w głowie. Siermiężny wybór systemu - jak wciśniemy ALT lub wymusimy pokazanie systemów do rozruchu - to pokazuje się lista np 3 - 4 pozycje od góry ponumerowane 1. 2. 3. ale nie ma żadnego znacznika który aktualnie jest wybrany do rozruchu. Tak samo jak ustawiony jest timeout to nie widać ile czasu jest odliczania. Zmiana rozruchu odbywa się wciskając klawisze 1, 2, 3 itd. Mam nadzieję, że to wkrótce zostanie usprawnione - mi osobiście NIE zalezy na kolorowych skórkach, ale niech minimalna obsługa zostanie zachowana. OpenCore preferuje VirtualSMC zamiast FakeSMC - podstawowe funkcje VirtualSMC spełnia - niestety nie ma pluginu do odczytu temperatur, wiatraków, etc z VGA. Dodatkowa uwaga - bo nie mogę tego uznać jako minus, a jako wymóg - OpenCore wymaga poprawnie działającego NVRAM, także np na Z97 z zablokowanym BIOSem lub Z390 ja bym się nie pokusił o stawianie. W teorii można, bo jest emulator, ale emulator NIE załatwi wszystkiego. Dodatkowo mi się zdarzały restarty po wybudzeniu z sleep, których nie miałem w cloverze - ale tego dokładnie nie zdiagnozowałem, krótko testowałem OC na Z97 i była to jedyna bolączka. Poza tym OC działał mi naprawdę zaczie. Gdyby nie problem z wywalającą się licencja elektroniczną na Windows szczerze mówiąc już bym miał OC na co dzień, a tak nie chce mi się walczyć z ponownymi aktywacjami czy reinstalacjami Windows. Mam w nim parę programów aktywowanych które są o wiele droższe niż sam Windows. PS Zaraz wrzucę Config przykładowy dla Z87/Z97.
  9. 1 point
    matys

    Problem z brakiem partycji EFI

    Tak więc rozwiązanie mojego problemu podane jest w tym filmie: https://youtu.be/YaPTdqguyAY?t=1659 Pokrótce procedura przywracania partycji rozruchowej w moim przypadku jest następująca: 1. Uruchamiamy komputer z butowalnego pendriva wchodząc w tryb "BOOT MENU" (u mnie F12) i wybieramy pendriva, jako źródło rozruchu 2. Następnie używamy shella klikając na "Start UEFI Shell 64" 3. Po załadowaniu się shella wpisujemy komendę fs2: co jest odpowiednikiem naszego dysku rozruchowego (pierwszy dysk SATA na liście). 4. Kolejne polecenie to: bcfg boot dump gdzie widzimy dostępne dyski, napędy, USB... 5. W tym momencie możemy usunąć niepotrzebne peryferia, które nie są potrzebne do bootowania. Do tego służy komenda: bcfg boot rm xx gdzie w miejsce "xx" wprowadzamy numer (wyświetlany na niebiesko) danego np. dysku po czym odświeżamy widok poleceniem: bcfg boot dump i możemy usunąć kolejne peryferia. 6. W ostatnim etapie dodajemy naszą upragnioną partycję rozruchową z kolejnym wolnym numerem, którą nazywamy jakkolwiek, wpisując tę nazwę w cudzysłów: bcfg boot add 05 EFI\CLOVER\CLOVERX64.efi "Hackintosh" 7. Wychodzimy wpisując: exit i w BOOT MENU klikamy ikonkę restartu. Cieszymy się "naprawioną" partycją rozruchową z systemem OS X
  10. 1 point
    AptioMemoryFix został wchłonięty przez OpenCore, jednak ktoś postanowił wyodrębnić jego nowe wcielenie z OC, by móc z niego korzystać w Cloverze: https://github.com/ReddestDream/OcQuirks Podaję jako ciekawostę, bo prędzej czy później i tak wszyscy skończymy na OC
  11. 1 point
    De3ny

    Asus Z390 -dysk systemowy M2 dla 10.15

    Również polecam MP510 480GB. Miałem SX8200 Pro w Z390. Jedyna rzecz w której był lepszy to trochę mniejsze temperatury. MP510 znacznie szybciej ładuje system i programy.
  12. 1 point
    javazlaz

    Asus Z390 -dysk systemowy M2 dla 10.15

    https://www.morele.net/dysk-ssd-corsair-mp510-480gb-pcie-x4-nvme-cssd-f480gbmp510-5616538/
  13. 1 point
    Estrax

    Asus Z390 -dysk systemowy M2 dla 10.15

    Nie jest to najlepsza opcja, ale i nie jest to również najgorsza opcja. Na minus to, że zauważalnie zwalnia przy długotrwałym zapisie (wystarczy tylko, że bufor się zapcha i już prędkości lecą znacznie w dół, nawet do 150-200 MB/s), a przy zapchaniu na poziomie 80-90% potrafi spaść nawet i do zapisu na poziomie 100 MB/s. Rekompensuje ceną. Osobiście bym się kierował w stronę Samsunga, gdyż od czasu do czasu idzie wyrwać 970 Evo Plus w podobnych pieniądzach (z FV), ale jeśli budżet Cię na sztywno trzyma, to i ten SX8200 Pro nie powinien być zły.
  14. 1 point
    314TeR

    Na co patrzeć kupując MacBook Pro?

    Nie musisz flashować dysku. Od 10.13 macOS wspiera pecetowe dyski NVMe z sektorami 512. Jedynie polecam względnie pomijać SSD od Lite-ON/Plextor - mają jakieś błędy w protokole NVMe i działają dopiero od 10.14.5/6.
  15. 1 point
    danielosx86

    Obudowa PC wzorowana na Mac Pro

    Jasne, ale to dalej robienie kasy na cudzej pracy, w tym przypadku designerów Apple. Kiedy ktoś robi podróbkę iPhone'a z Androidem to jest zabawnie, ale kiedy ktoś robi podróbkę budy Maca Pro, w którą można wsadzić taniego peceta to są propsy. Coś tu nie gra
  16. 1 point
    danielosx86

    Update do Catalina.

    Zrobiłem nowy kext, mam patche na limit portów, ale dalej restart po wybudzaniu. Wyrzucenie USBPort.kext i zastąpienie go alternatywną metodą również z Hackintoola, czyli USBInjectAll.kext + SSDT-UIAC.aml nie wywołuje tego objawu, a efekt jest ten sam - mapuje tylko swoje porty. Jakby ktoś szukał patcha na limit portów do Cataliny: com.apple.iokit.IOUSBHostFamily 83FB0F0F 83FB3F0F USB port limit patch #1 10.15 (Credits PMheart and daliansky) 10.15.x com.apple.driver.usb.AppleUSBXHCI 83F90F0F 83F93F0F USB port limit patch #2 10.15 (Credits PMheart and daliansky) 10.15.x Zauważyłem jeszcze jedną rzecz, niezwiązaną z USB, ale być może związaną z jakimś problemem ze wstrzykiwaniem kextów do Cataliny lub niekompatybilnością Hackintoola. W Mojave używałem kexta z nadpisanym EDID monitora, żeby po wybudzeniu na UHD630 nie robił się przez chwilę zielony ekran. W Catalinie mimo kexta wygenerowanego na nowo Hackintoolem, zielony ekran przez chwilę się pojawia.
  17. 1 point
    music

    Update do Catalina.

    Na Reddit https://www.reddit.com/r/hackintosh/comments/den28t/whats_new_in_macos_catalina/ Wiele szczegółowych informacji odnośnie zmian w Catalinie można przeczytać tu
  18. 1 point
    Postanowiłem napisać ten post, aby każdy mógł zobaczyć na własne oczy jak naprawdę świecą matryce na domyślnych ustawieniach i czy kalibracja / profilowanie ma sens. W tym konkretnym przypadku pokazuje co można uzyskać samym profilowaniem wyświetlacza z Mac Book Pro 9,1 (mid 2012 z HD4000/GT650). Ponieważ wyświetlacz w Mac Book Pro nie można kalibrować (bo i jak), pozostało stworzenie profilu ICC korygującego ustawienia balansu bieli, tak aby skompensować błędy wyświetlania matrycy. Efekt oceńcie sami, polecam przyjrzeć się błędom dE 2000, ponieważ one najlepiej charakteryzują czy kolor widziany na ekranie różni się od rzeczywistego. Błędy dE 2000 poniżej 3 uznawane są w materiale video za niewidoczne, dla obrazów statycznych, np zdjęć, niewidoczne różnice będą przy dE 2000 poniżej 1, jeśli są w okolicy to już jest bardzo dobrze. Błędy powyżej 3 a mniejsze niż 5 są zauważalne, powyżej 5 mocno zauważalne, a powyżej 10 rażące. Tak świeci matryca zaraz po wyjęciu z pudełka. Widać bardzo mocno przesunięty punkt bieli w kierunku niebieskiego, co jest typowe dla obecnych "tendencji" do robienia "WoW" dla niewprawnego oka. Niestety standardy są nieubłagane i dla ogólnego użytkowania matryc LCD najlepiej sprawdza się przestrzeń barwna sRGB, do której dążyłem w poniższym przykładzie. Przegląd wszystkich parametrów po profilowaniu. Szczegółowy wygląd i przebieg balansu bieli, to tę część jesteśmy w stanie modyfikować profilowaniem, jeśli jest zrobione dobrze, to będzie miało przełożenie na pozostałe parametry. Tutaj najbardziej rzuca się w oczy rozbieżność składowych, przez co średnia temperatura barwowa to aż 18375k - powinna być 6503k (D65), jak widać norma jest przekroczona aż 3 razy. Ogólny wygląd takiego wyświetlacza można scharakteryzować "wygląda jakby palnikiem acetylenowym" był podświetlany. Niestety to typowe obecnie zagranie producentów, szczególnie z matrycami podświetlanymi LED. Drugi problem to błędna krzywa luminancji, przez co "jasność" kolorów dla niskich wartości IRE jest błędnie odwzorowywana, kolory są za ciemne. Balans bieli po korekcie, temperatura nieco za niska, średnio 6363, ale więcej za pomocą profilowania się nie zdziała, a i tak to jest błąd niedostrzegalny praktycznie przez oko. Średnia dE 2000 na bardzo dobrym poziomie 0,98, ogólnie wynik bardzo dobry plus. Nasycenie poszczególnych kolorów przed profilowaniem. Nasycenie poszczególnych kolorów po profilowaniu, widać że sama korekta balansu bieli powoduje "naprostowanie" całej przestrzeni barwnej i poszczególne kolory są bardzo blisko swoich referencyjnych punktów. Największy problem sprawia niebieski - typowe przy podświetleniu LED, trzeba jakoś kompensować niebieskawą barwę jego. Tutaj jest małe oszustwo, ponieważ zbyt duże nasycenie niebieskiego jest kompensowane przez zaniżoną znacznie luminancję, nie powinno to mieć miejsca, ale przy takim typie matrycy nie da się wiele zdziałać samym profilowaniem. Luminancja punktów 100% przed kalibracją. Luminancja punktów 100% po kalibracji, widać problem z niebieskim. Najważniejszy test, wykresiki, wykresikami, ale nas interesuje jak faktycznie matryca odwzorowuje kolory w praktycze. Color checker pozwala sprawdzić popularne kolory, znane ludzkiemu oku jak np kolor skóry. Przed profilowaniem widać błąd dla skóry białego człowieka na poziomie 21,987 - to bardzo rażąca odchyłka. Średni błąd dE 2000 to 11,88 (jest na pierwszym screenie). Po profilowaniu średni błąd spada do 1,54, maksymalny to zaledwie 2,53, a ludzka skóra ma już tylko odchyłkę na poziomie 1,29. A tu w bardziej przyjaznej formie, wykres CIE pokazujący jak "wstrzeliwują" się punkty w referencyjne miejsca. Jak bym scharakteryzował ogólnie matrycę po profilowaniu, w skrócie jest całkiem nieźle, spokojnie zasługuje na 5 - 5,5 w 6ścio stopniowej skali. Kontrast też jest na przyzwoitym poziomie jak pamiętam ~600:1 (nie mam danych pod ręką, jak otworzę sesję kalibracyjną, to uzupełnię tę fragment). A odpowiedź na postawioną tezę? Czy warto bawić się w kalibrację? Niech każdy sam sobie odpowie. Standardów jest parę, ale każdy ma na celu to aby kolory widziane przez autora, były tak samo odwzorowane na wyświetlaczu docelowym, w końcu np taki obraz mona lizy chcielibyśmy obejrzeć w jak najbardziej wiernych barwach, a nie na wyświetlaczu który jest rozregulowany jakby przez narkomana naćpanego LSD. Jak ktoś ma jakieś pytania, to proszę pisać. Jak ktoś ma ochotę aby jego wyświetlacz w laptopie, monitor, telewizor, czy projektor zaczęły świecić dokładnie jak to tylko jest możliwe to zapraszam na PW.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.