Udzielone Odpowiedzi
- Posty
Masz hybrydowy układ AMD+AMD (pierwszy jest w APU). System normalnie pracuje na nim. W obu przypadkach masz wykorzystywany sterownik amdgpu. Oba są – chyba – GCN 3. U Ciebie „podstawowy”, na którym pracuje system, to GPU zintegrowane w APU.
I… praktycznie nie masz ruchu, bowiem właściwym dla nich sterownikiem otwartym jest amdgpu (który jest używany), a sterownikiem własnościowym jest amdgpu-pro. Pomijając już, że ten ostatni wcale nie musi być „lepszy” od otwartego (oba zawierają te same rozwiązania, pochodzące z tego samego /AMD/ źródła, a różnica jest np. w możliwości wykorzystania GPU do obliczeń itp.), pomijając to, że w testach wydajnościowych – w zależności rodzaju wykonywanego zadania – niekiedy „lepiej” wypada jeden, a niekiedy drugi, to… na kernelu, to:
1. w ogóle bez zmian PKGBUILD dostępnego w AUR nie zbudujesz tego sterownika (próba budowy utknie na brakujących zależnościach),
2. kernel, dla którego jest przeznaczony – o ile widzę – musi mieć ustawiony w config KALLSYMS_ALL=y (nie wiem, jak ma linux419),
3. nie jestem w 100% pewny, czy w ogóle da się ten sterownik dla kernela (dowolnego, nie tylko z Manjaro) w wersji 4.19 zbudować,
4. prawdopodobieństwo, że będzie on pracować (oczywiście, po dostosowaniu PKGBUILDu do Manjaro) jest mizerne.
5. dodatkowo musisz zbudować pewną wersję mesa z AUR, bo na tej, którą masz – nie będzie działać.
Nadto powinieneś być świadomy tego, że praktycznie każdy kernel może wymagać przebudowania tego sterownika, a także, że amdgpu-pro w wersji dostępnej w AUR pochodzi z zeszłego roku; w tym roku do kernela doszło kilaset tysięcy linii kodu dotyczących wyłącznie sterowników grafiki od AMD. Może się okazać, że ów sterownik jest zatem „gorszy” (a na pewno starszy) od otwartego.
Przede wszystkim też musisz wziąć pod uwagę, że Manjaro nie jest systemem wspieranym przez AMD jeśli chodzi o sterownik amdgpu-pro.W grach – też w zależności od tego jakich, albowiem nie istnieje coś takiego jak „gra” – być może lepszym okaże się GPU dedykowane (drugi układ).
Kwestia TV to prawdopodobnie ustawienia HDMI (bo pewnie po nim się podłączasz) i najprawdopodobniej nie mają wspólnego nic z otwartym/własnościowym sterownikiem.
Artefakty itp. – cóż tu nic nie wiemy, ale prawdopodobnie albo „ten DM tak ma” („ten” bo również nie wiemy jaki), albo coś z ustawieniem tej/tych kart/sterowników.
@azja – Oczywiście, że zbierze z wyjątkiem tej jednej, najistotniejszej – na jakiej architekturze oparty jest ten GPU, a to jest istotne.
Niestety Radeon R7 nic/niewiele znaczy. To nazwa handlowa dla kilku modeli, budowanych na różnych układach (jeśli to prawidłowa tabela, to masz GCN 1 lub 2). Jaki konkretnie? Jeśli są to te układy to do dyspozycji masz 3 sterowniki: ATI, AMDGPU oraz Catalyst. Tylko te ostatnie są własnościowe i na kernelu 4.19 nie powinny już działać (AMD zarzucił ich rozwój bodaj 3 lata temu, a w miejsce tego wdrożył się w rozwój sterowników w kernelu).
Zatem po pierwsze: jaki masz tam GPU i jakiego sterownika używasz?
Wiki Manjaro o Catalyst możesz sobie odpuścić (ma aktualność sprzed kilku lat).
Generalnie o sterownikach własnościowych AMD – niezależnie od tego, czy to Catalyst czy ewentualnie w ogóle wchodziłby w grę AMDGPU-PRO – możesz sobie zapomnieć.
Po prostu dobierz właściwy sterownik (ATI lub AMDGPU) i skonfiguruj go. Tu leży problem. Dopóki jednak nie wiemy jaki masz GPU, której generacji to GCN, jaki masz obecnie sterownik używany, to mi nie chce się pisać rozprawki na wszelkie możliwości.Oczywiście, że – z punktu widzenia użytkownika, owe „yy” nie powoduje niczego złego. Zwróć jednak uwagę, że pobranie czegoś z serwera powoduje jego obciążenie. W przypadku takiej „praktyki”, gdy dosięgnie ona wszystkich użytkowników danego systemu, to jego obciążenie będzie znaczne. Oczywiście można to mieć gdzieś ze swojego, egoistycznego (nie w pejoratywnym znaczeniu) punktu widzenia. Niemniej jednak – przynajmniej ja wychodzę z takiego założenia – szanujmy tych, którzy nam coś dają. W tym przypadku udostępniają swój serwer dla naszej wygody i przyjemności.
Zwłaszcza, że owe „yy” absolutnie nic nie daje (przynajmniej nie wytłumaczyłeś w swoim wpisie od jakiegoż to voodoo może uchronić Twój system) w codziennym użytkowaniu. Jeśli to ma być panaceum na utratę zasilania (nie, nie zdarzyło mi się) bądź zawieszenie komputera (Arch mi się nie zawiesił, wcześniejsze systemy? bodaj zdarzyło mi się to w Debianie i Kubuntu), to raczej nie tędy droga, a i rozwiązanie wówczas bywa doraźne (i pewnie nie tylko polegające na wymuszonej aktualizacji nawet aktualnej bazy).Kiedy natomiast stosować? Ja znalazłem taki w zasadzie jeden przypadek – gdy nasza baza w jakiś sposób jest uszkodzona (o potrzebie i tak się dowiemy, wówczas wymusimy).
Thx za reklamę :)
A poważnie, to nie tyle uwagi, co pytanie. Jak piszesz, preferujesz:
pacman -Syy
nad
pacman -Sy
(mniejsza o to co po ostatnim „y”). Dlaczego? Różnica między „y”, a „yy” jest taka, że w pierwszym przypadku dochodzi do pobrania świeżych (tj. „nowszych” niż te, które już naszemu systemowi są już udostępnione) baz danych pakietów z serwera, podczas, gdy w drugim dokonywane jest pobranie baz nawet jeśli nasze, lokalne, są aktualne. Pacman ma wbudowany system, który umożliwia weryfikację, czy baz odległych i lokalnych pod kątem ich aktualności. Preferowane przez Ciebie polecenie powoduje zatem – wg mnie – wyłącznie niepotrzebny ruch sieciowy i dodatkowe obciążenie serwerów, z których korzystamy, podczas gdy efekt dla naszego systemu jest taki sam.
Bez żadnych podtekstów i broń boże nie czepiając się, chciałbym się dowiedzieć co przemawia do Ciebie, by wybrać owe podwójne „y” w miejsce pojedynczego.
(Bo kiedy w istocie należy wymusić aktualizację nawet aktualnych baz, to myślę, że wiem).@azja – Z całym szacunkiem, ale mocno nie do końca. Zmienne umieszczane w plikach w /etc/ są tzw. zmiennymi globalnymi. Obowiązują w całym systemie o ile dany użytkownik nie ustawi dla siebie w swoim katalogu domowym innych. Wówczas te w ~/ mają pierwszeństwo nad tymi, które są w /etc/.
Nie jest zatem prawidłowym twierdzenie: w Manjaro ustawienia zmiennej dla qt5ct winny być w /etc/environment. Prawidłowe jest: ustawienia winny znajdować się w takim pliku, który przyniesie spodziewany efekt. Mogą, ale nie muszą być w /etc/, mogą być w /home/$USER/. O ile wiem, to również pliki zaczynające się do „x” (np. ~/.xprofile itp.) będą mieć „połowiczny” efekt, bowiem te pliki są czytane wyłącznie w sesji X, ale już nie w sesji Wayland (nie wiem jak z programami korzystającymi z XWayland; generalnie dokumentacja Wayland jest jak na razie dość uboga, ale i DE, które potrafią z niego korzystać niewiele).
Generalnie polecam lekturę wiki Archa, choć to tylko wierzchołek góry.W przypadku używania qt5ct istotne jest ustawienie wyłącznie jednej zmiennej (inne przedstawione przez @Robert75) tego nie dotyczą:
export QT_QPA_PLATFORMTHEME="qt5ct"
Plik, z którego to system przeczyta jest już mniej istotny (niekoniecznie musi to być .profile).
Generalnie aby aplikacje Qt5 działały w środowiskach innych niż Plasma konieczne jest „przekonanie” ich o tym. Jedną z metod, to właśnie eksport zmiennej QT_QPA_PLATFORMTHEME.A nie lepiej zastosować ten sterownik z: AUR? Dodatkowo to dkms, a zatem sam się winien przebudować po aktualizacji kernela. Dodatkowo zarządzać paczką można wygodnie przez pacman.
Żadne „ignore” ICU!!! Od tego zależy (czyt. jest na nowej wersji przebudowywane) od groma paczek. Jeśli chcesz sobie rozwalić system – Twoja sprawa. Masz dokonać pełnej aktualizacji systemu, na aktualnych mirrorach. Bez kombinowania. Jeśli manjaro-settings-manager nie został przebudowany na nowe ICU to masz możliwość wywalenia tego pakietu albo przebudowanie go ze zmianą depends w zakresie ICU. Nie istnieje żadna inna możliwość z wyjątkiem nieaktualizowania systemu. Bez kombinowania!
1. Poczekaj. Devy Manjaro być może zaspały.
2. Zmień mirrory – może jednak nie zaspały.
3. Wykonaj pełną aktualizację systemu!
4. Jeśli jednak chcesz mieć obecnie tę aktualizację – ściągnij źródła manjaro-settings-manager i przebuduj zmieniając „depends”.
5. W żadnym przypadku nie wywalaj icu!Do czego Ci służą/służyły moduły:
ashmem_linux binder_linuxPrawdopodobnie z nimi związany jest błąd. U mnie (Arch) takie moduły nie są znajdowane w paczkach (w repo). Sprawdź co to w Manjaro dostarcza i czemu służy. Jeśli niczemu, a przynajmniej niczemu w Twoim systemie dodaj je do listy w pliku /etc/modprobe.d/blacklist.conf i przeładuj usługę. Powinno się już wówczas ładować poprawnie. Niemniej jednak wpierw sprawdź, bowiem jeśli te moduły są Ci do czegoś potrzebne, to trzeba szukać innego rozwiązania.
TIP: Z informacji w necie – oba moduły są związane z Androidem.@Robert75 – Nie do końca, a w zasadzie od początku nie tak.
@szrejm – Czy masz zainstalowane pliki nagłówkowe dla tego kernela? Co pokażą:$ systemctl --failed $ journalctl _PID=344Jak na razie nie wiemy, który z modułów nie staruje.
Czy wydanie polecenia:
systemctl restart systemd-modules-load
cokolwiek zmienia?
Co masz w:
/etc/modules-load.d
Dobrze byłoby też wiedzieć, czy dokonywałeś tu jakichś wpisów samodzielnie, czy nie.Tak, na pierwszy rzut oka, wszak są tu osoby, które lepiej winny znać Manjaro – czy na pewno masz właściwe uprawnienia dostępu do katalogu domowego?
Jeśli nie, a niczego nie kombinowałeś i jest to świeża instalacja, to zastanowiłbym się poważnie, czy przebiegła ona prawidłowo. Wadliwe uprawnienia naprawić oczywiście można i to łatwo, ale jeśli problem leży w instalacji, to bóg raczy wiedzieć co się jeszcze po drodze skopało.
Jeśli to system był instalowany jakiś czas temu, to co robiłeś z katalogiem $HOME? Generalnie w takim przypadku polecenie chown jest Twoim przyjacielem.@bobek – Pokazałeś ucięty log. Po poleceniu journalctl dodaj „–no-pager”. Jak na razie nie jest to możliwe do zdiagnozowania, bo mamy np. „Failed with result>”, no ale właśnie to co istotne, czyli ów „result” nie jest widoczny.
pavbaranov przecież podałem komendę którą mi system podpowiedział i widnieje odpowiedź konsoli powyżej.
Gdzie, bo to o czym pisałem w poprzednim poście – ja nie widzę, ale jestem już stary i ślepy.
