wintv pci support

hallo people,

has anyone tested the wintv pci card under qnx 6.10, l just got told that the DDK kit is a non starter for such a project. l checked thru the DDK and found some
tv / video tuner / capture programms for the voodoo3 cards. my problem is why can l not use the same skeleton for my wintv card. If it really does not work with the help
of the gDDk, which tv / video cards can l try to implement drivers for (that is using the examples given in the ddk), and not yet implemented for qnx without having to
start from scratch.

If none, and l’m really to start from zero, what type of resource manager would be a good starting point. can l use the dev/null type of thing even though l can’t figure out
what type of functions l could override in the connect and I/O tables. throw some light please.

Any help and suggestions will be strongly appreciated.

so long

In article 1103_1006970007@peter, bmasuku@hotmail.com says…

hallo people,

has anyone tested the wintv pci card under qnx 6.10, l just got told that the DDK kit is a non starter for such a project. l checked thru the DDK and found some
tv / video tuner / capture programms for the voodoo3 cards. my problem is why can l not use the same skeleton for my wintv card. If it really does not work with the help
of the gDDk, which tv / video cards can l try to implement drivers for (that is using the examples given in the ddk), and not yet implemented for qnx without having to
start from scratch.

If none, and l’m really to start from zero, what type of resource manager would be a good starting point. can l use the dev/null type of thing even though l can’t figure out
what type of functions l could override in the connect and I/O tables. throw some light please.

Any help and suggestions will be strongly appreciated.

so long


You can use the capture programs for the voodoo3 cards as starter

skeletons. The problem comes about when you want to use some API for a
program to control the activity of the video capture.
Basically, the voodoo3 code assumes a framework (in the OS) for such
devices that will not exist (apparently) in the future. In the future, a
different framework will be present. So - you can use the DDK code as a
skeleton, you just cannot assume that the API as shown in that code will
exist for very long. There may be other issues, too. Such as the DDK
example may have the capture device and the video display device on the
same physical PCI card, with internal data pathways for the digitized
video signal to go to the graphics card.
If you want to design your own API - which ioctl() calls mean what to the
capture card - then you have designed your own API, and your application
programs - the ones that set the channel, capture resolution, etc., will
have to use your custom API. But they will need re-work before they are
compatible with whatever future video capture API from QSSL is in the
works. If you want the video and sound to go to your video and sound
cards, you also have to find a way to convey the video and sound data to
them.

I (for fun) started to write a capture card program for QNX6 before they
even had a graphics DDK available. I did not get very far - basically I
could read/write the srom (want to be very careful writing it!), change
the tuner frequency, and stalled in the part where I was enabling the
sound on the card - had some documentation/debugging/frustration issues
that shut my interest down.

I never even got close to getting a video stream from the card.


Stephen Munnings
Software Developer
Corman Technologies Inc.

Stephen Munnings <steve@cormantech.com> wrote:

Basically, the voodoo3 code assumes a framework (in the OS) for such
devices that will not exist (apparently) in the future. In the future, a
different framework will be present. So - you can use the DDK code as a
skeleton, you just cannot assume that the API as shown in that code will
exist for very long. There may be other issues, too. Such as the DDK

We do not have any plans to scrap the API that the VooDoo3 capture code
is using. In fact, we plan use this API to support video capture on
other video adapters. However, this API is specifically intended to
support devices whereby the video data is streamed into the offscreen
memory of the video card. Hence, it works fine for devices where
the capture device and the graphics are integrated onto the same
video device.

In addition, we are implementing a supplemental API for devices like
the BT878, where the video capture device is standalone, and can
DMA/bus master to anywhere in physical address space. This model would
also better suit devices such as USB cameras etc. The new API will
complement, but is unlikely to ever supercede, the API to which the
VooDoo3 capture routines are implemented.

Dave

thanks a lot for the advice stephen, l’ll try to experiment a bit and see where l land.
any way when is qnx intending to release their ddk for stanalone tv/video cards.

