PCIe capture driver

PCIe capture driver

[Ran Shalit]

Hello,

When writing a device driver for  capturing video coming from PCIe,
does it need to be used as v4l device (video for linux) , ?

Regards,
Ran

Re: PCIe capture driver

[Hans Verkuil]

On 10/19/2015 10:26 PM, Ran Shalit wrote:
> Hello,
> 
> When writing a device driver for  capturing video coming from PCIe,
> does it need to be used as v4l device (video for linux) , ?

Yes. If you don't then 1) you will never be able to upstream the driver,
2) any application that wants to use your driver will need custom code to
talk to your driver, 3) it will be a lot more work to write the driver
since you can't use the V4L2 kernel frameworks it provides or ask for
help.

Basically, by deciding to reinvent the wheel you're screwing over your
customers and yourself.

Here is a nice PCI(e) template driver that you can use as your starting
point: Documentation/video4linux/v4l2-pci-skeleton.c

Regards,

	Hans

Re: PCIe capture driver

[Ran Shalit]

On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On 10/19/2015 10:26 PM, Ran Shalit wrote:
>> Hello,
>>
>> When writing a device driver for  capturing video coming from PCIe,
>> does it need to be used as v4l device (video for linux) , ?
>
> Yes. If you don't then 1) you will never be able to upstream the driver,
> 2) any application that wants to use your driver will need custom code to
> talk to your driver, 3) it will be a lot more work to write the driver
> since you can't use the V4L2 kernel frameworks it provides or ask for
> help.
>
> Basically, by deciding to reinvent the wheel you're screwing over your
> customers and yourself.
>
> Here is a nice PCI(e) template driver that you can use as your starting
> point: Documentation/video4linux/v4l2-pci-skeleton.c
>
> Regards,
>
>         Hans

Hans,

Many thanks for the detailed answer and the example !

Regards,
Ran

Re: PCIe capture driver

[Ran Shalit]

On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On 10/19/2015 10:26 PM, Ran Shalit wrote:
>> Hello,
>>
>> When writing a device driver for  capturing video coming from PCIe,
>> does it need to be used as v4l device (video for linux) , ?
>
> Yes. If you don't then 1) you will never be able to upstream the driver,
> 2) any application that wants to use your driver will need custom code to
> talk to your driver, 3) it will be a lot more work to write the driver
> since you can't use the V4L2 kernel frameworks it provides or ask for
> help.
>
> Basically, by deciding to reinvent the wheel you're screwing over your
> customers and yourself.
>
> Here is a nice PCI(e) template driver that you can use as your starting
> point: Documentation/video4linux/v4l2-pci-skeleton.c
>
> Regards,
>
>         Hans

Hi Hans,

I now understand, that I will be using media sdk (Intel) which is
based on DRM framework, and does not use v4l.
So I probably need to do some custom driver for delivering video with PCIe.

Regards,
Ran

Re: PCIe capture driver

[Hans Verkuil]

On 10/23/2015 23:57, Ran Shalit wrote:
> On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On 10/19/2015 10:26 PM, Ran Shalit wrote:
>>> Hello,
>>>
>>> When writing a device driver for  capturing video coming from PCIe,
>>> does it need to be used as v4l device (video for linux) , ?
>>
>> Yes. If you don't then 1) you will never be able to upstream the driver,
>> 2) any application that wants to use your driver will need custom code to
>> talk to your driver, 3) it will be a lot more work to write the driver
>> since you can't use the V4L2 kernel frameworks it provides or ask for
>> help.
>>
>> Basically, by deciding to reinvent the wheel you're screwing over your
>> customers and yourself.
>>
>> Here is a nice PCI(e) template driver that you can use as your starting
>> point: Documentation/video4linux/v4l2-pci-skeleton.c
>>
>> Regards,
>>
>>         Hans
> 
> Hi Hans,
> 
> I now understand, that I will be using media sdk (Intel) which is
> based on DRM framework, and does not use v4l.

