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