GPL code for Omnivision USB video camera available.
Hi all,
I have a driver for a USB video camera that I'd like to see added to the mainline kernel, mainly so I don't have to fix breakage due to constant changes in the kernel :-).
The code is GPL and is available here:
http://stage.bcode.com/erikd/ovcamchip
and the history of this code is here:
http://stage.bcode.com/erikd/ovcamchip/README
My problem is that I am way too busy to sheperd this into the kernel myself. If someone is willing to work on getting this in, I can send them a camera to keep. If getting paid is more likely to help someone focus on the task then that is also a possibility.
Any takers? Please email me privately.
Cheers,
Erik
Signature · 13 lines
======================= erik de castro lopo senior design engineer bCODE level 2, 2a glen street milsons point sydney nsw 2061 australia tel +61 (0)2 9954 4411 fax +61 (0)2 9954 4422 www.bcode.com
Quoted 12 lines · Erik de Castro Lopo
Hi all,
I have a driver for a USB video camera that I'd like to see added to the mainline kernel, mainly so I don't have to fix breakage due to constant changes in the kernel :-).
The code is GPL and is available here:
http://stage.bcode.com/erikd/ovcamchip
and the history of this code is here:
Quoted 9 lines
http://stage.bcode.com/erikd/ovcamchip/README
My problem is that I am way too busy to sheperd this into the kernel myself. If someone is willing to work on getting this in, I can send them a camera to keep. If getting paid is more likely to help someone focus on the task then that is also a possibility.
Any takers? Please email me privately.
This looks to me like its just ov51x-jpeg made to compile with the latest kernel. Did you make any functional changes?
Note that ov51x-jpeg is not acceptable as is as it does in kernel decompression of the ov51x jpeg-like compression format.
I'm currently finishing up adding ov511(+) and ov518(+) support to the gspca ov519 subdriver. And I've already added support for decompressing their format in userspace to libv4l.
Also I wonder if you're subscribed to the (low trafic) ov51x-jpeg mailinglist, that seems to be the right thing todo for someone who tries to get that driver in to the mainline. I've already announced my work on getting the ov511(+) and ov518(+) supported properly in the mainline kernel there.
May I ask what cam you have? I could certainly use more people testing this.
Regards,
Hans
Quoted 2 lines · Hans de Goede
This looks to me like its just ov51x-jpeg made to compile with the latest kernel.
Its more than that. This driver supports a number of cameras and the only one we (bCODE) are really interested in is the ovfx2 driver.
Quoted 1 line
Did you make any functional changes?
I believe the ovfx2 driver is completely new.
Quoted 3 lines
Also I wonder if you're subscribed to the (low trafic) ov51x-jpeg mailinglist, that seems to be the right thing todo for someone who tries to get that driver in to the mainline.
Sorry its the ovfx2 that I'm interested in pushing into the kernel.
Quoted 2 lines
May I ask what cam you have? I could certainly use more people testing this.
It looks like this on the USB bus:
Bus 007 Device 002: ID 05a9:2800 OmniVision Technologies, Inc.
Cheers,
Erik
Signature · 13 lines
======================= erik de castro lopo senior design engineer bCODE level 2, 2a glen street milsons point sydney nsw 2061 australia tel +61 (0)2 9954 4411 fax +61 (0)2 9954 4422 www.bcode.com
Hi,
Quoted 8 lines · Erik de Castro Lopo
Quoted 2 lines · Hans de Goede
This looks to me like its just ov51x-jpeg made to compile with the latest kernel.
Its more than that. This driver supports a number of cameras and the only one we (bCODE) are really interested in is the ovfx2 driver.
Ah, I hadn't noticed the ovfx2 driver, actually I've never heard of it before.
Quoted 4 lines
Quoted 1 line
Did you make any functional changes?
I believe the ovfx2 driver is completely new.
It is atleast to me and I know lots of webcam drivers.
Quoted 6 lines
Quoted 3 lines
Also I wonder if you're subscribed to the (low trafic) ov51x-jpeg mailinglist, that seems to be the right thing todo for someone who tries to get that driver in to the mainline.
Sorry its the ovfx2 that I'm interested in pushing into the kernel.
Ok,
Getting ovfx2 support into the mainline kernel sounds like a good idea!
I'm not such a big fan of merging the driver as is though, as it does its own buffer management (and ioctl handling, usb interrupt handling, locking, etc).
Now a days we prefer for new drivers to use existing infrastructure.
Preferably the ovfx2 driver would be re-written to use the gspca usb webcam driver framework. See for example the ov519 driver:drivers/media/video/gspca/ov519.c
Which is also based on ov51x-jpeg. There are also several bulk mode using drivers under drivers/media/video/gspca
As you will see when you look here, gspca sub drivers currently do not have the sensor code separated from the bridge :( There are several reasons for this, the biggest one being that most drivers are reverse engineered and we simply do not know enough about what all the sensor registers do, to cleanly separate bridge and sensor code.
Another reason is that quite a few sensor settings can be quite bridge
specific, for example vsync / hsync timing which seems quite sane may
not work with some bridges, because the require some strange timings,
another example is that registers which are meant to adjust the
framerate to match the powernet frequency, are sometimes abused to
correct for a somewhat strange clock being offer to the sensor by the bridge, etc. So doing the bridge sensor separation cleanly is far from easy, and for now we've given up doing this for webcams, esp. as just
getting webcams to work and working properly has a higher priority atm.
Once we have most cams working we can better analyze which sensor settings are the same for all bridges and which are bridge specific and find a why to separate the sensor and bridge code.
For adding the ovfx2 driver, you could start by copying ov519.c, which
already has setup and control code fro most ov sensors and then rewrite
the bridge part to be ovfx2 code, then later we can try to move the sensor code to a shared c file for the ov519 and ovfx2 driver, depending on how much you needed to change the sensor code. Or you could add
support for the ovfx2 to the ov519 driver.
Note I've recently being doing quite a bit of work on the ov519 driver, adding support for the ov511 and ov518 and adding more controls. I'll make a mercurial tree available with my latest code in it asap.
Regards,
Hans
Quoted 5 lines · On Sat, 13 Jun 2009 18:12:10 +1000 Hans de Goede <[email protected]> wrote:
Getting ovfx2 support into the mainline kernel sounds like a good idea!
I'm not such a big fan of merging the driver as is though, as it does its own buffer management (and ioctl handling, usb interrupt handling, locking, etc).
I understand completely.
Quoted 10 lines
For adding the ovfx2 driver, you could start by copying
ov519.c, which already has setup and control code fro most ov sensors and then rewrite the bridge part to be ovfx2 code, then later we can try to move the sensor code to a shared c file for the ov519 and ovfx2 driver, depending on how much you needed to change the sensor code. Or you could add support for the ovfx2 to the ov519 driver.Note I've recently being doing quite a bit of work on the ov519 driver, adding support for the ov511 and ov518 and adding more controls. I'll make a mercurial tree available with my latest code in it asap.
Ok, there's the rub. I am simply way too busy at the moment to push this through myself.
I was hoping I could contract someone to take the existing code and massage it into shape ready for merging. I would prefer it if that someone was already a V4L hacker, but if I can't find anyone with pre-existing V4L experience I'll find someone local with general Linux kernel/driver experience.
Cheers,
Erik
Signature · 13 lines
======================= erik de castro lopo senior design engineer bCODE level 2, 2a glen street milsons point sydney nsw 2061 australia tel +61 (0)2 9954 4411 fax +61 (0)2 9954 4422 www.bcode.com
Quoted 11 lines · Erik de Castro Lopo
Quoted 5 lines · On Sat, 13 Jun 2009 18:12:10 +1000 Hans de Goede<[email protected]> wrote:
Getting ovfx2 support into the mainline kernel sounds like a good idea!
I'm not such a big fan of merging the driver as is though, as it does its own buffer management (and ioctl handling, usb interrupt handling, locking, etc).
I understand completely.
Good!
Quoted 11 lines
Quoted 10 lines
For adding the ovfx2 driver, you could start by copying
ov519.c, which already has setup and control code fro most ov sensors and then rewrite the bridge part to be ovfx2 code, then later we can try to move the sensor code to a shared c file for the ov519 and ovfx2 driver, depending on how much you needed to change the sensor code. Or you could add support for the ovfx2 to the ov519 driver.Note I've recently being doing quite a bit of work on the ov519 driver, adding support for the ov511 and ov518 and adding more controls. I'll make a mercurial tree available with my latest code in it asap.
Quoted 9 lines
Ok, there's the rub. I am simply way too busy at the moment to push this through myself.
I was hoping I could contract someone to take the existing code and massage it into shape ready for merging. I would prefer it if that someone was already a V4L hacker, but if I can't find anyone with pre-existing V4L experience I'll find someone local with general Linux kernel/driver experience.
Well I can't offer you contracting, as I simply do not have the spare time to make such promises, but as any good hacker: "will work for hardware" on a I'll do my best but no promises made basis.
I'm actually spending quite a bit of time lately on v4l stuff again, and I'm sure willing to spend some time on this. I can even promise you I'll bump it to the top of the list of my v4l projects.
For a general idea how deep I'm involved in v4l webcam support see:
https://fedoraproject.org/wiki/Features/BetterWebcamSupport
Regards,
Hans
Hi Erik,
For the latest version of the gspca ov519 driver, with all me recent work for adding ov511 and ov518 support in it see:
http://linuxtv.org/hg/~hgoede/gspca
Regards,
Hans
Quoted 27 lines · Erik de Castro Lopo
Quoted 2 lines · Hans de Goede
This looks to me like its just ov51x-jpeg made to compile with the latest kernel.
Its more than that. This driver supports a number of cameras and the only one we (bCODE) are really interested in is the ovfx2 driver.
Quoted 1 line
Did you make any functional changes?
I believe the ovfx2 driver is completely new.
Quoted 3 lines
Also I wonder if you're subscribed to the (low trafic) ov51x-jpeg mailinglist, that seems to be the right thing todo for someone who tries to get that driver in to the mainline.
Sorry its the ovfx2 that I'm interested in pushing into the kernel.
Quoted 2 lines
May I ask what cam you have? I could certainly use more people testing this.
It looks like this on the USB bus:
Bus 007 Device 002: ID 05a9:2800 OmniVision Technologies, Inc.Cheers,
Erik