DRM is for video output, not video capture. So this seems irrelevant.

> So I probably need to do some custom driver for delivering video with PCIe.

There is only one linux API for video capture: V4L2. What PCIe card are we
talking about here? What are you trying to achieve?

Regards,

	Hans

Re: PCIe capture driver

[Ran Shalit]

On Sat, Oct 24, 2015 at 11:38 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
>
> On 10/23/2015 23:57, Ran Shalit wrote:
>> On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> On 10/19/2015 10:26 PM, Ran Shalit wrote:
>>>> Hello,
>>>>
>>>> When writing a device driver for  capturing video coming from PCIe,
>>>> does it need to be used as v4l device (video for linux) , ?
>>>
>>> Yes. If you don't then 1) you will never be able to upstream the driver,
>>> 2) any application that wants to use your driver will need custom code to
>>> talk to your driver, 3) it will be a lot more work to write the driver
>>> since you can't use the V4L2 kernel frameworks it provides or ask for
>>> help.
>>>
>>> Basically, by deciding to reinvent the wheel you're screwing over your
>>> customers and yourself.
>>>
>>> Here is a nice PCI(e) template driver that you can use as your starting
>>> point: Documentation/video4linux/v4l2-pci-skeleton.c
>>>
>>> Regards,
>>>
>>>         Hans
>>
>> Hi Hans,
>>
>> I now understand, that I will be using media sdk (Intel) which is
>> based on DRM framework, and does not use v4l.
>
> DRM is for video output, not video capture. So this seems irrelevant.
>
>> So I probably need to do some custom driver for delivering video with PCIe.
>
> There is only one linux API for video capture: V4L2. What PCIe card are we
> talking about here? What are you trying to achieve?
>

I need to capture video from PCIe . The video stream will be delivered
from PC through PCIe to a custom board with Intel cpu using media sdk.
The purpose is to encode the raw video and save the encoded stream to
a file.
I guess I can build some custom driver which waits for frames and
deliver the received frames to the media sdk encoder.
Since media sdk does not use v4l anyway, so I guess such custom driver
is the best under this conditions, Right ?
Regards,
Ran

Re: PCIe capture driver

[Hans Verkuil]

On 10/25/2015 21:16, Ran Shalit wrote:
> On Sat, Oct 24, 2015 at 11:38 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>
>>
>> On 10/23/2015 23:57, Ran Shalit wrote:
>>> On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>> On 10/19/2015 10:26 PM, Ran Shalit wrote:
>>>>> Hello,
>>>>>
>>>>> When writing a device driver for  capturing video coming from PCIe,
>>>>> does it need to be used as v4l device (video for linux) , ?
>>>>
>>>> Yes. If you don't then 1) you will never be able to upstream the driver,
>>>> 2) any application that wants to use your driver will need custom code to
>>>> talk to your driver, 3) it will be a lot more work to write the driver
>>>> since you can't use the V4L2 kernel frameworks it provides or ask for
>>>> help.
>>>>
>>>> Basically, by deciding to reinvent the wheel you're screwing over your
>>>> customers and yourself.
>>>>
>>>> Here is a nice PCI(e) template driver that you can use as your starting
>>>> point: Documentation/video4linux/v4l2-pci-skeleton.c
>>>>
>>>> Regards,
>>>>
>>>>         Hans
>>>
>>> Hi Hans,
>>>
>>> I now understand, that I will be using media sdk (Intel) which is
>>> based on DRM framework, and does not use v4l.
>>
>> DRM is for video output, not video capture. So this seems irrelevant.
>>
>>> So I probably need to do some custom driver for delivering video with PCIe.
>>
>> There is only one linux API for video capture: V4L2. What PCIe card are we
>> talking about here? What are you trying to achieve?
>>
> 
> I need to capture video from PCIe . The video stream will be delivered
> from PC through PCIe to a custom board with Intel cpu using media sdk.
> The purpose is to encode the raw video and save the encoded stream to
> a file.
> I guess I can build some custom driver which waits for frames and
> deliver the received frames to the media sdk encoder.

