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