Użytkownik Shining Path napisał:
- na v4l2 nie działa w ogóle, wypluwa taki błąd:
v4l2: ioctl query capabilities failed: Zły argument
v4l2: 0 frames successfully processed, 0 frames dropped.
============ Sorry, this file format is not recognized/supported =============
=== If this file is an AVI, ASF or MPEG stream, please contact the author! ===
Cannot open demuxer.
- na v4l działa, acz tutaj także się pluje, bowiem:
Card reports an unknown audio mode !
Kernel patchowany łatkami z bytesex.org.
Jeśli używasz v4l2, to lepiej chyba użyć bttv-0.9 zamiast 0.7 (kernele 2.2 i niepatchowane 2.4).
0.9 pracuje na v4l2, 0.7 najwyżej używa v4l1-compat.
2.4.22 łatałem kraxelem, bttv pozostawiłem niezmienone, teraz rozumiem czemu
v4l2 nie działa w ogóle.
Kompiluje 2.6 z łatkami - wczoraj niestety potrzeba snu okazała się silniejsza.
mplayer własny - dystrybucyjny nie spełnił mych oczekiwań. przerobiłem pldowego speca w/g własnego widzimisię, do przejrzenia tutaj http://www.ghnet.pl/~halab/pliki/scripts/mplayer.spec Zaznaczę jednak istotną rzecz - na dystrybucyjnym tez nie działa!
Używam 2.4.22 - własna produkcja.
2.6.0-test9 - mam także, ale bez jakichkolwiek łatek - skompilowałem sobie
dla testu (jak nazwa wskazuje :).
Myślisz, że babor może być w kernelu 2.4.x? Na 2.4.20 pod Ra z mplayerem
2.4.20 - tu się zaczęły moje klopoty z v4l2 i trwały do 2.6 - próbowałem potem z 2.4.21 (2.4.22 sobie darowałem:)) i było to samo
Na 2.4.20 używałem v4l, działało OK. O v4l2 nie było mowy, choćby z tej przyczyny, że
nie łatałem kernela pod tym kątem. Ten sam kernel kompilowany pod Ac - póki miałem
mplayera 0.90, było w porządku.
- w videodev2.h było include <time.h> - wywoływało redeklarację (kolidowało - time.h jest nawet w kernelu chyba 2 razy i jeszcze w glibc),
potrzebne to jest do kompilacji samego videodev, od 2.4.22 jest już warunek - tylko w przypadku kompilacji kernela (i modułów),
aplikacje to omijają.
#ifdef __KERNEL__
#include <linux/time.h> /* need struct timeval */
#endif
W 2.4.20 jest tylko środkowa linijka.
Krótko - niektóre programy (w tym mplayer) w ogóle nie wykrywały (albo "unusable") v4l, albo się wywalały w trakcie kompilacji.
Teraz znowu jest ok. A przygodę z 2.4 skończyłem na 2.4.20 właśnie.
A 2.6 już na desktopie na 2.4 bym nie zamienił.
Ja 2.6 ino tak na chwilkę i dla sprawdzenia jak to działa. A działa naprawdę nieźle. Wydaje mi
się czy jest rzeczywiście szybszy? Zakończyłem jednak z nim przygodę na rzecz 2.4.22 bo
nie umiałem zmusić lirca i sensors do działania. Szkoda, że wcześniej nie zajrzałem na
Twoją stronę (/dev/input/eventX - żebym to ja wiedział wcześniej :)
Nadal mam jednak wątpliwości co do sensors - z tego co pamiętam burzył się o
brak i2c-proc, nadal go nie ma - jak to łyknąć?
A patche nie są moje :(.
A lirc-devinput nie jest konieczny z tymi łatami - devinput działa na "czystym" 2.6.
A łaty lirca dodają moduły do starego, dobrego gpio animaxa, i seriala - wystarczą programy z distro - lirc-0.6.6.
(Piszę, bo zauważyłem, żeś i to chwycił ;)).
Ano chwyciłem i to nie raz - dopiero za którymś razem udało mi się pobrać plik prawidłowo.
Nonstop miałem błędy w paczce i nic nie można było z nią zrobić.
Właśnie na czystym 2.6 nie było gpio co mnie bardzo zmartwiło.
A lirc-0.6.6 podczas kompilacji wywalał się. Widać za szybko się wtedy poddałem :/
Ufff.
Ja se ufffne jak będzie to działać. Strasznie długo się kompiluje to 2.6 :(
-- Robert Halabowski - http://www.ghnet.pl/~halab Komputer bez Linuksa jest jak plaża bez słońca. z /dev/dsp wydobywa się: Borysewicz_and_Kukiz_-_01_-_Bo_tutaj_jest_jak_jest
_________________________________________ http://pld-linux.org/ = faq, howto, newsy
dostales tutaj odpowiedz na swoje pytanie?
podziel sie z innymi i dopisz do FAQ!
http://pld-linux.org/FAQ/