So the capture driver captures the video to memory and passes it on to
the media sdk for encoding? That's V4L2: that API capures video into
memory.

So don't reinvent the wheel but use V4L2 for your PCIe driver.

> Since media sdk does not use v4l anyway, so I guess such custom driver
> is the best under this conditions, Right ?

No, use V4L2. What you do with the frame after it has been captured
into memory has no relevance to the API you use to capture into memory.

Regards,

	Hans

Re: PCIe capture driver

[Steven Toth]

> No, use V4L2. What you do with the frame after it has been captured
> into memory has no relevance to the API you use to capture into memory.

Ran, I've built many open and closed source Linux drivers over the
last 10 years - so I can speak with authority on this.

Hans is absolutely correct, don't make the mistake of going
proprietary with your API. Take advantage of the massive amount of
video related frameworks the kernel has to offer. It will get you to
market faster, assuming your goal is to build a driver that is open
source. If your licensing prohibits an open source driver solution,
you'll have no choice but to build your own proprietary API.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: PCIe capture driver

[Ran Shalit]

On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth <stoth@kernellabs.com> wrote:
>> No, use V4L2. What you do with the frame after it has been captured
>> into memory has no relevance to the API you use to capture into memory.
>
> Ran, I've built many open and closed source Linux drivers over the
> last 10 years - so I can speak with authority on this.
>
> Hans is absolutely correct, don't make the mistake of going
> proprietary with your API. Take advantage of the massive amount of
> video related frameworks the kernel has to offer. It will get you to
> market faster, assuming your goal is to build a driver that is open
> source. If your licensing prohibits an open source driver solution,
> you'll have no choice but to build your own proprietary API.
>
> --
> Steven Toth - Kernel Labs
> http://www.kernellabs.com

Hi,

Thank you very much for these valuable comments.
If I may ask one more on this issue:
Is there an example in linux tree, for a pci device which is used both
as a capture and a display device ? (I've made a search but did not
find any)
The PCIe device we are using will be both a capture device and output
video device (for display).

Many Thanks,
Ran

Re: PCIe capture driver

[Jean-Michel Hautbois]

Hi Ran,

2015-10-26 18:04 GMT+01:00 Ran Shalit <ranshalit@gmail.com>:
> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth <stoth@kernellabs.com> wrote:
>>> No, use V4L2. What you do with the frame after it has been captured
>>> into memory has no relevance to the API you use to capture into memory.
>>
>> Ran, I've built many open and closed source Linux drivers over the
>> last 10 years - so I can speak with authority on this.
>>
>> Hans is absolutely correct, don't make the mistake of going
>> proprietary with your API. Take advantage of the massive amount of
>> video related frameworks the kernel has to offer. It will get you to
>> market faster, assuming your goal is to build a driver that is open
>> source. If your licensing prohibits an open source driver solution,
>> you'll have no choice but to build your own proprietary API.
>>
>> --
>> Steven Toth - Kernel Labs
>> http://www.kernellabs.com
>
> Hi,
>
> Thank you very much for these valuable comments.
> If I may ask one more on this issue:
> Is there an example in linux tree, for a pci device which is used both
> as a capture and a display device ? (I've made a search but did not
> find any)
> The PCIe device we are using will be both a capture device and output
> video device (for display).

Is is a custom card ? If not, which one is it ?
And if it is a custom board, then maybe can you at least describe the
inputs and outputs exactly (ideally, the chips used) ?
This would help understand what you problem really is :).

JM

Re: PCIe capture driver

[Steven Toth]

>> Hans is absolutely correct, don't make the mistake of going
>> proprietary with your API. Take advantage of the massive amount of

> Thank you very much for these valuable comments.
> If I may ask one more on this issue:
> Is there an example in linux tree, for a pci device which is used both
> as a capture and a display device ? (I've made a search but did not
> find any)
> The PCIe device we are using will be both a capture device and output
> video device (for display).

