Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Hans de Goede wrote: > Hi, > > On 03/22/2010 09:11 AM, Hans Verkuil wrote: >> On Sunday 21 March 2010 00:14:25 Hans de Goede wrote: >>> Hi, >>> >>> On 03/20/2010 10:21 AM, Hans Verkuil wrote: Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. >>> >>> Yes it can, this for example already happens when using v4l1 apps with >>> uvcvideo (which is not possible without libv4l1). >> >> In what way does libv4l1 still depend on the kernel's v4l1 compat layer? > > It depends on some of the ioctl compatibility stuff, which lives in > drivers/media/video/v4l1-compat.c > > Basically it depends on: > > v4l_compat_translate_ioctl() > > From that file and on what that depends on in turn. Note that it does not > depend on v4l_compat_translate_ioctl() for all ioctl's. It handles > some of them in its own, see: > lib/libv4l1/libv4l1.c > > In v4l-utils git, specifically the v4l1_ioctl() function. Note that simply > checking which one are listed in the switch case is not enough to determine > which ones are already handled by libv4l, some still call > v4l_compat_translate_ioctl() (by doing the v4l1 ioctl) and then munge the > results. > > Currently it is mainly targeted and tested with webcam using apps, so no > overlay, input switching, vbi or tuning support. Probably no radio. Radio is not that different from tuning, but, as radio uses tuning on a different way (it needs only a subset of ioctl's), you may see troubles on radio applications with V4L1 even when the driver works with TV with V4L1. We had this issue when ported the radio drivers from V4L1 to V4L2: we had to implement some dummy V4L2 ioctls, for the V4L1 compat logic to work. > Adding input switching, vbi and tuning support, should be easy I think. > Overlay has me worried as the v4l1 API does not clearly separate between > overlay and capture. Since overlay does not really work out of the box > on any distro's anyways (in my experience), I think the best thing to > do would be to just hide the overlay capability for v4l1 apps. The last time I tested overlay, it worked perfectly. You need to be sure that you're not running it on a machine with Via or Sys chipsets, as those chips have bugs with pci2pci data transfers, so the PCI quirk code disables overlay with broken north bridge chipsets. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Hans Verkuil wrote: > On Sunday 21 March 2010 00:14:25 Hans de Goede wrote: >> Yes it can, this for example already happens when using v4l1 apps with >> uvcvideo (which is not possible without libv4l1). > > In what way does libv4l1 still depend on the kernel's v4l1 compat layer? And > what is needed to remove that dependency? > > Because I think that that is the best approach. Agreed. After being sure that it will properly work with all types of app (e. g. radio/vbi/tv/stream/record/..), we can add a features removal patch announcing that the backport got moved to userspace and it will be removed from kernel. > >>> The third phase that can be done in parallel is to convert V4L1-only apps. >>> I strongly suspect that any apps that are V4L1-only are also unmaintained. >>> We have discussed before that we should set up git repositories for such >>> tools (xawtv being one of the more prominent apps since it contains several >>> v4l1-only console apps). Once we have maintainership, then we can convert >>> these tools to v4l2 and distros and other interested parties have a place >>> to send patches to. >>> >> As said before I wouldn't mind maintaining an xawtv git tree @ linuxtv, >> assuming this tree were to be based on the 3.95 release. > > Mauro, do you have any objection to hosting xawtv on linuxtv? We may need > another tree later as well if we decide to split off the xawtv console tools > into a separate tree. But perhaps they would fit under v4l-utils as well, > we'll have to see. Not at all. Feel free to add a git tree to all applications you want. If you have problems, please ping me. After creating the tree(s), just send me an email with the name of the maintainer(s) and I'll move them to the right place, enabling the announcement hooks if needed. If possible, please get the old maintainer's ack. With respect to the announcements, we're currently using the same mailing list (linuxtv-comm...@linuxtv.org) for all sorts of announcement: dvb-apps, v4l-utils, v4l-dvb.git, fixes.git v4l-dvb(hg). If we're starting to populate the server with other trees, it may be a good idea to split the ML into groups, or eventually into per-tree list. Comments? -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Hi, On 03/22/2010 09:11 AM, Hans Verkuil wrote: On Sunday 21 March 2010 00:14:25 Hans de Goede wrote: Hi, On 03/20/2010 10:21 AM, Hans Verkuil wrote: Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. Yes it can, this for example already happens when using v4l1 apps with uvcvideo (which is not possible without libv4l1). In what way does libv4l1 still depend on the kernel's v4l1 compat layer? It depends on some of the ioctl compatibility stuff, which lives in drivers/media/video/v4l1-compat.c Basically it depends on: v4l_compat_translate_ioctl() From that file and on what that depends on in turn. Note that it does not depend on v4l_compat_translate_ioctl() for all ioctl's. It handles some of them in its own, see: lib/libv4l1/libv4l1.c In v4l-utils git, specifically the v4l1_ioctl() function. Note that simply checking which one are listed in the switch case is not enough to determine which ones are already handled by libv4l, some still call v4l_compat_translate_ioctl() (by doing the v4l1 ioctl) and then munge the results. Currently it is mainly targeted and tested with webcam using apps, so no overlay, input switching, vbi or tuning support. Adding input switching, vbi and tuning support, should be easy I think. Overlay has me worried as the v4l1 API does not clearly separate between overlay and capture. Since overlay does not really work out of the box on any distro's anyways (in my experience), I think the best thing to do would be to just hide the overlay capability for v4l1 apps. Note that the default: case which passes the ioctl through to libv4l2, will end up passing v4l1 ioctl's to the kernel, as libv4l2 will pass unknown ioctl's to the kernel unmodified. > And what is needed to remove that dependency? Someone to: - add emulation of the not yet emulated ioctl's; and - remove the limits of not working on complex devices, see libv4l1.c line 295 (in v4l1_open, marked IMPROVEME */; and - remove the dependency of some already emulated ioctl's on the the kernels v4l_compat_translate_ioctl(), for example the VIDIOCGCAP emulation calls the kernel, then overrides some results. Note that all emulation needs to be re-implemented, not copied from the kernel as the kernel is GPLv2 and libv4l1 LGPLv2+, an alternative approach would be to find out who holds the copyrights and ask them for permission. Because I think that that is the best approach. Ack. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
On Sunday 21 March 2010 00:14:25 Hans de Goede wrote: > Hi, > > On 03/20/2010 10:21 AM, Hans Verkuil wrote: > > Hi all! > > > > The second phase that needs to be done to remove the v4l1 support from the > > kernel is that libv4l1 should replace the v4l1-compat code from the kernel. > > > > I do not know how complete the libv4l1 code is right now. I would like to > > know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in > > libv4l1 if drivers do not support the cgmbuf vidioc call. > > > > Yes it can, this for example already happens when using v4l1 apps with > uvcvideo (which is not possible without libv4l1). In what way does libv4l1 still depend on the kernel's v4l1 compat layer? And what is needed to remove that dependency? Because I think that that is the best approach. > > The third phase that can be done in parallel is to convert V4L1-only apps. > > I strongly suspect that any apps that are V4L1-only are also unmaintained. > > We have discussed before that we should set up git repositories for such > > tools (xawtv being one of the more prominent apps since it contains several > > v4l1-only console apps). Once we have maintainership, then we can convert > > these tools to v4l2 and distros and other interested parties have a place > > to send patches to. > > > > As said before I wouldn't mind maintaining an xawtv git tree @ linuxtv, > assuming this tree were to be based on the 3.95 release. Mauro, do you have any objection to hosting xawtv on linuxtv? We may need another tree later as well if we decide to split off the xawtv console tools into a separate tree. But perhaps they would fit under v4l-utils as well, we'll have to see. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Hi, On 03/20/2010 10:21 AM, Hans Verkuil wrote: Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. Yes it can, this for example already happens when using v4l1 apps with uvcvideo (which is not possible without libv4l1). The third phase that can be done in parallel is to convert V4L1-only apps. I strongly suspect that any apps that are V4L1-only are also unmaintained. We have discussed before that we should set up git repositories for such tools (xawtv being one of the more prominent apps since it contains several v4l1-only console apps). Once we have maintainership, then we can convert these tools to v4l2 and distros and other interested parties have a place to send patches to. As said before I wouldn't mind maintaining an xawtv git tree @ linuxtv, assuming this tree were to be based on the 3.95 release. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
On Saturday 20 March 2010 17:14:12 Devin Heitmueller wrote: > On Sat, Mar 20, 2010 at 10:14 AM, Hans Verkuil wrote: > > Of course, the best solution is to convert the V4L1 apps to using V4L2. > > On that topic, if I wanted to ensure that an application was not using > any V4L1 functionality, is there any easy way to do that? For > example, can I just remove the #include "videodev.h" and fix whatever > breaks? That should do the trick, yes. Regards, Hans > Right now a problem is that there could easily be situations where an > app uses V4L1 functionality without my knowledge, and it would be good > if there were an easy way to audit the app and make sure it is doing > V4L2 entirely (in fact, I had this issue in a few places with tvtime). > > Devin > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
On Sat, Mar 20, 2010 at 10:14 AM, Hans Verkuil wrote: > Of course, the best solution is to convert the V4L1 apps to using V4L2. On that topic, if I wanted to ensure that an application was not using any V4L1 functionality, is there any easy way to do that? For example, can I just remove the #include "videodev.h" and fix whatever breaks? Right now a problem is that there could easily be situations where an app uses V4L1 functionality without my knowledge, and it would be good if there were an easy way to audit the app and make sure it is doing V4L2 entirely (in fact, I had this issue in a few places with tvtime). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
On Saturday 20 March 2010 14:51:44 Chicken Shack wrote: > Am Samstag, den 20.03.2010, 13:37 +0100 schrieb Hans Verkuil: > > On Saturday 20 March 2010 13:17:15 Chicken Shack wrote: > > > Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil: > > > > Hi all! > > > > > > > > The second phase that needs to be done to remove the v4l1 support from > > > > the > > > > kernel is that libv4l1 should replace the v4l1-compat code from the > > > > kernel. > > > > > > > > I do not know how complete the libv4l1 code is right now. I would like > > > > to > > > > know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in > > > > libv4l1 if drivers do not support the cgmbuf vidioc call. > > > > > > > > In principle libv4l1 should allow V4L1 apps to run fine with V4L2 > > > > drivers. > > > > That will also solve the problem of embedded device vendors running new > > > > kernels with old V4L1 applications. They just need to use libv4l1. > > > > > > > > The third phase that can be done in parallel is to convert V4L1-only > > > > apps. > > > > I strongly suspect that any apps that are V4L1-only are also > > > > unmaintained. > > > > We have discussed before that we should set up git repositories for such > > > > tools (xawtv being one of the more prominent apps since it contains > > > > several > > > > v4l1-only console apps). Once we have maintainership, then we can > > > > convert > > > > these tools to v4l2 and distros and other interested parties have a > > > > place > > > > to send patches to. > > > > > > > > I'm afraid that it is unlikely that anyone will do that work for us, so > > > > it's > > > > probably best just to bite the bullet and do it ourselves. > > > > > > > > Regards, > > > > > > > > Hans > > > > > > > > > > Hello Hans, > > > > > > I haven't followed your discussion so far (sorry!). > > > I got a trivial question: > > > > > > I run a Miro PCTV pro (stereo) on one of my machines. > > > It needs "simple tuner transport" / "TDA 9885/6/7 analog IF > > > demodulator", Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as > > > kernel options to run / to be usable at all. > > > > That's the V4L2 bttv driver. What app are you using with this card? > > Should rather be: > What apps are you using (Plural mode)? > > One big mess somehow. > > 1. The only one that runs is tvtime. But with tvtime I cannot record > streams. > 2. Then I have tested zapping, which is a gnome app. > No matter if I start it without parameters or with parameter > LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so (it's a Debian system), channel > switching is simply impossible. Version is 0.10cvs6. zapping is definitely V4L2 aware. Make sure it is not trying to use V4L1. > > Well, and the biggest pest are the radio apps: > 1. Running gnomeradio the channel scanner does not find anything and I > cannot hear anything (independent from starting mode - with or without > parameters). Which gnomeradio version are you using? 1.8 seems to support V4L2. Again, make sure it isn't selecting V4L1 instead of V4L2. > 2. Maybe Gerd's "radio" solves it, but in that case recording is > unclear, as it is a rather primitive GUI without recording function > implied. > > > > > > > Can you make sure that this card will still be usable after your v4l1 > > > removal activities are finished? > > > > You can easily test this by turning off the compat layer in the kernel > > config. You should still be able to use your v4l1 app by using > > LD_PRELOAD=/usr/lib/v4l1compat.so. > > Hmmm. See above. If I used the parametry in a wrong way please tell me. > > > > In other words: What happens to this v4l1 compat code which is obviously > > > necessary for this (and other) card(s) to run? > > > > > > That's it what I haven't understood right now, so could you please be > > > kind enough to explain that with a couple of words? > > > > > > Thanks! > > > > > > CS > > > > > > P. S.: If you make your decision to host xawtv and other apps please do > > > not merge hybrid applications (i. e. apps made for DVB and analogue > > > devices) as you can find them in the xawtv 4.0 pre alpha code for > > > example in analogue trees. > > > Rather establish extra trees for hybrid applications please. > > > > These apps will each get their own tree. > > > > Regards, > > > > Hans > > This sounds excellent :) > > Best Regards > > Uwe > > P. S.: So if I take you right the kernel compat module function does not > hit or point to the driver itself, but rather to the application layer? > Not easy to anticipate this as a picture in my head.. The driver is V4L2, but the kernel compat layer can translate V4L1 calls to V4L2 calls. The libv4l1compat can do the same, but now in userspace instead of kernelspace. What I don't really know is whether libv4l1compat can completely replace the kernel compat layer. Of course, the best solution is to convert the V4L1 apps to using V4L2. Note that it would be useful if you can try to
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Am Samstag, den 20.03.2010, 13:37 +0100 schrieb Hans Verkuil: > On Saturday 20 March 2010 13:17:15 Chicken Shack wrote: > > Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil: > > > Hi all! > > > > > > The second phase that needs to be done to remove the v4l1 support from the > > > kernel is that libv4l1 should replace the v4l1-compat code from the > > > kernel. > > > > > > I do not know how complete the libv4l1 code is right now. I would like to > > > know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in > > > libv4l1 if drivers do not support the cgmbuf vidioc call. > > > > > > In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers. > > > That will also solve the problem of embedded device vendors running new > > > kernels with old V4L1 applications. They just need to use libv4l1. > > > > > > The third phase that can be done in parallel is to convert V4L1-only apps. > > > I strongly suspect that any apps that are V4L1-only are also unmaintained. > > > We have discussed before that we should set up git repositories for such > > > tools (xawtv being one of the more prominent apps since it contains > > > several > > > v4l1-only console apps). Once we have maintainership, then we can convert > > > these tools to v4l2 and distros and other interested parties have a place > > > to send patches to. > > > > > > I'm afraid that it is unlikely that anyone will do that work for us, so > > > it's > > > probably best just to bite the bullet and do it ourselves. > > > > > > Regards, > > > > > > Hans > > > > > > > Hello Hans, > > > > I haven't followed your discussion so far (sorry!). > > I got a trivial question: > > > > I run a Miro PCTV pro (stereo) on one of my machines. > > It needs "simple tuner transport" / "TDA 9885/6/7 analog IF > > demodulator", Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as > > kernel options to run / to be usable at all. > > That's the V4L2 bttv driver. What app are you using with this card? Should rather be: What apps are you using (Plural mode)? One big mess somehow. 1. The only one that runs is tvtime. But with tvtime I cannot record streams. 2. Then I have tested zapping, which is a gnome app. No matter if I start it without parameters or with parameter LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so (it's a Debian system), channel switching is simply impossible. Version is 0.10cvs6. Well, and the biggest pest are the radio apps: 1. Running gnomeradio the channel scanner does not find anything and I cannot hear anything (independent from starting mode - with or without parameters). 2. Maybe Gerd's "radio" solves it, but in that case recording is unclear, as it is a rather primitive GUI without recording function implied. > > > > Can you make sure that this card will still be usable after your v4l1 > > removal activities are finished? > > You can easily test this by turning off the compat layer in the kernel > config. You should still be able to use your v4l1 app by using > LD_PRELOAD=/usr/lib/v4l1compat.so. Hmmm. See above. If I used the parametry in a wrong way please tell me. > > In other words: What happens to this v4l1 compat code which is obviously > > necessary for this (and other) card(s) to run? > > > > That's it what I haven't understood right now, so could you please be > > kind enough to explain that with a couple of words? > > > > Thanks! > > > > CS > > > > P. S.: If you make your decision to host xawtv and other apps please do > > not merge hybrid applications (i. e. apps made for DVB and analogue > > devices) as you can find them in the xawtv 4.0 pre alpha code for > > example in analogue trees. > > Rather establish extra trees for hybrid applications please. > > These apps will each get their own tree. > > Regards, > > Hans This sounds excellent :) Best Regards Uwe P. S.: So if I take you right the kernel compat module function does not hit or point to the driver itself, but rather to the application layer? Not easy to anticipate this as a picture in my head.. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
On Saturday 20 March 2010 13:17:15 Chicken Shack wrote: > Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil: > > Hi all! > > > > The second phase that needs to be done to remove the v4l1 support from the > > kernel is that libv4l1 should replace the v4l1-compat code from the kernel. > > > > I do not know how complete the libv4l1 code is right now. I would like to > > know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in > > libv4l1 if drivers do not support the cgmbuf vidioc call. > > > > In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers. > > That will also solve the problem of embedded device vendors running new > > kernels with old V4L1 applications. They just need to use libv4l1. > > > > The third phase that can be done in parallel is to convert V4L1-only apps. > > I strongly suspect that any apps that are V4L1-only are also unmaintained. > > We have discussed before that we should set up git repositories for such > > tools (xawtv being one of the more prominent apps since it contains several > > v4l1-only console apps). Once we have maintainership, then we can convert > > these tools to v4l2 and distros and other interested parties have a place > > to send patches to. > > > > I'm afraid that it is unlikely that anyone will do that work for us, so it's > > probably best just to bite the bullet and do it ourselves. > > > > Regards, > > > > Hans > > > > Hello Hans, > > I haven't followed your discussion so far (sorry!). > I got a trivial question: > > I run a Miro PCTV pro (stereo) on one of my machines. > It needs "simple tuner transport" / "TDA 9885/6/7 analog IF > demodulator", Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as > kernel options to run / to be usable at all. That's the V4L2 bttv driver. What app are you using with this card? > > Can you make sure that this card will still be usable after your v4l1 > removal activities are finished? You can easily test this by turning off the compat layer in the kernel config. You should still be able to use your v4l1 app by using LD_PRELOAD=/usr/lib/v4l1compat.so. > > In other words: What happens to this v4l1 compat code which is obviously > necessary for this (and other) card(s) to run? > > That's it what I haven't understood right now, so could you please be > kind enough to explain that with a couple of words? > > Thanks! > > CS > > P. S.: If you make your decision to host xawtv and other apps please do > not merge hybrid applications (i. e. apps made for DVB and analogue > devices) as you can find them in the xawtv 4.0 pre alpha code for > example in analogue trees. > Rather establish extra trees for hybrid applications please. These apps will each get their own tree. Regards, Hans > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil: > Hi all! > > The second phase that needs to be done to remove the v4l1 support from the > kernel is that libv4l1 should replace the v4l1-compat code from the kernel. > > I do not know how complete the libv4l1 code is right now. I would like to > know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in > libv4l1 if drivers do not support the cgmbuf vidioc call. > > In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers. > That will also solve the problem of embedded device vendors running new > kernels with old V4L1 applications. They just need to use libv4l1. > > The third phase that can be done in parallel is to convert V4L1-only apps. > I strongly suspect that any apps that are V4L1-only are also unmaintained. > We have discussed before that we should set up git repositories for such > tools (xawtv being one of the more prominent apps since it contains several > v4l1-only console apps). Once we have maintainership, then we can convert > these tools to v4l2 and distros and other interested parties have a place > to send patches to. > > I'm afraid that it is unlikely that anyone will do that work for us, so it's > probably best just to bite the bullet and do it ourselves. > > Regards, > > Hans > Hello Hans, I haven't followed your discussion so far (sorry!). I got a trivial question: I run a Miro PCTV pro (stereo) on one of my machines. It needs "simple tuner transport" / "TDA 9885/6/7 analog IF demodulator", Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as kernel options to run / to be usable at all. Can you make sure that this card will still be usable after your v4l1 removal activities are finished? In other words: What happens to this v4l1 compat code which is obviously necessary for this (and other) card(s) to run? That's it what I haven't understood right now, so could you please be kind enough to explain that with a couple of words? Thanks! CS P. S.: If you make your decision to host xawtv and other apps please do not merge hybrid applications (i. e. apps made for DVB and analogue devices) as you can find them in the xawtv 4.0 pre alpha code for example in analogue trees. Rather establish extra trees for hybrid applications please. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers. That will also solve the problem of embedded device vendors running new kernels with old V4L1 applications. They just need to use libv4l1. The third phase that can be done in parallel is to convert V4L1-only apps. I strongly suspect that any apps that are V4L1-only are also unmaintained. We have discussed before that we should set up git repositories for such tools (xawtv being one of the more prominent apps since it contains several v4l1-only console apps). Once we have maintainership, then we can convert these tools to v4l2 and distros and other interested parties have a place to send patches to. I'm afraid that it is unlikely that anyone will do that work for us, so it's probably best just to bite the bullet and do it ourselves. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
