Linux testers wanted for Genius iSlim 310

2010-02-24 Thread Németh Márton
Hi,

based on the information from installing the Windows driver the
Genius iSlim 310 is a potential candidate that the gspca_pac7302 driver under
Linux may handle, see
http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302#Identification .

If you have access to Genius iSlim 310 and would like to give a try please
apply the patch in this email, compile and install the patched kernel,
check "dmesg" for messages and try whether the webcam is working for
example with cheese.

Regards,

Márton Németh

---
From: Márton Németh 

On the schematics in PixArt PAC7301/PAC7302 datasheet
(http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf)
pages 19, 20, 21 and 22 there is a note titled "PID IO_TRAP" which describes
the possible product ID range 0x2620..0x262f. In this range there are some
known webcams, however, there are some PIDs with unknown or future devices.
Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is
probable that this driver will work correctly independent of the used PID.

Signed-off-by: Márton Németh 
---
diff -r dfa82cf98a85 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sat Jan 30 20:03:02 2010 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Jan 31 11:08:21 2010 +0100
@@ -96,6 +96,7 @@
u8 flags;
 #define FL_HFLIP 0x01  /* mirrored by default */
 #define FL_VFLIP 0x02  /* vertical flipped by default */
+#define FL_EXPERIMENTAL 0x80   /* USB IDs based on heuristic without any known 
product */

u8 sof_read;
u8 autogain_ignore_frames;
@@ -1220,17 +1221,33 @@
 };

 /* -- module initialisation -- */
+/* Note on FL_EXPERIMENTAL:
+ * On the schematics in PixArt PAC7301/PAC7302 datasheet
+ * 
(http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf)
+ * pages 19, 20, 21 and 22 there is a note titled "PID IO_TRAP" which describes
+ * the possible product ID range 0x2620..0x262f. In this range there are some
+ * known webcams, however, there are some PIDs with unknown or future devices.
+ * Because PixArt PAC7301/PAC7302 is a System on a Chip (SoC) device is is
+ * probable that this driver will work correctly independent of the used PID.
+ */
 static const struct usb_device_id device_table[] __devinitconst = {
{USB_DEVICE(0x06f8, 0x3009)},
{USB_DEVICE(0x093a, 0x2620)},
{USB_DEVICE(0x093a, 0x2621)},
{USB_DEVICE(0x093a, 0x2622), .driver_info = FL_VFLIP},
+   {USB_DEVICE(0x093a, 0x2623), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2624), .driver_info = FL_VFLIP},
+   {USB_DEVICE(0x093a, 0x2625), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2626)},
+   {USB_DEVICE(0x093a, 0x2627), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x2628)},
{USB_DEVICE(0x093a, 0x2629), .driver_info = FL_VFLIP},
{USB_DEVICE(0x093a, 0x262a)},
+   {USB_DEVICE(0x093a, 0x262b), .driver_info = FL_EXPERIMENTAL },
{USB_DEVICE(0x093a, 0x262c)},
+   {USB_DEVICE(0x093a, 0x262d), .driver_info = FL_EXPERIMENTAL },
+   {USB_DEVICE(0x093a, 0x262e), .driver_info = FL_EXPERIMENTAL },
+   {USB_DEVICE(0x093a, 0x262f), .driver_info = FL_EXPERIMENTAL },
{}
 };
 MODULE_DEVICE_TABLE(usb, device_table);
@@ -1239,6 +1256,17 @@
 static int __devinit sd_probe(struct usb_interface *intf,
const struct usb_device_id *id)
 {
+   if ((u8)id->driver_info & FL_EXPERIMENTAL) {
+   PDEBUG(D_ERR | D_PROBE, "WARNING: USB device ID %04x:%04x is "
+   "not known, but based on some heuristics this driver "
+   "tries to handle it.",
+   id->idVendor, id->idProduct);
+   PDEBUG(D_ERR | D_PROBE, "WARNING: Plase send an email to "
+   "linux-media@vger.kernel.org with 'lsusb -v' output, "
+   "the vendor and name of the product and whether the "
+   "device is working or not.");
+   }
+
return gspca_dev_probe(intf, id, &sd_desc, sizeof(struct sd),
THIS_MODULE);
 }

--
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: Chroma gain configuration

2010-02-24 Thread Devin Heitmueller
On Tue, Feb 23, 2010 at 2:53 AM, Hans Verkuil  wrote:
>> Control enumeration is actually working fine.  The queryctrl does
>> properly return all of the controls, including my new private control.
>
> OK. So the problem is that v4l2-ctl uses G/S_EXT_CTRLS for non-user controls,
> right? Why not change v4l2-ctl: let it first try the EXT version but if that
> fails with EINVAL then try the old control API.

For what it's worth, I actually bisected the v4l2-ctl.cpp, and found
out the breakage got introduced in rev 12546:

==
v4l2-ctl: add support for string controls

From: Hans Verkuil 

Add support for string controls to v4l2-ctl.
Also refactor the code to generalize the handling of control classes.

Priority: normal
==

And this change breaks the v4l2-ctl application not just with my
driver but with *any* of the drivers which have private controls
implemented in g_ctrl or s_ctrl (including bttv, saa7134, and pwc)

The root of the issue is that private controls are not considered
"user controls".  Hence when getting or setting the control, the
v4l2-ctl app will always insist on attempting to use the
g_ext_ctrls/s_ext_ctrls ioctl calls, even though the underlying driver
doesn't have them implemented as extended controls.

The enumeration of all of control values (using the "-l" argument)
does include the private controls properly because the logic is
written such that it always uses g_ctrl for all cases where the
control ID >= V4L2_CID_PRIVATE_BASE.

I guess I'll see whether I can rework the logic a bit such that the
set/get routines work in a comparable manner to the routine to
enumerate all the controls.  I would prefer to avoid making the
g_ext_ctrls ioctl() call and then retrying it as g_ctrl if it fails,
since that will cause errors to be printed to the screen (due to the
abstraction of doioctl() function) and is generally a bad practice.

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: Requested feedback on V4L2 driver design

2010-02-24 Thread Kamoolkar, Mugdha
Chase, Laurent,

Sorry for the extreme delay in my response ...
>From the code available currently on omapzoom, our plans are to eventually 
>have only the Notify module in kernel-space. All the other code in 
>multicore_ipc will actually move to user-side. The Notify module gives 
>additional functionality over the basic mailbox driver to abstract the single 
>physical event into multiple logical events. This enables multiple clients 
>(one of which is the DSS driver) to use the single physical interrupt for 
>multiple different purposes in a fully modular manner. We will ensure that the 
>kernel-side Notify module is fully integrated into the kernel in the proper 
>way and still meets our functionality requirements, taking feedback from the 
>community into account.

We are also making several changes in the APIs for all modules to make them 
much easier to use. A lot of the complexity as seen by the user will vanish 
underneath. This is still under progress, so it's not out on omapzoom yet, but 
will definitely be done.

As soon as this is done, we will work on moving most of the modules (except 
Notify) fully from kernel->user space. Once our kernel->user work has at least 
gone far enough ahead to allow us to make a design proposal, we will push it 
out for review to get your valuable feedback.

I have also looped in the TI engineers who have worked on and pushed out the 
omapzoom SysLink code.

Regards,
Mugdha

-Original Message-
From: Maupin, Chase
Sent: Friday, February 12, 2010 10:17 PM
To: Laurent Pinchart
Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; 
mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to discuss 
the VPSS driver design (May contain non-TIers); linux-media@vger.kernel.org; 
Kamoolkar, Mugdha
Subject: RE: Requested feedback on V4L2 driver design

Laurent,

First let me thank you for taking time to review this.  I have made comments 
below to address your concerns.

Sincerely,
Chase Maupin
Software Applications
Catalog DSP Products
e-mail: chase.mau...@ti.com
phone: (281) 274-3285

For support:
Forums - http://community.ti.com/forums/
Wiki - http://wiki.davincidsp.com/

> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Thursday, February 11, 2010 7:23 PM
> To: Maupin, Chase
> Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com;
> mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to
> discuss the VPSS driver design (May contain non-TIers); linux-
> me...@vger.kernel.org
> Subject: Re: Requested feedback on V4L2 driver design
>
> Hi Chase,
>
> On Monday 08 February 2010 16:08:37 Maupin, Chase wrote:
> > All,
> >
> > Texas Instruments (TI) is working on the design for the V4L2 capture and
> > display drivers for our next generation system-on-chip (SoC) processor
> and
> > would like to solicit your feedback.
>
> Thank you very much for requesting feedback on the system design. I
> personally
> appreciate this, and I'm pretty sure that the feeling is shared by most of
> the
> Linux kernel developers.
>
> > If you have additional questions or need more information please feel
> free
> > to contact us (we have setup a mailing list at
> > vpss_driver_des...@list.ti.com) so we can answer them.
>
> I'll answer here as the instructions provided in the wiki to subscribe to
> the
> vpss_driver_design mailing list are incorrect (http://list.ti.com/ isn't
> accessible, the name has no A record associated to it). I've CC'ed the
> list in
> case subscription wouldn't be required to post.

The page for subscribing to the list requires a my.TI login which you can setup 
at 
https://myportal.ti.com/portal/dt?provider=TIPassLoginSingleContainer<=myti&j5=2&j3=1&goto=https%3A%2F%2Fmy.ti.com%3A443%2Fcgi-bin%2Fhome.pl%3FDCMP%3DTIHeaderTracking%26HQS%3DOther%2BOT%2Bhdr_my_ti.
  However, your reply to the list should be fine without subscribing.

>
> 1. Multi-core design
> 
>
> OMAP3 was already a dual-core system, OMAP4 (I assume all this is about
> the
> OMAP4 processors family) seems to push the concept one step further.
>
> With its heterogeneous multi-core design (ARM master CPU and slave DSPs),
> the
> OMAP architecture delivers high performances at the cost of higher
> development
> time and effort as users need to write software for completely different
> cores, usually using different toolchains. This is in my opinion a good
> (or at
> least acceptable) trade-off between CPU power, development time and power
> consumption (DSPs being more efficient at signal processing at the cost of
> a
> higher development complexity).
>
> I'm a bit puzzled, however, by how the VPSS MCU will help improving the
> situation compared to the OMAP3 design. The VPSS MCU will provide an API
> that
> will expose a fixed subset of the hardware capabilities. This is only a
> guess,
> but I suppose the firmware will be fairly generic, and that TI will
> provide
> customized versions to b

Re: [PATCH 0/4] DocBook additions for V4L new formats

2010-02-24 Thread Mauro Carvalho Chehab
Randy Dunlap wrote:
> On 02/17/10 18:31, Randy Dunlap wrote:
>> On 02/17/10 09:06, Mauro Carvalho Chehab wrote:
>>> Adds DocBook items for Bayer and two proprietary formats used on gspca.
>>>
>>> In the past, a few targets were generated at the Mercurial development
>>> tree. However, at the beginning of this year, we moved to use -git as
>>> the primary resource. So, the Makefile logic to autogenerate those
>>> targets needs to be moved to git as well.
>>>
>>> While here, I noticed that DocBook is too verbose to generate the
>>> htmldocs target. So, make it less verbose, if V=0.
>>>
>>> Guennadi Liakhovetski (1):
>>>   V4L/DVB: v4l: document new Bayer and monochrome pixel formats
>>>
>>> Mauro Carvalho Chehab (3):
>>>   DocBook/Makefile: Make it less verbose
>>>   DocBook: Add rules to auto-generate some media docbooks
>>>   DocBook/v4l/pixfmt.xml: Add missing formats for gspca cpia1 and
>>> sn9c2028 drivers
>> Hi Mauro,
>>
>> Patches 1 & 3 are OK.
>>
>> I'm having problems with patch 2/4 when I use O=DOCDIR on the make command
>> (which I always do).  videodev2.h.xml is not being generated, and after
>> that it goes downhill.
>>
>> I will let you know more when I have more info, or you or Guennadi can send
>> a fixup patch for that.
>>
> 
> I'm not making any progress on this.
> "make O=DOCDIR htmldocs" needs to work, but it does not:
> 

The enclosed patch should fix the build after applying the 4 patches from the 
series.

Tomorrow, I'll take a look at the index.html issue.


Fix makefile

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 1c796fc..4ebe4e1 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
mac80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
-   tracepoint.xml media.xml
+   tracepoint.xml media_tmp/media.xml
 
 ###
 # The build process is as follows (targets):
@@ -32,10 +32,10 @@ PS_METHOD   = $(prefer-db2x)
 
 ###
 # The targets that may be used.
-PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs 
cleandocs xmldoclinks mediaprep
+PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs 
cleandocs mediaprep
 
 BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
-xmldocs: $(BOOKS) xmldoclinks
+xmldocs: $(BOOKS)
 sgmldocs: xmldocs
 
 PS := $(patsubst %.xml, %.ps, $(BOOKS))
@@ -48,23 +48,10 @@ HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS)))
 htmldocs: $(HTML)
@$($(quiet)cmd_build_main_index)
@$($(call build_main_index))
-   @($(call build_images))
 
 MAN := $(patsubst %.xml, %.9, $(BOOKS))
 mandocs: $(MAN)
 
