Re: [PATCH v8 4/6] V4L: Events: Add backend
Sakari Ailus wrote: 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. Hi, Some style problems accidentally slipped into this one. I'm not resending the whole set, just the broken patch, now v8.1. -- 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 v8.1 4/6] V4L: Events: Add backend
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 sakari.ai...@maxwell.research.nokia.com
---
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..a0cadeb
--- /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 sakari.ai...@maxwell.research.nokia.com
+ *
+ * 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 media/v4l2-dev.h
+#include media/v4l2-fh.h
+#include media/v4l2-event.h
+
+#include linux/sched.h
+
+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--;
+
+
Re: Announcing v4l-utils-0.7.90 (which includes libv4l-0.7.90)
On 03/01/2010 08:45 AM, Hans Verkuil wrote: On Friday 26 February 2010 20:43:19 Hans de Goede wrote: Hi, I'm happy to announce the first (test / beta) release of v4l-utils, v4l-utils is the combination of various v4l and dvb utilities which used to be part of the v4l-dvb mercurial kernel tree and libv4l. Is it correct that I only see v4l utilities and no dvb? I just went with was already put in the repo by Mauro and Douglas. I'm fine with adding dvb utilities, but I don't feel it is my place to decide to do that. I encourage people to give this version a spin. I esp. would like feedback on which v4l / dvb utilities should end up being installed by make install. For now I've stuck with what the Makefile in v4l2-apps did. See README for a list of all utilities and if they are currently installed or not. qv4l2-qt3 should either be dropped altogether (my preference, although Mauro thinks differently), or be moved to contrib. I think it is nuts to keep that one around since the qt4 version is much, much better and the qt3 version is no longer maintained anyway. Well currently it compiles on recent distro's without issues, so I'm fine with keeping things as is for now, if this becomes a maintenance burden it can always be moved to contrib later. xc3028-firmware, v4l2-compliance and rds should also be moved to contrib. I'm fine with moving xc3028-firmware and rds there. But v4l2-compliance sounds like something that could be useful I've no idea how useful it actually is though, I have not tested it. I'm not sure about decode_tm6000, keytable and v4l2-sysfs-path. These too may belong to contrib. Ack for decode_tm6000 (if that is useful it should be turned into a lib) and I have no clue what v4l2-sysfs-path does. keytable might be usefull, well at least the keycode tables. The tool it self seems to overlap with other evdev utilities in distro's so maybe we should put the keycode tables in some sort of standard format, and drop keytable itself ? We definitely want to have alevtv here as well (it's currently in dvb-apps). See above. snip You can always find the latest developments here: http://git.linuxtv.org/v4l-utils.git Hmm, I get errors when I attempt to clone this. Hmm, I had the same issue myself when using ssh+git, I had to use: git+ssh://hgo...@linuxtv.org/git/v4l-utils Notice the /git/ (and no .git at the end) 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: How do private controls actually work?
Hi Devin, On Monday 01 March 2010 03:56:17 Devin Heitmueller wrote: This might seem like a bit of a silly question, but I've been banging my head on the wall for a while on this. I need to add a single private control to the saa7115 driver. However, it's not clear to me exactly how this is supposed to work. The v4l2-ctl program will always use the extended controls interface for private controls, since the code only uses the g_ctrl ioctl if the class is V4L2_CTRL_CLASS_USER (and the control class for private controls is V4L2_CID_PRIVATE_BASE). However, if you look at the actual code in v4l2-ioctl.c, the call for g_ext_ctrls calls check_ext_ctrls(), which fails because V4L2_CID_PRIVATE_BASE cannot be used as control class when using extended controls. The above two behaviors would seem to be conflicting. I don't think it should matter which API (the base one or the extended one) you use for controls, be they private, standard or whatever. I don't see a reason for disallowing some controls to be used through one or the other API. My original plan was to implement it as a non-extended control, but the v4l2-ctl application always sent the get call using the extended interface. So then I went to convert saa7115 to use the extended control interface, but then found out that the v4l2 core wouldn't allow an extended control to use a private control number. To make matters worse, the G_CTRL function that supposedly passes through calls to vidioc_g_ext_ctrl also calls check_ext_ctrl(), so if you want to have a private control then you would need to implement both the extended controls interface and the older g_ctrl in the driver (presumably the idea was that you would be able to only need to implement an extended controls interface, but that doesn't work given the above). I can change v4l2-ctl to use g_ctrl for private controls if we think that is the correct approach. But I didn't want to do that until I knew for sure that it is correct that you can never have a private extended control. Do we have extended *controls* ? All I see today is two APIs to access controls, a base *control API* and an extended *control API*. G_CTRL/S_CTRL should always be available to userspace. If you want to set a single control, the extended API isn't required. -- Regards, Laurent Pinchart -- 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 1/3] add feedback LED control
Hi Márton,
On Sunday 28 February 2010 08:55:04 Németh Márton wrote:
From: Márton Németh nm...@freemail.hu
On some webcams a feedback LED can be found. This LED usually shows
the state of streaming mode: this is the Auto mode. The LED can
be programmed to constantly switched off state (e.g. for power saving
reasons, preview mode) or on state (e.g. the application shows motion
detection or on-air).
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r d8fafa7d88dc linux/Documentation/DocBook/v4l/controls.xml
--- a/linux/Documentation/DocBook/v4l/controls.xmlThu Feb 18 19:02:51
2010
+0100 +++ b/linux/Documentation/DocBook/v4l/controls.xml Sun Feb 28
08:41:17 2010 +0100 @@ -311,6 +311,17 @@
Applications depending on particular custom controls should check the
driver name and version, see xref linkend=querycap /./entry
/row
+ row id=v4l2-led
+ entryconstantV4L2_CID_LED/constant/entry
+ entryenum/entry
+ entryControls the feedback LED on the camera. In auto mode
+the LED is on when the streaming is active. The LED is off when not
streaming. +The LED can be also turned on and off independent from
streaming. +Possible values for constantenum v4l2_led/constant are:
+constantV4L2_CID_LED_AUTO/constant (0),
+constantV4L2_CID_LED_ON/constant (1) and
+constantV4L2_CID_LED_OFF/constant (2)./entry
+ /row
There's more than just auto, on and off. On Logitech webcams, LEDs can be
configured to blink as well.
/tbody
/tgroup
/table
diff -r d8fafa7d88dc linux/Documentation/DocBook/v4l/videodev2.h.xml
--- a/linux/Documentation/DocBook/v4l/videodev2.h.xml Thu Feb 18 19:02:51
2010 +0100 +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml Sun Feb
28 08:41:17 2010 +0100 @@ -1024,8 +1024,14 @@
#define V4L2_CID_ROTATE (V4L2_CID_BASE+34)
#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35)
+#define V4L2_CID_LED(V4L2_CID_BASE+36)
+enum v4l2_led {
+V4L2_LED_AUTO = 0,
+V4L2_LED_ON = 1,
+V4L2_LED_OFF= 2,
+};
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+37)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG |
0x900) diff -r d8fafa7d88dc linux/drivers/media/video/v4l2-common.c
--- a/linux/drivers/media/video/v4l2-common.c Thu Feb 18 19:02:51 2010
+0100 +++ b/linux/drivers/media/video/v4l2-common.c Sun Feb 28 08:41:17
2010 +0100 @@ -349,6 +349,12 @@
75 useconds,
NULL,
};
+ static const char *led[] = {
+ Auto,
+ On,
+ Off,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -389,6 +395,8 @@
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
+ case V4L2_CID_LED:
+ return led;
default:
return NULL;
}
@@ -434,6 +442,7 @@
case V4L2_CID_COLORFX: return Color Effects;
case V4L2_CID_ROTATE: return Rotate;
case V4L2_CID_BG_COLOR: return Background color;
+ case V4L2_CID_LED: return Feedback LED;
/* MPEG controls */
case V4L2_CID_MPEG_CLASS: return MPEG Encoder Controls;
@@ -575,6 +584,7 @@
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
+ case V4L2_CID_LED:
qctrl-type = V4L2_CTRL_TYPE_MENU;
step = 1;
break;
diff -r d8fafa7d88dc linux/include/linux/videodev2.h
--- a/linux/include/linux/videodev2.h Thu Feb 18 19:02:51 2010 +0100
+++ b/linux/include/linux/videodev2.h Sun Feb 28 08:41:17 2010 +0100
@@ -1030,8 +1030,14 @@
#define V4L2_CID_ROTATE (V4L2_CID_BASE+34)
#define V4L2_CID_BG_COLOR(V4L2_CID_BASE+35)
+#define V4L2_CID_LED (V4L2_CID_BASE+36)
+enum v4l2_led {
+ V4L2_LED_AUTO = 0,
+ V4L2_LED_ON = 1,
+ V4L2_LED_OFF= 2,
+};
enums shouldn't be used in kernelspace - userspace APIs, as their size is
not stable across ARM ABIs. In this case it won't matter much, the enum not
being part of any structure. If someone creates a new ioctl that uses enum
v4l2_led as one field of its structure argument, things will break.
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+37)
/* MPEG-class control IDs defined by V4L2 */
#define
Re: [PATCH 1/3] add feedback LED control
On Sunday 28 February 2010 20:38:00 Németh Márton wrote: Jean-Francois Moine wrote: On Sun, 28 Feb 2010 08:55:04 +0100 Németh Márton nm...@freemail.hu wrote: On some webcams a feedback LED can be found. This LED usually shows the state of streaming mode: this is the Auto mode. The LED can be programmed to constantly switched off state (e.g. for power saving reasons, preview mode) or on state (e.g. the application shows motion detection or on-air). Hi, There may be many LEDs on the webcams. One LED may be used for the streaming state, Some other ones may be used to give more light in dark rooms. One webcam, the microscope 093a:050f, has a top and a bottom lights/illuminators; an other one, the MSI StarCam 370i 0c45:60c0, has an infra-red light. That's why I proposed to have bit fields in the control value to switch on/off each LED. With a bitfield on and off state can be specified. What about the auto mode? Should two bits grouped together to have auto, on and off state? Is there already a similar control? I don't like the bitfield either. As stated in my previous mail, we can have more than 3 states, so using 2 bits per LED will simply not scale. Is the brightness of the background light LEDs adjustable or are they just on/off? If yes, then maybe the feedback LEDs and the background light LEDs should be treated as different kind. I think there should indeed be a different control for the background LEDs. Still, there could be more than one feedback LED. -- Regards, Laurent Pinchart -- 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: How do private controls actually work?
Hello Laurent, On Mon, Mar 1, 2010 at 3:57 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I don't think it should matter which API (the base one or the extended one) you use for controls, be they private, standard or whatever. I don't see a reason for disallowing some controls to be used through one or the other API. I would generally agree. My original belief was that the extended control API was designed to be a superset of the older API and that it could be used for both types of controls. Imagine my surprise to find that private controls were specifically excluded from the extended control interface. I can change v4l2-ctl to use g_ctrl for private controls if we think that is the correct approach. But I didn't want to do that until I knew for sure that it is correct that you can never have a private extended control. Do we have extended *controls* ? All I see today is two APIs to access controls, a base *control API* and an extended *control API*. G_CTRL/S_CTRL should always be available to userspace. If you want to set a single control, the extended API isn't required. The MPEG controls count as extended controls, since they provide the ability for grouping controls and modifying the values for multiple controls in an atomic manner. It's worth noting that I actually did track down the regression in v4l2-ctl, and the fix ended up being pretty simple (although it took a couple of hours to understand the code and nail down the proper fix): http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/142ae5aa9e8e It's kind of annoying that I have to tell my client that the ability to query/update private controls using v4l2-ctl has been completely broken for six months, but it seems like that is where we are at. 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: [PATCH 1/3] add feedback LED control
On Sun, 28 Feb 2010 20:38:00 +0100
Németh Márton nm...@freemail.hu wrote:
With a bitfield on and off state can be specified. What about the
auto mode? Should two bits grouped together to have auto, on and
off state? Is there already a similar control?
Is the brightness of the background light LEDs adjustable or are they
just on/off? If yes, then maybe the feedback LEDs and the background
light LEDs should be treated as different kind.
OK. My idea about switching the LEDs by v4l2 controls was not good. So,
forget about it.
Instead, some job of the led class may be done in the gspca main,
especially register/unregister.
I propose to add a LED description in the gspca structure (level
'struct cam'). There would be 'nleds' for the number of LEDS and
'leds', a pointer to an array of:
struct gspca_led {
struct led_classdev led_cdev;
char led_name[32];
struct led_trigger led_trigger;
char trigger_name[32];
};
(this array should be in the subdriver structure - I don't show the
#ifdef's)
Then, this would work as:
- on probe, in the 'config' function of the subdriver, this one
initializes the led and trigger fields. The 'led_cdev.name' and
'led_trigger.name' should point to a sprintf format with one
argument: the video device number (ex: video%d::toplight).
- then, at the end of gspca_dev_probe(), the gspca main creates the real
names of the leds and triggers, and does the register job.
- all led/trigger events are treated by the subdriver, normally by a
workqueue. This one must not be the system workqueue.
- on disconnection, the gspca main unregisters the leds and triggers
without calling the subdriver. In the workqueue, the disconnection
can be simply handled testing the flag 'present' after each subsystem
call.
Cheers.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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
Usb Video Grabber
Hi, do you know some usb video grabber (input rca or s-video, audio is not important), that are supported by one of these kernel modules: kmod-video-gspca kmod-video-nw8xx kmod-video-ov51x-jpeg kmod-video-quickcam kmod-video-uvc thank you -- Denis Barbazza -- 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: How do private controls actually work?
Hello Laurent, On Mon, Mar 1, 2010 at 3:57 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I don't think it should matter which API (the base one or the extended one) you use for controls, be they private, standard or whatever. I don't see a reason for disallowing some controls to be used through one or the other API. I would generally agree. My original belief was that the extended control API was designed to be a superset of the older API and that it could be used for both types of controls. Imagine my surprise to find that private controls were specifically excluded from the extended control interface. New private controls should not use V4L2_CID_PRIVATE_BASE at all. That mechanism was a really bad idea. Instead a new control should be added to the appropriate control class and with a offset = 0x1000. See for example the CX2341X private controls in videodev2.h. The EXT_G/S_CTRLS ioctls do not accept PRIVATE_BASE because I want to force driver developers to stop using PRIVATE_BASE. So only G/S_CTRL will support controls in that range for backwards compatibility. Regards, Hans I can change v4l2-ctl to use g_ctrl for private controls if we think that is the correct approach. But I didn't want to do that until I knew for sure that it is correct that you can never have a private extended control. Do we have extended *controls* ? All I see today is two APIs to access controls, a base *control API* and an extended *control API*. G_CTRL/S_CTRL should always be available to userspace. If you want to set a single control, the extended API isn't required. The MPEG controls count as extended controls, since they provide the ability for grouping controls and modifying the values for multiple controls in an atomic manner. It's worth noting that I actually did track down the regression in v4l2-ctl, and the fix ended up being pretty simple (although it took a couple of hours to understand the code and nail down the proper fix): http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/142ae5aa9e8e It's kind of annoying that I have to tell my client that the ability to query/update private controls using v4l2-ctl has been completely broken for six months, but it seems like that is where we are at. 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 -- 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: Proposal for a V4L2 Media Controller mini-summit
Hi Hans, (...) Darn. Having a mini-summit without Laurent and yourself is pointless since you are both key developers. New proposal: May 5-7 in Lysaker, Norway. Does that work? Most probably. Depending how the Media Controller thing looks by then we consider sending a representative there. It's in Europe, so maybe the management would swallow the business trip costs ;) 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 Regards -- Tomasz Fujak -- 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: How do private controls actually work?
On Mon, Mar 1, 2010 at 4:58 AM, Hans Verkuil hverk...@xs4all.nl wrote: New private controls should not use V4L2_CID_PRIVATE_BASE at all. That mechanism was a really bad idea. Instead a new control should be added to the appropriate control class and with a offset = 0x1000. See for example the CX2341X private controls in videodev2.h. So, you're suggesting that the following patch then is going to be NAK'd and that I'm going to have to go back and convert saa7115 to support the extended controls API, extend the em28xx driver to support the extended controls API, and retest with all the possible applications given how they might potentially be attempting to implement the rather poorly documented interface? http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/a7d50db75420 And exactly what class of extended controls should I use for video decoders? It would seem that a video decoder doesn't really fall into any of the existing categories - Old-style user controls, MPEG compression controls, Camera controls, or FM modulator controls. Are we saying that now I'm also going to be introducing a whole new class of control too? The EXT_G/S_CTRLS ioctls do not accept PRIVATE_BASE because I want to force driver developers to stop using PRIVATE_BASE. So only G/S_CTRL will support controls in that range for backwards compatibility. While we're on the topic, do you see any problem with the proposed fix for the regression you introduced?: http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/142ae5aa9e8e Between trying to figure out what the expected behavior is supposed to be (given the complete lack of documentation on how private controls are expected to be implemented in the extended controls API) and isolating and fixing the regression, it's hard not to be a little irritated at this situation. This was supposed to be a very small change - a single private control to a mature driver. And now it seems like I'm going to have to extend the basic infrastructure in the decoder driver, the bridge driver, add a new class of controls, all so I can poke one register? 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
[PATCH] firedtv: correct version number and current/next in CA_PMT
Date: Tue, 21 Jul 2009 18:45:50 +0200 From: Henrik Kurelid hen...@kurelid.se The version number in the CA_PMT message sent to the hardware was alwaysed set to zero. This could cause problems if the PMT would change during decryption of a channel since the new CA_PMT would have the same version number as the old. The version number is now copied from the original PMT. Signed-off-by: Henrik Kurelid hen...@kurelid.se Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de --- This patch got stuck somehow on the long way upstream. :-) Would be good to get into one of the next .34-rc releases. drivers/media/dvb/firewire/firedtv-avc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/drivers/media/dvb/firewire/firedtv-avc.c === --- a/drivers/media/dvb/firewire/firedtv-avc.c +++ b/drivers/media/dvb/firewire/firedtv-avc.c @@ -1096,7 +1096,7 @@ int avc_ca_pmt(struct firedtv *fdtv, cha c-operand[15] = msg[1]; /* Program number */ c-operand[16] = msg[2]; - c-operand[17] = 0x01; /* Version number=0 + current/next=1 */ + c-operand[17] = msg[3]; /* Version number and current/next */ c-operand[18] = 0x00; /* Section number=0 */ c-operand[19] = 0x00; /* Last section number=0 */ c-operand[20] = 0x1f; /* PCR_PID=1FFF */ -- Stefan Richter -=-==-=- --== = http://arcgraph.de/sr/ -- 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] firedtv: add parameter to fake ca_system_ids in CA_INFO
Date: Sun, 4 Oct 2009 15:00:36 +0200
From: Henrik Kurelid hen...@kurelid.se
The Digital Everywhere firmware have the shortcoming that ca_info_enq and
ca_info are not supported. This means that we can never retrieve the correct
ca_system_id to present in the CI message CA_INFO. Currently the driver uses
the application id retrieved using app_info_req and app_info, but this id
only match the correct ca_system_id as given in ca_info in some cases.
This patch adds a parameter to the driver in order for the user to override
what will be returned in the CA_INFO CI message. Up to four ca_system_ids can
be specified.
This is needed for users with CAMs that have different manufacturer id and
ca_system_id and that uses applications that take this into account, like
MythTV.
Signed-off-by: Henrik Kurelid hen...@kurelid.se
Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de (rebased, format of
comment)
---
Would be good to get into an .34-rc too.
drivers/media/dvb/firewire/firedtv-avc.c | 31 ---
1 file changed, 27 insertions(+), 4 deletions(-)
Index: b/drivers/media/dvb/firewire/firedtv-avc.c
===
--- a/drivers/media/dvb/firewire/firedtv-avc.c
+++ b/drivers/media/dvb/firewire/firedtv-avc.c
@@ -130,6 +130,20 @@ MODULE_PARM_DESC(debug, Verbose logging
, FCP payloads = __stringify(AVC_DEBUG_FCP_PAYLOADS)
, or a combination, or all = -1));
+/*
+ * This is a workaround since there is no vendor specific command to retrieve
+ * ca_info using AVC. If this parameter is not used, ca_system_id will be
+ * filled with application_manufacturer from ca_app_info.
+ * Digital Everywhere have said that adding ca_info is on their TODO list.
+ */
+static int num_fake_ca_system_ids;
+static int fake_ca_system_ids[4] = { -1, -1, -1, -1 };
+module_param_array(fake_ca_system_ids, int, num_fake_ca_system_ids, 0644);
+MODULE_PARM_DESC(fake_ca_system_ids, If your CAM application manufacturer
+does not have the same ca_system_id as your CAS, you can
+override what ca_system_ids are presented to the
+application by setting this field to an array of ids.);
+
static const char *debug_fcp_ctype(unsigned int ctype)
{
static const char *ctypes[] = {
@@ -977,7 +991,7 @@ int avc_ca_info(struct firedtv *fdtv, ch
{
struct avc_command_frame *c = (void *)fdtv-avc_data;
struct avc_response_frame *r = (void *)fdtv-avc_data;
- int pos, ret;
+ int i, pos, ret;
mutex_lock(fdtv-avc_mutex);
@@ -1004,9 +1018,18 @@ int avc_ca_info(struct firedtv *fdtv, ch
app_info[0] = (EN50221_TAG_CA_INFO 16) 0xff;
app_info[1] = (EN50221_TAG_CA_INFO 8) 0xff;
app_info[2] = (EN50221_TAG_CA_INFO 0) 0xff;
- app_info[3] = 2;
- app_info[4] = r-operand[pos + 0];
- app_info[5] = r-operand[pos + 1];
+ if (num_fake_ca_system_ids == 0) {
+ app_info[3] = 2;
+ app_info[4] = r-operand[pos + 0];
+ app_info[5] = r-operand[pos + 1];
+ } else {
+ app_info[3] = num_fake_ca_system_ids * 2;
+ for (i = 0; i num_fake_ca_system_ids; i++) {
+ app_info[4 + i * 2] =
+ (fake_ca_system_ids[i] 8) 0xff;
+ app_info[5 + i * 2] = fake_ca_system_ids[i] 0xff;
+ }
+ }
*len = app_info[3] + 4;
out:
mutex_unlock(fdtv-avc_mutex);
--
Stefan Richter
-=-==-=- --== =
http://arcgraph.de/sr/
--
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 05/11] ov534: Fix setting manual exposure
On Sun, 28 Feb 2010 19:54:25 +0100 Antonio Ospite osp...@studenti.unina.it wrote: On Sun, 28 Feb 2010 19:38:14 +0100 Jean-Francois Moine moin...@free.fr wrote: On Sat, 27 Feb 2010 21:20:22 +0100 Antonio Ospite osp...@studenti.unina.it wrote: Exposure is now a u16 value, both MSB and LSB are set, but values in the v4l2 control are limited to the interval [0,506] as 0x01fa (506) is the maximum observed value with AEC enabled. [snip] .type= V4L2_CTRL_TYPE_INTEGER, .name= Exposure, .minimum = 0, - .maximum = 255, + .maximum = 506, .step= 1, #define EXPO_DEF 120 .default_value = EXPO_DEF, Hi Antonio, Do we need a so high precision for the exposure? Just setting the maximum value to 253 should solve the problem. JF, the intent here is to cover all the range of values available in Auto Exposure mode too, doesn't this make sense to you? I could set .maximum to 253 to limit the UI control precision but then I should use 2*value when setting the registers in order to cover the actual max value, this looks a little unclean. Ok, I now see that that's exactly what current code does, sorry for the noise. The patch then degenerates to a simpler one with some documentation added, so others don't overlook the code like I did. Sending it in a min. Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgpW3oPfs6eYu.pgp Description: PGP signature
Re: How do private controls actually work?
On Mon, Mar 1, 2010 at 4:58 AM, Hans Verkuil hverk...@xs4all.nl wrote: New private controls should not use V4L2_CID_PRIVATE_BASE at all. That mechanism was a really bad idea. Instead a new control should be added to the appropriate control class and with a offset = 0x1000. See for example the CX2341X private controls in videodev2.h. So, you're suggesting that the following patch then is going to be NAK'd and that I'm going to have to go back and convert saa7115 to support the extended controls API, extend the em28xx driver to support the extended controls API, and retest with all the possible applications given how they might potentially be attempting to implement the rather poorly documented interface? I have a lot to say on this subject, but unfortunately I'm swamped with work at the moment. I'll get back to you on this tomorrow. Regards, Hans http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/a7d50db75420 And exactly what class of extended controls should I use for video decoders? It would seem that a video decoder doesn't really fall into any of the existing categories - Old-style user controls, MPEG compression controls, Camera controls, or FM modulator controls. Are we saying that now I'm also going to be introducing a whole new class of control too? The EXT_G/S_CTRLS ioctls do not accept PRIVATE_BASE because I want to force driver developers to stop using PRIVATE_BASE. So only G/S_CTRL will support controls in that range for backwards compatibility. While we're on the topic, do you see any problem with the proposed fix for the regression you introduced?: http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/142ae5aa9e8e Between trying to figure out what the expected behavior is supposed to be (given the complete lack of documentation on how private controls are expected to be implemented in the extended controls API) and isolating and fixing the regression, it's hard not to be a little irritated at this situation. This was supposed to be a very small change - a single private control to a mature driver. And now it seems like I'm going to have to extend the basic infrastructure in the decoder driver, the bridge driver, add a new class of controls, all so I can poke one register? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: [PATCH] firedtv: add parameter to fake ca_system_ids in CA_INFO
The Digital Everywhere firmware have the shortcoming that ca_info_enq and ca_info are not supported. This means that we can never retrieve the correct ca_system_id to present in the CI message CA_INFO. Currently the driver uses the application id retrieved using app_info_req and app_info, but this id only match the correct ca_system_id as given in ca_info in some cases. This patch adds a parameter to the driver in order for the user to override what will be returned in the CA_INFO CI message. Up to four ca_system_ids can be specified. This is needed for users with CAMs that have different manufacturer id and ca_system_id and that uses applications that take this into account, like MythTV. This workaround is of course rather awkward. Users who need this will have a hard time to work out that this parameter needs to be set and how. Furthermore, the web site of Digital Everywhere says that hey stopped manufacturing and ramped down support, hence it looks like this issue will stay with us forever. Isn't there a CA command that could be (mis)used for some kind of probing of the CAM for correct system IDs? E.g. a loop which retries a kind of dummy operation with different system IDs until success, initially during fdtv_dvb_register/ fdtv_ca_register? (I don't know how CI works, and alas I don't have a CAM myself for testing and am not very keen on getting one...) -- Stefan Richter -=-==-=- --== = http://arcgraph.de/sr/ -- 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: [IR RC, REGRESSION] Didn't work IR RC
On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote: Hi All After rework of the IR subsystem, IR RC no more work in our TV cards. As I see call saa7134_probe_i2c_ir, configure i2c call i2c_new_device New i2c device not registred. The module kbd-i2c-ir loaded after i2c_new_device. Jean, There was also a problem reported with the cx23885 driver's I2C connected IR by Timothy Lenz: http://www.spinics.net/lists/linux-media/msg15122.html The failure mode sounds similar to Dmitri's, but maybe they are unrelated. I worked a bit with Timothy on IRC and the remote device fails to be detected whether ir-kbd-i2c is loaded before the cx23885 driver or after the cx23885 driver. I haven't found time to do any folow-up and I don't have any of the hardware in question. Do you have any thoughts or a suggested troubleshooting approach? Regards, Andy I try to found what happens. With my best regards, Dmitry. -- 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: Announcing v4l-utils-0.7.90 (which includes libv4l-0.7.90)
Hi, Am Montag, 1. März 2010 10:26:47 schrieb Hans de Goede: I'm happy to announce the first (test / beta) release of v4l-utils, v4l-utils is the combination of various v4l and dvb utilities which used to be part of the v4l-dvb mercurial kernel tree and libv4l. Reading some more about dvb-apps, I have to side with the people who are voting for keeping dvb-apps separate. I do wonder if those people and you and Mauro are talking about the same dvb-apps, or if this is just a misunderstanding. The dvp-apps I'm talking about now, and of which I'm not in favor of merging them with v4l-utils are the ones, which can be downloaded here: http://linuxtv.org/downloads/ http://linuxtv.org/hg/dvb-apps Although I must agree with the people who are in favor of integrating this into v4l-utils, that this needs much more active maintainership wrt to making regular tarbal releases for distro's to consume. Still I believe this should stay as a separate project, because so far it clearly was, and I see no huge advantages in integrating it. Signs that this clearly is a separate stand alone project: 1) It has done several tarbal releases (these are ancient guys, this needs to be fixed). 2) It has its own VCS 3) It is packaged up by various distros: http://packages.debian.org/sid/video/dvb-apps http://packages.ubuntu.com/source/dapper/linuxtv-dvb-apps http://cvs.fedoraproject.org/viewvc/rpms/dvb-apps/ http://rpm.pbone.net/index.php3?stat=3search=dvb-appssrodzaj=3 http://gentoo-portage.com/media-tv/linuxtv-dvb-apps http://aur.archlinux.org/packages.php?ID=2034 http://www.slax.org/modules.php?action=detailid=3143 https://dev.openwrt.org/ticket/2804 4) It is referenced as a standalone project by 3th parties: http://www.mythtv.org/wiki/Dvb-apps So given the stand alone nature, and that it is already widely packaged as a standalone project by distro's. For now I'm against ingrating this into v4l-utils. And the most important argument for me being against this, is that one of the 2 active contributors (judging from the hg tree), Manu Abraham, is very much against integration. And the people who are in favor (Hans Verkuil and Mauro) don't seem to have done any commits to the tree in question, for at least the last 2 years. So unless we can get some buy in for integrating this in to v4l-utils from active dvb-apps contributors I'm opposed to the integration. I agree with you that dvb-apps should stay a seperate project as there are now. I don't see any reason for integrating them into one project with v4l- utils. There are no developers actively working on both projects. This would lead to problematic release preparation for sure. Especially when keeping in mind that Mauro and Manu are not exactly happy with working together, so I really think it would be much easier to keep it seperated. Also I don't think that all users who use dvb-apps would need to have all the v4l-utils and vice versa. So please keep it seperate. With this all said, I must say: Manu please do a tarbal release real real soon, and make a habit out of doing so regularly! This is of course right and should be done soon. I think this wasn't done for a long time due to the incompleteness of v5 API support. But afaik Manu is currently working on it, so it shouldn't take too long anymore. Regards, Julian -- 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: How do private controls actually work?
On Mon, 2010-03-01 at 10:58 +0100, Hans Verkuil wrote: Hello Laurent, On Mon, Mar 1, 2010 at 3:57 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: I don't think it should matter which API (the base one or the extended one) you use for controls, be they private, standard or whatever. I don't see a reason for disallowing some controls to be used through one or the other API. I would generally agree. My original belief was that the extended control API was designed to be a superset of the older API and that it could be used for both types of controls. Imagine my surprise to find that private controls were specifically excluded from the extended control interface. New private controls should not use V4L2_CID_PRIVATE_BASE at all. That mechanism was a really bad idea. Instead a new control should be added to the appropriate control class and with a offset = 0x1000. See for example the CX2341X private controls in videodev2.h. I recall doing something like this a while ago: #define CX18_AV_CID_USER_PRIV_BASE (V4L2_CTRL_CLASS_USER | 0x1000) #define CX18_AV_CID_EXTRA_12DB_GAIN (CX18_AV_CID_USER_PRIV_BASE+0) . http://linuxtv.org/hg/~awalls/v4l-dvb-ctls/file/e4b2c5d550b5/linux/drivers/media/video/cx18/cx18-av-core.h#l77 (I'm not sure if it's a good example though.) I'm still just waiting for an approved method for implementing such video decoder controls. I don't care how, just that there is a way. I don't have much in the way of plans to offer, because I really don't grok all the existing issues with controls. Regards, Andy The EXT_G/S_CTRLS ioctls do not accept PRIVATE_BASE because I want to force driver developers to stop using PRIVATE_BASE. So only G/S_CTRL will support controls in that range for backwards compatibility. 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
[PATCH v2 05/11] ov534: Fix and document setting manual exposure
Document that even if the state is a u8 value, both MSB and LSB are set as sd-exposure represents half of the value we are going to set into registers. Skip setting exposure when AEC is enabled. Signed-off-by: Antonio Ospite osp...@studenti.unina.it --- The code was already doing the right thing, I just overlooked it. Regards, Antonio linux/drivers/media/video/gspca/ov534.c |9 + 1 file changed, 9 insertions(+) Index: gspca/linux/drivers/media/video/gspca/ov534.c === --- gspca.orig/linux/drivers/media/video/gspca/ov534.c +++ gspca/linux/drivers/media/video/gspca/ov534.c @@ -686,6 +686,15 @@ struct sd *sd = (struct sd *) gspca_dev; u8 val; + if (sd-aec) + return; + + /* 'val' is one byte and represents half of the exposure value we are +* going to set into registers, a two bytes value: +* +*MSB: ((u16) val 1) 8 == val 7 +*LSB: ((u16) val 1) 0xff == val 1 +*/ val = sd-exposure; sccb_reg_write(gspca_dev, 0x08, val 7); sccb_reg_write(gspca_dev, 0x10, val 1); -- 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 v2 09/11] ov534: Cosmetics: fix indentation and hex digits
* Indent with tabs, not with spaces, nor with mixed style.
* Less indentation for controls index comments.
* Use lowercase hex digits.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
Changes since v1:
Indent controls by one more level as JF requested.
Note that the controls index comments are still less indented than before,
it is more readable this way.
Thanks,
Antonio
linux/drivers/media/video/gspca/ov534.c | 260
1 file changed, 130 insertions(+), 130 deletions(-)
Index: gspca/linux/drivers/media/video/gspca/ov534.c
===
--- gspca.orig/linux/drivers/media/video/gspca/ov534.c
+++ gspca/linux/drivers/media/video/gspca/ov534.c
@@ -92,147 +92,147 @@
static int sd_getcontrast(struct gspca_dev *gspca_dev, __s32 *val);
static const struct ctrl sd_ctrls[] = {
-{ /* 0 */
- {
- .id = V4L2_CID_BRIGHTNESS,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Brightness,
- .minimum = 0,
- .maximum = 255,
- .step= 1,
+ { /* 0 */
+ {
+ .id = V4L2_CID_BRIGHTNESS,
+ .type= V4L2_CTRL_TYPE_INTEGER,
+ .name= Brightness,
+ .minimum = 0,
+ .maximum = 255,
+ .step= 1,
#define BRIGHTNESS_DEF 0
- .default_value = BRIGHTNESS_DEF,
- },
- .set = sd_setbrightness,
- .get = sd_getbrightness,
-},
-{ /* 1 */
- {
- .id = V4L2_CID_CONTRAST,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Contrast,
- .minimum = 0,
- .maximum = 255,
- .step= 1,
+ .default_value = BRIGHTNESS_DEF,
+ },
+ .set = sd_setbrightness,
+ .get = sd_getbrightness,
+ },
+ { /* 1 */
+ {
+ .id = V4L2_CID_CONTRAST,
+ .type= V4L2_CTRL_TYPE_INTEGER,
+ .name= Contrast,
+ .minimum = 0,
+ .maximum = 255,
+ .step= 1,
#define CONTRAST_DEF 32
- .default_value = CONTRAST_DEF,
- },
- .set = sd_setcontrast,
- .get = sd_getcontrast,
-},
-{ /* 2 */
- {
- .id = V4L2_CID_GAIN,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Main Gain,
- .minimum = 0,
- .maximum = 63,
- .step= 1,
+ .default_value = CONTRAST_DEF,
+ },
+ .set = sd_setcontrast,
+ .get = sd_getcontrast,
+ },
+ { /* 2 */
+ {
+ .id = V4L2_CID_GAIN,
+ .type= V4L2_CTRL_TYPE_INTEGER,
+ .name= Main Gain,
+ .minimum = 0,
+ .maximum = 63,
+ .step= 1,
#define GAIN_DEF 20
- .default_value = GAIN_DEF,
- },
- .set = sd_setgain,
- .get = sd_getgain,
-},
-{ /* 3 */
- {
- .id = V4L2_CID_EXPOSURE,
- .type= V4L2_CTRL_TYPE_INTEGER,
- .name= Exposure,
- .minimum = 0,
- .maximum = 255,
- .step= 1,
+ .default_value = GAIN_DEF,
+ },
+ .set = sd_setgain,
+ .get = sd_getgain,
+ },
+ { /* 3 */
+ {
+ .id = V4L2_CID_EXPOSURE,
+ .type= V4L2_CTRL_TYPE_INTEGER,
+ .name= Exposure,
+ .minimum = 0,
+ .maximum = 255,
+ .step= 1,
#define EXPO_DEF 120
- .default_value = EXPO_DEF,
- },
- .set = sd_setexposure,
- .get = sd_getexposure,
-},
-{ /* 4 */
- {
- .id = V4L2_CID_AUTOGAIN,
- .type= V4L2_CTRL_TYPE_BOOLEAN,
- .name= Auto Gain,
- .minimum = 0,
- .maximum = 1,
- .step= 1,
+ .default_value = EXPO_DEF,
+ },
+ .set = sd_setexposure,
+ .get = sd_getexposure,
+ },
+ { /* 4 */
+ {
+ .id = V4L2_CID_AUTOGAIN,
+ .type= V4L2_CTRL_TYPE_BOOLEAN,
+ .name
[PATCH update] firedtv: add parameter to fake ca_system_ids in CA_INFO
From: Henrik Kurelid hen...@kurelid.se
Subject: firedtv: add parameter to fake ca_system_ids in CA_INFO
The Digital Everywhere firmware have the shortcoming that ca_info_enq and
ca_info are not supported. This means that we can never retrieve the correct
ca_system_id to present in the CI message CA_INFO. Currently the driver uses
the application id retrieved using app_info_req and app_info, but this id
only match the correct ca_system_id as given in ca_info in some cases.
This patch adds a parameter to the driver in order for the user to override
what will be returned in the CA_INFO CI message. Up to four ca_system_ids can
be specified.
This is needed for users with CAMs that have different manufacturer id and
ca_system_id and that uses applications that take this into account, like
MythTV.
Signed-off-by: Henrik Kurelid hen...@kurelid.se
Signed-off-by: Stefan Richter stef...@s5r6.in-berlin.de (rebased, type of
num_fake_ca_system_ids, format of comment)
---
Update: I found a sparse warning after the fact. num_fake_ca_system_ids
is meant to be unsigned, not signed. Sorry that I missed it in my first
posting; it was hidden by an unrelated sparse error in
include/linux/skbuff.h which was introduced by commit 14d18a81. I need
to have a word (again) with the author of this commit.
drivers/media/dvb/firewire/firedtv-avc.c | 31 ---
1 file changed, 27 insertions(+), 4 deletions(-)
Index: b/drivers/media/dvb/firewire/firedtv-avc.c
===
--- a/drivers/media/dvb/firewire/firedtv-avc.c
+++ b/drivers/media/dvb/firewire/firedtv-avc.c
@@ -130,6 +130,20 @@ MODULE_PARM_DESC(debug, Verbose logging
, FCP payloads = __stringify(AVC_DEBUG_FCP_PAYLOADS)
, or a combination, or all = -1));
+/*
+ * This is a workaround since there is no vendor specific command to retrieve
+ * ca_info using AVC. If this parameter is not used, ca_system_id will be
+ * filled with application_manufacturer from ca_app_info.
+ * Digital Everywhere have said that adding ca_info is on their TODO list.
+ */
+static unsigned int num_fake_ca_system_ids;
+static int fake_ca_system_ids[4] = { -1, -1, -1, -1 };
+module_param_array(fake_ca_system_ids, int, num_fake_ca_system_ids, 0644);
+MODULE_PARM_DESC(fake_ca_system_ids, If your CAM application manufacturer
+does not have the same ca_system_id as your CAS, you can
+override what ca_system_ids are presented to the
+application by setting this field to an array of ids.);
+
static const char *debug_fcp_ctype(unsigned int ctype)
{
static const char *ctypes[] = {
@@ -977,7 +991,7 @@ int avc_ca_info(struct firedtv *fdtv, ch
{
struct avc_command_frame *c = (void *)fdtv-avc_data;
struct avc_response_frame *r = (void *)fdtv-avc_data;
- int pos, ret;
+ int i, pos, ret;
mutex_lock(fdtv-avc_mutex);
@@ -1004,9 +1018,18 @@ int avc_ca_info(struct firedtv *fdtv, ch
app_info[0] = (EN50221_TAG_CA_INFO 16) 0xff;
app_info[1] = (EN50221_TAG_CA_INFO 8) 0xff;
app_info[2] = (EN50221_TAG_CA_INFO 0) 0xff;
- app_info[3] = 2;
- app_info[4] = r-operand[pos + 0];
- app_info[5] = r-operand[pos + 1];
+ if (num_fake_ca_system_ids == 0) {
+ app_info[3] = 2;
+ app_info[4] = r-operand[pos + 0];
+ app_info[5] = r-operand[pos + 1];
+ } else {
+ app_info[3] = num_fake_ca_system_ids * 2;
+ for (i = 0; i num_fake_ca_system_ids; i++) {
+ app_info[4 + i * 2] =
+ (fake_ca_system_ids[i] 8) 0xff;
+ app_info[5 + i * 2] = fake_ca_system_ids[i] 0xff;
+ }
+ }
*len = app_info[3] + 4;
out:
mutex_unlock(fdtv-avc_mutex);
--
Stefan Richter
-=-==-=- --== =
http://arcgraph.de/sr/
--
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
How will the locking be handled ? I suppose opening a plane and closing a plane will just be a matter of sending one (or several) messages to the VPSS. In that case what would prevent a userspace application from sending a direct message to close a plane that a driver would have opened ? Will the firmware be able to identify if a close message comes from the same source as a previous open message, without any risk of identify spoofing ? That is a good question. Let me have one of the firmware guys answer this. I too am assuming that some other application can't issue a close on a channel if they weren't the one to open it. Puru, can you answer this? Laurent, You are correct in saying that opening of plan will be matter of sending one message but it is slightly different for closing of driver and other commands. As part of open, firmware returns specific identifier i.e. handle which has to be used for all further commands/messages related to specific plan. It means that close will also require this specific identifier i.e. handle and so it will not be possible for other application to close any driver unless specific identifier i.e. handle is also supplied along with close message. This identifier or handles helps in identifying source of open/close or any commands. Regards, Purushotam -Original Message- From: Maupin, Chase Sent: Friday, February 26, 2010 9:05 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, Responses inline Puru, There is a question for you below. Can you look at it and provide an answer? 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 25, 2010 6:32 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; Kamoolkar, Mugdha Subject: Re: Requested feedback on V4L2 driver design Hi Chase, On Friday 12 February 2010 17:46:55 Maupin, Chase wrote: Laurent, First let me thank you for taking time to review this. You're welcome. [snip] -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Thursday, February 11, 2010 7:23 PM On Monday 08 February 2010 16:08:37 Maupin, Chase wrote: [snip] 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=TIPassLoginSingleContainerlt=m ytij5=2j3=1goto=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. Thanks for the information, but http://list.ti.com/ still can't be accessed. The host list.ti.com has no A record, an HTTP connection can't thus be established. I'm not sure what is going on here. Let me file a ticket with our IT group and see if they can fix the problem. 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
Re: Info
Devin, can you ask Prahal to keep this mailing list updated with the progress of develop? People from the list could help him in any need. Thank you. Adri On 02/14/2010 06:33 PM, Florent NOUVELLON wrote: Hi Devin, Did you with Prahal advanced the 0072/terratec hybrid xs fm support in linux-dvb driver ? If you need any kind of help (testing, or whatever) feel free to ask me. Regards, Florent -- 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: [IR RC, REGRESSION] Didn't work IR RC
Andy Walls wrote: On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote: Hi All After rework of the IR subsystem, IR RC no more work in our TV cards. As I see call saa7134_probe_i2c_ir, configure i2c call i2c_new_device New i2c device not registred. The module kbd-i2c-ir loaded after i2c_new_device. Jean, There was also a problem reported with the cx23885 driver's I2C connected IR by Timothy Lenz: http://www.spinics.net/lists/linux-media/msg15122.html The failure mode sounds similar to Dmitri's, but maybe they are unrelated. I worked a bit with Timothy on IRC and the remote device fails to be detected whether ir-kbd-i2c is loaded before the cx23885 driver or after the cx23885 driver. I haven't found time to do any folow-up and I don't have any of the hardware in question. Do you have any thoughts or a suggested troubleshooting approach? Andy/Dmitri, With the current i2c approach, the bridge driver is responsible for binding an i2c device into the i2c adapter. In other words, the bridge driver should have some logic to know what devices use ir-kbd-i2c, loading it at the right i2c address(es). Manually loading IR shouldn't make any difference. From Andy's comment, I suspect that such logic is missing at cx23885 for the board you're referring. Not sure if this is the same case of the boards Dmitri is concerned about. It should be noticed that the i2c redesign happened on 2.6.31 or 2.6.32, so, if this is the case, a patch should be sent also to -stable. In the case of saa7134, Jean worked on a fix for some boards: http://patchwork.kernel.org/patch/75883/ He is currently waiting for someone with the affected boards to test it and give some return. -- 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] Input: scancode in get/set_keycodes should be unsigned
On Sat, Feb 27, 2010 at 10:13:11PM -0800, Dmitry Torokhov wrote: The HID layer has some scan codes of the form 0xffbc for logitech devices which do not work if scancode is typed as signed int, so we need to switch to unsigned int instead. While at it keycode being signed does not make much sense either. Signed-off-by: Dmitry Torokhov d...@mail.ru --- Acked-by: Matthew Garrett m...@redhat.com -- Matthew Garrett | mj...@srcf.ucam.org -- 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: [PULL] http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2
Devin Heitmueller wrote: Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2 for the following: as102: import initial as102 driver as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: Add Elgato EyeTV DTT Deluxe as102: properly handle multiple product names Generating hg_14330_as102_properly_handle_multiple_product_names.patch ERROR: Missing Signed-off-by: line(s) It seems that you forgot to sign one of the patches... 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: [PULL] http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2
On Mon, Mar 1, 2010 at 10:08 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Devin Heitmueller wrote: Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2 for the following: as102: import initial as102 driver as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: Add Elgato EyeTV DTT Deluxe as102: properly handle multiple product names Generating hg_14330_as102_properly_handle_multiple_product_names.patch ERROR: Missing Signed-off-by: line(s) It seems that you forgot to sign one of the patches... Hi Mauro, I have to admit I'm a bit confused. I just double checked the patch in question, and the SOB looks fine. http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/rev/22ef1bdca69a Could you please clarify what the actual problem is? Thanks, 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: [PULL] http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2
On Mon, Mar 1, 2010 at 10:08 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Devin Heitmueller wrote: Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2 for the following: as102: import initial as102 driver as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: checkpatch fixes as102: Add Elgato EyeTV DTT Deluxe as102: properly handle multiple product names Generating hg_14330_as102_properly_handle_multiple_product_names.patch ERROR: Missing Signed-off-by: line(s) It seems that you forgot to sign one of the patches... Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Thanks, 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
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:Mon Mar 1 19:00:17 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14320:37ff78330942 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-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-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-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-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-x86_64: OK spec: OK sparse (linux-2.6.33): ERRORS linux-2.6.16.62-i686: OK linux-2.6.17.14-i686: OK 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: OK linux-2.6.17.14-x86_64: OK 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/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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 1/2] New driver for MI2020 sensor with GL860 bridge
Hello, light source is not related to LEDs, it is for the kind of light source (tungsten, etc). The Windows driver had this control beside the white balance. I could remove this new control as under Windows the white balance is achieved by software and not hardware so the white balance control is available with Linux. About delay, they are required with at least 2 of four sensors managed by the driver because there can be communication faults. It also depends on the laptop as a same sensor driver is kown to always fails with a laptop and not another one. I prefer now to secure the communication with all four sensors with a small delay after a data has been sent. The delay is mostly stringent in the case of the MI2020 because there is more than 400 USB messages sent to the webcam at startup and initialisation time. Added with other required delay, several seconds are needed to initialise the webcam. I know a msleep(1) lasts 5ms to 10ms depending on the scheduler. The msleep slows down too much the communication. The OV2640 requires also more than 200 messages. I never got any error with 850ms but we could use 900 or 1000ms. I chose the less long delay. Cheers, OL 2010/3/1, Jean-Francois Moine moin...@free.fr: On Sun, 28 Feb 2010 21:19:25 +0100 Olivier Lorin olori...@gmail.com wrote: - General changes for all drivers because of new MI2020 sensor driver : - add the light source control - control value changes only applied after an end of image - replace msleep with duration less than 5 ms by a busy loop - Fix for an irrelevant OV9655 image resolution identifier name Hello Olivier, What is this 'light source'? In the list, we are talking about the webcam LEDs and how to switch them on/off. Is it the same feature? Is it important to have a so precise delay in the webcam exchanges? Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: How do private controls actually work?
Hi Devin, Devin Heitmueller wrote: On Mon, Mar 1, 2010 at 4:58 AM, Hans Verkuil hverk...@xs4all.nl wrote: New private controls should not use V4L2_CID_PRIVATE_BASE at all. That mechanism was a really bad idea. Instead a new control should be added to the appropriate control class and with a offset = 0x1000. See for example the CX2341X private controls in videodev2.h. The better is to create a device-specific control, if the parameter you want to control is really specific to just one chip family. Otherwise, just add a new common control to the API. http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/a7d50db75420 FYI, v42-apps were moved to a separate tree. -- 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] DVB-T USB Devices
On Mon, 2010-03-01 at 19:03 +1100, Rodd Clarkson wrote: usb 1-4: Manufacturer: Hauppauge Computer Works ... smscore_set_device_mode: firmware download success: sms1xxx-nova-b-dvbt-01.fw I hate replying to myself, but I should have mentioned that sms1xxx-nova-b-dvbt-01.fw is a renamed sms1xxx-hcw-55xxx-dvbt-01.fw I've noticed that sms1xxx-hcw-55xxx-dvbt-02.fw seems to be out, but haven't tried this. R. -- 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
Audio4DJ (snd-usb-caiaq) noise when using DVB usb adapter
Hi all, I'm encountering a problem with the Audio4DJ audio card with a DVB USB adapter (Win-TV NOVA-T USB2 STICK). The problem is strange because it only happens after I disconnect and reconnect the audio card. Procedure 1: - boot from fresh - plug the DVB adapter - plug the Audio4DJ Everything works correctly - meaning I can watch TV and my audio is fine. Procedure 2: - boot from fresh - plug the Audio4DJ - plug the DVB adapter The audio starts cracking every few seconds, and constantly if I use jackd. Procedure 3: - boot from fresh - plug the DVB adapter - plug the Audio4DJ (everything is correct, as above in Procedure 1) - unplug the Audio4DJ - plug it again Cracking audio. I'm insisting in boot from fresh because from now on (that is, from the moment that I unplug the Audio4DJ) I always get cracking audio. rmmod'ing the snd-usb-caiaq and the usb-dvb modules produces the same result. I have to boot from fresh and do Procedure 1 for it to work OK. Can anyone please give a hint on how to debug this? (Please CC me directly as I'm not in both lists). Regards, Pedro -- 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: [IR RC, REGRESSION] Didn't work IR RC
Hi, Am Montag, den 01.03.2010, 10:37 -0300 schrieb Mauro Carvalho Chehab: Andy Walls wrote: On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote: Hi All After rework of the IR subsystem, IR RC no more work in our TV cards. As I see call saa7134_probe_i2c_ir, configure i2c call i2c_new_device New i2c device not registred. The module kbd-i2c-ir loaded after i2c_new_device. Jean, There was also a problem reported with the cx23885 driver's I2C connected IR by Timothy Lenz: http://www.spinics.net/lists/linux-media/msg15122.html The failure mode sounds similar to Dmitri's, but maybe they are unrelated. I worked a bit with Timothy on IRC and the remote device fails to be detected whether ir-kbd-i2c is loaded before the cx23885 driver or after the cx23885 driver. I haven't found time to do any folow-up and I don't have any of the hardware in question. Do you have any thoughts or a suggested troubleshooting approach? Andy/Dmitri, With the current i2c approach, the bridge driver is responsible for binding an i2c device into the i2c adapter. In other words, the bridge driver should have some logic to know what devices use ir-kbd-i2c, loading it at the right i2c address(es). Manually loading IR shouldn't make any difference. yes, we have info.addr at saa7134-input and Dmitri did add the Beholder IR address there recently. From Andy's comment, I suspect that such logic is missing at cx23885 for the board you're referring. Not sure if this is the same case of the boards Dmitri is concerned about. On a first look, Andy seems not to provide the IR addr from the bridge and without probing it can't work anymore. It should be noticed that the i2c redesign happened on 2.6.31 or 2.6.32, so, if this is the case, a patch should be sent also to -stable. In the case of saa7134, Jean worked on a fix for some boards: http://patchwork.kernel.org/patch/75883/ He is currently waiting for someone with the affected boards to test it and give some return. That fix should be unrelated and both variants of the patch are not anywhere yet. We can fake this single board in question on a P7131 Dual, but my receiver is broken, else all looked O.K., and it seems not worth yet to ask Mauro to lose time on faking it, assuming his IR receiver does still work. Here we can simply wait for Daro coming back from skiing, or can even apply already Jean's solution per this card without any risk. Else, do we not check for kernels 2.6.30 on hg v4l-dvb not using auto probing anymore? I tested only on two machines with some 2.6.30 and one with 2.6.29 and recent hg v4l-dvb. There at least all was fine, also with the patch moving IR init1 to saa7134_input_init2 and also for ir-kbd-ic2 for a early Pinnacle 310i under all conditions. Dmitri, on what kernel and/or SCM version of v4l-dvb you discover that flaw? Maybe I can reproduce it then. Andy has reports, that ir-kbd-i2c is still fine on 2.6.31, but breaks on 2.6.32. Do we already run out of sync? Cheers, Hermann -- 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: [IR RC, REGRESSION] Didn't work IR RC
Hi Not work I2C IR RC. GPIO RC I think works well. This patch remove addr of our RC from switch-case http://linuxtv.org/hg/v4l-dvb/rev/f700bce82813 When I set debug for ir-kbd-i2c I get ir-kbd-i2c: :Unsupported device at address 0x2d People with broken IR RC what addr has your I2C IR RC? With my best regards, Dmitry. Hi, Am Montag, den 01.03.2010, 10:37 -0300 schrieb Mauro Carvalho Chehab: Andy Walls wrote: On Mon, 2010-03-01 at 15:36 +0900, Dmitri Belimov wrote: Hi All After rework of the IR subsystem, IR RC no more work in our TV cards. As I see call saa7134_probe_i2c_ir, configure i2c call i2c_new_device New i2c device not registred. The module kbd-i2c-ir loaded after i2c_new_device. Jean, There was also a problem reported with the cx23885 driver's I2C connected IR by Timothy Lenz: http://www.spinics.net/lists/linux-media/msg15122.html The failure mode sounds similar to Dmitri's, but maybe they are unrelated. I worked a bit with Timothy on IRC and the remote device fails to be detected whether ir-kbd-i2c is loaded before the cx23885 driver or after the cx23885 driver. I haven't found time to do any folow-up and I don't have any of the hardware in question. Do you have any thoughts or a suggested troubleshooting approach? Andy/Dmitri, With the current i2c approach, the bridge driver is responsible for binding an i2c device into the i2c adapter. In other words, the bridge driver should have some logic to know what devices use ir-kbd-i2c, loading it at the right i2c address(es). Manually loading IR shouldn't make any difference. yes, we have info.addr at saa7134-input and Dmitri did add the Beholder IR address there recently. From Andy's comment, I suspect that such logic is missing at cx23885 for the board you're referring. Not sure if this is the same case of the boards Dmitri is concerned about. On a first look, Andy seems not to provide the IR addr from the bridge and without probing it can't work anymore. It should be noticed that the i2c redesign happened on 2.6.31 or 2.6.32, so, if this is the case, a patch should be sent also to -stable. In the case of saa7134, Jean worked on a fix for some boards: http://patchwork.kernel.org/patch/75883/ He is currently waiting for someone with the affected boards to test it and give some return. That fix should be unrelated and both variants of the patch are not anywhere yet. We can fake this single board in question on a P7131 Dual, but my receiver is broken, else all looked O.K., and it seems not worth yet to ask Mauro to lose time on faking it, assuming his IR receiver does still work. Here we can simply wait for Daro coming back from skiing, or can even apply already Jean's solution per this card without any risk. Else, do we not check for kernels 2.6.30 on hg v4l-dvb not using auto probing anymore? I tested only on two machines with some 2.6.30 and one with 2.6.29 and recent hg v4l-dvb. There at least all was fine, also with the patch moving IR init1 to saa7134_input_init2 and also for ir-kbd-ic2 for a early Pinnacle 310i under all conditions. Dmitri, on what kernel and/or SCM version of v4l-dvb you discover that flaw? Maybe I can reproduce it then. Andy has reports, that ir-kbd-i2c is still fine on 2.6.31, but breaks on 2.6.32. Do we already run out of sync? Cheers, Hermann -- 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: cx18: Unable to find blank work order form to schedule incoming mailbox ...
On 03/01/10 20:34, Andy Walls wrote: On Mon, 2010-03-01 at 11:07 -0500, Mark Lord wrote: I'm using MythTV-0.21-fixes (from svn) on top of Linux-2.6.33 (from kernel.org), with an HVR-1600 tuner card. This card usually works okay (with workarounds for the known analog recording bugs) in both analog and digital modes. Last night, for the first time ever, MythTV chose to record from both the analog and digital sides of the HVR-1600 card at exactly the same times.. The kernel driver failed, and neither recording was successful. The only message in /var/log/messages was: Feb 28 19:59:45 duke kernel: cx18-0: Unable to find blank work order form to schedule incoming mailbox command processing This is really odd. It means: 1. Your machine had a very busy burst of cx18 driver buffer handling activity. Stopping a number of different streams, MPEG, VBI, and (DTV) TS at nearly the same time could do it 2. The firmware locked up. 3. The work handler kernel thread, cx18-0-in, got killed, if that's possible, or the processor it was running on got really bogged down. .. Yeah, it was pretty strange. I wonder.. the system also has a Hauppauge 950Q USB tuner, which is also partially controlled by the cx18 driver (I think). I wonder if perhaps that had anything to do with it? If you want to make the problem just go away then up this parameter in cx18-driver.h: #define CX18_MAX_IN_WORK_ORDERS (CX18_MAX_FW_MDLS_PER_STREAM + 7) to something like #define CX18_MAX_IN_WORK_ORDERS (2*CX18_MAX_FW_MDLS_PER_STREAM + 7) .. Heh.. Yup, that's the first thing I did after looking at the code. :) Dunno if it'll help or not, but easy enough to do. And if the cx18 is indeed being used by two cards (HVR-1600 and HVR-950Q), then perhaps that number does need to be bigger or dynamic (?). I've since tried to reproduce the failure on purpose, with no luck to date. Thanks guys! -- 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
