Testujemy 12.04 LTS Precise

[mateczek]

Dobrze że jest płyta "alternate install" z tekstowym instalatorem bo inaczej wczoraj by komputer przez okno wyleciał Domyślny instalator po prostu wyczerpał moją cierpliwość A potem unity-2d dołożyło swoje. (Mają taki fajny tekstowy instalator a nie dodają go na płycie standardowej )
Sprzęt mam leciwy już. Unity 3d na lepszych kompach śmiga fajnie testowałem na lapiku, Ale ta alternatywa w postaci unity-2d dla tych niby starszych komputerów to nieporozumienie(odpalasz dwa teminale i jak chcesz się przełączyć to trzeba najpierw przeczekać tą symulację animacji zanim przemknie parę slajdów jak w prezentacji:P).
Gnome3 falback daje radę Więc jak na razie, po małych bojach na starcie, przez następne pół roku Ubuntu 12.04 będzie śmigać na kompie.

[luk1don]

Dobrze że jest płyta "alternate install" z tekstowym instalatorem bo inaczej wczoraj by komputer przez okno wyleciał Domyślny instalator po prostu wyczerpał moją cierpliwość A potem unity-2d dołożyło swoje. (Mają taki fajny tekstowy instalator a nie dodają go na płycie standardowej )
Sprzęt mam leciwy już. Unity 3d na lepszych kompach śmiga fajnie testowałem na lapiku, Ale ta alternatywa w postaci unity-2d dla tych niby starszych komputerów to nieporozumienie(odpalasz dwa teminale i jak chcesz się przełączyć to trzeba najpierw przeczekać tą symulację animacji zanim przemknie parę slajdów jak w prezentacji:P).
Gnome3 falback daje radę Więc jak na razie, po małych bojach na starcie, przez następne pół roku Ubuntu 12.04 będzie śmigać na kompie.

Nieporozumieniem to jest lenistwo. Unity 2D sprawuje się wyśmienicie i nawet lekciej niż 3D. Automatyczne wysuwanie okien, czas wysuwania i czy wysuwać, a także boczny panel np. w tryb Intelihide - to się konfiguruje, trzeba przeczytać o konfiguracji, a nie sadzić zarzuty dla Unity2D...

[FadeMind]

Nie wiem co zepsuto w kernelu lub/i usbmodeswitch ale modem Alcatel OT X221S (2G/3G/HSDPA) nie jest rozpoznawalny przez Gnome Network Manager (w terminalu urządzenie jest widoczne). W Wersji 11.10 nie ma tego problemu. Po za tym Unity szybkie, przekombinowane (nie mogło być tak jak było w menu głównym ?? ), spece od interfejsu nareszcie odrobili lekcje i w jakiś tam sposób GNOME 3 jest konfigurowalny, ale bez Ubuntu Tweak nie ma co się bawić w zmianę opcji... Poczekam na wersję finalną i wypowiem się ponownie.

[sharpq]

Podpisuję się pod pytaniem. Generalnie zawsze laptop mi się podnosi po hibernacji, ale czasami mam ciemny ekran i tylko kursor myszki. Co może być problemem? Pomaga tylko 'twardy' restart...

[e X t 7 3]