-build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \
-  cp $(srctree)/Documentation/DocBook/dvb/*.png 
$(srctree)/Documentation/DocBook/v4l/*.gif 
$(objtree)/Documentation/DocBook/media/
-
-xmldoclinks:
-ifneq ($(objtree),$(srctree))
-   for dep in dvb v4l; do \
-   rm -f $(objtree)/Documentation/DocBook/$$dep \
-   && ln -s $(srctree)/Documentation/DocBook/$$dep 
$(objtree)/Documentation/DocBook/ \
-   || exit; \
-   done
-endif
-
 installmandocs: mandocs
mkdir -p /usr/local/man/man9/
install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/
@@ -100,7 +87,7 @@ endef
$(call if_changed_rule,docproc)
 
 ###
-#Read in all saved dependency files 
+#Read in all saved dependency files
 cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd))
 
 ifneq ($(cmd_files),)
@@ -239,10 +226,9 @@ clean-files := $(DOCBOOKS) \
$(patsubst %.xml, %.pdf,  $(DOCBOOKS)) \
$(patsubst %.xml, %.html, $(DOCBOOKS)) \
$(patsubst %.xml, %.9,$(DOCBOOKS)) \
-   $(MEDIA_TEMP) \
$(index)
 
-clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
+clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man 
 
 cleandocs:
$(Q)rm -f $(call objectify, $(clean-files))
@@ -260,134 +246,133 @@ cleandocs:
 
 SHELL=/bin/bash
 
+MEDIA_DIR=$(objtree)/Documentation/DocBook/media_tmp
+
 V4L_SGMLS = \
-   v4l/biblio.xml \
-   v4l/common.xml \
-   v4l/compat.xml \
-   v4l/controls.xml \
-   v4l/dev-capture.xml \
-   v4l/dev-codec.xml \
-   v4l/dev-effect.xml \
-   v4l/dev-osd.xml \
-   v4l/dev-output.xml \
-   v4l/dev-overlay.xml \
-   v4l/dev-radio.xml \
-   v4l/dev-raw-vbi.xml \
-   v4l/dev-rds.xml \
-   v4l/dev-sliced-vbi.xml \
-   v4l/dev-teletext.xml \
-   v4l/driver.xml \
-   v4l/libv4l.xml \
-   v4l/remote_controllers.xml \
-   v4l/fdl-appendix.xml \
-   v4l/func-close.xml \
-   v4l/func-ioctl.xml \
-   v4l/func-mmap.xml \
-   v4l/func-munmap.xml \
-   v4l/func-open.xml \
-   v4l/func-po

Re: [ANNOUNCE] git tree repositories & libv4l

2010-02-24 Thread Douglas Schilling Landgraf

Hello all,

On 02/23/2010 10:51 AM, Hans de Goede wrote:

Hi,

On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:

Hans de Goede wrote:

Ok, so this will give me a local tree, how do I get this onto 
linuxtv.org ?


I added it. In thesis, it is open for commit to you, me, hverkuil and 
dougsland.




I see good, thanks! Can someone (Douglas ?) with better hg / git 
powers then me please

somehow import all the libv4l changes from:
http://linuxtv.org/hg/~hgoede/libv4l


Done!

Cheers
Douglas
--
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


Development of TM6000

2010-02-24 Thread Bee Hock Goh
Hi Mauro,

>From what I have gather so far, it seem that you are the only person
who might still be keen in the continue development of TM6000 driver.
Apparently, I saw that you are also pretty much occupied with other
works at hand.

I have recently bought a USB stick(MSI Vox II) that have the
TM5600/XC2028 chipset. Using the latest source from
http://linuxtv.org/hg/v4l-dvb and activating the TM6000 under staging,
I was able to detect the tuner stick. Firmware was extracted using the
tridvid.sys from the windows driver CD.

Unfortunately, this is the furthest that I can go. Both tvtime and
mplayer were able to load but the notebook just freeze some time.

Do you have any pointer on how I can get it to work?

Playing tv://.
TV file format detected.
Selected driver: v4l2
 name: Video 4 Linux 2 input
 author: Martin Olschewski 
 comment: first try, more to come ;-)
Selected device: Trident TVMaster TM5600/6000
 Tuner cap:
 Tuner rxs: MONO
 Capabilites:  video capture  tuner  read/write  streaming
 supported norms: 0 = NTSC-M; 1 = NTSC-M-JP; 2 = PAL; 3 = PAL-BG; 4 =
PAL-H; 5 = PAL-I; 6 = PAL-DK; 7 = PAL-M; 8 = PAL-N; 9 = PAL-Nc; 10 =
PAL-60; 11 = SECAM; 12 = SECAM-B; 13 = SECAM-G; 14 = SECAM-H; 15 =
SECAM-DK; 16 = SECAM-L; 17 = SECAM-Lc;
 inputs: 0 = Television; 1 = Composite; 2 = S-Video;
 Current input: 0
 Current format: YUYV
v4l2: current audio mode is : MONO
v4l2: ioctl set format failed: Invalid argument
v4l2: ioctl set format failed: Invalid argument


On a side note, I am starting to look through documentation on
developing v4l driver so that I can work on the existing TM6000
driver. Unfortunately, while I am verse in programming(userspace
only), C and Assembly is only something I am familiar with many years
back during school days. So its going to take a while for me to catch
up.

I guess working on the driver on my own might be the only possibility
if you cannot afford the time to work on it.
--
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


[PATCH v8 6/6] V4L: Events: Add documentation

2010-02-24 Thread Sakari Ailus
Add documentation on how to use V4L2 events, both for V4L2 drivers and for
V4L2 applications.

Signed-off-by: Sakari Ailus 
---
 Documentation/DocBook/media-entities.tmpl  |9 ++
 Documentation/DocBook/v4l/dev-event.xml|   31 +
 Documentation/DocBook/v4l/v4l2.xml |3 +
 Documentation/DocBook/v4l/vidioc-dqevent.xml   |  124 
 .../DocBook/v4l/vidioc-subscribe-event.xml |  104 
 Documentation/video4linux/v4l2-framework.txt   |   60 ++
 6 files changed, 331 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/DocBook/v4l/dev-event.xml
 create mode 100644 Documentation/DocBook/v4l/vidioc-dqevent.xml
 create mode 100644 Documentation/DocBook/v4l/vidioc-subscribe-event.xml

diff --git a/Documentation/DocBook/media-entities.tmpl 
b/Documentation/DocBook/media-entities.tmpl
index c725cb8..770be3c 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -17,6 +17,7 @@
 VIDIOC_DBG_G_REGISTER">
 VIDIOC_DBG_S_REGISTER">
 VIDIOC_DQBUF">
+VIDIOC_DQEVENT">
 VIDIOC_ENCODER_CMD">
 VIDIOC_ENUMAUDIO">
 VIDIOC_ENUMAUDOUT">
@@ -60,6 +61,7 @@
 VIDIOC_REQBUFS">
 VIDIOC_STREAMOFF">
 VIDIOC_STREAMON">
+VIDIOC_SUBSCRIBE_EVENT">
 VIDIOC_S_AUDIO">
 VIDIOC_S_AUDOUT">
 VIDIOC_S_CROP">
@@ -141,6 +143,8 @@
 v4l2_enc_idx">
 v4l2_enc_idx_entry">
 v4l2_encoder_cmd">
+v4l2_event">
+v4l2_event_subscription">
 v4l2_ext_control">
 v4l2_ext_controls">
 v4l2_fmtdesc">
@@ -200,6 +204,7 @@
 
 
 
+
 
 
 
@@ -292,6 +297,8 @@
 
 
 
+
+
 
 
 
@@ -381,3 +388,5 @@
 
 
 
+
+
diff --git a/Documentation/DocBook/v4l/dev-event.xml 
b/Documentation/DocBook/v4l/dev-event.xml
new file mode 100644
index 000..be5a98f
--- /dev/null
+++ b/Documentation/DocBook/v4l/dev-event.xml
@@ -0,0 +1,31 @@
+  Event Interface
+
+  The V4L2 event interface provides means for user to get
+  immediately notified on certain conditions taking place on a device.
+  This might include start of frame or loss of signal events, for
+  example.
+  
+
+  To receive events, the events the user is interested in first must
+  be subscribed using the &VIDIOC-SUBSCRIBE-EVENT; ioctl. Once an event is
+  subscribed, the events of subscribed types are dequeueable using the
+  &VIDIOC-DQEVENT; ioctl. Events may be unsubscribed using
+  VIDIOC_UNSUBSCRIBE_EVENT ioctl. The special event type V4L2_EVENT_ALL may
+  be used to unsubscribe all the events the driver supports.
+
+  The event subscriptions and event queues are specific to file
+  handles. Subscribing an event on one file handle does not affect
+  other file handles.
+  
+
+  The information on dequeueable events is obtained by using select or
+  poll system calls on video devices. The V4L2 events use POLLPRI events on
+  poll system call and exceptions on select system call.  
+
+  
diff --git a/Documentation/DocBook/v4l/v4l2.xml 
b/Documentation/DocBook/v4l/v4l2.xml
index 060105a..9737243 100644
--- a/Documentation/DocBook/v4l/v4l2.xml
+++ b/Documentation/DocBook/v4l/v4l2.xml
@@ -401,6 +401,7 @@ and discussions on the V4L mailing list.
  &sub-dev-teletext; 
  &sub-dev-radio; 
  &sub-dev-rds; 
+ &sub-dev-event; 
   
 
   
@@ -426,6 +427,7 @@ and discussions on the V4L mailing list.
 &sub-cropcap;
 &sub-dbg-g-chip-ident;
 &sub-dbg-g-register;
+&sub-dqevent;
 &sub-encoder-cmd;
 &sub-enumaudio;
 &sub-enumaudioout;
@@ -467,6 +469,7 @@ and discussions on the V4L mailing list.
 &sub-reqbufs;
 &sub-s-hw-freq-seek;
 &sub-streamon;
+&sub-subscribe-event;
 
 &sub-mmap;
 &sub-munmap;
diff --git a/Documentation/DocBook/v4l/vidioc-dqevent.xml 
b/Documentation/DocBook/v4l/vidioc-dqevent.xml
new file mode 100644
index 000..eb45c16
--- /dev/null
+++ b/Documentation/DocBook/v4l/vidioc-dqevent.xml
@@ -0,0 +1,124 @@
+
+  
+ioctl VIDIOC_DQEVENT
+&manvol;
+  
+
+  
+VIDIOC_DQEVENT
+Dequeue event
+  
+
+  
+
+  
+   int ioctl
+   int fd
+   int request
+   struct v4l2_event
+*argp
+  
+
+  
+
+  
+Arguments
+
+
+  
+   fd
+   
+ &fd;
+   
+  
+  
+   request
+   
+ VIDIOC_DQEVENT
+   
+  
+  
+   argp
+   
+ 
+   
+  
+
+  
+
+  
+Description
+
+Dequeue an event from a video device. No input is required
+for this ioctl. All the fields of the &v4l2-event; structure are
+filled by the driver. The file handle will also receive exceptions
+which the application may get by e.g. using the select system
+call.
+
+
+  struct v4l2_event
+  
+   &cs-str;
+   
+ 
+   __u32
+   type
+
+   Type of the event.
+ 
+ 
+   union
+   u
+
+   
+ 
+ 
+   
+   __u8
+data[64]
+   Event data. Defined by the event typ

[PATCH v8 1/6] V4L: File handles

2010-02-24 Thread Sakari Ailus
This patch adds a list of v4l2_fh structures to every video_device.
It allows using file handle related information in V4L2. The event interface
is one example of such use.

Video device drivers should use the v4l2_fh pointer as their
file->private_data.

Signed-off-by: Sakari Ailus 
---
 drivers/media/video/Makefile   |2 +-
 drivers/media/video/v4l2-dev.c |4 ++
 drivers/media/video/v4l2-fh.c  |   66 
 include/media/v4l2-dev.h   |5 +++
 include/media/v4l2-fh.h|   42 +
 5 files changed, 118 insertions(+), 1 deletions(-)
 create mode 100644 drivers/media/video/v4l2-fh.c
 create mode 100644 include/media/v4l2-fh.h

diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 5163289..14bf69a 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,7 @@ stkwebcam-objs:=  stk-webcam.o stk-sensor.o
 
 omap2cam-objs  :=  omap24xxcam.o omap24xxcam-dma.o
 
-videodev-objs  :=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o
+videodev-objs  :=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
 
 # V4L2 core modules
 
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 7090699..65a7b30 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -421,6 +421,10 @@ static int __video_register_device(struct video_device 
*vdev, int type, int nr,
if (!vdev->release)
return -EINVAL;
 
+   /* v4l2_fh support */
+   spin_lock_init(&vdev->fh_lock);
+   INIT_LIST_HEAD(&vdev->fh_list);
+
/* Part 1: check device type */
switch (type) {
case VFL_TYPE_GRABBER:
diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
new file mode 100644
index 000..93ea0af
--- /dev/null
+++ b/drivers/media/video/v4l2-fh.c
@@ -0,0 +1,66 @@
+/*
+ * v4l2-fh.c
+ *
+ * V4L2 file handles.
+ *
+ * Copyright (C) 2009--2010 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+
+int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev)
+{
+   fh->vdev = vdev;
+   INIT_LIST_HEAD(&fh->list);
+   set_bit(V4L2_FL_USES_V4L2_FH, &fh->vdev->flags);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_init);
+
+void v4l2_fh_add(struct v4l2_fh *fh)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+   list_add(&fh->list, &fh->vdev->fh_list);
+   spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_add);
+
+void v4l2_fh_del(struct v4l2_fh *fh)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+   list_del_init(&fh->list);
+   spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_del);
+
+void v4l2_fh_exit(struct v4l2_fh *fh)
+{
+   if (fh->vdev == NULL)
+   return;
+
+   fh->vdev = NULL;
+}
+EXPORT_SYMBOL_GPL(v4l2_fh_exit);
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index 2dee938..bebe44b 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -32,6 +32,7 @@ struct v4l2_device;
Drivers can clear this flag if they want to block all future
device access. It is cleared by video_unregister_device. */
 #define V4L2_FL_REGISTERED (0)
+#define V4L2_FL_USES_V4L2_FH   (1)
 
 struct v4l2_file_operations {
struct module *owner;
@@ -77,6 +78,10 @@ struct video_device
/* attribute to differentiate multiple indices on one physical device */
int index;
 
+   /* V4L2 file handles */
+   spinlock_t  fh_lock; /* Lock for all v4l2_fhs */
+   struct list_headfh_list; /* List of struct v4l2_fh */
+
int debug;  /* Activates debug level*/
 
/* Video standard vars */
diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
new file mode 100644
index 000..410e86c
--- /dev/null
+++ b/include/media/v4l2-fh.h
@@ -0,0 +1,42 @@
+/*
+ * v4l2-fh.h
+ *
+ * V4L2 file handle.
+ *
+ * Copyright (C) 2009--2010 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 

[PATCH v8 4/6] V4L: Events: Add backend

2010-02-24 Thread Sakari Ailus
Add event handling backend to V4L2. The backend handles event subscription
and delivery to file handles. Event subscriptions are based on file handle.
Events may be delivered to all subscribed file handles on a device
independent of where they originate from.

Signed-off-by: Sakari Ailus 
---
 drivers/media/video/Makefile |3 +-
 drivers/media/video/v4l2-event.c |  289 ++
 drivers/media/video/v4l2-fh.c|6 +-
 include/media/v4l2-event.h   |   67 +
 include/media/v4l2-fh.h  |2 +
 5 files changed, 365 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/video/v4l2-event.c
 create mode 100644 include/media/v4l2-event.h

diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 14bf69a..b84abfe 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -10,7 +10,8 @@ stkwebcam-objs:=  stk-webcam.o stk-sensor.o
 
 omap2cam-objs  :=  omap24xxcam.o omap24xxcam-dma.o
 
-videodev-objs  :=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
+videodev-objs  :=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
+   v4l2-event.o
 
 # V4L2 core modules
 
diff --git a/drivers/media/video/v4l2-event.c b/drivers/media/video/v4l2-event.c
new file mode 100644
index 000..aea4332
--- /dev/null
+++ b/drivers/media/video/v4l2-event.c
@@ -0,0 +1,289 @@
+/*
+ * v4l2-event.c
+ *
+ * V4L2 events.
+ *
+ * Copyright (C) 2009--2010 Nokia Corporation.
+ *
+ * Contact: Sakari Ailus 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+int v4l2_event_init(struct v4l2_fh *fh)
+{
+   fh->events = kzalloc(sizeof(*fh->events), GFP_KERNEL);
+   if (fh->events == NULL)
+   return -ENOMEM;
+
+   init_waitqueue_head(&fh->events->wait);
+
+   INIT_LIST_HEAD(&fh->events->free);
+   INIT_LIST_HEAD(&fh->events->available);
+   INIT_LIST_HEAD(&fh->events->subscribed);
+
+   fh->events->sequence = -1;
+
+   return 0;
+}
+
+int v4l2_event_alloc(struct v4l2_fh *fh, unsigned int n)
+{
+   struct v4l2_events *events = fh->events;
+   unsigned long flags;
+
+   if (!events) {
+   WARN_ON(1);
+   return -ENOMEM;
+   }
+
+   while (events->nallocated < n) {
+   struct v4l2_kevent *kev;
+
+   kev = kzalloc(sizeof(*kev), GFP_KERNEL);
+   if (kev == NULL)
+   return -ENOMEM;
+
+   spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+   list_add_tail(&kev->list, &events->free);
+   events->nallocated++;
+   spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_alloc);
+
+#define list_kfree(list, type, member) \
+   while (!list_empty(list)) { \
+   type *hi;   \
+   hi = list_first_entry(list, type, member);  \
+   list_del(&hi->member);  \
+   kfree(hi);  \
+   }
+
+void v4l2_event_free(struct v4l2_fh *fh)
+{
+   struct v4l2_events *events = fh->events;
+
+   if (!events)
+   return;
+
+   list_kfree(&events->free, struct v4l2_kevent, list);
+   list_kfree(&events->available, struct v4l2_kevent, list);
+   list_kfree(&events->subscribed, struct v4l2_subscribed_event, list);
+
+   kfree(events);
+   fh->events = NULL;
+}
+EXPORT_SYMBOL_GPL(v4l2_event_free);
+
+static int __v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event)
+{
+   struct v4l2_events *events = fh->events;
+   struct v4l2_kevent *kev;
+   unsigned long flags;
+
+   spin_lock_irqsave(&fh->vdev->fh_lock, flags);
+
+   if (list_empty(&events->available)) {
+   spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
+   return -ENOENT;
+   }
+
+   WARN_ON(events->navailable == 0);
+
+   kev = list_first_entry(&events->available, struct v4l2_kevent, list);
+   list_move(&kev->list, &events->free);
+   events->navailable--;
+
+   kev->event.pending = events->navailable;
+   *event = kev->event;
+
+   spin_unlock_

[PATCH v8 2/6] V4L: File handles: Add documentation

2010-02-24 Thread Sakari Ailus
Add documentation on using V4L2 file handles (v4l2_fh) in V4L2 drivers.

Signed-off-by: Sakari Ailus 
---
 Documentation/video4linux/v4l2-framework.txt |   37 ++
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/Documentation/video4linux/v4l2-framework.txt 
b/Documentation/video4linux/v4l2-framework.txt
index 74d677c..bfaf0c5 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -695,3 +695,40 @@ The better way to understand it is to take a look at vivi 
driver. One
 of the main reasons for vivi is to be a videobuf usage example. the
 vivi_thread_tick() does the task that the IRQ callback would do on PCI
 drivers (or the irq callback on USB).
+
+struct v4l2_fh
+--
+
+struct v4l2_fh provides a way to easily keep file handle specific data
+that is used by the V4L2 framework.
+
+struct v4l2_fh is allocated as a part of the driver's own file handle
+structure and is set to file->private_data in the driver's open
+function by the driver. Drivers can extract their own file handle
+structure by using the container_of macro.
+
+Useful functions:
+
+- v4l2_fh_init()
+
+  Initialise the file handle. This *MUST* be performed in the driver's
+  v4l2_file_operations->open() handler.
+
+- v4l2_fh_add()
+
+  Add a v4l2_fh to video_device file handle list. May be called after
+  initialising the file handle.
+
+- v4l2_fh_del()
+
+  Unassociate the file handle from video_device(). The file handle
+  exit function may now be called.
+
+- v4l2_fh_exit()
+
+  Uninitialise the file handle. After uninitialisation the v4l2_fh
+  memory can be freed.
+
+The users of v4l2_fh know whether a driver uses v4l2_fh as its
+file->private_data pointer by testing the V4L2_FL_USES_V4L2_FH bit in
+video_device->flags.
-- 
1.5.6.5

--
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


[PATCH v8 3/6] V4L: Events: Add new ioctls for events

2010-02-24 Thread Sakari Ailus
This patch adds a set of new ioctls to the V4L2 API. The ioctls conform to
V4L2 Events RFC version 2.3:

http://www.spinics.net/lists/linux-media/msg12033.html>

Signed-off-by: Sakari Ailus 
---
 drivers/media/video/v4l2-compat-ioctl32.c |3 +++
 drivers/media/video/v4l2-ioctl.c  |3 +++
 include/linux/videodev2.h |   26 ++
 3 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-compat-ioctl32.c 
b/drivers/media/video/v4l2-compat-ioctl32.c
index f77f84b..9004a5f 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -1086,6 +1086,9 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int 
cmd, unsigned long arg)
case VIDIOC_QUERY_DV_PRESET:
case VIDIOC_S_DV_TIMINGS:
case VIDIOC_G_DV_TIMINGS:
+   case VIDIOC_DQEVENT:
+   case VIDIOC_SUBSCRIBE_EVENT:
+   case VIDIOC_UNSUBSCRIBE_EVENT:
ret = do_video_ioctl(file, cmd, arg);
break;
 
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 4b11257..34c7d6e 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -290,6 +290,9 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_QUERY_DV_PRESET)]  = "VIDIOC_QUERY_DV_PRESET",
[_IOC_NR(VIDIOC_S_DV_TIMINGS)] = "VIDIOC_S_DV_TIMINGS",
[_IOC_NR(VIDIOC_G_DV_TIMINGS)] = "VIDIOC_G_DV_TIMINGS",
+   [_IOC_NR(VIDIOC_DQEVENT)]  = "VIDIOC_DQEVENT",
+   [_IOC_NR(VIDIOC_SUBSCRIBE_EVENT)]  = "VIDIOC_SUBSCRIBE_EVENT",
+   [_IOC_NR(VIDIOC_UNSUBSCRIBE_EVENT)] = "VIDIOC_UNSUBSCRIBE_EVENT",
 };
 #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
 
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c26560..d3b1446 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1622,6 +1622,29 @@ struct v4l2_streamparm {
 };
 
 /*
+ * E V E N T S
+ */
+
+struct v4l2_event {
+   __u32   type;
+   union {
+   __u8data[64];
+   } u;
+   __u32   pending;
+   __u32   sequence;
+   struct timespec timestamp;
+   __u32   reserved[9];
+};
+
+struct v4l2_event_subscription {
+   __u32   type;
+   __u32   reserved[7];
+};
+
+#define V4L2_EVENT_ALL 0
+#define V4L2_EVENT_PRIVATE_START   0x0800
+
+/*
  * A D V A N C E D   D E B U G G I N G
  *
  * NOTE: EXPERIMENTAL API, NEVER RELY ON THIS IN APPLICATIONS!
@@ -1743,6 +1766,9 @@ struct v4l2_dbg_chip_ident {
 #defineVIDIOC_QUERY_DV_PRESET  _IOR('V',  86, struct v4l2_dv_preset)
 #defineVIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct v4l2_dv_timings)
 #defineVIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct v4l2_dv_timings)
+#defineVIDIOC_DQEVENT   _IOR('V', 89, struct v4l2_event)
+#defineVIDIOC_SUBSCRIBE_EVENT   _IOW('V', 90, struct 
v4l2_event_subscription)
+#defineVIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct 
v4l2_event_subscription)
 
 /* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
-- 
1.5.6.5

--
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


[PATCH v8 5/6] V4L: Events: Support event handling in do_ioctl

2010-02-24 Thread Sakari Ailus
Add support for event handling to do_ioctl.

Signed-off-by: Sakari Ailus 
---
 drivers/media/video/v4l2-fh.c|   11 +++-
 drivers/media/video/v4l2-ioctl.c |   50 ++
 include/media/v4l2-ioctl.h   |7 +
 3 files changed, 67 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c
index aab2fb6..1423c44 100644
--- a/drivers/media/video/v4l2-fh.c
+++ b/drivers/media/video/v4l2-fh.c
@@ -34,7 +34,16 @@ int v4l2_fh_init(struct v4l2_fh *fh, struct video_device 
*vdev)
INIT_LIST_HEAD(&fh->list);
set_bit(V4L2_FL_USES_V4L2_FH, &fh->vdev->flags);
 
-   return v4l2_event_init(fh);
+   /*
+* fh->events only needs to be initialized if the driver
+* supports the VIDIOC_SUBSCRIBE_EVENT ioctl.
+*/
+   if (vdev->ioctl_ops && vdev->ioctl_ops->vidioc_subscribe_event)
+   return v4l2_event_init(fh);
+   else
+   fh->events = NULL;
+
+   return 0;
 }
 EXPORT_SYMBOL_GPL(v4l2_fh_init);
 
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 34c7d6e..4ba22da 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -25,6 +25,8 @@
 #endif
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #define dbgarg(cmd, fmt, arg...) \
@@ -1944,7 +1946,55 @@ static long __video_do_ioctl(struct file *file,
}
break;
}
+   case VIDIOC_DQEVENT:
+   {
+   struct v4l2_event *ev = arg;
+
+   if (!ops->vidioc_subscribe_event)
+   break;
+
+   ret = v4l2_event_dequeue(fh, ev, file->f_flags & O_NONBLOCK);
+   if (ret < 0) {
+   dbgarg(cmd, "no pending events?");
+   break;
+   }
+   dbgarg(cmd,
+  "pending=%d, type=0x%8.8x, sequence=%d, "
+  "timestamp=%lu.%9.9lu ",
+  ev->pending, ev->type, ev->sequence,
+  ev->timestamp.tv_sec, ev->timestamp.tv_nsec);
+   break;
+   }
+   case VIDIOC_SUBSCRIBE_EVENT:
+   {
+   struct v4l2_event_subscription *sub = arg;
 
+   if (!ops->vidioc_subscribe_event)
+   break;
+
+   ret = ops->vidioc_subscribe_event(fh, sub);
+   if (ret < 0) {
+   dbgarg(cmd, "failed, ret=%ld", ret);
+   break;
+   }
+   dbgarg(cmd, "type=0x%8.8x", sub->type);
+   break;
+   }
+   case VIDIOC_UNSUBSCRIBE_EVENT:
+   {
+   struct v4l2_event_subscription *sub = arg;
+
+   if (!ops->vidioc_unsubscribe_event)
+   break;
+
+   ret = ops->vidioc_unsubscribe_event(fh, sub);
+   if (ret < 0) {
+   dbgarg(cmd, "failed, ret=%ld", ret);
+   break;
+   }
+   dbgarg(cmd, "type=0x%8.8x", sub->type);
+   break;
+   }
default:
{
if (!ops->vidioc_default)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e8ba0f2..06daa6e 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -21,6 +21,8 @@
 #include 
 #endif
 
+struct v4l2_fh;
+
 struct v4l2_ioctl_ops {
/* ioctl callbacks */
 
@@ -254,6 +256,11 @@ struct v4l2_ioctl_ops {
int (*vidioc_g_dv_timings) (struct file *file, void *fh,
struct v4l2_dv_timings *timings);
 
+   int (*vidioc_subscribe_event)  (struct v4l2_fh *fh,
+   struct v4l2_event_subscription *sub);
+   int (*vidioc_unsubscribe_event)(struct v4l2_fh *fh,
+   struct v4l2_event_subscription *sub);
+
/* For other private ioctls */
long (*vidioc_default) (struct file *file, void *fh,
int cmd, void *arg);
-- 
1.5.6.5

--
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


[PATCH v8 0/6] V4L2 file handles and event interface

2010-02-24 Thread Sakari Ailus
Hi,

Here's the tenth version of the V4L2 file handle and event interface
patchset.

The patchset has been tested with the OMAP 3 ISP driver. Patches for
OMAP 3 ISP are not part of this patchset but are available in Gitorious
(branch is called event):

git://gitorious.org/omap3camera/mainline.git event

The patchset I'm posting now is against the v4l-dvb tree instead of
linux-omap. The omap3camera tree thus has a slightly different
version of these patches (just Makefiles) due to different baselines.

Some more comments from Hans and Randy. There are only improvements in
documentation this time.

Comments are welcome as always.

Cheers,

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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: af9015: tuner id:179 not supported, please report!

2010-02-24 Thread Bert Massop
This is a forward of the original email from Nikola Pajkovsky. Just
for the records, so it is on the list.

This solves the problem of the tuner id:179 not supported error, when
loading the AF9015 driver.

Thank you, Nikola!

Regards,
Bert Massop

-- Forwarded message --
From: Nikola Pajkovsky 
Date: Wed, Feb 24, 2010 at 11:54
Subject: Re: af901x: NXP TDA18218
To: Antti Palosaari 
Cc: jan.sund...@aland.net, bert.mas...@gmail.com,
mkru...@kernellabs.com, dheitmuel...@kernellabs.com


Hello,

   here is my solution, I can watch Vancouver right now :). I don't
look at the patch if there is some mistake(no time watch Vancouver),
but I will when I will have some free time.
Attached patch apply against this souce (hg clone
http://linuxtv.org/hg/~anttip/af9015/).

Firmware:
wget http://jusst.de/manu/fw/AFA/dvb-usb-af9015.fw_a-link
sudo mv dvb-usb-af9015.fw_a-link /lib/firmware/dvb-usb-af9015.fw

Have a nice day ;)

On 23.2.2010 14:02, Antti Palosaari wrote:
>
> Hello,
> I just got info from one user about this driver, looks like Terratec have 
> driver.
> http://forum.ubuntuusers.de/topic/probleme-beim-installieren-terratec-cinergy-t/3/?highlight=terratec+cinergy+t+stick
>
> Antti
>
> Nikola Pajkovsky wrote:
>>
>> Hello,
>>
>>    is any chance that will be support for TDA182118?
>>
>> Regards,
>>
>


--
Nikola
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Kconfig
--- a/linux/drivers/media/common/tuners/Kconfig	Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Kconfig	Wed Feb 24 11:47:14 2010 +0100
@@ -179,4 +179,11 @@
 	help
 	  A driver for the silicon tuner MAX2165 from Maxim.
 
+config MEDIA_TUNER_TDA18218
+	tristate "NXP TDA18218 silicon tuner"
+	depends on VIDEO_MEDIA && I2C
+	default m if MEDIA_TUNER_CUSTOMISE
+	help
+	  A driver for the silicon tuner TDA18218 from NXP.
+
 endif # MEDIA_TUNER_CUSTOMISE
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Makefile
--- a/linux/drivers/media/common/tuners/Makefile	Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Makefile	Wed Feb 24 11:47:14 2010 +0100
@@ -24,6 +24,7 @@
 obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o
 obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
 obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
+obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
 
 EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
 EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff -r 0f41fd7df85d linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c	Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c	Wed Feb 24 11:47:14 2010 +0100
@@ -20,11 +20,7 @@
  *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  *
  */
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 25)
 
-#include 
-
-#endif
 #include "af9015.h"
 #include "af9013.h"
 #include "mt2060.h"
@@ -32,6 +28,7 @@
 #include "tda18271.h"
 #include "mxl5005s.h"
 #include "mc44s803.h"
+#include "tda18218.h"
 
 static int dvb_usb_af9015_debug;
 module_param_named(debug, dvb_usb_af9015_debug, int, 0644);
@@ -273,7 +270,8 @@
 
 	while (i < num) {
 		if (msg[i].addr == af9015_af9013_config[0].demod_address ||
-		msg[i].addr == af9015_af9013_config[1].demod_address) {
+		msg[i].addr == af9015_af9013_config[1].demod_address  ||
+		msg[i].addr == 0x3a) {
 			addr = msg[i].buf[0] << 8;
 			addr += msg[i].buf[1];
 			mbox = msg[i].buf[2];
@@ -286,7 +284,8 @@
 
 		if (num > i + 1 && (msg[i+1].flags & I2C_M_RD)) {
 			if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+			msg[i].addr == 0x3a)
 req.cmd = READ_MEMORY;
 			else
 req.cmd = READ_I2C;
@@ -301,7 +300,8 @@
 		} else if (msg[i].flags & I2C_M_RD) {
 			ret = -EINVAL;
 			if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+			msg[i].addr == 0x3a)
 goto error;
 			else
 req.cmd = READ_I2C;
@@ -315,7 +315,8 @@
 			i += 1;
 		} else {
 			if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+			msg[i].addr == 0x3a)
 req.cmd = WRITE_MEMORY;
 			else
 req.cmd = WRITE_I2C;
@@ -560,24 +561,11 @@
 	return ret;
 }
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 25)
+/* dump eeprom */
 static int af9015_eeprom_dump(struct dvb_usb_device *d)