An in-kernel open source PCIe device that you can feed frames (and
presumably audio), have the device render and capture? Not that I'm
aware of.

I've done these kinds of driver projects in the past, on a commercial
basis, for our clients. Contact me off list if you're looking for
help.

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com

Re: PCIe capture driver

[Hans Verkuil]

On 10/27/2015 02:04, Ran Shalit wrote:
> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth <stoth@kernellabs.com> wrote:
>>> No, use V4L2. What you do with the frame after it has been captured
>>> into memory has no relevance to the API you use to capture into memory.
>>
>> Ran, I've built many open and closed source Linux drivers over the
>> last 10 years - so I can speak with authority on this.
>>
>> Hans is absolutely correct, don't make the mistake of going
>> proprietary with your API. Take advantage of the massive amount of
>> video related frameworks the kernel has to offer. It will get you to
>> market faster, assuming your goal is to build a driver that is open
>> source. If your licensing prohibits an open source driver solution,
>> you'll have no choice but to build your own proprietary API.
>>
>> --
>> Steven Toth - Kernel Labs
>> http://www.kernellabs.com
> 
> Hi,
> 
> Thank you very much for these valuable comments.
> If I may ask one more on this issue:
> Is there an example in linux tree, for a pci device which is used both
> as a capture and a display device ? (I've made a search but did not
> find any)
> The PCIe device we are using will be both a capture device and output
> video device (for display).

The cobalt driver (drivers/media/pci/cobalt) does exactly that: multiple HDMI inputs and an optional HDMI output (through a daughterboard).

Please note: using V4L2 for an output only makes sense if you will be outputting video, if the goal is to output a graphical desktop then the drm/kms API is much more suitable.

Regards,

	Hans

Re: PCIe capture driver

[Ran Shalit]

On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
>
> On 10/27/2015 02:04, Ran Shalit wrote:
>> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth <stoth@kernellabs.com> wrote:
>>>> No, use V4L2. What you do with the frame after it has been captured
>>>> into memory has no relevance to the API you use to capture into memory.
>>>
>>> Ran, I've built many open and closed source Linux drivers over the
>>> last 10 years - so I can speak with authority on this.
>>>
>>> Hans is absolutely correct, don't make the mistake of going
>>> proprietary with your API. Take advantage of the massive amount of
>>> video related frameworks the kernel has to offer. It will get you to
>>> market faster, assuming your goal is to build a driver that is open
>>> source. If your licensing prohibits an open source driver solution,
>>> you'll have no choice but to build your own proprietary API.
>>>
>>> --
>>> Steven Toth - Kernel Labs
>>> http://www.kernellabs.com
>>
>> Hi,
>>
>> Thank you very much for these valuable comments.
>> If I may ask one more on this issue:
>> Is there an example in linux tree, for a pci device which is used both
>> as a capture and a display device ? (I've made a search but did not
>> find any)
>> The PCIe device we are using will be both a capture device and output
>> video device (for display).
>
> The cobalt driver (drivers/media/pci/cobalt) does exactly that: multiple HDMI inputs and an optional HDMI output (through a daughterboard).
>
> Please note: using V4L2 for an output only makes sense if you will be outputting video, if the goal is to output a graphical desktop then the drm/kms API is much more suitable.
>
> Regards,
>
>         Hans

Hi Hans,

Thank you very much for the reference.
I see that the cobalt card is not for sale ?  If it was it could help
us in our development.

In our case it is more custom design which is based on FPGA:

Cpu ---PCIe---- FPGA <<<-->>>     3xHD+3xSD inputs & 1xHD(or SD) output

As I understand there is no product chip which can do the above
(3xHD+3xSD inputs & 1xHD(or SD) output), that's why the use of FPGA in
the board design.

Best Regards,
Ran

Re: PCIe capture driver

[Hans Verkuil]