Ja testuje Kubuntu 12.04 ... jest naprawde nieźle. Oczywiście parę błędów jest, ale nieporównywalnie lepiej niż było pod betą 11.10. Jedynie kernel będzie piętą achillesową na słabych maszynach. Jego konfiguracja moim zdaniem nie przystaje do słabszych maszyn - poniżej i3 ok 2.5 GHz, czy podobnego Athlona. Problem nie wynika z nowej linii kernela 3.2.x, ale z jego "nieodpowiedniej" konfiguracji. Przykładowo KDE 4.8.2 pod kernelem generic nie będzie płynne [choć by nie wiem co by się robiło] na AMD Brazos E-350 [mój MSI X370] ... natomiast - także przykładowo - pod moimi kernelami - jescze testowymi v18.4 bazującym na 3.2.15, czy też v19.0 bazującym na 3.3.2 jest praktycznie idealnie płynne - tu szczególnie pod mocno "customowymi" wersjami Brazos i odpowiednio i7. Choć już pod udostępnionymi atom i K8 różnica będzie widoczna dużo bardziej niż pod genericiem z 11.10, a wcześniejszymi moimi kernelami. Po prostu konfiguracja kernela generic bardziej pasuje do jakiś maszyn typu NUMA, niż do desktopów, czy maszyn mobilnych. Podobnie ma się sprawa z szybkością ładowania systemu ... o ile na mocnych maszynach różnica miedzy kernelem generic i moimi kernelami nie będzie wysoka, o tyle na słabszych maszynach powinna być raczej bardziej odczuwalna - tu znowu kłania się konfiguracja kernela. Poza tym zarówno wersja Ubuntu, jak i Kubuntu raczej na pewno zapowiadają się na bardzo udane wersje .

Pozdrawiam

-- 18 kwi 2012 13:12 --

Jeszcze jedno w 12.04 jest błąd odnośnie dekodowania video przez vaapi dla AMD ... już zrobiłem skrypt to "naprawiający" = system wie, że ma sprzętowe dekodowanie i nie pojawi się już segfault, a zatem np. VLC będzie już dekodował video przez Radeona . Szczerze nie rozumiem, czemu po raz kolejny Developerzy popełniają podobne błędy, jak w 11.10 ... to dość proste i szybkie do wykrycia braki.

Pozdrawiam

[mateczek]

Nieporozumieniem to jest lenistwo. Unity 2D sprawuje się wyśmienicie i nawet lekciej niż 3D. Automatyczne wysuwanie okien, czas wysuwania i czy wysuwać, a także boczny panel np. w tryb Intelihide - to się konfiguruje, trzeba przeczytać o konfiguracji, a nie sadzić zarzuty dla Unity2D...

Dodam, może że moim komputerem jest zabytek na chipsecie km400 (nawet instalatora graficznego nie chciał pciągnąć i instalacja się wykrzaczała) a do tego mam monitor 19 (1440X900). Co byś nie kombinował to jak odpalisz 2 terminale na unity a potem klikniesz ikonkę terminala na bocznym pasku to zaczyna startować animacja, A o przełączaniu obszarów roboczych nie wspomnę.

Gnome-falback daje radę nawet fajnie i szybko więc na razie mi pasuje

[e X t 7 3]

Oczywiście powstał "problem" ... wyłączenia defaultowo hibernacji ! Szczerze nie rozumie, czemu to zrobili ... o ile w przypadku problemów z usypianiem jeszcze bym to zrozumiał [problemy z maszynami pod nvidią + nowe kernele od 3.2.x = sterowniki nvidii - pod AMD działa idealnie - tu musze powiedzieć, że mocno raportowałem wcześniej błędy do AMD i naprawili ] o tyle wyłączenie hibernacji ... szczęka mi opadła Dla Ubuntu istnieje proste rozwiązanie ... ale na Kubuntu na razie nie działa ... szukam jakiegoś prostego rozwiązania - do czasu aż na powrót defaultowo wałczą hibernacje .

Pozdrawiam

[kklimonda]

Jeszcze jedno w 12.04 jest błąd odnośnie dekodowania video przez vaapi dla AMD ... już zrobiłem skrypt to "naprawiający" = system wie, że ma sprzętowe dekodowanie i nie pojawi się już segfault, a zatem np. VLC będzie już dekodował video przez Radeona ;). Szczerze nie rozumiem, czemu po raz kolejny Developerzy popełniają podobne błędy, jak w 11.10 ... to dość proste i szybkie do wykrycia braki.

Pozdrawiam