-#else
-/* hash (and dump) eeprom */
-static int af9015_eeprom_hash(struct usb_device *udev)
-#endif
 {
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 25)
 	u8 reg, val;
-#else
-	static const unsigned int eeprom_size = 256;
-	unsigned int reg;
-	int ret;
-	u8 val, *eeprom;
-	struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1, &val};
-#endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 25)
 	for (reg = 0; ; reg++) {
 		if (reg % 16 == 0) {
 			if (reg)
@@ -590,43 +578,9 @@
 			deb_info(KERN_CONT " --");
 		if (reg == 0xff)
 			break;
-#else
-	eeprom = kmalloc(eeprom_size, GFP_KERNEL);
-	if (eep

Fwd: af901x: NXP TDA18218

2010-02-24 Thread Bert Massop
This is a forward of the original email from Nikola Pajkovsky. Just
for the records, so it is on the list.

This solves the problem of the tuner id:179 not supported error, when
loading the AF9015 driver.

Thank you, Nikola!

Regards,
Bert Massop

-- Forwarded message --
From: Nikola Pajkovsky 
Date: Wed, Feb 24, 2010 at 11:54
Subject: Re: af901x: NXP TDA18218
To: Antti Palosaari 
Cc: jan.sund...@aland.net, bert.mas...@gmail.com,
mkru...@kernellabs.com, dheitmuel...@kernellabs.com


Hello,

   here is my solution, I can watch Vancouver right now :). I don't
look at the patch if there is some mistake(no time watch Vancouver),
but I will when I will have some free time.
Attached patch apply against this souce (hg clone
http://linuxtv.org/hg/~anttip/af9015/).

Firmware:
wget http://jusst.de/manu/fw/AFA/dvb-usb-af9015.fw_a-link
sudo mv dvb-usb-af9015.fw_a-link /lib/firmware/dvb-usb-af9015.fw

Have a nice day ;)

On 23.2.2010 14:02, Antti Palosaari wrote:
>
> Hello,
> I just got info from one user about this driver, looks like Terratec have 
> driver.
> http://forum.ubuntuusers.de/topic/probleme-beim-installieren-terratec-cinergy-t/3/?highlight=terratec+cinergy+t+stick
>
> Antti
>
> Nikola Pajkovsky wrote:
>>
>> Hello,
>>
>>    is any chance that will be support for TDA182118?
>>
>> Regards,
>>
>


--
Nikola
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Kconfig
--- a/linux/drivers/media/common/tuners/Kconfig	Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Kconfig	Wed Feb 24 11:47:14 2010 +0100
@@ -179,4 +179,11 @@
 	help
 	  A driver for the silicon tuner MAX2165 from Maxim.
 
+config MEDIA_TUNER_TDA18218
+	tristate "NXP TDA18218 silicon tuner"
+	depends on VIDEO_MEDIA && I2C
+	default m if MEDIA_TUNER_CUSTOMISE
+	help
+	  A driver for the silicon tuner TDA18218 from NXP.
+
 endif # MEDIA_TUNER_CUSTOMISE
diff -r 0f41fd7df85d linux/drivers/media/common/tuners/Makefile
--- a/linux/drivers/media/common/tuners/Makefile	Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/common/tuners/Makefile	Wed Feb 24 11:47:14 2010 +0100
@@ -24,6 +24,7 @@
 obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o
 obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
 obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
+obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
 
 EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
 EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff -r 0f41fd7df85d linux/drivers/media/dvb/dvb-usb/af9015.c
--- a/linux/drivers/media/dvb/dvb-usb/af9015.c	Thu Feb 11 02:33:12 2010 +0200
+++ b/linux/drivers/media/dvb/dvb-usb/af9015.c	Wed Feb 24 11:47:14 2010 +0100
@@ -20,11 +20,7 @@
  *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  *
  */
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 25)
 
-#include 
-
-#endif
 #include "af9015.h"
 #include "af9013.h"
 #include "mt2060.h"
@@ -32,6 +28,7 @@
 #include "tda18271.h"
 #include "mxl5005s.h"
 #include "mc44s803.h"
+#include "tda18218.h"
 
 static int dvb_usb_af9015_debug;
 module_param_named(debug, dvb_usb_af9015_debug, int, 0644);
@@ -273,7 +270,8 @@
 
 	while (i < num) {
 		if (msg[i].addr == af9015_af9013_config[0].demod_address ||
-		msg[i].addr == af9015_af9013_config[1].demod_address) {
+		msg[i].addr == af9015_af9013_config[1].demod_address  ||
+		msg[i].addr == 0x3a) {
 			addr = msg[i].buf[0] << 8;
 			addr += msg[i].buf[1];
 			mbox = msg[i].buf[2];
@@ -286,7 +284,8 @@
 
 		if (num > i + 1 && (msg[i+1].flags & I2C_M_RD)) {
 			if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+			msg[i].addr == 0x3a)
 req.cmd = READ_MEMORY;
 			else
 req.cmd = READ_I2C;
@@ -301,7 +300,8 @@
 		} else if (msg[i].flags & I2C_M_RD) {
 			ret = -EINVAL;
 			if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+			msg[i].addr == 0x3a)
 goto error;
 			else
 req.cmd = READ_I2C;
@@ -315,7 +315,8 @@
 			i += 1;
 		} else {
 			if (msg[i].addr ==
-af9015_af9013_config[0].demod_address)
+af9015_af9013_config[0].demod_address ||
+			msg[i].addr == 0x3a)
 req.cmd = WRITE_MEMORY;
 			else
 req.cmd = WRITE_I2C;
@@ -560,24 +561,11 @@
 	return ret;
 }
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 25)
+/* dump eeprom */
 static int af9015_eeprom_dump(struct dvb_usb_device *d)
