GNOME Bugzilla – Bug 654675
gegl:v4l operation does not support V4L2
Last modified: 2017-04-28 13:04:45 UTC
Using a git clone of gegl, configure.ac looks for linux/videodev.h so that V4L can be enabled. I have a 2.6.39 linux kernel and there isn't a videodev.h file. There is a videodev2.h file though. The severity of this is minor to me because I don't need this functionality. I see a note (using 'git log') from 21May2008 about 'Fix a problem when building on a Mac' That was when the check for linux/videodev.h was added.
Created attachment 194608 [details] [review] Gegl-patch for v4l support in newer kernel-versions.
It seems that newer kernel-versions (from 2.6.35 on or so) have dropped the videodev.h file, replacing it by videodev2.h. I yesterday came across this problem myself and have made a patch for gegl to support the compatibility layer library libv4l1. In order to use this functionality, you need to make sure, whether the library and the belonging libv4l1-videodev.h exists on your system. The library can be installed from the official ubuntu-repository (package named "libv4l-dev" in 11.04), from the official fedora-repository (package named "libv4l-devel" in F15). I guess there are packages for this library in most other distributions as well, alternatively you can download the source-code from here: http://linuxtv.org/downloads/v4l-utils/ (Actually, I tried using version 0.8.3). However, the so supplied libv4l1-videodev.h file lacks of some declarations that have been present in the original videodev.h file. (Namely the 'video_capture' and 'video_unit' struct-declarations as well as the 'VIDIOCGCAPTURE' macro-definition. After some googling I found a compatibility header file in the "cinelerra" community-repository at some older svn-revisions, although it has been removed in the meantime from the current revisions of cinelerra. Yet, the mentioned file is practically identical to the libv4l1-videodev.h file, extended just by the missing lines. So therefore my patch adjusts the files in the gegl-tree and supplies the cinelerra-extended version of the videodev header named "libv4l1-videodev.gegl.h". After applying the patch, gegl compiled perfectly with the v4l-support, and a quick test using my built-in notebook-webcam didn't show any problems with the v4l support.
Thanks for the patch! v4l(1) is considered to be deprecated, and the support was essentially dropped in 2.6.38. It would be much better if we simply ported the code to use v4l2, which is available on all recent (2.6) kernels. Would you be interested in doing that?
Sure! BUT, i have got so much work to do at the moment, including my own projects; I cannot give you any reliable date until I could finish this task. And as far as I understand, Gegl and the Gimp-project are under a high time preassure..?
I really think moving to v4l2 is the right (and only long-term) solution. Changing description to reflect this. There is no big time pressure for this specific bug. It would be preferable to have it in time for the next release, of course. That is probably a couple of months away.
Ok, I'll give it a try! :-)
Review of attachment 194608 [details] [review]: As discussed in bugreport, moving to v4l2 is the right solution.
Jon, I've been working on that issue for a couple of days now and came to the conclusion that it probably makes the most sense to use the v4l2 implementation as shipped in kernel 3.1. Therefore I would propose to include a kernel version switch which handles the incompatibility by the patch I submitted initially [ http://bugzilla-attachments.gnome.org/attachment.cgi?id=194608 ] with this bug for kernel < 3.1 && kernel > 2.6.36. Is that in the sense of the GIMP development guide-lines or do you prefer a complete change that is backward compatible to kernel releases from 2.6.36?
Created attachment 231536 [details] [review] Update autoconf for linux v4l2 Autoconf support for v4l2. v4l2 support patch 1 of 2. Please apply using git apply.
I've got a much more surgical patch to move to v4l2, consisting of two small diffs. Hopefully these will be found more pleasing. This work was done in the course of building SprezzOS 1.0.0. 0001-v4l-use-pkg-config-to-look-for-v4l2.patch updates the autoconf script to look for videodev2.h. this seems trivially correct. 0002-v4l-use-a-non-ancient-v4l-implementation.patch updates the various structures and calls. everything is pretty trivially correct except that we lose the "flags" argument to subcropping. this field has migrated to a different structure entirely, and can't really be smoothly integrated with the current API. i get the idea that this parameter probably wasn't being widely used, anyway, looking at callers of GEGL in the wild (and given that it's been broken for years). With these two patches, v4l is detected and successfully built on my SprezzOS turing, Linux 3.7.0 box. Please apply.
Created attachment 231537 [details] [review] Support v4l2 in GEGL V4L2 support, patch 2 of 2. Please apply using "git apply".
Created attachment 231538 [details] [review] autoconf support for libv4l check via pkg-config Ahhh, the header I used to get the old-style constants comes from libv4l. So here's autoconf support for checking for libv4l via pkg-config. We probably want to grab pkg-config's --cflags and --libs output, as well, though IIRC the PKG_CONFIG macro already handles that. I've not tested as much. Patch 3 of 2. :)
Wouldn't it be better to move away from the v4l1-compatibility layer? As far as I can see, you also include "libv4l1-videodev.h"? ----- snip ----- @@ -25,7 +26,8 @@ #define __V4LUTILS_H__ #include <sys/types.h> -#include <linux/videodev.h> +#include <linux/videodev2.h> +#include <libv4l1-videodev.h> #include <pthread.h> ----- snip -----
yeah, the third patch addresses that. if the library isn't installed, it's not a hard autoconf failure (arguably, it should be if --with-v4l2 has been explicitly supplied). the library's packaged in all major distros and has full pkg-config support. moving away from the compatibility layer is a noble goal, but a more distant one. these patches are surgical, indeed likely minimal, means to compile the v4l plugin. if they're not applied, i don't really understand the point of keeping v4l2 in the tree. future directions for gegl are best discussed with the project leaders. aside from depending on libv4l2 (which will be a dependency of any v4l2 plugin solution that doesn't reinvent libv4l2), these 3 patches make no move but the minimum necessary to work. had gegl have been based around libv4l1 in the first place, there would have been a natural upgrade path. as stands, this has been broken for years. thanks!
Any news on this? Any chance to have these patches in the next release?
Better late than never, the lack of a [PATCH] in title of bug meant that this bug got ignored on my previous hunts for bugs with patches ready to be pushed and committed. commit 69e4a0960e2fe0067e4f6ef1330fdc4ed3e88c5f Author: nick black <nick.black@sprezzatech.com> Date: Fri Dec 14 00:30:44 2012 -0500 add autoconf check for libv4l2 commit 798f9f51ab73692f6fed21c082f693dba0783103 Author: nick black <nick.black@sprezzatech.com> Date: Thu Dec 13 23:51:18 2012 -0500 use a non-ancient v4l implementation commit 43dd7848db189d2dfc9093a0ab2cc6f049c7dfdb Author: nick black <nick.black@sprezzatech.com> Date: Thu Dec 13 23:42:46 2012 -0500 use pkg-config to look for v4l2