Bardzo prosto, wystarczy, że żadnemu z deweloperów nie przyjdzie przetestowanie danej funkcjonalności w takiej konfiguracji, a dodatkowo nikt nie zgłosi buga na LP (hint, hint ;))

[e X t 7 3]

Jeszcze jedno w 12.04 jest błąd odnośnie dekodowania video przez vaapi dla AMD ... już zrobiłem skrypt to "naprawiający" = system wie, że ma sprzętowe dekodowanie i nie pojawi się już segfault, a zatem np. VLC będzie już dekodował video przez Radeona . Szczerze nie rozumiem, czemu po raz kolejny Developerzy popełniają podobne błędy, jak w 11.10 ... to dość proste i szybkie do wykrycia braki.

Pozdrawiam

Bardzo prosto, wystarczy, że żadnemu z deweloperów nie przyjdzie przetestowanie danej funkcjonalności w takiej konfiguracji, a dodatkowo nikt nie zgłosi buga na LP (hint, hint )

Oczywiście tak może być ... ale m.in. tu było zgłaszane, a rozwiązanie proste

Pozdrawiam

[kklimonda]

Oczywiście tak może być ;) ... ale m.in. tu było zgłaszane, a rozwiązanie proste ;)

Pozdrawiam

Które rozwiązanie? eksportowanie LIBVA_DRIVER_NAME czy zrobienie odpowiednich symlinków?

[e X t 7 3]

Oczywiście tak może być ... ale m.in. tu było zgłaszane, a rozwiązanie proste

Pozdrawiam

Które rozwiązanie? eksportowanie LIBVA_DRIVER_NAME czy zrobienie odpowiednich symlinków?

Oba elementy.

Pozdrawiam

[kklimonda]

Wątpię by ktoś z deweloperów miał czas to naprawić bo do tego potrzebny jest ciekawy mix - deweloper który używa karty AMD i zamkniętego sterownika, a tacy są zajęci ;)

ustawianie LIBVA_DRIVER_NAME nie powinno być potrzebne jeżeli odpowiednie pliki lądują w odpowiednich miejscach - w takim razie va-api powinno korzystać z xvba_drv_video.so - jeżeli to założenie jest błędne to rozwiązanie problemu nie jest "proste" ;). Jeżeli tak to faktycznie wystarczyłoby "jedynie" przerobić paczkę by instalowała pliki .so w odpowiednim katalogu.

BTW hibernacji to została wyłączona bo jest strasznie wolna i, co ważniejsze, nie działa na dużo większej liczbie komputerów, niż wstrzymanie.

[luk1don]

BTW hibernacji to została wyłączona bo jest strasznie wolna i, co ważniejsze, nie działa na dużo większej liczbie komputerów, niż wstrzymanie.

Dokładnie, większość ludzi z tego nie korzysta, nie tworzy w ogóle swapu, itp. (tak jak ja).

[e X t 7 3]

Wątpię by ktoś z deweloperów miał czas to naprawić bo do tego potrzebny jest ciekawy mix - deweloper który używa karty AMD i zamkniętego sterownika, a tacy są zajęci

ustawianie LIBVA_DRIVER_NAME nie powinno być potrzebne jeżeli odpowiednie pliki lądują w odpowiednich miejscach - w takim razie va-api powinno korzystać z xvba_drv_video.so - jeżeli to założenie jest błędne to rozwiązanie problemu nie jest "proste" . Jeżeli tak to faktycznie wystarczyłoby "jedynie" przerobić paczkę by instalowała pliki .so w odpowiednim katalogu.

BTW hibernacji to została wyłączona bo jest strasznie wolna i, co ważniejsze, nie działa na dużo większej liczbie komputerów, niż wstrzymanie.

