Future direction of driver

[sbertin@mindspring.com]

I'm going to renumber your priorities a little bit to better address
them below.

On  9 Sep, Jarl Totland wrote:
1A
> 1) Adopt the new filestructure and modulestructure,

1B
> make the cpia_pp right.
> This includes the hard stuff (IRQ/DMA). Don't bother too much with pre-ECP
> capabilities for now, or tuning, or avoiding duplicating kernel code,
> delegate that to the rest of us.

> 2) Port the USB driver to cpia_usb. This is relatively straightforward,
> basically just removing the V4L already in place there. The pp clients
> should accept cpia_usb as a dropin replacement for cpia_pp.
> 3) Start doing the V4L layer.  There is some code for this in the USB
> driver. Personally, I'd prefer V4L2, maybe simply basing it on V4L2's
> excellent sample capture driver source. Though as V4L2 is obviously not
> getting into 2.4, we're probably best off doing a V4L layer.

About 3:
	I personally think this should be #1.  All the lower stuff is working,
maybe not optimally, but working anyway.  The v4l layer is the only one
with zero functionality yet.
	I've looked briefly at v4l and v4l2, and I also prefer v4l2, but
the reality is that v4l is what people will have in the kernel during
the next 6 months.  If we have a complete driver in 3 months, requiring
users to patch the kernel to get v4l2 is unrealistic.

About 1A:
	I was thinking of a more incremental approach, but if you think
it's that important, I'm willing to take responsibility for this and
put together the new structure now.  There are some design issues I
haven't fully thought out yet.  For example, it may be useful to make
the pp and usb modules even more generic and usable by multiple higher
level modules simultaneously.  This would be useful, for example, when
new cameras come out that use the same communication methods, but
different message sets.  I should be able to have an initial
implementation available in about 2-3 weeks.  Please, nobody put off
doing some work on the driver for this.  I'll incorporate all changes
in the new structure before I release it.

About 1B:
	You didn't think I was volunteering to do all the work myself,
did you? :)
	I agree that the highest performance mode is where effort should
be spent right now, but I also think it is important to eventually
support other modes of operation.
	Some of the "hard stuff" won't really be that hard.  Looking at
the new ieee1284 code in the 2.3 kernels should be helpful.  This
actually brings up another point.  More standard kernel routines are
available in the 2.3 kernels that could make the low level code easier.
I would expect a low level pp module for the 2.3 kernel would be
significantly different from the same module for the 2.2 kernel.  How
much effort should be devoted to 2.2 vs 2.3?  I don't have a strong
opinion about this, but it should be addressed.

About 2:
	Are you volunteering?  This should probably wait until after 1A
is done.

Scott J. Bertin
sbertin@mindspring.com


-----------------------------------------------------------------------------
To unsubscribe from this mailinglist, send the line "unsubscribe vision-webcam" in the
body of a message to "majordomo@errors.no".