On 10/27/2015 22:56, Ran Shalit wrote:
> On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>
>>
>> On 10/27/2015 02:04, Ran Shalit wrote:
>>> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth <stoth@kernellabs.com> wrote:
>>>>> No, use V4L2. What you do with the frame after it has been captured
>>>>> into memory has no relevance to the API you use to capture into memory.
>>>>
>>>> Ran, I've built many open and closed source Linux drivers over the
>>>> last 10 years - so I can speak with authority on this.
>>>>
>>>> Hans is absolutely correct, don't make the mistake of going
>>>> proprietary with your API. Take advantage of the massive amount of
>>>> video related frameworks the kernel has to offer. It will get you to
>>>> market faster, assuming your goal is to build a driver that is open
>>>> source. If your licensing prohibits an open source driver solution,
>>>> you'll have no choice but to build your own proprietary API.
>>>>
>>>> --
>>>> Steven Toth - Kernel Labs
>>>> http://www.kernellabs.com
>>>
>>> Hi,
>>>
>>> Thank you very much for these valuable comments.
>>> If I may ask one more on this issue:
>>> Is there an example in linux tree, for a pci device which is used both
>>> as a capture and a display device ? (I've made a search but did not
>>> find any)
>>> The PCIe device we are using will be both a capture device and output
>>> video device (for display).
>>
>> The cobalt driver (drivers/media/pci/cobalt) does exactly that: multiple HDMI inputs and an optional HDMI output (through a daughterboard).
>>
>> Please note: using V4L2 for an output only makes sense if you will be outputting video, if the goal is to output a graphical desktop then the drm/kms API is much more suitable.
>>
>> Regards,
>>
>>         Hans
> 
> Hi Hans,
> 
> Thank you very much for the reference.
> I see that the cobalt card is not for sale ?  If it was it could help
> us in our development.

No, sorry. It's a Cisco-internal card only.
 
> In our case it is more custom design which is based on FPGA:
> 
> Cpu ---PCIe---- FPGA <<<-->>>     3xHD+3xSD inputs & 1xHD(or SD) output
> 
> As I understand there is no product chip which can do the above
> (3xHD+3xSD inputs & 1xHD(or SD) output), that's why the use of FPGA in
> the board design.

The ivtv driver (drivers/media/pci/ivtv) has SD input and output, so that can be a
useful reference for that as well. The Hauppauge PVR-350 board is no longer
sold, but you might be able to pick one up on ebay.

Regards,

	Hans

Re: PCIe capture driver

[Ran Shalit]

On Wed, Oct 28, 2015 at 12:50 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
>
> On 10/27/2015 22:56, Ran Shalit wrote:
>> On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>
>>>
>>> On 10/27/2015 02:04, Ran Shalit wrote:
>>>> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth <stoth@kernellabs.com> wrote:
>>>>>> No, use V4L2. What you do with the frame after it has been captured
>>>>>> into memory has no relevance to the API you use to capture into memory.
>>>>>
>>>>> Ran, I've built many open and closed source Linux drivers over the
>>>>> last 10 years - so I can speak with authority on this.
>>>>>
>>>>> Hans is absolutely correct, don't make the mistake of going
>>>>> proprietary with your API. Take advantage of the massive amount of
>>>>> video related frameworks the kernel has to offer. It will get you to
>>>>> market faster, assuming your goal is to build a driver that is open
>>>>> source. If your licensing prohibits an open source driver solution,
>>>>> you'll have no choice but to build your own proprietary API.
>>>>>
>>>>> --
>>>>> Steven Toth - Kernel Labs
>>>>> http://www.kernellabs.com
>>>>
>>>> Hi,
>>>>
>>>> Thank you very much for these valuable comments.
>>>> If I may ask one more on this issue:
>>>> Is there an example in linux tree, for a pci device which is used both
>>>> as a capture and a display device ? (I've made a search but did not
>>>> find any)
>>>> The PCIe device we are using will be both a capture device and output
>>>> video device (for display).
>>>
>>> The cobalt driver (drivers/media/pci/cobalt) does exactly that: multiple HDMI inputs and an optional HDMI output (through a daughterboard).
>>>
>>> Please note: using V4L2 for an output only makes sense if you will be outputting video, if the goal is to output a graphical desktop then the drm/kms API is much more suitable.
>>>
>>> Regards,
>>>
>>>         Hans
>>
>> Hi Hans,
>>
>> Thank you very much for the reference.
>> I see that the cobalt card is not for sale ?  If it was it could help
>> us in our development.
>
> No, sorry. It's a Cisco-internal card only.
>
>> In our case it is more custom design which is based on FPGA:
>>
>> Cpu ---PCIe---- FPGA <<<-->>>     3xHD+3xSD inputs & 1xHD(or SD) output
>>
>> As I understand there is no product chip which can do the above
>> (3xHD+3xSD inputs & 1xHD(or SD) output), that's why the use of FPGA in
>> the board design.
>
> The ivtv driver (drivers/media/pci/ivtv) has SD input and output, so that can be a
> useful reference for that as well. The Hauppauge PVR-350 board is no longer
> sold, but you might be able to pick one up on ebay.
>
> Regards,
>
>         Hans

