GPL code for Omnivision USB video camera available.

GPL code for Omnivision USB video camera available.

[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:

    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
-- 
=======================
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

Re: GPL code for Omnivision USB video camera available.

[Hans de Goede]

On 06/12/2009 03:02 AM, Erik de Castro Lopo wrote:
> 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.
>

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

Re: GPL code for Omnivision USB video camera available.

[Erik de Castro Lopo]

Hans de Goede wrote:

> 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.

> Did you make any functional changes?

I believe the ovfx2 driver is completely new.

> 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.

> 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
-- 
=======================
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

Re: GPL code for Omnivision USB video camera available.

[Hans de Goede]

Hi,

On 06/13/2009 02:45 AM, Erik de Castro Lopo wrote:
> Hans de Goede wrote:
>
>> 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.

>> 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.


>> 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

Re: GPL code for Omnivision USB video camera available.

[Hans de Goede]

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


On 06/13/2009 02:45 AM, Erik de Castro Lopo wrote:
> Hans de Goede wrote:
>
>> 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.
>
>> Did you make any functional changes?
>
> I believe the ovfx2 driver is completely new.
>
>> 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.
>
>> 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

Re: GPL code for Omnivision USB video camera available.

[Erik de Castro Lopo]

On Sat, 13 Jun 2009 18:12:10 +1000
Hans de Goede <hdegoede@redhat.com> 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.

> 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
-- 
=======================
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

Re: GPL code for Omnivision USB video camera available.

[Hans de Goede]

On 06/15/2009 03:01 AM, Erik de Castro Lopo wrote:
> On Sat, 13 Jun 2009 18:12:10 +1000
> Hans de Goede<hdegoede@redhat.com>  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!

>> 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.
>

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