Proste jest o tyle, że możliwe jest do zrealizowania od teraz ... a kwestia wykrywania przez vaapi, że sterownikiem jest fglrx to już insza inszość ... to nie musi interesować Usera, jedynie Developera. Skoro zatem można problem "obejść" poprzez wskazanie w zmiennej środowiskowej, ze serownikiem vaapi jest fglrx, to nie widzę problemu. Podobnie, jak stworzenie odpowiedniego simlinku - różne programy szukają tego sterownika w różnych miejscach - w szczególności w systemach 64 bitowych.

Kwestia hibernacji ... jak dla mnie to nie jest dobry pomysł - nie spotkałem maszyny, an której - bez winy usera - nie działałby hibernacja. Co innego usypianie - tu głównie wina sterowników graficznych. Dlatego nie uważam, iż to dobre rozwiązanie - na pewneo negatywnie odbije się na marketingu Canonical ...

Jeszcze kwestia zarządzania zasilaniem ... tu kolejny "błąd" = brak skryptu readahead. Bez tego skryptu czyni praktycznie niemożliwym prawidłowe zarządzania czasem bezczynności dysku = sleep, co oczywiście przekłada się na zużycie energii wyższe od 1 do 4 watt. Zresztą widzę, ze zrobili nowe skrypty np lista urządzeń PCI pci_devices - tylko po co je listowali ? Przecież można hurtem i dla wszystkich to samo zrobić - Ja to zamykam w kilku linijkach ... ... poza tym i tak ten skrypt nie zadziała prawidłowo ... w zasadzie brakuje dwóch linijek. Oczywiście mozna wdrożyć do 12.04 w/w skrypt readahead, który we współpracy z moim skryptem APM pozwala zaoszczędzić dodatkowe watty. W zasadzie to wiem dlaczego nie wsadzili tego skryptu = parkowanie głowicy "jak szalonej" ... oczywiście tylko wtedy, gdy nie zarządzamy pracą dysku w odpowiedni sposób - pod moim skryptem tego problemu nie ma . Analizując kolejne zmiany dochodzę do wniosku, ze albo Developerzy poszli na łatwiznę, albo nie maja już czasu poprawić pewnych elementów i ... po prostu je usuwają ... obie przesłanki nie napawają pozytywnie. Tu mam sprzeczne odczucia, z jednej strony mam wręcz idealną dystrybucje, ale te łyżki dziegciu psują trochę tę całość ... żywię nadzieje, ze w kolejnych miesiącach to poprawia ... Ja tak czy siak przygotuje odpowiednie skrypty.

Pozdrawiam

[kklimonda]

Proste jest o tyle, że możliwe jest do zrealizowania od teraz ... a kwestia wykrywania przez vaapi, że sterownikiem jest fglrx to już insza inszość ... to nie musi interesować Usera, jedynie Developera. Skoro zatem można problem "obejść" poprzez wskazanie w zmiennej środowiskowej, ze serownikiem vaapi jest fglrx, to nie widzę problemu. Podobnie, jak stworzenie odpowiedniego simlinku - różne programy szukają tego sterownika w różnych miejscach - w szczególności w systemach 64 bitowych.

Nie no, to trzeba zrobić poprawnie - w przypadku innych sterowników VA-API nie ma potrzeby ustawienia LIBVA_DRIVER_NAME więc można to zrobić. Ustawianie tej zmiennej jest po prostu obejściem problemu, które nie powinno lądować w paczce. Dlatego pytam się czy problemem nie jest to, że libva szuka standardowo xvba_drv_video.so którego w odpowiednim katalogu nie ma. Co do symlinków to ich stworzenie nie jest problemem, ale ktoś musi to zrobić (przerobić obecną paczkę tak by działała poprawnie z multiarch) a niestety xvba-video siedzi ciągle w multiverse i mało kto jest nim zainteresowany.

Kwestia hibernacji ... jak dla mnie to nie jest dobry pomysł - nie spotkałem maszyny, an której - bez winy usera - nie działałby hibernacja. co innego usypianie - tu głównie wina sterowników graficznych. Dlatego nie uważam, iż to dobre rozwiązanie - na pewneo negatywnie odbije się na marketingu Canonical ...