-#else
-/* hash (and dump) eeprom */
-static int af9015_eeprom_hash(struct usb_device *udev)
-#endif
 {
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 25)
 	u8 reg, val;
-#else
-	static const unsigned int eeprom_size = 256;
-	unsigned int reg;
-	int ret;
-	u8 val, *eeprom;
-	struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1, &val};
-#endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 25)
 	for (reg = 0; ; reg++) {
 		if (reg % 16 == 0) {
 			if (reg)
@@ -590,43 +578,9 @@
 			deb_info(KERN_CONT " --");
 		if (reg == 0xff)
 			break;
-#else
-	eeprom = kmalloc(eeprom_size, GFP_KERNEL);
-	if (eep

Re: Elgato EyeTV DTT deluxe v2 - i2c enumeration failed

2010-02-24 Thread Patrick Boettcher
On Wednesday 24 February 2010 21:23:45 Bringfried Stecklum wrote:
> Hi, I recently purchased the Elgato EyeTV DTT deluxe v2 stick. I am running
> Ubuntu 8.10 with Linux 2.6.28-15-generic. I installed v4l-dvb from
>  mercurial with a slight change of
>  linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h to account for the USB ID of
>  the device (#define USB_PID_ELGATO_EYETV_DTT_Dlx 0x002c). After insertion
>  the stick is recognized, however no frontend is activated since the i2c
>  enumeration failed. This might be related to a missing udev rule. 

Most likely Elgato has changed the USB ID of their product, because it is not 
the same product. In general (I'd say 50% of the cases) changing the USB ID is 
not the right solution to get the hardware work.

If you can, open the stick to see on which hardware the device is based on, or 
search the internet to find out.

If you're lucky another minor quirk in this or another driver is sufficient to 
make it work.

-- 
Patrick Boettcher - KernelLabs
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


[PULL] soc-camera: more patches for 2.6.34

2010-02-24 Thread Guennadi Liakhovetski
Hi Mauro

Here go the patches, that were missing in my last previous requests. And I 
still hope that also this time I've done everything right. My local 
soc-camera development branch was previously based off an earlier snapshot 
of your v4l development git tree. Now I have rebased that branch onto your 
current HEAD, applied the new patches, and pushed to linuxtv.org... It 
seems to have worked, but please, double-check whether it really has done 
everything right. If not - please, let me know. If everything is ok, I'll 
finally dlete my "fixes" tree from linuxtv.org.

The following changes since commit 0f857c8e41b32c27a5bb623cabad34f36afcb596:
  Guennadi Liakhovetski (1):
sh_mobile_ceu_camera: pass .set_parm and .get_parm down to subdevices

are available in the git repository at:

  ssh://linuxtv.org/git/gliakhovetski/soc-camera.git devel

Guennadi Liakhovetski (1):
  soc-camera: add runtime pm support for subdevices

Márton Németh (1):
  The first two parameters of soc_camera_limit_side() are usually pointers 
to struct v4l2_rect elements. They are signed, so adjust the prototype 
accordingly.

Valentin Longchamp (1):
  mt9t031: use runtime pm support to restore ADDRESS_MODE registers

 drivers/media/video/mt9t031.c  |   66 ++--
 drivers/media/video/mt9v022.c  |2 +-
 drivers/media/video/mx3_camera.c   |4 +-
 drivers/media/video/rj54n1cb0c.c   |   18 
 drivers/media/video/sh_mobile_ceu_camera.c |8 ++--
 drivers/media/video/soc_camera.c   |   18 +++-
 include/media/soc_camera.h |   12 -
 7 files changed, 105 insertions(+), 23 deletions(-)

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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


Elgato EyeTV DTT deluxe v2 - i2c enumeration failed

2010-02-24 Thread Bringfried Stecklum

Hi, I recently purchased the Elgato EyeTV DTT deluxe v2 stick. I am running
Ubuntu 8.10 with Linux 2.6.28-15-generic. I installed v4l-dvb from mercurial
with a slight change of linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h to account
for the USB ID of the device (#define USB_PID_ELGATO_EYETV_DTT_Dlx 0x002c).
After insertion the stick is recognized, however no frontend is activated since
the i2c enumeration failed. This might be related to a missing udev rule. Any
support is appreciated. This is the corresponding part from dmesg

kernel: [24106.302688] usb 2-1: new high speed USB device using ehci_hcd and 
address 45
kernel: [24106.459222] usb 2-1: configuration #1 chosen from 1 choice
kernel: [24106.459730] dvb-usb: found a 'Elgato EyeTV Dtt Dlx PD378S' in cold 
state, will try to load a firmware
kernel: [24106.459738] usb 2-1: firmware: requesting dvb-usb-dib0700-1.20.fw
kernel: [24106.523808] dvb-usb: downloading firmware from file 
'dvb-usb-dib0700-1.20.fw'
kernel: [24106.733953] dib0700: firmware started successfully.
kernel: [24107.244517] dvb-usb: found a 'Elgato EyeTV Dtt Dlx PD378S' in warm 
state.
kernel: [24107.244631] dvb-usb: will pass the complete MPEG2 transport stream 
to the software demuxer.
kernel: [24107.244862] DVB: registering new adapter (Elgato EyeTV Dtt Dlx 
PD378S)
kernel: [24107.327206] dib0700: stk7070p_frontend_attach: 
dib7000p_i2c_enumeration failed.  Cannot continue
kernel: [24107.327211]
kernel: [24107.327216] dvb-usb: no frontend was attached by 'Elgato EyeTV Dtt 
Dlx PD378S'
kernel: [24107.327223] dvb-usb: Elgato EyeTV Dtt Dlx PD378S successfully 
initialized and connected.
kernel: [24107.327703] dib0700: ir protocol setup failed
kernel: [24130.411288] dvb-usb: Elgato EyeTV Dtt Dlx PD378S successfully 
deinitialized and disconnected.


--
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


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2010-02-24 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Wed Feb 24 19:01:07 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14233:2e0444bf93a4
gcc version: i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os: 2.6.32.5

linux-2.6.32.6-armv5: OK
linux-2.6.33-rc5-armv5: OK
linux-2.6.32.6-armv5-davinci: WARNINGS
linux-2.6.33-rc5-armv5-davinci: WARNINGS
linux-2.6.32.6-armv5-dm365: ERRORS
linux-2.6.33-rc5-armv5-dm365: ERRORS
linux-2.6.32.6-armv5-ixp: OK
linux-2.6.33-rc5-armv5-ixp: OK
linux-2.6.32.6-armv5-omap2: OK
linux-2.6.33-rc5-armv5-omap2: OK
linux-2.6.22.19-i686: OK
linux-2.6.23.17-i686: OK
linux-2.6.24.7-i686: OK
linux-2.6.25.20-i686: OK
linux-2.6.26.8-i686: OK
linux-2.6.27.44-i686: OK
linux-2.6.28.10-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: OK
linux-2.6.32.6-i686: OK
linux-2.6.33-rc5-i686: OK
linux-2.6.32.6-m32r: OK
linux-2.6.33-rc5-m32r: OK
linux-2.6.32.6-mips: OK
linux-2.6.33-rc5-mips: OK
linux-2.6.32.6-powerpc64: WARNINGS
linux-2.6.33-rc5-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: OK
linux-2.6.23.17-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.20-x86_64: OK
linux-2.6.26.8-x86_64: OK
linux-2.6.27.44-x86_64: OK
linux-2.6.28.10-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: OK
linux-2.6.32.6-x86_64: OK
linux-2.6.33-rc5-x86_64: OK
spec: OK
sparse (v4l-dvb-git): ERRORS
sparse (linux-2.6.33-rc5): ERRORS
linux-2.6.16.62-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: OK
linux-2.6.19.7-i686: OK
linux-2.6.20.21-i686: OK
linux-2.6.21.7-i686: OK
linux-2.6.16.62-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: OK
linux-2.6.19.7-x86_64: OK
linux-2.6.20.21-x86_64: OK
linux-2.6.21.7-x86_64: OK

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
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: [PATCH v7 6/6] V4L: Events: Add documentation

2010-02-24 Thread Sakari Ailus
Randy Dunlap wrote:
> On 02/22/10 15:01, Sakari Ailus wrote:
>> Add documentation on how to use V4L2 events, both for V4L2 drivers and for
>> V4L2 applications.

Thanks for the comments, Randy! I'll put the fixes to the next version.

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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


[PATCH] cx88: increase BUFFER_TIMEOUT to 2 seconds

2010-02-24 Thread Marton Balint
# HG changeset patch
# User Marton Balint 
# Date 1267027831 -3600
# Node ID 5013801372b14e3d143955c04108d450323eb2de
# Parent  2e0444bf93a4a93e5e9363d43e6f6e9d451fa9bc
cx88: increase BUFFER_TIMEOUT to 2 seconds

From: Marton Balint 

When temporarily there is no video signal, sometimes it takes more than 0.5
secs for the cx88 chip to generate a single frame. If a dma timeout occurs
during recording, it confuses the recording application (at least mencoder) and
the recording stops. Since there is already an ifdefed-out 2 second buffer
timeout in the code, re-enabling that seemed the most simple solution.

Priority: normal

Signed-off-by: Marton Balint 

diff -r 2e0444bf93a4 -r 5013801372b1 linux/drivers/media/video/cx88/cx88.h
--- a/linux/drivers/media/video/cx88/cx88.h Mon Feb 22 10:58:43 2010 -0300
+++ b/linux/drivers/media/video/cx88/cx88.h Wed Feb 24 17:10:31 2010 +0100
@@ -290,10 +290,7 @@
 #define RESOURCE_VIDEO 2
 #define RESOURCE_VBI   4
 
-#define BUFFER_TIMEOUT msecs_to_jiffies(500)  /* 0.5 seconds */
-#if 0
 #define BUFFER_TIMEOUT msecs_to_jiffies(2000)
-#endif
 
 /* buffer for one video frame */
 struct cx88_buffer {
--
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: [linux-dvb] soft demux device

2010-02-24 Thread ozgur cagdas
Lovely! It worked straight away, at least happily created the nodes :) I'm 
hoping to give an update after I manage to find sometime to play with it.

On the other hand, as a small note, I've applied your patch ( 
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/16540 
) on top of the latest hg clone but linux/drivers/media/dvb/Makefile patch 
failed. It's a very simple patch to apply manually though.

Cheers,

Ozgur.



- Original Message 
From: Andy Walls 
To: linux-media@vger.kernel.org
Cc: linux-...@linuxtv.org
Sent: Wed, February 24, 2010 1:22:32 PM
Subject: Re: [linux-dvb] soft demux device

On Wed, 2010-02-24 at 03:57 -0800, ozgur cagdas wrote:
> Hi,
> 
> Thanks very much for the previous information. To give it a go just as
> it is, I've loaded dvb_dummy_fe module manually and many other modules
> including dvb_core as well, but no hope, don't have /dev/dvb folder
> yet. As I've mentioned earlier, I do not have a hardware at the
> moment, so I should trigger loading of proper modules manually. In my
> scenario, which modules should I load? Any simple set of modules
> that'd create necessary /dev/dvb/ and subsequent would do for me. If
> it matters, I am using 2.6.31 kernel and ubuntu 9.10 distribution.

See my dvb_dummy_adapter patch I just posted to the list.

Regards,
Andy

> Cheers,
> 
> Ozgur.
> 
> 
>  
> 
> ___
> linux-dvb users mailing list
> For V4L/DVB development, please use instead linux-media@vger.kernel.org
> linux-...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> 


___
linux-dvb users mailing list
For V4L/DVB development, please use instead linux-media@vger.kernel.org
linux-...@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb



  
--
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: [linux-dvb] soft demux device

2010-02-24 Thread Roland Mieslinger
Hi,

> I have just compiled v4l-dvb successfully. My aim is to develop some 
> experimental dvb applications on top of this dvb kernel api. Initially, I do 
> not want to use any hardware and would like to play with the recorded ts 
> files I have. So, is there any software demux device available within this 
> package or somewhere else? If so, how can I load this device and make it work 
> on a given ts file circularly? On the other hand, I have no /dev/dvb node  at 
> the moment, so should I do anything for this or would loading the driver 
> create it automatically?
> 
> Thanks in advance.
> 
> Cheers,
> 
> Ozgur.

maybe this is a good starting point for you:

 "I wrote a Linux kernel module which provides one or more 
  virtual DVB adapters. When loaded, it creates a char device 
  of the form /dev/dvbloop for every virtual DVB adapter.
  All Transport Stream packets written to a char device will
  be delivered on the corresponding virtual DVB adapter.

  You can get the sources at
  http://cpn.dyndns.org/projects/dvbloop.shtml

  Maybe somebody finds it useful.

  Cheers,
  Christian.
  -- 
  Christian Praehauser"

the link seems to be outdated, but the following is still
working https://svn.baycom.de/repos/dvbloop/.

A S2API patch is out as well:
http://www.vdrportal.de/board/attachment.php?attachmentid=24024

I've no idea if this is working well or not, I'm not using it myself.
YMWV

Roland

--
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: [linux-dvb] cx23885 / HVR 1200 - A/V Inputs?

2010-02-24 Thread Devin Heitmueller
On Wed, Feb 24, 2010 at 10:34 AM, Jean-Michel Bruenn
 wrote:
> Hello Devin,
>
> thanks for your answer. Might i be able to help a bit? Whats missing?
>
> Cheers,
> Jean

Hi Jean,

At this point, what really needs to happen is a developer who is
familiar with the internals of the cx23885 (and has the datasheets)
needs to sit down and spend a few days debugging the driver.  I've
been too swamped with commercial projects to spend any real time on it
(although that's the sort of problem that would get solved faster if
some commercial party threw some money at the problem).  Since I'm
only really working on it in my free time, it's the sort of situation
where it'll start working "when I finally get around to it".

For what it's worth, most of the work I'm doing for the HVR-1800 is
common to the 1200/1250 as well in terms of the bugs I'm fixing would
be common to both.

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: [linux-dvb] cx23885 / HVR 1200 - A/V Inputs?

2010-02-24 Thread Jean-Michel Bruenn

Hello Devin,

thanks for your answer. Might i be able to help a bit? Whats missing?

Cheers,
Jean

Devin Heitmueller wrote:

On Wed, Feb 24, 2010 at 10:24 AM, Jean-Michel Bruenn
 wrote:
  

Hello,

i wanted to ask whether theres some progress or status on the cx23885
driver. DVB-T is working fine,
however - i'm currently interested into the A/V Inputs. Maybe there's some
alpha/beta thing to test?

http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1200

Talking about this card and would like to use the A/V Inputs.



Hi Jean,

No, there hasn't really been any progress in this area.  I've started
doing some work on the 23885 tree for the HVR-1800, all of which is
work applicable for the 1200/1250.  But frankly those cards are a
relatively low priority on my todo list and I'm only working on it in
the background.

Cheers,

Devin

  


--
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: [linux-dvb] cx23885 / HVR 1200 - A/V Inputs?

2010-02-24 Thread Devin Heitmueller
On Wed, Feb 24, 2010 at 10:24 AM, Jean-Michel Bruenn
 wrote:
> Hello,
>
> i wanted to ask whether theres some progress or status on the cx23885
> driver. DVB-T is working fine,
> however - i'm currently interested into the A/V Inputs. Maybe there's some
> alpha/beta thing to test?
>
> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1200
>
> Talking about this card and would like to use the A/V Inputs.

Hi Jean,

No, there hasn't really been any progress in this area.  I've started
doing some work on the 23885 tree for the HVR-1800, all of which is
work applicable for the 1200/1250.  But frankly those cards are a
relatively low priority on my todo list and I'm only working on it in
the background.

Cheers,

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: [ANNOUNCE] git tree repositories & libv4l

2010-02-24 Thread Patrick Boettcher

Hi all,

On Wed, 24 Feb 2010, Mauro Carvalho Chehab wrote:

I know that was mentioned then, but re-thinking this, as this will all
be Linux specific, I don't really see a need for autotools atm, and as
I personally find autotools a bit overcomplicated. I would like to try
just using plain Makefiles for now. If it turns out this does not work
we can always switch to autotools later.


I suspect it won't work fine. There are some library dependencies at
utils/contrib, like libsysfs and libqt stuff. The build system should or
refuse to compile or disable some of those tools if the dependencies are
missing.


Have a look at cmake: cmake.org . It is extremely powerful in terms of 
external-library--detection, it can do QT natively and all other things 
around library generation and dependencies.


Cmake has become my favorite build-tool for user-space development.

Just my 2cts.

--

Patrick Boettcher - 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: Requested feedback on V4L2 driver design

2010-02-24 Thread Hans Verkuil
On Wednesday 24 February 2010 15:34:19 Maupin, Chase wrote:
> Hans,
> 
> Some follow-up from the syslink team about the driver code in the git tree.
> 
> The only code to be referred on omapzoom that will actually be in the kernel 
is the Notify module. All the other code in multicore_ipc will actually move 
to user-side. The Notify module gives additional functionality over the basic 
mailbox driver to abstract the single physical event into multiple logical 
events. This enables multiple clients (one of which is the DSS driver) to use 
the single physical interrupt for multiple different purposes in a fully 
modular manner.

Hi Chase,

That is good news. Will it also switch to the standard linux mailbox code? I 
saw a patch on the omap mailinglist recently that replaced the DSPBRIDGE 
mailbox code with the kernel mailbox code.

I'm not sure whether this is applicable to the Notify code as well, but if it 
is, then that seems a sensible move.

Regards,

Hans

> 
> Sincerely,
> Chase Maupin
> Software Applications
> Catalog DSP Products
> e-mail: chase.mau...@ti.com
> phone: (281) 274-3285
> 
> For support:
> Forums - http://community.ti.com/forums/
> Wiki - http://wiki.davincidsp.com/
> 
> > -Original Message-
> > From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> > Sent: Tuesday, February 09, 2010 1:52 AM
> > To: Mauro Carvalho Chehab; laurent.pinch...@ideasonboard.com
> > Cc: Maupin, Chase; sakari.ai...@maxwell.research.nokia.com;
> > vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver
> > design (May contain non-TIers); linux-media@vger.kernel.org
> > Subject: Re: Requested feedback on V4L2 driver design
> > 
> > On Monday 08 February 2010 21:23:00 Mauro Carvalho Chehab wrote:
> > > Maupin, Chase wrote:
> > > > All,
> > > >
> > > > Texas Instruments (TI) is working on the design for the V4L2 capture
> > and display drivers for our next generation system-on-chip (SoC) processor
> > and would like to solicit your feedback.  Our new SoCs have been improved
> > to allow for higher video resolutions and greater frame rates.  To this
> > end the display hardware has been moved to a separate processing block
> > called the video processing subsystem (VPSS).  The VPSS will be running a
> > firmware image that controls the capture/display hardware and services
> > requests from one or more host processors.
> > > >
> > > > Moving to a remote processor for the processing of video input and
> > output data requires that commands to control the hardware be passed to
> > this processing block using some form of inter-processor communication
> > (IPC).  TI would like to solicit your feedback on proposal for the V4L2
> > driver design to get a feel for whether or not this design would be
> > accepted into the Linux kernel.  To this end we have put together an
> > overview of the design and usage on our wiki at
> > http://wiki.davincidsp.com/index.php/Video_Processing_Subsystem_Driver_Des
> > ign.  We would greatly appreciate feedback from community members on the
> > acceptability of our driver design.
> > > >
> > > > If you have additional questions or need more information please feel
> > free to contact us (we have setup a mailing list at
> > vpss_driver_des...@list.ti.com) so we can answer them.
> > > >
> > >
> > > Hi Chase,
> > >
> > > I'm not sure if I got all the details on your proposal, so let me try to
> > give my
> > > understanding.
> > >
> > > First of all, for normal usage (e.g. capturing a stream or sending an
> > stream
> > > to an output device), the driver should work with only the standard V4L2
> > API.
> > > I'm assuming that the driver will provide this capability.
> > >
> > > I understand that, being a SoC hardware, there are much more that can be
> > done
> > > than just doing the normal stream capture/output, already supported by
> > V4L2 API.
> > >
> > > For such advanced usages, we're open to a proposal to enhance the
> > existing API
> > > to support the needs. There are some important aspects that need to be
> > considered
> > > when designing any Linux userspace API's:
> > 
> > The full functionality of this device can be handled by the proposals made
> > during
> > last year's LPC and that are currently being implemented/prototyped for
> > omap3.
> > That's no coincidence, by the way :-)
> > 
> > >
> > >   1) kernel-userspace API's are forever. So, they need to be designed
> > in
> > > a way that new technology changes won't break the old API;
> > >
> > >   2) API's are meant to be generic. So, they needed to be designed in
> > a way
> > > that, if another hardware with similar features require an API, the
> > planned one
> > > should fit;
> > >
> > >   3) The API's should be, as much as possible, independent of the
> > hardware
> > > architecture. You'll see that even low-level architecture dependent
> > stuff, like
> > > bus drivers are designed in a way that they are not bound to a
> > particular hardware,
> > > but instead provide the same common met

RE: Requested feedback on V4L2 driver design

2010-02-24 Thread Maupin, Chase
Hans,

Some follow-up from the syslink team about the driver code in the git tree.

The only code to be referred on omapzoom that will actually be in the kernel is 
the Notify module. All the other code in multicore_ipc will actually move to 
user-side. The Notify module gives additional functionality over the basic 
mailbox driver to abstract the single physical event into multiple logical 
events. This enables multiple clients (one of which is the DSS driver) to use 
the single physical interrupt for multiple different purposes in a fully 
modular manner.

Sincerely,
Chase Maupin
Software Applications
Catalog DSP Products
e-mail: chase.mau...@ti.com
phone: (281) 274-3285

For support:
Forums - http://community.ti.com/forums/
Wiki - http://wiki.davincidsp.com/

> -Original Message-
> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> Sent: Tuesday, February 09, 2010 1:52 AM
> To: Mauro Carvalho Chehab; laurent.pinch...@ideasonboard.com
> Cc: Maupin, Chase; sakari.ai...@maxwell.research.nokia.com;
> vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver
> design (May contain non-TIers); linux-media@vger.kernel.org
> Subject: Re: Requested feedback on V4L2 driver design
> 
> On Monday 08 February 2010 21:23:00 Mauro Carvalho Chehab wrote:
> > Maupin, Chase wrote:
> > > All,
> > >
> > > Texas Instruments (TI) is working on the design for the V4L2 capture
> and display drivers for our next generation system-on-chip (SoC) processor
> and would like to solicit your feedback.  Our new SoCs have been improved
> to allow for higher video resolutions and greater frame rates.  To this
> end the display hardware has been moved to a separate processing block
> called the video processing subsystem (VPSS).  The VPSS will be running a
> firmware image that controls the capture/display hardware and services
> requests from one or more host processors.
> > >
> > > Moving to a remote processor for the processing of video input and
> output data requires that commands to control the hardware be passed to
> this processing block using some form of inter-processor communication
> (IPC).  TI would like to solicit your feedback on proposal for the V4L2
> driver design to get a feel for whether or not this design would be
> accepted into the Linux kernel.  To this end we have put together an
> overview of the design and usage on our wiki at
> http://wiki.davincidsp.com/index.php/Video_Processing_Subsystem_Driver_Des
> ign.  We would greatly appreciate feedback from community members on the
> acceptability of our driver design.
> > >
> > > If you have additional questions or need more information please feel
> free to contact us (we have setup a mailing list at
> vpss_driver_des...@list.ti.com) so we can answer them.
> > >
> >
> > Hi Chase,
> >
> > I'm not sure if I got all the details on your proposal, so let me try to
> give my
> > understanding.
> >
> > First of all, for normal usage (e.g. capturing a stream or sending an
> stream
> > to an output device), the driver should work with only the standard V4L2
> API.
> > I'm assuming that the driver will provide this capability.
> >
> > I understand that, being a SoC hardware, there are much more that can be
> done
> > than just doing the normal stream capture/output, already supported by
> V4L2 API.
> >
> > For such advanced usages, we're open to a proposal to enhance the
> existing API
> > to support the needs. There are some important aspects that need to be
> considered
> > when designing any Linux userspace API's:
> 
> The full functionality of this device can be handled by the proposals made
> during
> last year's LPC and that are currently being implemented/prototyped for
> omap3.
> That's no coincidence, by the way :-)
> 
> >
> > 1) kernel-userspace API's are forever. So, they need to be designed
> in
> > a way that new technology changes won't break the old API;
> >
> > 2) API's are meant to be generic. So, they needed to be designed in
> a way
> > that, if another hardware with similar features require an API, the
> planned one
> > should fit;
> >
> > 3) The API's should be, as much as possible, independent of the
> hardware
> > architecture. You'll see that even low-level architecture dependent
> stuff, like
> > bus drivers are designed in a way that they are not bound to a
> particular hardware,
> > but instead provide the same common methods to interact with the
> hardware to other
> > device drivers.
> >
> > That's said, it would be interesting if you could give us a more deep
> detail on
> > what kind of functionalities and how do you think you'll be implementing
> them.
> 
> For me the core issue will be the communication between the main ARM and
> the ARM
> controlling the VPSS. Looking at the syslink part of the git tree it all
> looks
> way overengineered to me. In particular the multicore_ipc directory. Is
> all that
> code involved in setting up the communication path between the main and
> VPSS ARM?
> Is there some more det