I've been delving in V4l Wikis,  API,   and the PCI driver examples code.

I think a good starting point for the development will be
v4l2-pci-skeleton.c , becuase it is much simpler than the more
production examples,
do you recommend it as a starting point ?

I am just not sure that the pci skeleton supports the HD & SD channels
at the same time:
I think it will open only one device (for example /dev/video0) , so
that the application will need to select which input is used (not
both) ?

Best Regards,
Ran

Re: PCIe capture driver

[Ran Shalit]

On Wed, Oct 28, 2015 at 12:50 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
>
> On 10/27/2015 22:56, Ran Shalit wrote:
>> On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>
>>>
>>> On 10/27/2015 02:04, Ran Shalit wrote:
>>>> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth <stoth@kernellabs.com> wrote:
>>>>>> No, use V4L2. What you do with the frame after it has been captured
>>>>>> into memory has no relevance to the API you use to capture into memory.
>>>>>
>>>>> Ran, I've built many open and closed source Linux drivers over the
>>>>> last 10 years - so I can speak with authority on this.
>>>>>
>>>>> Hans is absolutely correct, don't make the mistake of going
>>>>> proprietary with your API. Take advantage of the massive amount of
>>>>> video related frameworks the kernel has to offer. It will get you to
>>>>> market faster, assuming your goal is to build a driver that is open
>>>>> source. If your licensing prohibits an open source driver solution,
>>>>> you'll have no choice but to build your own proprietary API.
>>>>>
>>>>> --
>>>>> Steven Toth - Kernel Labs
>>>>> http://www.kernellabs.com
>>>>
>>>> Hi,
>>>>
>>>> Thank you very much for these valuable comments.
>>>> If I may ask one more on this issue:
>>>> Is there an example in linux tree, for a pci device which is used both
>>>> as a capture and a display device ? (I've made a search but did not
>>>> find any)
>>>> The PCIe device we are using will be both a capture device and output
>>>> video device (for display).
>>>
>>> The cobalt driver (drivers/media/pci/cobalt) does exactly that: multiple HDMI inputs and an optional HDMI output (through a daughterboard).
>>>
>>> Please note: using V4L2 for an output only makes sense if you will be outputting video, if the goal is to output a graphical desktop then the drm/kms API is much more suitable.
>>>
>>> Regards,
>>>
>>>         Hans
>>
>> Hi Hans,
>>
>> Thank you very much for the reference.
>> I see that the cobalt card is not for sale ?  If it was it could help
>> us in our development.
>
> No, sorry. It's a Cisco-internal card only.
>
>> In our case it is more custom design which is based on FPGA:
>>
>> Cpu ---PCIe---- FPGA <<<-->>>     3xHD+3xSD inputs & 1xHD(or SD) output
>>
>> As I understand there is no product chip which can do the above
>> (3xHD+3xSD inputs & 1xHD(or SD) output), that's why the use of FPGA in
>> the board design.
>
> The ivtv driver (drivers/media/pci/ivtv) has SD input and output, so that can be a
> useful reference for that as well. The Hauppauge PVR-350 board is no longer
> sold, but you might be able to pick one up on ebay.
>


