Development: Discussion of Video4Linux API Version 3: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
mNo edit summary
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
# 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.
and /dev/radio. The main problem with it is in simultaneous work of
# 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).
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:10, 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.

  1. 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.
  2. Userspace program should be able to select cards and tuners and so on, no need to keep cards database in kernel.
  3. 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.