After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 654675 - gegl:v4l operation does not support V4L2
gegl:v4l operation does not support V4L2
Status: RESOLVED FIXED
Product: GEGL
Classification: Other
Component: operations
git master
Other Linux
: Normal minor
: Future
Assigned To: Default Gegl Component Owner
Default Gegl Component Owner
Depends on:
Blocks:
 
 
Reported: 2011-07-15 10:21 UTC by John D. Coleman
Modified: 2017-04-28 13:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Gegl-patch for v4l support in newer kernel-versions. (36.16 KB, patch)
2011-08-24 15:10 UTC, Tobias Vogel
rejected Details | Review
Update autoconf for linux v4l2 (728 bytes, patch)
2012-12-14 05:15 UTC, nick black
none Details | Review
Support v4l2 in GEGL (3.98 KB, patch)
2012-12-14 05:16 UTC, nick black
none Details | Review
autoconf support for libv4l check via pkg-config (2.13 KB, patch)
2012-12-14 05:31 UTC, nick black
none Details | Review

Description John D. Coleman 2011-07-15 10:21:59 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.
Comment 1 Tobias Vogel 2011-08-24 15:10:24 UTC
Created attachment 194608 [details] [review]
Gegl-patch for v4l support in newer kernel-versions.
Comment 2 Tobias Vogel 2011-08-24 15:11:34 UTC
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.
Comment 3 Jon Nordby 2011-08-24 15:40:09 UTC
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?
Comment 4 Tobias Vogel 2011-08-24 17:49:48 UTC
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..?
Comment 5 Jon Nordby 2011-08-25 08:28:45 UTC
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.
Comment 6 Tobias Vogel 2011-08-25 09:20:10 UTC
Ok, I'll give it a try! :-)
Comment 7 Jon Nordby 2011-09-04 14:04:14 UTC
Review of attachment 194608 [details] [review]:

As discussed in bugreport, moving to v4l2 is the right solution.
Comment 8 Tobias Vogel 2011-10-27 10:01:22 UTC
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?
Comment 9 nick black 2012-12-14 05:15:49 UTC
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.
Comment 10 nick black 2012-12-14 05:16:04 UTC
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.
Comment 11 nick black 2012-12-14 05:16:48 UTC
Created attachment 231537 [details] [review]
Support v4l2 in GEGL

V4L2 support, patch 2 of 2. Please apply using "git apply".
Comment 12 nick black 2012-12-14 05:31:12 UTC
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. :)
Comment 13 Tobias Vogel 2012-12-14 07:24:48 UTC
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 -----
Comment 14 nick black 2012-12-14 14:53:44 UTC
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!
Comment 15 Sebastian Pipping 2013-04-28 18:52:26 UTC
Any news on this?  Any chance to have these patches in the next release?
Comment 16 Øyvind Kolås (pippin) 2017-04-28 13:04:45 UTC
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