Hello Hans,

Is it possible to use the PVR-350 which is a PCI device connected to
PCI express in mothrboard ? (I think it will required an adapter )
Does the ivtv driver function correctly if an adapter to PCIe is connected ?

Best Regards,
Ran

Re: PCIe capture driver

[Hans Verkuil]

On 11/11/2015 07:04 AM, Ran Shalit wrote:
> On Wed, Oct 28, 2015 at 12:50 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>
>>
>> On 10/27/2015 22:56, Ran Shalit wrote:
>>> On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>
>>>>
>>>> On 10/27/2015 02:04, Ran Shalit wrote:
>>>>> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth <stoth@kernellabs.com> wrote:
>>>>>>> No, use V4L2. What you do with the frame after it has been captured
>>>>>>> into memory has no relevance to the API you use to capture into memory.
>>>>>>
>>>>>> Ran, I've built many open and closed source Linux drivers over the
>>>>>> last 10 years - so I can speak with authority on this.
>>>>>>
>>>>>> Hans is absolutely correct, don't make the mistake of going
>>>>>> proprietary with your API. Take advantage of the massive amount of
>>>>>> video related frameworks the kernel has to offer. It will get you to
>>>>>> market faster, assuming your goal is to build a driver that is open
>>>>>> source. If your licensing prohibits an open source driver solution,
>>>>>> you'll have no choice but to build your own proprietary API.
>>>>>>
>>>>>> --
>>>>>> Steven Toth - Kernel Labs
>>>>>> http://www.kernellabs.com
>>>>>
>>>>> Hi,
>>>>>
>>>>> Thank you very much for these valuable comments.
>>>>> If I may ask one more on this issue:
>>>>> Is there an example in linux tree, for a pci device which is used both
>>>>> as a capture and a display device ? (I've made a search but did not
>>>>> find any)
>>>>> The PCIe device we are using will be both a capture device and output
>>>>> video device (for display).
>>>>
>>>> The cobalt driver (drivers/media/pci/cobalt) does exactly that: multiple HDMI inputs and an optional HDMI output (through a daughterboard).
>>>>
>>>> Please note: using V4L2 for an output only makes sense if you will be outputting video, if the goal is to output a graphical desktop then the drm/kms API is much more suitable.
>>>>
>>>> Regards,
>>>>
>>>>         Hans
>>>
>>> Hi Hans,
>>>
>>> Thank you very much for the reference.
>>> I see that the cobalt card is not for sale ?  If it was it could help
>>> us in our development.
>>
>> No, sorry. It's a Cisco-internal card only.
>>
>>> In our case it is more custom design which is based on FPGA:
>>>
>>> Cpu ---PCIe---- FPGA <<<-->>>     3xHD+3xSD inputs & 1xHD(or SD) output
>>>
>>> As I understand there is no product chip which can do the above
>>> (3xHD+3xSD inputs & 1xHD(or SD) output), that's why the use of FPGA in
>>> the board design.
>>
>> The ivtv driver (drivers/media/pci/ivtv) has SD input and output, so that can be a
>> useful reference for that as well. The Hauppauge PVR-350 board is no longer
>> sold, but you might be able to pick one up on ebay.
>>
> 
> 
> Hello Hans,
> 
> Is it possible to use the PVR-350 which is a PCI device connected to
> PCI express in mothrboard ? (I think it will required an adapter )
> Does the ivtv driver function correctly if an adapter to PCIe is connected ?

Yes, that should work. You need an adapter like this one:

http://www.dx.com/p/pci-express-to-pci-adapter-card-26080#.VkLso3yrRwE

Regards,

	Hans