When do v4l2_ioctl() with VIDIOC_ENUMINPUT fails on some devices,
kernels before 3.3.0 return EINVAL, but newer kernels return ENOTTY.
This patch make those devices work well on kernel 3.3+.
Related kernel commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=07d106d0a33d6063d2061305903deb02489eba20
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Rui Wang <wangr@lemote.com>
Signed-off-by: Jie Chen <chenj@lemote.com>
This was unused apparently and removed in the kernel in commit:
From 2b719d7baf490e24ce7d817c6337b7c87fda84c1 Mon Sep 17 00:00:00 2001
From: Sakari Ailus <sakari.ailus@iki.fi>
Date: Wed, 2 May 2012 09:40:03 -0300
Subject: [PATCH] [media] v4l: drop v4l2_buffer.input and V4L2_BUF_FLAG_INPUT
Remove input field in struct v4l2_buffer and flag V4L2_BUF_FLAG_INPUT which
tells the former is valid. The flag is used by no driver currently.
https://bugzilla.gnome.org/show_bug.cgi?id=681491
Conflicts:
sys/v4l2/gstv4l2bufferpool.c
UVC devices are never interlaced, and doing VIDIOC_TRY_FMT on them
causes expensive and slow USB IO, so don't probe them for interlaced.
This shaves 2 seconds of the startup time of cheese with a Logitech
Webcam Pro 9000.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=677722
Block gst_osx_video_sink_run_cocoa_loop until the loop thread has started and
finished initializing NSApp. Fixes occasional warnings/crashes due to two
threads going inside NSApp before finishLaunching had completed.
When we are using a dedicated thread to run the main run loop we
must make sure that all selectors are performed on this same thread.
For instance if performSelectorOnMainThread is called from the real
main thread, it will not go through the message queue and will be
executed from the real main thread. By forcing the target thread,
we ensure that all functions will be called either from the real
main thread when the main run loop is running or from our thread
spinning the main loop.
Add a little hack to run the cocoa main runloop from a separate thread _when_
the main runloop is not being run (which means that the app doesn't use cocoa).
Runloops are thread specific, so the hack boils down to getting the runloop for
the main thread and setting it as the runloop for our dedicated thread.