so long


On Wed, 28 Nov 2001 14:06:16 -0500, Stephen Munnings <steve@cormantech.com> wrote:


In article 1103_1006970007@peter, > bmasuku@hotmail.com > says…
hallo people,

has anyone tested the wintv pci card under qnx 6.10, l just got told that the DDK kit is a non starter for such a project. l checked thru the DDK and found some
tv / video tuner / capture programms for the voodoo3 cards. my problem is why can l not use the same skeleton for my wintv card. If it really does not work with the help
of the gDDk, which tv / video cards can l try to implement drivers for (that is using the examples given in the ddk), and not yet implemented for qnx without having to
start from scratch.

If none, and l’m really to start from zero, what type of resource manager would be a good starting point. can l use the dev/null type of thing even though l can’t figure out
what type of functions l could override in the connect and I/O tables. throw some light please.

Any help and suggestions will be strongly appreciated.

so long


You can use the capture programs for the voodoo3 cards as starter
skeletons. The problem comes about when you want to use some API for a
program to control the activity of the video capture.
Basically, the voodoo3 code assumes a framework (in the OS) for such
devices that will not exist (apparently) in the future. In the future, a
different framework will be present. So - you can use the DDK code as a
skeleton, you just cannot assume that the API as shown in that code will
exist for very long. There may be other issues, too. Such as the DDK
example may have the capture device and the video display device on the
same physical PCI card, with internal data pathways for the digitized
video signal to go to the graphics card.
If you want to design your own API - which ioctl() calls mean what to the
capture card - then you have designed your own API, and your application
programs - the ones that set the channel, capture resolution, etc., will
have to use your custom API. But they will need re-work before they are
compatible with whatever future video capture API from QSSL is in the
works. If you want the video and sound to go to your video and sound
cards, you also have to find a way to convey the video and sound data to
them.

I (for fun) started to write a capture card program for QNX6 before they
even had a graphics DDK available. I did not get very far - basically I
could read/write the srom (want to be very careful writing it!), change
the tuner frequency, and stalled in the part where I was enabling the
sound on the card - had some documentation/debugging/frustration issues
that shut my interest down.

I never even got close to getting a video stream from the card.


Stephen Munnings
Software Developer
Corman Technologies Inc.

You ought to go look at the thread “TV Tuner/Capture support…” from 10/15/01 in this group.

I assume the WinTV PCI card you are using is probably based on a Conexant (Brooktree)
848, 878, or 879 series chip?

We (Nexware) have a driver for Conexant series capture chips that I wrote for QNX RTP
but it uses a proprietary API to interface to it (until such time as QNX releases a standard API
for standalone video capture devices). Donahoe already has some of the framework in place for
integrated VGA/TV capture boards (i.e. ATI All-In-Wonder series) but due a multitude of reasons,
the drivers for secondary standalone device will most likely have to be handled a bit differently.

\

Michael Burkey (mailto:Michael.Burkey@Nexwarecorp.com)
Nexware Corp. (http://www.nexwarecorp.com)
Software Engineer
865.546.9998 x201



“madoda ndodana” <bmasuku@hotmail.com> wrote in message news:1103_1006970007@peter…

hallo people,

has anyone tested the wintv pci card under qnx 6.10, l just got told that the DDK kit is a non starter for such a project. l
checked thru the DDK and found some
tv / video tuner / capture programms for the voodoo3 cards. my problem is why can l not use the same skeleton for my wintv card.
If it really does not work with the help
of the gDDk, which tv / video cards can l try to implement drivers for (that is using the examples given in the ddk), and not yet
implemented for qnx without having to
start from scratch.

If none, and l’m really to start from zero, what type of resource manager would be a good starting point. can l use the dev/null
type of thing even though l can’t figure out
what type of functions l could override in the connect and I/O tables. throw some light please.

Any help and suggestions will be strongly appreciated.

so long