|
Size: 1712
Comment:
|
Size: 2391
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 10: | Line 10: |
The most likely course of action for adding V4L/DVB support to the cx88 driver stack is to have the kernel drivers create additional devices that conform to V4L/DVB naming conventions, and then process V4L/DVB ioctls on these devices. Those ioctls that can be handled entirely in kernel mode, such as buffer control ioctls, will be translated directly into calls to the underlying cx88 hardware control routines. Tuning and peripheral control ioctls will more than likely need to be bounced to userspace daemon which will interact with userspace driver frameworks like [[http://www.freshports.org/multimedia/libtuner|libtuner]] to perform the necessary frontend operations. |
V4L/DVB support
Video4Linux(V4L) and it's associated digital video API (DVB) are the de facto open-source audio/video capture frameworks. Most popular recording applications (e.g. MythTV and Freevo) are designed around these APIs, and many other applications, such as VLC, provide specialized features that can talk directly to V4L/DVB-compliant devices. Therefore, it would be beneficial to add V4L/DVB API support to the cx88 drivers so that all of these applications could (hopefully) "just work".
Unfortunately, this isn't a straightforward task. While V4L/DVB are reasonably flexible APIs, they do make one big assumption that isn't necessarily compatible with modern driver design--they are entirely ioctl(2) based. This essentially requires a kernel presence for every V4L/DVB-compliant driver, even though some drivers (such as those for simple USB video devices) could otherwise be implemented entirely in userspace. The cx88 driver is a hybrid, in that it requires a kernel presence for hardware protection, register access, DMA control, and interrupt processing, but all peripheral control is performed in userspace. Moving highly-variable and non-performance-critical components like these to userspace seems to be the way forward, for reasons such as the following:
- Reduced kernel bloat
- Increased reliability (think segfault vs. kernel panic)
- Increased programming flexibility (for example, the ability to do floating-point calculations for things like tuner signal-to-noise ratio)
- Lower barriers to entry for contributors--familiarity with kernel driver design principles and restrictions is not necessary
The most likely course of action for adding V4L/DVB support to the cx88 driver stack is to have the kernel drivers create additional devices that conform to V4L/DVB naming conventions, and then process V4L/DVB ioctls on these devices. Those ioctls that can be handled entirely in kernel mode, such as buffer control ioctls, will be translated directly into calls to the underlying cx88 hardware control routines. Tuning and peripheral control ioctls will more than likely need to be bounced to userspace daemon which will interact with userspace driver frameworks like libtuner to perform the necessary frontend operations.