Re: [ANNOUNCE] git tree repositories & libv4l

2010-02-24 Thread Brandon Philips
On 13:55 Wed 24 Feb 2010, Hans de Goede wrote:
> On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
> >Hans de Goede wrote:
> >The better here is to have the latest kernel headers copied on the tree.
> >This way, it is possible to compile libv4l2 with an older kernel version and
> >later upgrade the kernel, if needed, or to use a fast machine to compile
> >it, and then use it on another machine.
> >
> 
> If possible I would like to avoid this, afaik no other userspace
> utility packages are doing this.

Off the top of my head I know ethtool does this. It greatly simplifies
the work of maintaing the package:

  
http://git.kernel.org/?p=network/ethtool/ethtool.git;a=blob;f=ethtool-copy.h;h=09dd5480ff3488214ab67ad04459541314291f79;hb=HEAD

> Where necessary libv4l currently has code snippets like:
> 
> #ifndef V4L2_PIX_FMT_SPCA501
> #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
> #endif

I don't think this is less work than copying the header file from the
Kernel. Test building under all versions of the Kernel headers that
exist to make sure something isn't missed isn't possible. It really is
easier just to sync the header file up.

> The reason for this is that I want to avoid carrying a copy of a dir
> from some other tree, with all getting stale and needing sync all
> the time issues that come with that, not to mention chicken and egg
> problems in the case of new formats which simultaneously need to be
> added to both libv4l and the kernel.

