What to do with videodev.h
Hi All,
With v4l1 support going completely away, the question is raised what to do with linux/videodev.h .
Since v4l1 apps can still use the old API through libv4l1, these apps will still need linux/videodev.h to compile.
So I see 3 options:
1) Keep videodev.h in the kernel tree even after we've dropped the API support at the kernel level (seems like a bad idea to me)
2) Copy videodev.h over to v4l-utils as is (under a different name) and modify the #include in libv4l1.h to include it under the new name
3) Copy the (needed) contents of videodev.h over to libv4l1.h
I'm not sure where I stand wrt 2 versus 3. Comments anyone?
Regards,
Hans
Hi Hans,
Em 26-01-2011 06:26, Hans de Goede escreveu:
Quoted 11 lines
Hi All,
With v4l1 support going completely away, the question is raised what to do with
linux/videodev.h.Since v4l1 apps can still use the old API through libv4l1, these apps will still need
linux/videodev.hto compile.So I see 3 options:
1) Keepvideodev.hin the kernel tree even after we've dropped the API support at the kernel level (seems like a bad idea to me)
That's a bad idea.
Quoted 4 lines
2) Copy
videodev.hover to v4l-utils as is (under a different name) and modify the #include inlibv4l1.hto include it under the new name
3) Copy the (needed) contents ofvideodev.hover tolibv4l1.h
I would do (3). This provides a clearer signal that V4L1-only apps need to use libv4l1, or otherwise will stop working.
Of course, the better is to remove V4L1 support from those old apps. There are a number of applications that support both API's. So, it is time to remove V4L1 support from them.
Quoted 1 line
I'm not sure where I stand wrt 2 versus 3. Comments anyone?
Cheers,
Mauro
Quoted 17 lines
Hi Hans,
Em 26-01-2011 06:26, Hans de Goede escreveu:
Quoted 11 lines
Hi All,
With v4l1 support going completely away, the question is raised what to do with
linux/videodev.h.Since v4l1 apps can still use the old API through libv4l1, these apps will still need
linux/videodev.hto compile.So I see 3 options:
1) Keepvideodev.hin the kernel tree even after we've dropped the API support at the kernel level (seems like a bad idea to me)That's a bad idea.
Quoted 7 lines
Quoted 4 lines
2) Copy
videodev.hover to v4l-utils as is (under a different name) and modify the #include inlibv4l1.hto include it under the new name
3) Copy the (needed) contents ofvideodev.hover tolibv4l1.hI would do (3). This provides a clearer signal that V4L1-only apps need to use libv4l1, or otherwise will stop working.
I agree with this.
Quoted 3 lines
Of course, the better is to remove V4L1 support from those old apps. There are a number of applications that support both API's. So, it is time to remove V4L1 support from them.
So who is going to do that work? That's the problem...
But ensuring that they no longer compile is a good start :-)
Although most have a private copy of videodev.h as part of their sources.
Regards,
Hans
Quoted 9 lines
Quoted 1 line
I'm not sure where I stand wrt 2 versus 3. Comments anyone?
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Hans Verkuil - video4linux developer - sponsored by Cisco
Em 26-01-2011 07:47, Hans Verkuil escreveu:
Quoted 31 lines
Quoted 17 lines
Hi Hans,
Em 26-01-2011 06:26, Hans de Goede escreveu:
Quoted 11 lines
Hi All,
With v4l1 support going completely away, the question is raised what to do with
linux/videodev.h.Since v4l1 apps can still use the old API through libv4l1, these apps will still need
linux/videodev.hto compile.So I see 3 options:
1) Keepvideodev.hin the kernel tree even after we've dropped the API support at the kernel level (seems like a bad idea to me)That's a bad idea.
Quoted 7 lines
Quoted 4 lines
2) Copy
videodev.hover to v4l-utils as is (under a different name) and modify the #include inlibv4l1.hto include it under the new name
3) Copy the (needed) contents ofvideodev.hover tolibv4l1.hI would do (3). This provides a clearer signal that V4L1-only apps need to use libv4l1, or otherwise will stop working.
I agree with this.
Quoted 3 lines
Of course, the better is to remove V4L1 support from those old apps. There are a number of applications that support both API's. So, it is time to remove V4L1 support from them.
Quoted 5 lines
So who is going to do that work? That's the problem...
But ensuring that they no longer compile is a good start :-)
Although most have a private copy of
videodev.has part of their sources.
The ones that don't have videodev.h will compile-break on distros. So distros will need to do something to keep it working, or they'll just drop those pre-historic beasts. It is the Evolution Theory working for software:
to adapt or to be extinguished ;)
The ones that are shipped with videodev.h and weren't converted to libv4l might eventually stay there for a longer time, as people will only notice when a bug will be reported. If we know what are those apps, then we can add a blacklist at linuxtv and/or contact interested parties on fixing/removing them.
We should touch the tools that we care of. Maybe Devin could change tvtime, we should remove V4L1 driver from xawtv3/xawtv4.
Regards,
Mauro
Quoted 2 lines · Mauro Carvalho Chehab
We should touch the tools that we care of. Maybe Devin could change tvtime, we should remove V4L1 driver from xawtv3/xawtv4.
Yeah, I have some tvtime work planned, and dropping v4l1 was definitely on the list. I actually dropped the private versions of videodev.h/videodev2.h from my repo, so I won't have much choice.
Devin
Signature · 2 lines
Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com