Canonical ma dane z dużo większej ilości maszyn niż ty - ba, ja z doświadczenia mogę powiedzieć, że hibernacja, w przeciwieństwi do usypiania, nie działała na kilku różnych maszynach z którymi miałem przyjemność pracować.

Jeszcze kwestia zarządzania zasilaniem ... tu kolejny "błąd" = brak skryptu readahead. Bez tego skryptu praktycznie niemożliwym jest prawidłowe zarządzania czasem bezczynności dysku = sleep, co oczywiście przekłada się na zużycie energii wyższe od 1 do 4 watt. Zresztą widzę, ze zrobili nowe skrypty np lista urządzeń PCI pci_devices - tylko po co je listowali ? Przecież można hurtem i dla wszystkich to samo zrobić - Ja to zamykam w kilku linijkach ... ;). Oczywiście mozna wdrożyć do 12.04 w/w skrypt readahead, który we współpracy z moim skryptem APM pozwala zaoszczędzić dodatkowe watty.

Podejrzewam, że skrypt listuje urządzenia PCI z tego samego powodu z którego Canonical wyłącza hibernację - kiedy musisz wspierać kilkanaście milionów instalacji ryzyko, że na części z nich nie będzie coś działać wzrasta. Takie blacklisty i whitelisty nie biorą się z niczego.

Cheers

[e X t 7 3]

Kwestia vaapi ... wskazuje rozwiązania które są możliwe na teraz - oczywiście długoterminowo powinni się dogadać z ludźmi z free desktop oraz AMD i ustanowić jednolity standard. Na teraz mogą to poprawić - użytkownik będzie zadowolony, że wsparcie sprzętowe działa i raczej nie zauważy "niuansu" w postaci braku eleganckiego rozwiązania sprawy.

Kwestia hibernacji ... proszę podaj mi maszyny na których taka sytuacja miała miejsce. Zaintrygowało mnie to - Ja już zainstalowałem Ubuntu/Kubuntu/Minta ze swoimi rozwiązaniami na ... w zasadzie na pewno ponad 100 maszynach i nigdy nie trafiłem na ten problem [jeśli nie popełniony został błąd - za mały swap, etc.) - z usypianiem i owszem.

Kwestia listowania. Oczywiście trudno jest przewidzieć pewne sytuacje, przy tak olbrzymiej ilości sprzętu, sterowników, etc. ... ale Canonical w tym konkretnym przypadku nie listuje modułów sterowników, etc. tylko wymienia np. wifi etc. To absolutnie nie zabezpieczy przed niczym - zresztą abstrahując od tego, że ten skrypt nie zadziała prawidłowo - sprawdź proszę na powertop - lista urządzeń na PCI = bad.

Pozdrawiam

[kklimonda]

Kwestia vaapi ... wskazuje rozwiązania które są możliwe na teraz - oczywiście długoterminowo powinni się dogadać z ludźmi z free desktop oraz AMD i ustanowić jednolity standard. Na teraz mogą to poprawić - użytkownik będzie zadowolony, że wsparcie sprzętowe działa i raczej nie zauważy "niuansu" w postaci braku eleganckiego rozwiązania sprawy.

Nie odpowiadasz ciągle na moje pytanie - dlaczego trzeba ustawiać na sztywno LIBVA_DRIVER_NAME? Użytkownik nie zauważnie braku eleganckiego rozwiązania, i dlatego można takie rozwiązania robić jako obejścia, ale nie na poziomie dystrybucji - tam trzeba dojść do tego co jest problemem ale najwyraźniej nikomu to nie przeszkadza bo bug jest od ponad pół roku obecny i nikt nie zainteresował się tym by go poprawić.