Worst case is that if it is stale then it won't build since it depends
on fancy new feature XYZ. But, at least it won't build on all systems
instead of randomly breaking based on installed kernel headers
version.

> For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it
> hits any official v4l-dvb kernel tree, with the:

Please don't add features to releases before they are merged with
Linus. It would suck to ship a copy of libv4l that has a different
idea of structs or constants then the upstream Kernel.

> Approach this works fine, if I were to carry an include tree copy, that would
> now need to become a patched include tree copy, and with the next sync I then
> need to ensure that any needed patches are either already in the sync source,
> or applied again.

Or just fix it upstream with #ifdef __KERNEL__ tags once and for all,
right?

Cheers,

Brandon
--
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: [ANNOUNCE] git tree repositories & libv4l

2010-02-24 Thread Mauro Carvalho Chehab
Hans de Goede wrote:
> Hi,
> 
> On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
>> Hans de Goede wrote:
>>> Hi,
>>>
>>> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
 Hans de Goede wrote:

> Ok, so this will give me a local tree, how do I get this onto
> linuxtv.org ?

 I added it. In thesis, it is open for commit to you, me, hverkuil and
 dougsland.

>>>
>>> I see good, thanks! Can someone (Douglas ?) with better hg / git powers
>>> then me please
>>> somehow import all the libv4l changes from:
>>> http://linuxtv.org/hg/~hgoede/libv4l
>>
>> Ok, I added there. The procedure were simple: I ran Brandon script again,
>> but after pulling from your tree. Then, I used git format-patch to
>> generate
>> a quilt series, and used git quiltimport on the correct -git tree.
>>
> 
> Thanks!
> 
> 
>>> Once that is done I'll retire my own tree, and move all my userspace
>>> work to
>>> the git tree.
>>>
>>> For starters I plan to create / modify Makefiles so that everything will
>>> build
>>> out of the box, and has proper make install targets which can be used by
>>> distro's
>>>
>>> So:
>>> -proper honoring of CFLAGS
>>> -work with standard (and possibly somewhat older kernel headers)
>>> -honor DESTDIR, PREFIX and LIBDIR when doing make install
>>
>> The better here is to have the latest kernel headers copied on the tree.
>> This way, it is possible to compile libv4l2 with an older kernel
>> version and
>> later upgrade the kernel, if needed, or to use a fast machine to compile
>> it, and then use it on another machine.
>>
> 
> If possible I would like to avoid this, afaik no other userspace utility
> packages
> are doing this.
> 
> Where necessary libv4l currently has code snippets like:
> 
> #ifndef V4L2_PIX_FMT_SPCA501
> #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per
> line */
> #endif
> 
> So libv4l (in its current state) will already compile fine with older
> kernel
> headers. I expect that the other utilities will not need a lot of
> recent kernel ABI. So for now I would like to try and extend the above
> approach
> to the other utilities.

