GigEVision support

[Falco Hirschenberger]

Greg KH schrieb:
> On Wed, Jul 08, 2009 at 05:50:38PM +0200, Falco Hirschenberger wrote:
>> Hi,
>>
>> I think Linux can really benefit from an open kernel-based GigEVision 
>> driver.
>>
>> GigEVision[1] is a proprietary closed standard for controlling 
>> high-quality video cameras over gigabit-ethernet. These cameras are 
>> often used in industrial vision software. This driver can be a great 
>> benefit for the industrial vision industry, because using small embedded 
>> Linux systems is in the trend there.
>>
>> Some manufacturers provide closed-source drivers for Linux because of 
>> the NDA which they signed at the AIA (Automated Imaging Association).
>> [2], [3]
>> Some provide no drivers but I think these cameras will work with a 
>> generic driver because they have to implement the standard to get certified.
>>
>> I have written a proof-of-concept userlevel driver by means of sniffing 
>> and reverse-engineering, but some features are missing and I think I 
>> will need some help to implement the rest. Btw. a kernel driver would 
>> perform a lot better.
> 
> Why would it perform better?  You can send/receive ethernet packets just
> as fast from userspace as from within the kernel, right?

You're right, the send/rec. performance will not be increased, but
I know that there's a so called "filter driver" for GigEVision on 
Windows systems. It's bypassing the UDP/IP stack which significantly 
reduces the CPU-load on the system. And that's good because in most 
cases the algorithms are running on the same machine.
But I think developing a filter driver is not the primary goal here.

> Or are you referring to the fact that the device should show up as a
> proper v4l2 device to userspace, and not need a custom userspace program
> interface?

This would also be an option, but I suppose the v4l2 Interface is not 
flexible enough for these complex cameras.

>> I hope this list is the correct place for this suggestion, feel free to 
>> forward it to another place.
> 
> It's a good place, hopefully people who wish to help out with this will
> contact you.
> 
> But note, without specs, this will be a lot of work :)

As mentioned, I have a basic implementation. The so called PACKET_RESEND 
functionality, which can request lost UDP packets is totally 
unimplemented and will be the hardest part. But the whole reverse 
engineering is rather easy with a normal packet sniffer and the 
closed-source driver.

I hope there is some interest in the community.

Regards, Falco