Kwestia hibernacji ... proszę podaj mi maszyny na których taka sytuacja miała miejsce. Zaintrygowało mnie to - Ja już zainstalowałem Ubuntu/Kubuntu/Minta ze swoimi rozwiązaniami na ... w zasadzie na pewno ponad 100 maszynach i nigdy nie trafiłem na ten problem [jeśli nie popełniony został błąd - za mały swap, etc.) - z usypianiem i owszem.

Thinkpad T61 z kartą nvidii - z jednymi sterownikami działał, z innymi nie. Desktop z płytą ASUS P8P67 Pro z kartą nvidii - nie wstawał (teraz wstaje) po próbie podniesienia komputera po hibernacji.

Kwestia listowania. Oczywiście trudno jest przewidzieć pewne sytuacje, przy tak olbrzymiej ilości sprzętu, sterowników, etc. ... ale Canonical w tym konkretnym przypadku nie listuje modułów sterowników, etc. tylko wymienia np. wifi etc. To absolutnie nie zabezpieczy przed niczym - zresztą abstrahując od tego, że ten skrypt nie zadziała prawidłowo - sprawdź proszę na powertop - lista urządzeń na PCI = bad.

Listowanie modułów nic nie daje bo moduł może wspierać różne wersje sprzętu - z jednymi działać, z innymi nie. Nie sprawdzę teraz na powertop bo nie mam pod ręką laptopa, ale jeżeli twoim zdaniem to nie działa to dlaczego nie próbowałeś tego zmienić przez ostatnie pół roku? Co za sens stwierdzać, że rozwiązanie nie działa na 5 dni przed premierą, na forum którego nie odwiedzają zainteresowane osoby?

[e X t 7 3]

Co do vaapi ... jakiś czas temu się tym interesowałem i wynikało, że "błąd" leżał w pewnym "rozjechaniu" się założeń sterowników fglrx, a odmiennym układem katalogów i rozmieszczenia plików w Ubuntu ... ale teraz nie wiem nie miałem czasu się w to "wgłębiać". Z tego co wiem, ze w Debianie sobie z tym poradzili ... a w Ubuntu nie.

Ciekawe z hibernacją ... tu sterowniki nie powinny odgrywać, aż takiej roli, jak przy usypianiu. W sumie to potwierdzasz moje opinie - zauważyłem przez dostani rok, że sterowniki dla Nvidii (zarówno na Linuksie, jak i windows) są coraz gorsze, a te dla AMD/ATi coraz lepsze i Developerzy tego ostatniego bardzo szybko reagują na zgłaszane błędy.

Co do kwestii zarządzania zasilaniem wiesz ... pisze tu bo wiem, że i tak Canonical na tę chwilę nic z tym nic nie zrobi ... tak jak i np. z modułem rts5139, którego aktywowanie skutkuje wywalaniem całego usb-storage. Błąd zgłaszłem, potwierdzałem, etc. ... już jakieś pół roku temu i co ? i nic ... Canonical nadal aktywuje ten moduł w kernelu. Skutkuje to tym, ze zainstalowanie Ubuntu, np. na MSI X370 oraz innych maszynach posiadających czytnik kard rts5139 by Realtek graniczy wręcz z cudem ... non stop wywalanie squashfs i usb-storage. Udało mi się zainstalować Kubuntu 12.04 na w/w chyba za ... 16 razem – wczytać desktop i od razu do konsoli a tam sudo rmmod rts5139 i można w końcu działać. Moje kernele nie mają aktywnego tego modułu. Zresztą za namową Grega K-H napisałem do Developerów Realteka, aby w końcu coś z tym zrobili ... zobaczymy, co odpowiedzą.

Pozdrawiam

[kklimonda]

Co do vaapi ... jakiś czas temu się tym interesowałem i wynikało, że "błąd" leżał w pewnym "rozjechaniu" się założeń sterowników fglrx, a odmiennym układem katalogów i rozmieszczenia plików w Ubuntu ... ale teraz nie wiem nie miałem czasu się w to "wgłębiać". Z tego co wiem, ze w Debianie sobie z tym poradzili ... a w Ubuntu nie.