I think build will fail. I remember I had some such troubles when compiling
it against RHEL5, before we did the merge with the in-tree videodev2.h.

It should be reminded that, when people upgrade their kernels by hand,
they generally don't run "make headers_install". So, the kernel headers
on /usr/include/linux are the ones found on the original distro kernel,
and not the ones that are needed by the user.

> The reason for this is that I want to avoid carrying a copy of a dir
> from some
> other tree, with all getting stale and needing sync all the time issues
> that
> come with that,

The sync problem will keep existing, since some of the tools from
this tree are used as examples on media-specs.

> not to mention chicken and egg problems in the case of
> new formats which simultaneously  need to be added to both libv4l and
> the kernel.
> 
> For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l,
> before it
> hits any official v4l-dvb kernel tree, with the:
> #ifndef V4L2_PIX_FMT_SPCA501
> #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per
> line */
> #endif
> 
> Approach this works fine, if I were to carry an include tree copy, that
> would
> now need to become a patched include tree copy, and with the next sync I
> then
> need to ensure that any needed patches are either already in the sync
> source,
> or applied again.

True, but the additional work for those occasional changes are minimum, and
may save some time when handling complains about why the tree don't build
on his machine.

-- 

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: [ANNOUNCE] git tree repositories & libv4l

2010-02-24 Thread Hans Verkuil

> Hi,
>
> On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:
>> Hans de Goede wrote:
>>> Hi,
>>>
>>> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
 Hans de Goede wrote:

> Ok, so this will give me a local tree, how do I get this onto
> linuxtv.org ?

 I added it. In thesis, it is open for commit to you, me, hverkuil and
 dougsland.

>>>
>>> I see good, thanks! Can someone (Douglas ?) with better hg / git powers
>>> then me please
>>> somehow import all the libv4l changes from:
>>> http://linuxtv.org/hg/~hgoede/libv4l
>>
>> Ok, I added there. The procedure were simple: I ran Brandon script
>> again,
>> but after pulling from your tree. Then, I used git format-patch to
>> generate
>> a quilt series, and used git quiltimport on the correct -git tree.
>>
>
> Thanks!
>
>
>>> Once that is done I'll retire my own tree, and move all my userspace
>>> work to
>>> the git tree.
>>>
>>> For starters I plan to create / modify Makefiles so that everything
>>> will
>>> build
>>> out of the box, and has proper make install targets which can be used
>>> by
>>> distro's
>>>
>>> So:
>>> -proper honoring of CFLAGS
>>> -work with standard (and possibly somewhat older kernel headers)
>>> -honor DESTDIR, PREFIX and LIBDIR when doing make install
>>
>> The better here is to have the latest kernel headers copied on the tree.
>> This way, it is possible to compile libv4l2 with an older kernel version
>> and
>> later upgrade the kernel, if needed, or to use a fast machine to compile
>> it, and then use it on another machine.
>>
>
> If possible I would like to avoid this, afaik no other userspace utility
> packages
> are doing this.
>
> Where necessary libv4l currently has code snippets like:
>
> #ifndef V4L2_PIX_FMT_SPCA501
> #define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line
> */
> #endif
>
> So libv4l (in its current state) will already compile fine with older
> kernel
> headers. I expect that the other utilities will not need a lot of
> recent kernel ABI. So for now I would like to try and extend the above
> approach
> to the other utilities.

Note that the v4l2-ctl and v4l2-dbg utilities often *do* track the latest
kernel. In particular v4l2-ctl is often used to control/test new features.

Regards,

 Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
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: [ANNOUNCE] git tree repositories & libv4l

2010-02-24 Thread Mauro Carvalho Chehab
Hans de Goede wrote:
> Hi,
> 
> On 02/24/2010 07:05 AM, Brandon Philips wrote:
>> On 16:51 Tue 23 Feb 2010, Hans de Goede wrote:
>>> On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:
 Hans de Goede wrote:

> Ok, so this will give me a local tree, how do I get this onto
> linuxtv.org ?

 I added it. In thesis, it is open for commit to you, me, hverkuil
 and dougsland.

>>>
>>> I see good, thanks! Can someone (Douglas ?) with better hg / git
>>> powers then me please somehow import all the libv4l changes from:
>>> http://linuxtv.org/hg/~hgoede/libv4l
>>>
>>> Once that is done I'll retire my own tree, and move all my userspace
>>> work to the git tree.
>>>
>>> For starters I plan to create / modify Makefiles so that everything
>>> will build out of the box, and has proper make install targets which
>>> can be used by distro's
>>>
>>> So:
>>> -proper honoring of CFLAGS
>>> -work with standard (and possibly somewhat older kernel headers)
>>> -honor DESTDIR, PREFIX and LIBDIR when doing make install
>>
>> Do you still want me to convert to autoconf? I was still planning on
>> doing that. We discussed it a month ago when this conversation
>> started.
>>
>> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009
>>
>>
> 
> I know that was mentioned then, but re-thinking this, as this will all
> be Linux specific, I don't really see a need for autotools atm, and as
> I personally find autotools a bit overcomplicated. I would like to try
> just using plain Makefiles for now. If it turns out this does not work
> we can always switch to autotools later.

I suspect it won't work fine. There are some library dependencies at 
utils/contrib, like libsysfs and libqt stuff. The build system should or
refuse to compile or disable some of those tools if the dependencies are
missing.

Of course you may create a non-autotools configure script that checks for
those libraries. They aren't many, so this approach works, but it will
likely require more time than using autotools.


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: Status of the patches under review (29 patches)

2010-02-24 Thread Andy Walls
On Wed, 2010-02-24 at 02:40 -0300, Mauro Carvalho Chehab wrote:
> Hi,
> 
> I suspect that Linus should be releasing the 2.6.33 kernel any time soon,
> so the next merge window is about to open. I've handled already everything
> on my pending queues. However, I missed some emails due to a crash on my 
> exim filter. Also, patchwork.kernel.org missed some emails due to some
> trouble there. So, maybe there are still some unnoticed pending stuff.

I had emailed some cx18 component video patches to the list.  They are
not critical for 2.6.34 but you can find them as the two most recent
patches here:

http://linuxtv.org/hg/~awalls/cx18-pvr2100-component/

Regards,
Andy

> If you still have any pending work for 2.6.34 that aren't merged nor
> are under review, please submit it ASAP, as patches received after the 
> release of 2.6.33 will likely be postponed to 2.6.35.
> 
> 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: [linux-dvb] soft demux device

2010-02-24 Thread Andy Walls
On Wed, 2010-02-24 at 03:57 -0800, ozgur cagdas wrote:
> Hi,
> 
> Thanks very much for the previous information. To give it a go just as
> it is, I've loaded dvb_dummy_fe module manually and many other modules
> including dvb_core as well, but no hope, don't have /dev/dvb folder
> yet. As I've mentioned earlier, I do not have a hardware at the
> moment, so I should trigger loading of proper modules manually. In my
> scenario, which modules should I load? Any simple set of modules
> that'd create necessary /dev/dvb/ and subsequent would do for me. If
> it matters, I am using 2.6.31 kernel and ubuntu 9.10 distribution.

See my dvb_dummy_adapter patch I just posted to the list.

Regards,
Andy

> Cheers,
> 
> Ozgur.
> 
> 
>   
> 
> ___
> linux-dvb users mailing list
> For V4L/DVB development, please use instead linux-media@vger.kernel.org
> linux-...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> 

--
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: Status of the patches under review (29 patches)

2010-02-24 Thread Mauro Carvalho Chehab
Hi Jean,

Jean Delvare wrote:
 
> I have 3 patches pending which aren't in your list. I can see them in
> patchwork:
> 
> http://patchwork.kernel.org/patch/79755/
> http://patchwork.kernel.org/patch/79754/
> http://patchwork.kernel.org/patch/77349/
> 
> The former two are in "Accepted" state, and actually I received an
> e-mail telling me they had been accepted, however I can't see them in
> the hg repository. So where are they?

They are already on the git tree:

commit 2887117b31b77ebe5fb42f95ea8d77a3716b405b
Author: Jean Delvare 
Date:   Tue Feb 16 14:22:37 2010 -0300

V4L/DVB: bttv: Let the user disable IR support

Add a new module parameter "disable_ir" to disable IR support. Several
other drivers do that already, and this can be very handy for
debugging purposes.

Signed-off-by: Jean Delvare 
Signed-off-by: Mauro Carvalho Chehab 

commit e151340a2a9e7147eb48114af0381122130266b0
Author: Jean Delvare 
Date:   Fri Feb 19 00:18:41 2010 -0300

V4L/DVB: bttv: Move I2C IR initialization

Move I2C IR initialization from just after I2C bus setup to right
before non-I2C IR initialization. This avoids the case where an I2C IR
device is blocking audio support (at least the PV951 suffers from
this). It is also more logical to group IR support together,
regardless of the connectivity.

This fixes bug #15184:
http://bugzilla.kernel.org/show_bug.cgi?id=15184

Signed-off-by: Jean Delvare 
CC: sta...@kernel.org
Signed-off-by: Mauro Carvalho Chehab 

As patches in -hg are manually backported, maybe Douglas
haven't backported it yet or he simply missed.

Douglas, could you please check this?

> The latter is in "Not Applicable" state, and I have no idea what it
> means. The patch is really simple and I see no formatting issue. Should
> I just resend it?

This means that this patch is not applicable on -git. There's no versions.txt
upstream. All patches that don't have upstream code are marked as such on
patchwork. I generally ping Douglas on such cases, for him to double check on
-hg.

Anyway, the better is to c/c to Douglas on all patches that are meant only
to the building system.

Douglas, could you please check if you've applied this patch?

-- 

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: [PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of operation

2010-02-24 Thread Muralidharan Karicheri
On Wed, Feb 24, 2010 at 12:37 AM, Hiremath, Vaibhav  wrote:
>
>> -Original Message-
>> From: Muralidharan Karicheri [mailto:mkarich...@gmail.com]
>> Sent: Wednesday, February 24, 2010 4:53 AM
>> To: Hiremath, Vaibhav
>> Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org;
>> hverk...@xs4all.nl; Karicheri, Muralidharan
>> Subject: Re: [PATCH-V1 09/10] VPFE Capture: Add support for USERPTR mode of
>> operation
>>
>> Vaibhav,
>>
>> There are changes to vpfe capture on Arago tree on top of this. For
>> example, vpfe_uservirt_to_phys() is removed and is replaced with
>> videobuf_iolock(). So please get the latest changes to upstream.
>>
> [Hiremath, Vaibhav] No, the Arago version doesn't support USERPTR mode at all,

Probably you are referring to the wrong tree. This code has gone
through test cycles and I prefer re-using the code as much as
possible. Check out below...

http://arago-project.org/git/people/sneha/linux-davinci-staging.git

My linux-davinci-video.git tree just track the upstream...

Murali
>
>
> 1386            if (V4L2_MEMORY_USERPTR == req_buf->memory) {
> 1386                 /* we don't support user ptr IO */
> 1387                 v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_reqbufs:"
> 1388                          " USERPTR IO not supported\n");
> 1389                 return  -EINVAL;
> 1390         }
>
> And also, I have received important comment from Mauro, which expects some 
> code tobe moved to generic VideoBuf layer. I will be submitting patch for the 
> same separately.


