Development: Discussion of Video4Linux API Version 3: Difference between revisions
Jump to navigation
Jump to search
m (fixed formatting for better visibility, including 800x600 screen resolutions) |
mNo edit summary |
||
| Line 4: | Line 4: | ||
on future development of v4l kernel API. |
on future development of v4l kernel API. |
||
#. We should not split control over video and radio on /dev/video |
|||
and /dev/radio. The main problem with it is in simultaneous work of |
|||
multiple video/radio programs - actually we have single device and |
|||
control over it should be collected in one place. |
|||
#. Userspace program should be able to select cards and tuners and so |
|||
on, no need to keep cards database in kernel. |
|||
#. Probably we need to provide some offical user-space library with |
|||
more intellectual and more natural programming interface (probably |
|||
with the ability to support several operation systems). |
|||
Everyone is welcome to add comments and extend this list. |
Everyone is welcome to add comments and extend this list. |
||
Revision as of 04:08, 9 January 2006
Although probably some days v4l and television will became obsolete at all, they will probably stay as radio stays for now. So we need to plan our future development. I've created a new wiki page with some thoughts on future development of v4l kernel API.
- . We should not split control over video and radio on /dev/video
and /dev/radio. The main problem with it is in simultaneous work of multiple video/radio programs - actually we have single device and control over it should be collected in one place.
- . Userspace program should be able to select cards and tuners and so
on, no need to keep cards database in kernel.
- . Probably we need to provide some offical user-space library with
more intellectual and more natural programming interface (probably with the ability to support several operation systems).
Everyone is welcome to add comments and extend this list.