Jeżeli w Debianie sobie z tym poradzili to rozwiązaniem będzie zapewne poprawienie paczki w taki sposób by sterowniki lądowały w /usr/lib/{i386,x86_64}-linux-gnu/dri/ (tam są odpowiedniki z paczki vdpau-va-driver) ale sam nie mam jak tego sprawdzić, bo nie mam takiego sprzętu. Mogę nawet zbudować odpowiednią paczkę, ale ktoś musi ją przetestować.

Ciekawe z hibernacją ... tu sterowniki nie powinny odgrywać, aż takiej roli, jak przy usypianiu. W sumie to potwierdzasz moje opinie - zauważyłem przez dostani rok, że sterowniki dla Nvidii (zarówno na Linuksie, jak i windows) są coraz gorsze, a te dla AMD/ATi coraz lepsze i Developerzy tego ostatniego bardzo szybko reagują na zgłaszane błędy.

AMD/ATI faktycznie w ostatnim roku zwiększyło współpracę z deweloperami kernela, zresztą NVIDIA właściwie nigdy nie robiła dobrych sterowników - może i były wydajne, ale obchodziły całe podsystemy grafiki od zawsze, i nigdy nie nadążali z wprowadzaniem nowych technologii.

Co do kwestii zarządzania zasilaniem wiesz ... pisze tu bo wiem, że i tak Canonical na tę chwilę nic z tym nic nie zrobi ... tak jak i np. z modułem rts5139, którego aktywowanie skutkuje wywalaniem całego usb-storage. Błąd zgłaszłem, potwierdzałem, etc. ... już jakieś pół roku temu i co ? i nic ... Canonical nadal aktywuje ten moduł w kernelu. Skutkuje to tym, ze zainstalowanie Ubuntu, np. na MSI X370 oraz innych maszynach posiadających czytnik kard rts5139 by Realtek graniczy wręcz z cudem ... non stop wywalanie squashfs i usb-storage. Udało mi się zainstalować Kubuntu 12.04 na w/w chyba za ... 16 razem – wczytać desktop i od razu do konsoli a tam sudo rmmod rts5139 i można w końcu działać. Moje kernele nie mają aktywnego tego modułu. Zresztą za namową Grega K-H napisałem do Developerów Realteka, aby w końcu coś z tym zrobili ... zobaczymy, co odpowiedzą.

Ja nie jestem przekonany, by zgłaszanie błędów na LP było wystarczającym sposobem na rozwiązywanie problemów w jakimkolwiek dużym projekcie open source :) [1] Łatwiej byłoby kopać ich po kostkach na liście dyskusyjnej i kanałach IRC (jeżeli masz czas siedzieć). Z doświadczenia wiem, że w ten sposób można rozwiązać właściwie każdy problem..

[1] Faktycznie tak powinno być, ale w praktyce jeżeli dany bug nie dotyczy wystarczającej ilości osób to po prostu jest spychany przez pilniejsze rzeczy.

[e X t 7 3]

Co do sterownika vaapi - tak dokładnie tu:

Kod: Zaznacz cały

/usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so

Powiem szczerze już nie mam czasu pisać na listy Ubuntu ... ostatnio dość dużo czas zajęło mi szukanie przyczyn, diagnozowanie i opisywanie błędów w kernelu 3.2.x, a następnie 3.3.x ... i w tym pierwszym i ostatnim udało się to usunąć - błąd btusb i bluetooth - skutkujący wywalaniem btusb i usbstorage ... po serii konsultacji - Andrei Emeltchenko znalazł rozwiązanie, ja przetestowałem na wszelkie możliwe sposoby i mam nadzieje będzie widoczne w wersji 3.3.3 ... upadło się to usunąć . Moje testowe kernel v19.0 na będą miały zaaplikowane te patche.

Pozdrawiam