>
> Thanks,
> Vaibhav
>
>> Murali
>>
>> On Tue, Feb 23, 2010 at 3:34 AM,   wrote:
>> > From: Vaibhav Hiremath 
>> >
>> >
>> > Signed-off-by: Vaibhav Hiremath 
>> > Signed-off-by: Muralidharan Karicheri 
>> > ---
>> >  drivers/media/video/ti-media/vpfe_capture.c |   94
>> ++
>> >  1 files changed, 79 insertions(+), 15 deletions(-)
>> >
>> > diff --git a/drivers/media/video/ti-media/vpfe_capture.c
>> b/drivers/media/video/ti-media/vpfe_capture.c
>> > index cece265..7d4ab44 100644
>> > --- a/drivers/media/video/ti-media/vpfe_capture.c
>> > +++ b/drivers/media/video/ti-media/vpfe_capture.c
>> > @@ -538,7 +538,24 @@ static void vpfe_schedule_next_buffer(struct
>> vpfe_device *vpfe_dev)
>> >                                        struct videobuf_buffer, queue);
>> >        list_del(&vpfe_dev->next_frm->queue);
>> >        vpfe_dev->next_frm->state = VIDEOBUF_ACTIVE;
>> > -       addr = videobuf_to_dma_contig(vpfe_dev->next_frm);
>> > +       if (V4L2_MEMORY_USERPTR == vpfe_dev->memory)
>> > +               addr = vpfe_dev->cur_frm->boff;
>> > +       else
>> > +               addr = videobuf_to_dma_contig(vpfe_dev->next_frm);
>> > +
>> > +       ccdc_dev->hw_ops.setfbaddr(addr);
>> > +}
>> > +
>> > +static void vpfe_schedule_bottom_field(struct vpfe_device *vpfe_dev)
>> > +{
>> > +       unsigned long addr;
>> > +
>> > +       if (V4L2_MEMORY_USERPTR == vpfe_dev->memory)
>> > +               addr = vpfe_dev->cur_frm->boff;
>> > +       else
>> > +               addr = videobuf_to_dma_contig(vpfe_dev->cur_frm);
>> > +
>> > +       addr += vpfe_dev->field_off;
>> >        ccdc_dev->hw_ops.setfbaddr(addr);
>> >  }
>> >
>> > @@ -559,7 +576,6 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
>> >  {
>> >        struct vpfe_device *vpfe_dev = dev_id;
>> >        enum v4l2_field field;
>> > -       unsigned long addr;
>> >        int fid;
>> >
>> >        v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "\nStarting
>> vpfe_isr...\n");
>> > @@ -604,10 +620,7 @@ static irqreturn_t vpfe_isr(int irq, void *dev_id)
>> >                         * the CCDC memory address
>> >                         */
>> >                        if (field == V4L2_FIELD_SEQ_TB) {
>> > -                               addr =
>> > -                                 videobuf_to_dma_contig(vpfe_dev-
>> >cur_frm);
>> > -                               addr += vpfe_dev->field_off;
>> > -                               ccdc_dev->hw_ops.setfbaddr(addr);
>> > +                               vpfe_schedule_bottom_field(vpfe_dev);
>> >                        }
>> >                        goto clear_intr;
>> >                }
>> > @@ -1234,7 +1247,10 @@ static int vpfe_videobuf_setup(struct
>> videobuf_queue *vq,
>> >        struct vpfe_device *vpfe_dev = fh->vpfe_dev;
>> >
>> >        v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_buffer_setup\n");
>> > -       *size = config_params.device_bufsize;
>> > +       *size = vpfe_dev->fmt.fmt.pix.sizeimage;
>> > +       if (vpfe_dev->memory == V4L2_MEMORY_MMAP &&
>> > +               vpfe_dev->fmt.fmt.pix.sizeimage >
>> config_params.device_bufsize)
>> > +               *size = config_params.device_bufsize;
>> >
>> >        if (*count < config_params.min_numbuffers)
>> >                *count = config_params.min_numbuffers;
>> > @@ -1243,6 +1259,46 @@ static int vpfe_videobuf_setup(struct
>> videobuf_queue *vq,
>> >        return 0;
>> >  }
>> >
>> > +/*
>> > + * vpfe_uservirt_to_phys: 

Re: Status of the patches under review (29 patches)

2010-02-24 Thread Mauro Carvalho Chehab
Guennadi Liakhovetski wrote:
> Hi Mauro
> 
> On Wed, 24 Feb 2010, Mauro Carvalho Chehab wrote:
> 
>> Hi,
>>
>> I suspect that Linus should be releasing the 2.6.33 kernel any time soon,
>> so the next merge window is about to open. I've handled already everything
>> on my pending queues. However, I missed some emails due to a crash on my 
>> exim filter. Also, patchwork.kernel.org missed some emails due to some
>> trouble there. So, maybe there are still some unnoticed pending stuff.
> 
> Looks like you missed about two of my pull requests.
> 
>> If you still have any pending work for 2.6.34 that aren't merged nor
>> are under review, please submit it ASAP, as patches received after the 
>> release of 2.6.33 will likely be postponed to 2.6.35.
> 
> Namely:
> 
>>  == soc_camera patches - Waiting Guennadi 
>>  submission/review == 
>>
>> Feb, 9 2010: mt9t031: use runtime pm support to restore ADDRESS_MODE 
>> registers  http://patchwork.kernel.org/patch/77997
> 
> This one depends on my runtime-pm patch (which is not listed here btw), 
> which we didn't come to a consensus about, so, I think, I'll just push 
> both of them and let you decide whether or not to pull.

Yes, please do it. I'll keep it as "under review" for now.

> 
>> Feb,19 2010: v4l: soc_camera: fix bound checking of mbus_fmt[] index 
>>http://patchwork.kernel.org/patch/80757
> 
> This one 
> (http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/16068/match=pull+soc+camera)
>  

This one I missed. Applying it.

> and
> 
>> Feb, 2 2010: [1/3] soc-camera: mt9t112: modify exiting conditions from 
>> standby mode http://patchwork.kernel.org/patch/76212

This patch were applied only to the fixes.git tree:

commit 2b59125b1b5f8c9bb0524b8a0bdad4b780a239ac
Author: Kuninori Morimoto 
Date:   Tue Feb 2 13:17:54 2010 +0900

soc-camera: mt9t112: modify exiting conditions from standby mode

This polling is needed if camera is in standby mode, but current exiting
condition is inverted.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Guennadi Liakhovetski 
Signed-off-by: Mauro Carvalho Chehab 

I'll merge it back to v4l-dvb.git when merging 2.6.33, after its release.

Removed it from my queue, since it should be upstream already.

> this one are in fixes branch of 
> http://git.linuxtv.org/gliakhovetski/soc-camera.git?a=shortlog;h=refs/heads/fixes
>  
> which I asked you to pull in 
> http://www.spinics.net/lists/linux-media/msg16281.html
> 
>> Feb, 2 2010: [2/3] soc-camera: mt9t112: modify delay time after initialize   
>>http://patchwork.kernel.org/patch/76213
>> Feb, 2 2010: [3/3] soc-camera: mt9t112: The flag which control camera-init 
>> is   http://patchwork.kernel.org/patch/76214
> 
> These two have been put on hold by Morimoto-san.

Ok, I think I'll keep them at the "Under Review" status.

-- 

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: [ANNOUNCE] git tree repositories & libv4l

2010-02-24 Thread Hans de Goede

Hi,

On 02/24/2010 01:58 AM, Mauro Carvalho Chehab wrote:

Hans de Goede wrote:

Hi,

On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:

Hans de Goede wrote:


Ok, so this will give me a local tree, how do I get this onto
linuxtv.org ?


I added it. In thesis, it is open for commit to you, me, hverkuil and
dougsland.



I see good, thanks! Can someone (Douglas ?) with better hg / git powers
then me please
somehow import all the libv4l changes from:
http://linuxtv.org/hg/~hgoede/libv4l


Ok, I added there. The procedure were simple: I ran Brandon script again,
but after pulling from your tree. Then, I used git format-patch to generate
a quilt series, and used git quiltimport on the correct -git tree.



Thanks!



Once that is done I'll retire my own tree, and move all my userspace
work to
the git tree.

For starters I plan to create / modify Makefiles so that everything will
build
out of the box, and has proper make install targets which can be used by
distro's

So:
-proper honoring of CFLAGS
-work with standard (and possibly somewhat older kernel headers)
-honor DESTDIR, PREFIX and LIBDIR when doing make install


The better here is to have the latest kernel headers copied on the tree.
This way, it is possible to compile libv4l2 with an older kernel version and
later upgrade the kernel, if needed, or to use a fast machine to compile
it, and then use it on another machine.



If possible I would like to avoid this, afaik no other userspace utility 
packages
are doing this.

Where necessary libv4l currently has code snippets like:

#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
#endif

So libv4l (in its current state) will already compile fine with older kernel
headers. I expect that the other utilities will not need a lot of
recent kernel ABI. So for now I would like to try and extend the above approach
to the other utilities.

The reason for this is that I want to avoid carrying a copy of a dir from some
other tree, with all getting stale and needing sync all the time issues that
come with that, not to mention chicken and egg problems in the case of
new formats which simultaneously  need to be added to both libv4l and the 
kernel.

For example often I add support for V4L2_PIX_FMT_NEW_FOO to libv4l, before it
hits any official v4l-dvb kernel tree, with the:
#ifndef V4L2_PIX_FMT_SPCA501
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S','5','0','1') /* YUYV per line */
#endif

Approach this works fine, if I were to carry an include tree copy, that would
now need to become a patched include tree copy, and with the next sync I then
need to ensure that any needed patches are either already in the sync source,
or applied again.

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: [ANNOUNCE] git tree repositories & libv4l

2010-02-24 Thread Hans de Goede

Hi,

On 02/24/2010 07:05 AM, Brandon Philips wrote:

On 16:51 Tue 23 Feb 2010, Hans de Goede wrote:

On 02/23/2010 04:37 PM, Mauro Carvalho Chehab wrote:

Hans de Goede wrote:


Ok, so this will give me a local tree, how do I get this onto
linuxtv.org ?


I added it. In thesis, it is open for commit to you, me, hverkuil
and dougsland.



I see good, thanks! Can someone (Douglas ?) with better hg / git
powers then me please somehow import all the libv4l changes from:
http://linuxtv.org/hg/~hgoede/libv4l

Once that is done I'll retire my own tree, and move all my userspace
work to the git tree.

For starters I plan to create / modify Makefiles so that everything
will build out of the box, and has proper make install targets which
can be used by distro's

So:
-proper honoring of CFLAGS
-work with standard (and possibly somewhat older kernel headers)
-honor DESTDIR, PREFIX and LIBDIR when doing make install


Do you still want me to convert to autoconf? I was still planning on
doing that. We discussed it a month ago when this conversation
started.

http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/15009



I know that was mentioned then, but re-thinking this, as this will all
be Linux specific, I don't really see a need for autotools atm, and as
I personally find autotools a bit overcomplicated. I would like to try
just using plain Makefiles for now. If it turns out this does not work
we can always switch to autotools later.

Thanks for the offer though!

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


Install Sasc-NG in FC12

2010-02-24 Thread Aslam Mullapilly
Hi,

I'm trying to install Sasc-NG in my fedora 12. But no luck. It is showing 
Kernel error. 

Does anybody installed Sasc-NG in fedora 12 or in latest kernel?


Regards,

Aslam
--
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


Install Sasc-NG in FC12

2010-02-24 Thread Aslam Mullapilly
Hi,

I'm trying to install Sasc-NG in my fedora 12. But no luck. It is showing 
Kernel error. 

Does anybody installed Sasc-NG in fedora 12 or in latest kernel?


Regards,

Aslam
--
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: Status of the patches under review (29 patches)

2010-02-24 Thread Jean Delvare
Hi Mauro,

On Wed, 24 Feb 2010 02:40:00 -0300, Mauro Carvalho Chehab wrote:
> Hi,
> 
> I suspect that Linus should be releasing the 2.6.33 kernel any time soon,
> so the next merge window is about to open. I've handled already everything
> on my pending queues. However, I missed some emails due to a crash on my 
> exim filter. Also, patchwork.kernel.org missed some emails due to some
> trouble there. So, maybe there are still some unnoticed pending stuff.
> 
> If you still have any pending work for 2.6.34 that aren't merged nor
> are under review, please submit it ASAP, as patches received after the 
> release of 2.6.33 will likely be postponed to 2.6.35.

I have 3 patches pending which aren't in your list. I can see them in
patchwork:

http://patchwork.kernel.org/patch/79755/
http://patchwork.kernel.org/patch/79754/
http://patchwork.kernel.org/patch/77349/

The former two are in "Accepted" state, and actually I received an
e-mail telling me they had been accepted, however I can't see them in
the hg repository. So where are they?

The latter is in "Not Applicable" state, and I have no idea what it
means. The patch is really simple and I see no formatting issue. Should
I just resend it?

Thanks,
-- 
Jean Delvare
--
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


failing videobuf_iolock() in multiple drivers - wrong error processing?

2010-02-24 Thread Guennadi Liakhovetski
Looking at .buf_prepare() videobuf_queue_ops methods I cannot understand, 
why if videobuf_iolock() fails they all call some internal buffer freeing 
function, that, among others, also calls some nideobuf-specific free 
function... Is this really needed, if yes - why?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: [PATCH] gspca pac7302: add USB PID range based on heuristics

2010-02-24 Thread Németh Márton
Hi,
Jean-Francois Moine wrote:
> On Wed, 24 Feb 2010 08:09:41 +0100
> Németh Márton  wrote:
> 
>> On the schematics in PixArt PAC7301/PAC7302 datasheet
>> (http://www.pixart.com.tw/upload/PAC7301_7302%20%20Spec%20V1_20091228174030.pdf)
>> pages 19, 20, 21 and 22 there is a note titled "PID IO_TRAP" which
>> describes the possible product ID range 0x2620..0x262f. In this range
>> there are some known webcams, however, there are some PIDs with
>> unknown or future devices. Because PixArt PAC7301/PAC7302 is a System
>> on a Chip (SoC) device is is probable that this driver will work
>> correctly independent of the used PID.
> 
> Hello,
> 
> I got such information from ms-win drivers. I appeared that most of the
> unknown/new webcams were never manufactured. Now, I wait for user
> requests before adding such webcams.

What about Genius iSlim 310? Based on the Windows driver this device is
a potential candidate for pac7302 driver, see
http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302#Identification

I don't have access to Genius iSlim 310 so I cannot tell it for sure.

Regards,

Márton Németh

--
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