The biggest question in my mind is should there be structural changes to videodevX? I think there were roughly three possibilities: 1. videodevX does bare minimum, little beyond doling out minors. Drivers export a regular fops that is called directly (except for open()) by the kernel. 2. Drivers export a regular fops interface, but all calls go through videodevX first. videodevX does more, like moving ioctl parameters from/to user memory to/from kernel memory 3. Drivers export a designed-for-V4L2 interface, all calls go through videodevX, and as much boilerplate code as makes sense is done by videodevX What's most Linux-like? -- Here are my TO-DO's briefly: + videodevX design philosophy? + using user-space buffers for streaming capture + multiple tuners (I think the only problem here is that VIDIOC_*_FREQ doesn't spec which tuner. there is a struct v4l2_frequency that was never used. we can change VIDIOC_*_FREQ or make a new ioctl) + design /proc filesystem support + multiple capturing opens spec + interruptible streams (e.g. one program watching video, other catching CC data; first program switches channel/input/etc. so no more CC; second program is notified that CC stream has ended) + add two-plane Y/CbCr pixel formats + audio capture API + fixes for kernel internal changes in 2.5.x? Bill.
