Re: PCIe capture driver
On 11/11/2015 07:04 AM, Ran Shalit wrote: > On Wed, Oct 28, 2015 at 12:50 AM, Hans Verkuil wrote: >> >> >> On 10/27/2015 22:56, Ran Shalit wrote: >>> On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil wrote: On 10/27/2015 02:04, Ran Shalit wrote: > On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On Wed, Oct 28, 2015 at 12:50 AM, Hans Verkuil wrote: > > > On 10/27/2015 22:56, Ran Shalit wrote: >> On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil wrote: >>> >>> >>> On 10/27/2015 02:04, Ran Shalit wrote: On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On Wed, Oct 28, 2015 at 12:50 AM, Hans Verkuil wrote: > > > On 10/27/2015 22:56, Ran Shalit wrote: >> On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil wrote: >>> >>> >>> On 10/27/2015 02:04, Ran Shalit wrote: On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On 10/27/2015 22:56, Ran Shalit wrote: > On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil wrote: >> >> >> On 10/27/2015 02:04, Ran Shalit wrote: >>> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On Tue, Oct 27, 2015 at 12:21 AM, Hans Verkuil wrote: > > > On 10/27/2015 02:04, Ran Shalit wrote: >> On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On 10/27/2015 02:04, Ran Shalit wrote: > On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
Hi Ran, 2015-10-26 18:04 GMT+01:00 Ran Shalit : > On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On 10/25/2015 21:16, Ran Shalit wrote: > On Sat, Oct 24, 2015 at 11:38 AM, Hans Verkuil wrote: >> >> >> On 10/23/2015 23:57, Ran Shalit wrote: >>> On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On Sat, Oct 24, 2015 at 11:38 AM, Hans Verkuil wrote: > > > On 10/23/2015 23:57, Ran Shalit wrote: >> On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On 10/23/2015 23:57, Ran Shalit wrote: > On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
On Tue, Oct 20, 2015 at 9:23 AM, Hans Verkuil 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PCIe capture driver
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
