ЦитатаСо слов пользователя free-x
Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
самое время начать новый топик
ЦитатаСо слов пользователя free-x
Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
самое время начать новый топик
ЦитатаПоказать весь код
Regarding the multiproto situation:
A number of developers, maintainers and users are unhappy with the
multiproto situation, actually they've been unhappy for a considerable
amount of time. The linuxtv developer community (to some degree) is seen
as a joke and a bunch in-fighting people. Multiproto is a great
demonstration of this. [1] The multiproto project has gone too far, for
too long and no longer has any credibility in the eyes of many people.
In response, a number developers have agreed that "enough is enough" and
"it's time to take a new direction", for these developers the technical,
political and personal cost of multiproto is too high. These developers
have decided to make an announcement.
Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby
announcing that we no longer support multiproto and are forming a
smaller dedicated project group which is focusing on adding next
generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a
different and simpler API.
Basic patches and demo code for this API is currently available here.
Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
Does it even work? Yes
Is this new API complete? No
Is it perfect? No, we've already had feedback on structural and
namingspace changes that people would like to see.
Does it have bugs? Of course, we have a list of things we already know
we want to fix.
but ...
Is the new approach flexible? Yes, we're moving away from passing fixed
modulation structures into the kernel.
Can we add to it without breaking the future ABI when unforseen
modulations types occur? Yes
Does it preserve backwards compatibility? Yes
Importantly, is the overall direction correct? Yes
Does it impact existing frontend drivers? No.
What's the impact to dvb-core? Small.
What's the impact to application developers? None, unless an application
developer wants to support the new standards - binary compatibility!
We want feedback and we want progress, we aim to achieve it.
Importantly, this project group seeks your support.
If you also feel frustrated by the multiproto situation and agree in
principle with this new approach, and the overall direction of the API
changes, then we welcome you and ask you to help us.
Growing the list of supporting names by 100%, and allowing us to publish
your name on the public mailing list, would show the non-maintainer
development community that we recognize the problem and we're taking
steps to correct the problem. We want to make LinuxTV a perfect platform
for S2, ISDB-T and other advanced modulation types, without using the
multiproto patches.
We're not asking you for technical help, although we'd like that ,
we're just asking for your encouragement to move away from multiproto.
If you feel that you want to support our movement then please help us by
acking this email.
Regards - Steve, Mike, Patrick and Mauro.
Acked-by: Patrick Boettcher <pb@linuxtv.org>
Acked-by: Michael Krufky <mkrufky@linuxtv.org>
Acked-by: Steven Toth <stoth@linuxtv.org>
Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* [1]. Rather than point out the issues with multiproto here, take a
look at the patches and/or read the comments on the mailing lists.
ЦитатаПоказать весь код
Hello,
It's been a crazy few days, please forgive my short absence.
What have I been doing? Well, rather than spending time discussing a new
S2API on the mailing list, I wanted to actually produce a working series
of patches that kernel and application developers could begin to test.
Here's where all of the new S2API patches will now appear:
Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
In addition, here's is a userland application that demonstrates tuning
the current DVB-S/T/C and US ATSC modulations types using the new API.
(Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.)
A tuning demo app? What? Obviously, tuning older modulation types via
the new API isn't a requirements, but it's a useful validation exercise
for the new S2API. What _IS_ important is..... that it also demonstrates
using the same tuning mechanism to tune DVB-S2 8PSK / NBC-QPSK
modulation types, and also has rudimentary ISDB-T support for any
developers specifically interested.
This S2API tree also contains support for the cx24116 demodulator
driver, and the Hauppauge HVR4000 family of S2 products. So those
interested testers/developers can modify the tune.c app demo and make
changes specific to their area, and try experimenting with the new API
if they desire. [1]
Obviously, tune.c isn't intelligent, it's not a replacement for szap,
tzap or whatever - it's simply a standalone S2API test tool, that
demonstrates the important API interface.
QAM/ATSC are working well, the HVR4000 changes look fine according to
the debug log (although I have no local satellite feed for testing
tonight). DVB-T should just work as-is, but I can't test this for a day
or so. I.E. I've tested what I can in the US but we might have a few
bugs or gotchas!
If anyone is willing to pull the tree and begin testing with the tune.c
app then please post all feedback on this thread. [2]
I've received a lot of good feedback of the original 2007 patches. I
expect to start merging those changes of the coming days. Don't be too
concerned that your changes are not yet merged, keep watching the S2API
tree and they will soon appear ... along with a lot of general code
cleanup (checkpatch violations)
I expect to catchup on my older email tomorrow.
Regards to all,
- Steve
[1] I'll need to review and diff any of the newer HVR4000 driver
derivatives that people have been using, before merging those changes
into the S2API tree.
[2] Remember you're going to need the cx24116 firmware if you're
specifically testing the HVR4000.... but you probably already know that!
кто напишет патч для vdr 170 для совместимости с новым апи ?
KLS ответил что ему собсно по барабану какой АПИ...все сведется к правке dvbdevice.c.
Проблема в том что пока S2-3200 нету. А у него как раз эта карта. Он не будет рыпаться пока драйвера не будет.
ЦитатаПоказать весь код
[6:56] <_abbenormal> hey stoth
[6:56] <_abbenormal> does that have the tt-3200 in it
[6:56] <stoth> did you read the email?
[6:56] <_abbenormal> looking
[6:57] <stoth> not yet, maybe soon.
То есть, как я понял, не доделали одно, а уже взялись за другое?
И каковы шансы, что он не забросит свое творение через полгода.. чем-то ситуация похожа с "недооцененноым" Коливасом...
p.s.: вот и покупай после этого s2 карты
немного не так понял - 2 апи от двух разных команд - соперников.
Если мультипрото в основном ведет Ману Абрахам, который ну очень непродуктивно в последние полгода работал над ним, то новое апи в основном разрабатывается Стивеном Toth , который является давним оппонентом Ману. Про Стива могу сказать, что его cx24116 драйвер, написанный 3 года назад работает вполне нормально. Конечно же его, как автора дров задевает факт, что по вине нерасторопности Ману эти дрова еще не в кернеле. Кроме того, Стив - работник американской Hauppauge, Ману - не знаю чей работник.
Имхо для конечных пользователей от этого не легче. Через пару месяцев они начнут пиписьками меряться, а это явно не ускорит добавление того или иного апи в ядро..
Ведь, как я понял, мультипрото еще не стандартизирован? или reelbox нечто своё использует?
они (reel) изнасиловали старое API
еще вообще ничего не стандартизовано, что касается новых типов ....
Привет ребята, я снова с вами и сразу подолью масла в огонь. Не поленился и поставил стивовские дрова, выглядит пока не очень утешительно
[ 41.236159] Linux video capture interface: v2.00
[ 41.303522] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded
[ 41.303558] ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [APC3] -> GSI 18 (lev
el, low) -> IRQ 20
[ 41.303594] cx88[0]: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lit
e) DVB-S/S2 [card=69,autodetected]
[ 41.303596] cx88[0]: TV tuner type -1, Radio tuner type -1
[ 41.347425] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded
[ 41.528336] tveeprom 2-0050: Hauppauge model 69100, rev B2C3, serial# 2897909
[ 41.528339] tveeprom 2-0050: MAC address is 00-0D-FE-2C-37-F5
[ 41.528341] tveeprom 2-0050: tuner model is Conexant CX24118A (idx 123, type
4)
[ 41.528343] tveeprom 2-0050: TV standards ATSC/DVB Digital (eeprom 0x80)
[ 41.528344] tveeprom 2-0050: audio processor is None (idx 0)
[ 41.528346] tveeprom 2-0050: decoder processor is CX882 (idx 25)
[ 41.528347] tveeprom 2-0050: has no radio, has IR receiver, has no IR transmi
tter
[ 41.528349] cx88[0]: hauppauge eeprom: model=69100
[ 41.528409] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci0000:00/000
0:00:08.0/0000:01:08.0/input/input5
[ 41.535634] cx88_alsa: disagrees about version of symbol videobuf_dma_free
[ 41.535637] cx88_alsa: Unknown symbol videobuf_dma_free
[ 41.535666] cx88_alsa: disagrees about version of symbol cx88_core_put
[ 41.535668] cx88_alsa: Unknown symbol cx88_core_put
[ 41.535716] cx88_alsa: Unknown symbol videobuf_pci_alloc
[ 41.535735] cx88_alsa: disagrees about version of symbol cx88_core_irq
[ 41.535736] cx88_alsa: Unknown symbol cx88_core_irq
[ 41.535762] cx88_alsa: disagrees about version of symbol cx88_core_get
[ 41.535764] cx88_alsa: Unknown symbol cx88_core_get
[ 41.535870] cx88_alsa: disagrees about version of symbol btcx_riscmem_free
[ 41.535872] cx88_alsa: Unknown symbol btcx_riscmem_free
[ 41.535944] cx88_alsa: disagrees about version of symbol videobuf_dma_init
[ 41.535946] cx88_alsa: Unknown symbol videobuf_dma_init
[ 41.535989] cx88_alsa: disagrees about version of symbol cx88_sram_channel_du
mp
[ 41.535990] cx88_alsa: Unknown symbol cx88_sram_channel_dump
[ 41.536017] cx88_alsa: disagrees about version of symbol cx88_sram_channel_se
tup
[ 41.536018] cx88_alsa: Unknown symbol cx88_sram_channel_setup
[ 41.536039] cx88_alsa: disagrees about version of symbol videobuf_dma_init_ke
rnel
[ 41.536041] cx88_alsa: Unknown symbol videobuf_dma_init_kernel
[ 41.536076] cx88_alsa: Unknown symbol videobuf_pci_dma_unmap
[ 41.536121] cx88_alsa: Unknown symbol videobuf_pci_dma_map
[ 41.536146] cx88_alsa: disagrees about version of symbol cx88_risc_databuffer
[ 41.536148] cx88_alsa: Unknown symbol cx88_risc_databuffer
[ 41.536167] cx88_alsa: disagrees about version of symbol videobuf_to_dma
[ 41.536168] cx88_alsa: Unknown symbol videobuf_to_dma
[ 41.551911] cx88[0]/0: found at 0000:01:08.0, rev: 5, irq: 20, latency: 32, m
mio: 0xf4000000
[ 41.551955] cx88[0]/0: registered device video0 [v4l2]
[ 41.551968] cx88[0]/0: registered device vbi0
[ 41.552013] cx88[0]/2: cx2388x 8802 Driver Manager
[ 41.552026] ACPI: PCI Interrupt 0000:01:08.2[A] -> Link [APC3] -> GSI 18 (lev
el, low) -> IRQ 20
[ 41.552032] cx88[0]/2: found at 0000:01:08.2, rev: 5, irq: 20, latency: 32, m
mio: 0xf6000000
[ 41.763281] cx88/2: cx2388x dvb driver version 0.0.6 loaded
[ 41.763285] cx88/2: registering cx8802 driver, type: dvb access: shared
[ 41.763287] cx88[0]/2: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(L
ite) DVB-S/S2 [card=69]
[ 41.763290] cx88[0]/2: cx2388x based DVB/ATSC card
[ 41.919982] ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 23
[ 41.919986] ACPI: PCI Interrupt 0000:00:07.0[B] -> Link [AAZA] -> GSI 23 (lev
el, low) -> IRQ 16
[ 41.920002] PCI: Setting latency timer of device 0000:00:07.0 to 64
[ 41.946648] Linux agpgart interface v0.102
[ 41.962715] DVB: registering new adapter (cx88[0])
[ 41.962718] DVB: registering frontend 0 (Conexant CX24116/CX24118)...
[ 41.992150] ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16
Показать весь код
Попробовал самое простое, что есть под рукой - кафеин. Кафеин карту распознал, но сканировать спутники пока не получилось.
попробуй удалить все v4l модули от предыдучих сборок и собери по свежему. stoth думает что у тебя остался мусор от предыдущих экспериментов
ЦитатаСо слов пользователя free-x
попробуй удалить все v4l модули от предыдучих сборок и собери по свежему. stoth думает что у тебя остался мусор от предыдущих экспериментов
Присмотрелся повнимательнее., надо поновой собирать кернел с изменениями в tune.c . У меня на данный момент стоит Ubuntu Hardy, разумеется для кернела только хедерсы.
не понял юмора....
ошибка в несоответствии версий videobuf ... причем тут tune.c
ЦитатаСо слов пользователя free-x
не понял юмора....
ошибка в несоответствии версий videobuf ...
Ну разумеется я старые драйвера предварительно удалил и поставил новые, ошибка не в этом.
Хе-хе, Ману психует
lucian orasanu wrote:
> Hello Steven Toth,
>
> I was not pro for new DVBS2 API, but seeing now how fast the things are mouving, I think this is reale goodand cool, can you add your API to stb6100 and stb08900 driver?
>
Let me put things a bit clear. The multiproto tree already supports
DVB-S2 and future modulations, with backward compatibility. Also all
STB0899 based devices are supported by the multiproto tree. Patches do
exist for the cx24116 devices as well. Once the API patches are in
kernel (a pull request is already pending) it will be easy to add in
newer devices as well.
If you need to use the stb0899 based drivers, you can simply pull the
tree from http:http://jusst.de/hg/multiproto
It is available -now- you don't have to wait for things
Regards,
Manu
Показать весь код
Снёс стивовский апи и поставил дрова из hg от Игоря, проверяю - таже ошибка
"cx88_alsa: disagrees about version of symbol videobuf_dma_free
cx88_alsa: Unknown symbol videobuf_dma_free"
Но! Кафеин тоже карту отловил и...... просканировал спутники. На предмет DVB-S2 пока не пробовал.
Однако не совсем понятно откуда ошибка, неужто alsa по-горбатому стоит?
Пробую szap - чегой-то не лочит
Пробую tune -подставил в tune.c параметры существующего канала - залочил
igor@useri:~/hg/tune-s2$ ./tune -t5
/dev/dvb/adapter0/frontend0
test 5
ioctl result = 0
ioctl result = 0, [ 0x1f ] = FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
ioctl result = 0, [ 0x1f ] = FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
ioctl result = 0, [ 0x1f ] = FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
ioctl result = 0, [ 0x1f ] = FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
ioctl result = 0, [ 0x1f ] = FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
ioctl result = 0, [ 0x1f ] = FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
ioctl result = 0, [ 0x1f ] = FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
^C
Показать весь код
Наследство поломано - Legacy broken
Ну ничего, просто молод еще S2
ЦитатаСо слов пользователя warp
Хе-хе, Ману психует
С одной стороны, причина понятна. С другой - неплохо его подстегнули все-таки продолжить ковыряться в мультипрото. а то два месяца уже прошло с последнего изменения. такими "темпами" и в 2.6.30 ядро не попадет. Тем более, он же сам пишет, что уже всё практически завершено.
так он 2 месяца был в свадебном путешествии - до мультипрото ли ему было.
Вот мои мысли и сомнения по поводу нового апи. Все мы знаем недостатки Ману и мультипрото. Про недостатки нового апи пока еще ничего не знаем.
Если владельцы сx24116 карт могут расчитывать на достаточно хорошую поддержку этих карт в обновленных дровах, то владельцам stb0899 карт есть над чем призадуматься. Ману неоднократно жаловался на очень сложный код stb0899 , который содержит очень сложные математические вычисления (видимо для cx24116 карт эти вычисления находится в firmware). Соответственно, отладить код очень и очень сложно. Мы знаем, что в настоящее время stb0899 карты не лочат высокие двб-с потоки и плохо работают с потоками ср=30000 для 8psk. Ману пока не может найти глюк. Ману имеет хорошие связи и доки на stb0899 от производителя - SТМ. По моему скромному мнению, в настоящий момент он и только он сможет продолжить работу над кодом stb0899. И если будет принято новое апи, то уж Стив и компани из Хапуги уж никак не будут заинтересованы в продвижении на рынке карт их конкурентов, которые базируются на stb0899. А Ману объявит тихий бойкот и не будет ничего делать. Поэтому мы и подошли к самому главному вопросу - Кто адаптирует код stb0899 для нового апи и кто потом будет вылавливать в нем оставшиеся глюки ? Кто ? Я задал в листе этот вопрос Стиву - точного ответа не получил.
активно однако новое апи развивается. Вот уже и мультифронтэнд патч для hvr4000 подоспел
Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу. - еще бы вдр поддерживал мультфронтэнд