[GIT PATCHES FOR 2.6.35] Small miscellaneous fixes
Retry. I accidentally based by tree from linux-2.6.git instead of v4l-dvb.git. Sorry about that, hopefully this works better. Hans The following changes since commit 942ab4762505a51a7a433a7608ba5d3eed6e4f8b: Jean Delvare (1): V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135 variants are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc-fixes Hans Verkuil (3): videobuf-core: fix spelling mistake in debug message. v4l doc: fix font of field name v4l2: sort chip IDs in v4l2-chip-ident.h Michael Hunold (1): saa7146: fix up bytesperline if it is an impossible value Documentation/DocBook/v4l/vidioc-reqbufs.xml |2 +- drivers/media/common/saa7146_video.c |8 +- drivers/media/video/videobuf-core.c |2 +- include/media/v4l2-chip-ident.h | 120 + 4 files changed, 69 insertions(+), 63 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
Magic in videobuf
Hello, is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code besides driver debugging? I intend to remove them, as we weren't able to find any particular use for them when we were discussing this at the memory handling meeting in Norway... Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- 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
[BUGFIX][PATCH] change some parameters for tlg2300
The orgin parameters may cause a bug : The audio may lost in certain
situation (such as open the VLC at the first time).
The origin parameters set a small stop_threshold for snd_pcm_runtime{}.
So a xrun occurs in some situation.
Signed-off-by: Huang Shijie shij...@gmail.com
---
drivers/media/video/tlg2300/pd-alsa.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/tlg2300/pd-alsa.c
b/drivers/media/video/tlg2300/pd-alsa.c
index 6f42621..e9ad715 100644
--- a/drivers/media/video/tlg2300/pd-alsa.c
+++ b/drivers/media/video/tlg2300/pd-alsa.c
@@ -21,9 +21,6 @@
static void complete_handler_audio(struct urb *urb);
#define AUDIO_EP (0x83)
#define AUDIO_BUF_SIZE (512)
-#define PERIOD_SIZE(1024 * 8)
-#define PERIOD_MIN (4)
-#define PERIOD_MAX PERIOD_MIN
static struct snd_pcm_hardware snd_pd_hw_capture = {
.info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
@@ -38,18 +35,11 @@ static struct snd_pcm_hardware snd_pd_hw_capture = {
.rate_max = 48000,
.channels_min = 2,
.channels_max = 2,
- .buffer_bytes_max = PERIOD_SIZE * PERIOD_MIN,
- .period_bytes_min = PERIOD_SIZE,
- .period_bytes_max = PERIOD_SIZE,
- .periods_min = PERIOD_MIN,
- .periods_max = PERIOD_MAX,
- /*
.buffer_bytes_max = 62720 * 8,
.period_bytes_min = 64,
.period_bytes_max = 12544,
.periods_min = 2,
.periods_max = 98
- */
};
static int snd_pd_capture_open(struct snd_pcm_substream *substream)
--
1.6.6
--
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] V4L: v4l2-subdev driver for AK8813 and AK8814 TV-encoders from AKM
On Sun, 14 Mar 2010, Hans Verkuil wrote:
Review notes below...
On Thursday 11 March 2010 11:25:42 Guennadi Liakhovetski wrote:
AK8814 only differs from AK8813 by included Macrovision Copy Protection
function. This patch adds a driver for AK8813 and AK8814 I2C PAL/NTSC TV
encoders.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
[snip]
diff --git a/drivers/media/video/ak881x.c b/drivers/media/video/ak881x.c
new file mode 100644
index 000..b91f0f6
--- /dev/null
+++ b/drivers/media/video/ak881x.c
@@ -0,0 +1,360 @@
+/*
+ * Driver for AK8813 / AK8814 TV-ecoders from Asahi Kasei Microsystems
Co., Ltd. (AKM)
+ *
+ * Copyright (C) 2010, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * 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.
+ */
+
+#include linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+
+#include media/ak881x.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+
+#define AK881X_INTERFACE_MODE 0
+#define AK881X_VIDEO_PROCESS1 1
+#define AK881X_VIDEO_PROCESS2 2
+#define AK881X_VIDEO_PROCESS3 3
+#define AK881X_DAC_MODE5
+#define AK881X_STATUS 0x24
+#define AK881X_DEVICE_ID 0x25
+#define AK881X_DEVICE_REVISION 0x26
+
+struct ak881x {
+ struct v4l2_subdev subdev;
+ struct ak881x_pdata *pdata;
+ int id; /* DEVICE_ID code V4L2_IDENT_AK881X code from v4l2-chip-ident.h
*/
+ char revision; /* DEVICE_REVISION content */
+};
+
+static int reg_read(struct i2c_client *client, const u8 reg)
+{
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int reg_write(struct i2c_client *client, const u8 reg,
+const u8 data)
+{
+ return i2c_smbus_write_byte_data(client, reg, data);
+}
I suggest making these inline.
Disagree. It has been advised on the LKML to _not_ use inline in .c files
- the compiler decides itself, and it does trivially inline these.
I also recommend using struct v4l2_subdev instead of struct i2c_client as
argument. In my experience it makes the code cleaner if the mapping from
subdev to i2c_client is done at the lowest possible level.
May I disagree with this one too?;) Just for a mere reason, that in this
specific case, register-access routines should not need anything except the
i2c-client - by desiign.
+
+static int reg_set(struct i2c_client *client, const u8 reg,
+ const u8 data, u8 mask)
+{
+ int ret = reg_read(client, reg);
+ if (ret 0)
+ return ret;
+ return reg_write(client, reg, (ret ~mask) | (data mask));
+}
+
+static struct ak881x *to_ak881x(const struct i2c_client *client)
+{
+ return container_of(i2c_get_clientdata(client), struct ak881x, subdev);
+}
Ditto for this one.
+
+static int ak881x_g_chip_ident(struct v4l2_subdev *sd,
+ struct v4l2_dbg_chip_ident *id)
+{
+ struct i2c_client *client = sd-priv;
Don't use sd-priv directly. Use v4l2_get_subdevdata(sd) instead.
Ok.
+ struct ak881x *ak881x = to_ak881x(client);
+
+ if (id-match.type != V4L2_CHIP_MATCH_I2C_ADDR)
+ return -EINVAL;
+
+ if (id-match.addr != client-addr)
+ return -ENODEV;
+
+ id-ident = ak881x-id;
+ id-revision= ak881x-revision;
+
+ return 0;
+}
+
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static int ak881x_g_register(struct v4l2_subdev *sd,
+ struct v4l2_dbg_register *reg)
+{
+ struct i2c_client *client = sd-priv;
+
+ if (reg-match.type != V4L2_CHIP_MATCH_I2C_ADDR || reg-reg 0x26)
+ return -EINVAL;
+
+ if (reg-match.addr != client-addr)
+ return -ENODEV;
+
+ reg-val = reg_read(client, reg-reg);
+
+ if (reg-val 0x)
+ return -EIO;
+
+ return 0;
+}
+
+static int ak881x_s_register(struct v4l2_subdev *sd,
+ struct v4l2_dbg_register *reg)
+{
+ struct i2c_client *client = sd-priv;
+
+ if (reg-match.type != V4L2_CHIP_MATCH_I2C_ADDR || reg-reg 0x26)
+ return -EINVAL;
+
+ if (reg-match.addr != client-addr)
+ return -ENODEV;
+
+ if (reg_write(client, reg-reg, reg-val) 0)
+ return -EIO;
+
+ return 0;
+}
+#endif
+
+static int ak881x_try_g_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *mf)
Can you rename this function to ak881x_try_g_mbus_fmt? Same for the other
fmt functions.
Well, we (including you) wanted to eventually convert all subdev drivers
to mediabus, and then to rename *_mbus_fmt to just *_fmt. That's why I
kept these names without mbus
Re: [BUGFIX][PATCH] change some parameters for tlg2300
Hi Mauro:
Please ignore this patch.
This patch has side effect : the radio does not run well with this patch.
Best Regards
Huang Shijie.
The orgin parameters may cause a bug : The audio may lost in certain
situation (such as open the VLC at the first time).
The origin parameters set a small stop_threshold for snd_pcm_runtime{}.
So a xrun occurs in some situation.
Signed-off-by: Huang Shijie shij...@gmail.com
---
drivers/media/video/tlg2300/pd-alsa.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/tlg2300/pd-alsa.c
b/drivers/media/video/tlg2300/pd-alsa.c
index 6f42621..e9ad715 100644
--- a/drivers/media/video/tlg2300/pd-alsa.c
+++ b/drivers/media/video/tlg2300/pd-alsa.c
@@ -21,9 +21,6 @@
static void complete_handler_audio(struct urb *urb);
#define AUDIO_EP (0x83)
#define AUDIO_BUF_SIZE (512)
-#define PERIOD_SIZE (1024 * 8)
-#define PERIOD_MIN (4)
-#define PERIOD_MAX PERIOD_MIN
static struct snd_pcm_hardware snd_pd_hw_capture = {
.info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
@@ -38,18 +35,11 @@ static struct snd_pcm_hardware snd_pd_hw_capture = {
.rate_max = 48000,
.channels_min = 2,
.channels_max = 2,
- .buffer_bytes_max = PERIOD_SIZE * PERIOD_MIN,
- .period_bytes_min = PERIOD_SIZE,
- .period_bytes_max = PERIOD_SIZE,
- .periods_min = PERIOD_MIN,
- .periods_max = PERIOD_MAX,
- /*
.buffer_bytes_max = 62720 * 8,
.period_bytes_min = 64,
.period_bytes_max = 12544,
.periods_min = 2,
.periods_max = 98
- */
};
static int snd_pd_capture_open(struct snd_pcm_substream *substream)
--
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: Capturing raw JPEG stream from webcam
Hi Basil,
On Saturday 13 March 2010 02:55:47 Basil Mohamed Gohar wrote:
I originally posted this to the video4linux mailing list, but I've since
discovered that this is the appropriate place (or so I understand) for
video4linux questions. My question is how can I capture the raw JPEG
image stream (e.g., MJPEG) from my webcam, which reports through v4l2
that it is capable of. I am using the gst-launch cli to gstreamer,
which confirms that my webcam has this capability:
image/jpeg, width=(int)640, height=(int)480, framerate=(fraction){
30/1, 25/1, 20/1, 15/1, 10/1, 5/1 }
And, indeed, I can capture using this capability, but the framerate is
not at the specified rate, but at a much lower value (half or less).
So, even if I specify 30fps, I get something less. I can capture the
full 30fps when I use one of the yuv modes, though, so it's clearly
capable of delivering that framerate.
My webcam is a Logitech QuickCam Pro 5000. The lsusb output is:
046d:08ce Logitech, Inc. QuickCam Pro 5000
An example command line I try is as follows:
gst-launch-0.10 v4l2src device=/dev/video0 ! 'image/jpeg, width=640,
height=480, framerate=30/1' ! jpegdec ! xvimagesink
Have you tried disabling auto-exposure ? The camera is allowed to reduce the
frame rate in low-light conditions if auto-exposure is turned on.
--
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
unsupported device: Lightel Technologies Inc - CI-1000-USB2 Connector Inspector
Hi In syslog I've found a request to send e-mail with log, so I do it. http://pastebin.com/g5WtquKY -- Greetings, Seweryn -- 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: missing audio for analog recordings
On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote: On 03/02/10 07:40, Andy Walls wrote: Again, maybe dynamically allocating these work order objects from the kernel as needed, would be better from a small dynamically allocated pool for each card. I was concerned that the interrupt handler was taking to long at the time I implemented the things the way they are now. .. I haven't seen that particular issue again, with or without increasing the work orders, so hopefully it won't recur. OK. But after updating to the tip of the v4l2-dvb git tree last week, I've been hitting the no audio on analog recordings bug much more often. Is that tuner audio or baseband (line-in) audio? Digging through google, it appears this problem has been around as long as the cx18 driver has existed, with no clear resolution. Lots of people have reported it to you before, and nobody has found a silver bullet fix. Correct. I thought it was completely gone, but apparently, there just isn't a lot of reporting of this intermittent problem. The problem is still there. I have now spent a good many hours trying to isolate *when* it happens, and have narrowed it down to module initialization. Basically, if the audio is working after modprobe cx18, it then continues to work from recording to recording until the next reboot. If the audio is not working after modprobe, then simply doing rmmod/modprobe in a loop (until working audio is achieved) is enough to cure it. Good to know. So for my Mythtv box here, I now have a script to check for missing audio and do the rmmod/modprobe. This is a good, effective workaround. http://rtr.ca/hvr1600/fix_hvr1600_audio.sh That's a link to my script. As for the actual underlying cause/bug, it's still not clear what is happening. But the problem is a LOT more prevalent (for me, and for two other people I know) with versions of the cx18 driver since spring 2009. My suspicion is that the firmware download for the APU is somehow being corrupted, and now that the driver downloads the firmware *twice* during init, it doubles the odds of said corruption. Just a theory, but it's the best fit so far. Please isolate an APU load and initialization problem, by seeing if audio fails for both tuner audio and baseband audio. Here are all the potential problem areas I can think of: 1. A/V digitizer/decoder audio detection firmware load and init. (I've added firmware readback verification to try and head this off.) 2. A/V digitizer decoder audio microcontroller hard reset and soft reset sequencing. (I think the cx18 driver has this wrong ATM.) 3. APU load and init. (The double load is to fix a DTV TS stream bug on every other APU CPU firmware load sequence. The APU_AI_RESET is to fix the audio bitrate problem on first capture after a double firmware load.) 4. AI1 Mux setting failing when switching between the internal A/V decoder's I2S output and the external I2S inputs. (I thought I had this fixed, but I don't have detailed register specs for that register - so maybe not.) 5. A/V decoder audio clock PLL stops operating due to being programmed out of range. (This was a problem for 32 ksps audio a while ago, but I'm pretty confident I have it fixed.) 6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due to a problen Helen Buus reported with cable TV.) I think #2 is the real problem. I just started to disassmble the digitizer firmware 2 nights ago to see if I could get some insight as to how to properly reset it. I've got a first WAG at fixing the resets of the audio microcontroller's resets at: http://linuxtv.org/hg/~awalls/cx18-audio If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define from 0x810 to 0x9cc, although that may not work either. I think we have some nasty i2c issues somewhere in the kernel. The only I2C connected devices for analog audio are the analog tuner IF demodulator chip for SIF audio and the CS5345 chip for baseband audio. Unlike the PVR-150, which has an I2C connected CX25843 A/V decoder, the CX23418's A/V decoder is integrated and accessed via PCI bus registers. With that said, the CX23418 will sometimes have to let register access over the PCI bus fail. For that, I have routines in cx18-io.[ch] to perform retries. You may wish to add a log statement there to watch for retry loops that completely fail. Thanks for the troubleshooting and reporting. Regards, Andy -- 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/5] drivers/media/video/cx23885 needs kfifo conversion
Hi Andrew, You can drop this patch. The conversion to the new kfifo API happened on this patch: commit 7801edb0b8b66e83c13623b483bc2e846c007c9d Author: Stefani Seibold stef...@seibold.net AuthorDate: Mon Dec 21 14:37:33 2009 -0800 Commit: Linus Torvalds torva...@linux-foundation.org CommitDate: Tue Dec 22 14:17:57 2009 -0800 media video cx23888 driver: ported to new kfifo API The patch is already upstream. 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: [GIT FIXES FOR 2.6.34] Fixes for vpfe capture driver
Hi Murali, Muralidharan Karicheri wrote: Mauro, The following changes since commit 9178a7c062ff0c43e95d826419f9e9454c52ef15: Mauro Carvalho Chehab (1): V4L/DVB: Fix bad whitespacing Applied, thanks. Please, next time base your fixes against fixes.git. This make things easier for me. 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: [GIT PULL] V4L2 file handles and event interface
Hi Sakari,
Sakari Ailus wrote:
Hi Mauro,
The latest event patchset is available in my Gitorious tree now. The
file handles documentation patch changed due to unrelated changes in
Documentation/video4linux/v4l2-framework.txt. There are no other changes
compared to the patches sent to the list earlier.
Please pull.
The following changes since commit 9178a7c062ff0c43e95d826419f9e9454c52ef15:
Mauro Carvalho Chehab (1):
V4L/DVB: Fix bad whitespacing
are available in the git repository at:
git://gitorious.org/omap3camera/mainline.git v4l-dvb-event
Sakari Ailus (6):
V4L: File handles
The idea of having a common file handle at the V4L2 core is interesting, but
I see some troubles on it. As you said on this changeset's comment:
V4L/DVB: V4L: File handles
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.
You're saying that the drivers should use struct v4l2_fh, but there
aren't any patches on your series enforcing this change.
Also, you're defining it as just:
+struct v4l2_fh {
+ struct list_headlist;
+ struct video_device *vdev;
+};
while other drivers need something much more complex. For example, saa7134
defines the file handler struct used on file-private_data as:
struct saa7134_fh {
struct saa7134_dev *dev;
unsigned int radio;
enum v4l2_buf_type type;
unsigned int resources;
enum v4l2_priority prio;
/* video overlay */
struct v4l2_window win;
struct v4l2_clip clips[8];
unsigned int nclips;
/* video capture */
struct saa7134_format *fmt;
unsigned int width,height;
struct videobuf_queue cap;
struct saa7134_pgtable pt_cap;
/* vbi capture */
struct videobuf_queue vbi;
struct saa7134_pgtable pt_vbi;
};
Even the simplest driver we have (vivi) require more than just
the video device:
struct vivi_fh {
struct vivi_dev*dev;
/* video capture */
struct vivi_fmt*fmt;
unsigned int width, height;
struct videobuf_queue vb_vidq;
enum v4l2_buf_type type;
unsigned char bars[8][3];
intinput; /* Input Number on bars */
};
So, it is not clear for me how to convert any of the existing
drivers to fit on your proposal.
Also, the better is if you could provide us a patchset with the needed
conversion. It is interesting if you could add some notes there about why
this change is needed.
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: [GIT PULL] V4L2 file handles and event interface
Hi Mauro,
Hi Sakari,
Sakari Ailus wrote:
Hi Mauro,
The latest event patchset is available in my Gitorious tree now. The
file handles documentation patch changed due to unrelated changes in
Documentation/video4linux/v4l2-framework.txt. There are no other changes
compared to the patches sent to the list earlier.
Please pull.
The following changes since commit
9178a7c062ff0c43e95d826419f9e9454c52ef15:
Mauro Carvalho Chehab (1):
V4L/DVB: Fix bad whitespacing
are available in the git repository at:
git://gitorious.org/omap3camera/mainline.git v4l-dvb-event
Sakari Ailus (6):
V4L: File handles
The idea of having a common file handle at the V4L2 core is interesting,
but
I see some troubles on it. As you said on this changeset's comment:
V4L/DVB: V4L: File handles
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.
You're saying that the drivers should use struct v4l2_fh, but there
aren't any patches on your series enforcing this change.
I guess that was an unfortunate phrase in the comment. It should have
been: 'If drivers need the events interface, then they should use
v4l2_fh.'
So this is not required for all drivers. Although it is my intention to
move into that direction, but that will take much more time.
Also, you're defining it as just:
+struct v4l2_fh {
+ struct list_headlist;
+ struct video_device *vdev;
+};
while other drivers need something much more complex. For example, saa7134
defines the file handler struct used on file-private_data as:
struct saa7134_fh {
struct saa7134_dev *dev;
unsigned int radio;
enum v4l2_buf_type type;
unsigned int resources;
enum v4l2_priority prio;
/* video overlay */
struct v4l2_window win;
struct v4l2_clip clips[8];
unsigned int nclips;
/* video capture */
struct saa7134_format *fmt;
unsigned int width,height;
struct videobuf_queue cap;
struct saa7134_pgtable pt_cap;
/* vbi capture */
struct videobuf_queue vbi;
struct saa7134_pgtable pt_vbi;
};
Even the simplest driver we have (vivi) require more than just
the video device:
struct vivi_fh {
struct vivi_dev*dev;
/* video capture */
struct vivi_fmt*fmt;
unsigned int width, height;
struct videobuf_queue vb_vidq;
enum v4l2_buf_type type;
unsigned char bars[8][3];
intinput; /* Input Number on bars */
};
So, it is not clear for me how to convert any of the existing
drivers to fit on your proposal.
Drivers will still have their own fh structure, but it embed the v4l2_fh
struct. Just as is done with e.g. struct v4l2_subdev or struct v4l2_device
(or pretty much everywhere in the kernel these days).
Also, the better is if you could provide us a patchset with the needed
conversion. It is interesting if you could add some notes there about why
this change is needed.
I plan on converting ivtv to this (ivtv already has events using the
poorly defined dvb/video.h events interface). But it looks like that will
take two weeks before I get the time. Although if this would block you
from merging this patch series, then I can try to get it done earlier.
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: [GIT PULL] V4L2 file handles and event interface
Mauro Carvalho Chehab wrote:
Hi Sakari,
Hi Mauro,
...
The idea of having a common file handle at the V4L2 core is interesting, but
I see some troubles on it. As you said on this changeset's comment:
V4L/DVB: V4L: File handles
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.
You're saying that the drivers should use struct v4l2_fh, but there
aren't any patches on your series enforcing this change.
Oh, there should be an if there. It is described better in
Documentation/video4linux/v4l2-framework.txt .
Also, you're defining it as just:
+struct v4l2_fh {
+ struct list_headlist;
+ struct video_device *vdev;
+};
while other drivers need something much more complex. For example, saa7134
defines the file handler struct used on file-private_data as:
struct saa7134_fh {
struct saa7134_dev *dev;
unsigned int radio;
enum v4l2_buf_type type;
unsigned int resources;
enum v4l2_priority prio;
/* video overlay */
struct v4l2_window win;
struct v4l2_clip clips[8];
unsigned int nclips;
/* video capture */
struct saa7134_format *fmt;
unsigned int width,height;
struct videobuf_queue cap;
struct saa7134_pgtable pt_cap;
/* vbi capture */
struct videobuf_queue vbi;
struct saa7134_pgtable pt_vbi;
};
Even the simplest driver we have (vivi) require more than just
the video device:
struct vivi_fh {
struct vivi_dev*dev;
/* video capture */
struct vivi_fmt*fmt;
unsigned int width, height;
struct videobuf_queue vb_vidq;
enum v4l2_buf_type type;
unsigned char bars[8][3];
intinput; /* Input Number on bars */
};
So, it is not clear for me how to convert any of the existing
drivers to fit on your proposal.
The struct v4l2_fh is meant to be a part of the driver's own file handle
structure. It does not attempt to offer drivers anything directly but
generic functionality that depends on file handle specific data such as
V4L2 events. E.g.
struct my_video_fh {
blah;
struct v4l2_fh fh;
blah;
};
Also, the better is if you could provide us a patchset with the needed
conversion. It is interesting if you could add some notes there about why
this change is needed.
There is no need to change any existing drivers, this change does not
affect them. V4L2 file handles are only for those drivers that want to
use them. Other drivers can safely ignore this. But if a driver wants to
use V4L2 events it also has to use V4L2 file handles since event
information is stored in V4L2 file handles.
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: dual TT C-1501 on a single PCI riser
On 03/15/2010 01:50 PM, Martin van Es wrote: When I look at the pci layout, pci device 05 is connected to bridge 1e.0: -[:00]-+-00.0 +-1e.0-[05]--+-00.0 Philips Semiconductors SAA7146 |\-0c.0 Philips Semiconductors SAA7146 No, this means bridge 1e.0 connects to bus number 05. So I started to suspect that the motherboard had no way to know what PCI int's were used behind the bridge if both cards were detected to serve INTA (i.e. 05.0x = INTA in lspci -v) and would thus (quite stupidly?) route any int for this slot to INTA? I don't get that sentence.. Every slot has INTA/B/C/D and each PCI function announces which one of these it uses. In most cases INTA is used. The board manufacturer for bus 05 only knows how INTx maps to APIC inputs for slot 00. He knows there are people who use riser cards, so he adds mappings for non-existent slots by permuting those interrupts available to slot 00. Last change was to cut the original slot2 connection to INTD and gone were my extra interrupts! It might be INTD isn't connected to the APIC. It is rarely used on cards. So now I have two correctly recognised cards, both using int 20 and PCI INTA. Now I wonder if this will harm the performance if both cards are recording streams, let alone if they work, because that's the next test I still have to do. It should work. On interrupt the driver will be called once for each card to check if the card in question caused the interrupt. As long as we are not talking about thousands of interrupts per second, this shouldn't harm performance. Daniel -- Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055 emlix - your embedded linux partner -- 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: Capturing raw JPEG stream from webcam
On 03/15/2010 05:40 AM, Laurent Pinchart wrote:
Hi Basil,
Hi Laurent!
On Saturday 13 March 2010 02:55:47 Basil Mohamed Gohar wrote:
I originally posted this to the video4linux mailing list, but I've since
discovered that this is the appropriate place (or so I understand) for
video4linux questions. My question is how can I capture the raw JPEG
image stream (e.g., MJPEG) from my webcam, which reports through v4l2
that it is capable of. I am using the gst-launch cli to gstreamer,
which confirms that my webcam has this capability:
image/jpeg, width=(int)640, height=(int)480, framerate=(fraction){
30/1, 25/1, 20/1, 15/1, 10/1, 5/1 }
And, indeed, I can capture using this capability, but the framerate is
not at the specified rate, but at a much lower value (half or less).
So, even if I specify 30fps, I get something less. I can capture the
full 30fps when I use one of the yuv modes, though, so it's clearly
capable of delivering that framerate.
My webcam is a Logitech QuickCam Pro 5000. The lsusb output is:
046d:08ce Logitech, Inc. QuickCam Pro 5000
An example command line I try is as follows:
gst-launch-0.10 v4l2src device=/dev/video0 ! 'image/jpeg, width=640,
height=480, framerate=30/1' ! jpegdec ! xvimagesink
Have you tried disabling auto-exposure ? The camera is allowed to reduce the
frame rate in low-light conditions if auto-exposure is turned on.
Thanks for replying. I haven't actually tried this yet (I am currently
at work), but I do not think this is the issue, because when I choose
the YUV-style modes, I can capture at the full framerates. It's only
when I select the image/jpeg mode that I get the lower framerates,
despite explicitly requesting the higher ones.
I suppose it's not impossible that the camera is opting for different
behavior depending on the mode of the request, but I think that is not
likely the case. I do appreciate the suggestion, though, and I'll try
it when I get home.
Meanwhile, does anyone else have any other ideas?
--
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: [GIT PULL] V4L2 file handles and event interface
Sakari Ailus wrote:
Mauro Carvalho Chehab wrote:
Hi Sakari,
Hi Mauro,
...
The idea of having a common file handle at the V4L2 core is interesting, but
I see some troubles on it. As you said on this changeset's comment:
V4L/DVB: V4L: File handles
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.
You're saying that the drivers should use struct v4l2_fh, but there
aren't any patches on your series enforcing this change.
Oh, there should be an if there. It is described better in
Documentation/video4linux/v4l2-framework.txt .
Even there, it is not clear that this is an optional interface. Also, as I am
understanding, you'll likely add other things there, so the better would be
to add some notes at the header files that implement those functions, stating
when and how they should be used.
Also, you're defining it as just:
+struct v4l2_fh {
+ struct list_headlist;
+ struct video_device *vdev;
+};
while other drivers need something much more complex. For example, saa7134
defines the file handler struct used on file-private_data as:
struct saa7134_fh {
struct saa7134_dev *dev;
unsigned int radio;
enum v4l2_buf_type type;
unsigned int resources;
enum v4l2_priority prio;
/* video overlay */
struct v4l2_window win;
struct v4l2_clip clips[8];
unsigned int nclips;
/* video capture */
struct saa7134_format *fmt;
unsigned int width,height;
struct videobuf_queue cap;
struct saa7134_pgtable pt_cap;
/* vbi capture */
struct videobuf_queue vbi;
struct saa7134_pgtable pt_vbi;
};
Even the simplest driver we have (vivi) require more than just
the video device:
struct vivi_fh {
struct vivi_dev*dev;
/* video capture */
struct vivi_fmt*fmt;
unsigned int width, height;
struct videobuf_queue vb_vidq;
enum v4l2_buf_type type;
unsigned char bars[8][3];
intinput; /* Input Number on bars */
};
So, it is not clear for me how to convert any of the existing
drivers to fit on your proposal.
The struct v4l2_fh is meant to be a part of the driver's own file handle
structure. It does not attempt to offer drivers anything directly but
generic functionality that depends on file handle specific data such as
V4L2 events. E.g.
struct my_video_fh {
blah;
struct v4l2_fh fh;
blah;
};
Also, the better is if you could provide us a patchset with the needed
conversion. It is interesting if you could add some notes there about why
this change is needed.
There is no need to change any existing drivers, this change does not
affect them. V4L2 file handles are only for those drivers that want to
use them. Other drivers can safely ignore this. But if a driver wants to
use V4L2 events it also has to use V4L2 file handles since event
information is stored in V4L2 file handles.
It is always a good idea to add at least one use case when a new API is
added on kernel. So, I prefer if you could send those changes together
with some use case. Hans is planning to use on ivtv (as his email on
this thread). Also Guennadi said me once, at irc, that he has also something
ready or almost ready just waiting for this merge. So, it would be really
nice if you can send either one of the implementations together with the
patch series. This helps to better understand about the usecases.
Cheers,
--
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: Magic in videobuf
Hans Verkuil wrote: Hi Pawel, Pawel Osciak wrote: Hello, is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code besides driver debugging? I intend to remove them, as we weren't able to find any particular use for them when we were discussing this at the memory handling meeting in Norway... It is a sort of paranoid check to avoid the risk of mass memory corruption if something goes deadly wrong with the video buffers. The original videobuf, written back in 2001/2002 had this code, and I've kept it on the redesign I did in 2007, since I know that DMA is very badly implemented on some chipsets. There are several reports of the video driver to corrupt the system memory and damaging the disk data when a PCI transfer to disk happens at the same time that a PCI2PCI data transfer happens (This basically affects overlay mode, where the hardware is programmed to transfer data from the video board to the video adapter board). The DMA bug is present on several VIA and SYS old chipsets. It happened again in some newer chips (2007?), and the fix were to add a quirk blocking overlay mode on the reported broken hardware. It seems that newer BIOSes for those newer hardware fixed this issue. That's said, I never got any report from anyone explicitly saying that they hit the MAGIC_CHECK() logic. I prefer to keep this logic, but maybe we can add a CONFIG option to disable it. Something like: #ifdef CONFIG_VIDEO_DMA_PARANOID_CHECK #define MAGIC_CHECK() ... #else #define MAGIC_CHECK() #endif What on earth does this magic check have to do with possible DMA overruns/memory corruption? This assumes that somehow exactly these magic fields are overwritten and that you didn't crash because of memory corruption elsewhere much earlier. Yes, that's the assumption. As, in general, there are more than one videobuffer, and assuming that one buffer physical address is close to the other, if the data got miss-aligned at the DMA, it is likely that the magic number of the next buffer will be overwritten if something got bad. The real situation will depend on how fragmented is the memory. It pollutes the code There are only 18 occurences of MAGIC* at a given videobuf driver: $ grep MAGIC ~v4l/master_hg/v4l/videobuf-dma-sg.c |wc -l 18 So, I don't think it is too much pollution. for no good reason. All it does is oops anyway, so it really doesn't 'avoid' a crash (as if you could in such scenarios). And most likely the damage has been done already in that case. It won't avoid the damage, but the error message could potentially help to track the issue. It will also likely limit the damage. Please let us get rid of this. It makes no sense whatsoever. I don't have a strong opinion about this subject, but if this code might help to avoid propagating the damage and to track the issue, I don't see why we need to remove it, especially since it is easy to disable the entire logic by just adding a few #if's to remove this code on environments where no problem is expected. -- 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: [GIT PULL] V4L2 file handles and event interface
Mauro Carvalho Chehab wrote:
Video device drivers should use the v4l2_fh pointer as their
file-private_data.
...
The struct v4l2_fh is meant to be a part of the driver's own file handle
structure. It does not attempt to offer drivers anything directly but
generic functionality that depends on file handle specific data such as
V4L2 events. E.g.
struct my_video_fh {
blah;
struct v4l2_fh fh;
blah;
};
An additional comment about this:
On your comment, you said that Video device drivers should use the v4l2_fh
pointer as their file-private_data..
This can be understood as:
file-private_data = v4l2_fh;
But a driver following your example, should do, instead:
file-private_data = my_video_fh;
Please, be sure that you document it clearly when you submit it again.
--
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: Magic in videobuf
Hans Verkuil wrote: Hi Pawel, Pawel Osciak wrote: Hello, is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code besides driver debugging? I intend to remove them, as we weren't able to find any particular use for them when we were discussing this at the memory handling meeting in Norway... It is a sort of paranoid check to avoid the risk of mass memory corruption if something goes deadly wrong with the video buffers. The original videobuf, written back in 2001/2002 had this code, and I've kept it on the redesign I did in 2007, since I know that DMA is very badly implemented on some chipsets. There are several reports of the video driver to corrupt the system memory and damaging the disk data when a PCI transfer to disk happens at the same time that a PCI2PCI data transfer happens (This basically affects overlay mode, where the hardware is programmed to transfer data from the video board to the video adapter board). The DMA bug is present on several VIA and SYS old chipsets. It happened again in some newer chips (2007?), and the fix were to add a quirk blocking overlay mode on the reported broken hardware. It seems that newer BIOSes for those newer hardware fixed this issue. That's said, I never got any report from anyone explicitly saying that they hit the MAGIC_CHECK() logic. I prefer to keep this logic, but maybe we can add a CONFIG option to disable it. Something like: #ifdef CONFIG_VIDEO_DMA_PARANOID_CHECK #define MAGIC_CHECK() ... #else #define MAGIC_CHECK() #endif What on earth does this magic check have to do with possible DMA overruns/memory corruption? This assumes that somehow exactly these magic fields are overwritten and that you didn't crash because of memory corruption elsewhere much earlier. Yes, that's the assumption. As, in general, there are more than one videobuffer, and assuming that one buffer physical address is close to the other, if the data got miss-aligned at the DMA, it is likely that the magic number of the next buffer will be overwritten if something got bad. The real situation will depend on how fragmented is the memory. For the record: we are talking about the magic fields as found in include/media/videobuf*.h. None of the magic field there are actually in the video buffers. They are in administrative structures or in ops structs which are unlikely to be close in memory to the actual buffers. Magic values that are actually put in the buffers themselves might serve some purpose. It pollutes the code There are only 18 occurences of MAGIC* at a given videobuf driver: $ grep MAGIC ~v4l/master_hg/v4l/videobuf-dma-sg.c |wc -l 18 So, I don't think it is too much pollution. It is, because it is absolute not clear what its purpose is, and in this case even when I know the purpose it still makes no sense. Code like that confuses people and does more harm than good. for no good reason. All it does is oops anyway, so it really doesn't 'avoid' a crash (as if you could in such scenarios). And most likely the damage has been done already in that case. It won't avoid the damage, but the error message could potentially help to track the issue. It will also likely limit the damage. Please let us get rid of this. It makes no sense whatsoever. I don't have a strong opinion about this subject, but if this code might help to avoid propagating the damage and to track the issue, I don't see why we need to remove it, especially since it is easy to disable the entire logic by just adding a few #if's to remove this code on environments where no problem is expected. It is highly unlikely that this code ever prevented these issues. Especially given the places where the check is done. I think this is just debug code that has been dragged along for all these years without anyone bothering to remove it. 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: [GIT PULL] V4L2 file handles and event interface
Mauro Carvalho Chehab wrote:
Video device drivers should use the v4l2_fh pointer as their
file-private_data.
...
The struct v4l2_fh is meant to be a part of the driver's own file
handle
structure. It does not attempt to offer drivers anything directly but
generic functionality that depends on file handle specific data such as
V4L2 events. E.g.
struct my_video_fh {
blah;
struct v4l2_fh fh;
blah;
};
An additional comment about this:
On your comment, you said that Video device drivers should use the
v4l2_fh
pointer as their file-private_data..
This can be understood as:
file-private_data = v4l2_fh;
But a driver following your example, should do, instead:
file-private_data = my_video_fh;
No, it should do:
file-private_data = my_video_fh.fh;
Then later you can use to_container to get back to my_video_fh.
But it is true that a short example might clarify things.
Regards,
Hans
Please, be sure that you document it clearly when you submit it again.
--
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
--
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: Magic in videobuf
Hans Verkuil wrote: Hans Verkuil wrote: Hi Pawel, Pawel Osciak wrote: Hello, is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code besides driver debugging? I intend to remove them, as we weren't able to find any particular use for them when we were discussing this at the memory handling meeting in Norway... It is a sort of paranoid check to avoid the risk of mass memory corruption if something goes deadly wrong with the video buffers. The original videobuf, written back in 2001/2002 had this code, and I've kept it on the redesign I did in 2007, since I know that DMA is very badly implemented on some chipsets. There are several reports of the video driver to corrupt the system memory and damaging the disk data when a PCI transfer to disk happens at the same time that a PCI2PCI data transfer happens (This basically affects overlay mode, where the hardware is programmed to transfer data from the video board to the video adapter board). The DMA bug is present on several VIA and SYS old chipsets. It happened again in some newer chips (2007?), and the fix were to add a quirk blocking overlay mode on the reported broken hardware. It seems that newer BIOSes for those newer hardware fixed this issue. That's said, I never got any report from anyone explicitly saying that they hit the MAGIC_CHECK() logic. I prefer to keep this logic, but maybe we can add a CONFIG option to disable it. Something like: #ifdef CONFIG_VIDEO_DMA_PARANOID_CHECK #define MAGIC_CHECK() ... #else #define MAGIC_CHECK() #endif What on earth does this magic check have to do with possible DMA overruns/memory corruption? This assumes that somehow exactly these magic fields are overwritten and that you didn't crash because of memory corruption elsewhere much earlier. Yes, that's the assumption. As, in general, there are more than one videobuffer, and assuming that one buffer physical address is close to the other, if the data got miss-aligned at the DMA, it is likely that the magic number of the next buffer will be overwritten if something got bad. The real situation will depend on how fragmented is the memory. For the record: we are talking about the magic fields as found in include/media/videobuf*.h. None of the magic field there are actually in the video buffers. They are in administrative structures or in ops structs which are unlikely to be close in memory to the actual buffers. Well, Pawel's email didn't mentioned that he is referring just to one type of magic check. Magic values that are actually put in the buffers themselves might serve some purpose. It pollutes the code There are only 18 occurences of MAGIC* at a given videobuf driver: $ grep MAGIC ~v4l/master_hg/v4l/videobuf-dma-sg.c |wc -l 18 So, I don't think it is too much pollution. It is, because it is absolute not clear what its purpose is, and in this case even when I know the purpose it still makes no sense. Code like that confuses people and does more harm than good. for no good reason. All it does is oops anyway, so it really doesn't 'avoid' a crash (as if you could in such scenarios). And most likely the damage has been done already in that case. It won't avoid the damage, but the error message could potentially help to track the issue. It will also likely limit the damage. Please let us get rid of this. It makes no sense whatsoever. I don't have a strong opinion about this subject, but if this code might help to avoid propagating the damage and to track the issue, I don't see why we need to remove it, especially since it is easy to disable the entire logic by just adding a few #if's to remove this code on environments where no problem is expected. It is highly unlikely that this code ever prevented these issues. Especially given the places where the check is done. I think this is just debug code that has been dragged along for all these years without anyone bothering to remove it. I remember that when I did the conversion, the memory magic helped a lot to find several issues. So, yes, they are very useful when debug troubles at videbuf. I remember I had to re-format one disk, during that time, due to a videobuf issue. So, those checks help people that are touching at the videobuf code, reducing the chances of damaging their disk partitions when trying to implement overlay mode and userptr on the videobuf implementations that misses those features, or when working on a different mmap() logic at the driver. They also helped me with some troubles related to compat32 stuff and troubles at mmap() logic on the driver, as the videobuf magic hits when the data segment is pointing to the wrong place. This may also help to find bugs with troubles with the memory allocators. By looking only at the adm struct magic, I don't see any problem on getting rid of them. -- Cheers, Mauro -- To unsubscribe from this list: send the line
Plextor ConvertX AV100U
Hi I'm Don, I'm new here. I would like to see if it's possible to get the Plextor ConvertX AV100U to work under Linux, I own this device, and currently can use it only under Windows XP. I believe it is very similar to the Plextor ConvertX PX-TV100U which is listed as a device added to kernel but not tested (Em28xx). I believe the AV100U and TV100U both lack hardware encoders (I know the AV100U doesn't have it), unlike the Plextor TV-402U with does have hardware encoding. Anyway, I'm able to help out with testing and possibly some additional technical tasks as well (with some guidance) of getting this accomplished (assuming this is technically feasible in the first place). In a terminal, lsusb shows the device as this: Bus 001 Device 003: ID 093b:a003 Plextor Corp. ConvertX AV100U A/V Capture Audio Thanks, Don -- 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: [Spca50x-devs] 17a1:0118
On Mon, 15 Mar 2010 19:24:24 +0200 Shahar Or em...@shahar-or.co.il wrote: I have a non-supported one, with the ID 17a1:0118. Data attached. I am willing to cooperate with anything that I can, including testing patches. I've noticed there's one here related: http://lists-archives.org/spca50x-devs/01649-patch-for-17a1-0128-xpx-jpeg-webcam-tascorp.html I can also send the cam over by mail, if that is necessary. I'm subscribed to the list. Hello Shahar, A driver for this webcam is available (you may find it in the last gspca version that I have just uploaded - 2.9.6 - the subdriver is 'gspca_tasc.ko'). The only problem is that nobody could yet decode the images! (Jens, Jean-Yves, any news?) About the list, all the linux video stuff is hosted at LinuxTv.org and the linux-media mailing-list at vger.kernel.org (see Cc:). Best regards. -- 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
[GIT PATCHES FOR 2.6.34] gspca development
Hi Mauro, The following changes since commit 942ab4762505a51a7a433a7608ba5d3eed6e4f8b: Jean Delvare (1): V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135 variants are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.34 Erik Andrén (1): gspca - stv06xx: Remove the 046d:08da from the stv06xx driver. Yong Zhang (1): gspca - sn9c20x: Correct onstack wait_queue_head declaration. drivers/media/video/gspca/sn9c20x.c |2 +- drivers/media/video/gspca/stv06xx/stv06xx.c |2 -- 2 files changed, 1 insertions(+), 3 deletions(-) Thanks. -- 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
[GIT PATCHES FOR 2.6.34] gspca development
Hi Mauro, The following changes since commit 942ab4762505a51a7a433a7608ba5d3eed6e4f8b: Jean Delvare (1): V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135 variants are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.35 Olivier Lorin (2): gspca - gl860: Updates to prepare the new driver for MI2020 sensor. gspca - gl860: New driver for MI2020 sensor. drivers/media/video/gspca/gl860/gl860-mi1320.c |1 + drivers/media/video/gspca/gl860/gl860-mi2020.c | 731 +--- drivers/media/video/gspca/gl860/gl860-ov2640.c |1 + drivers/media/video/gspca/gl860/gl860-ov9655.c |5 +- drivers/media/video/gspca/gl860/gl860.c| 52 +-- drivers/media/video/gspca/gl860/gl860.h|6 +- 6 files changed, 288 insertions(+), 508 deletions(-) Thanks. -- 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
[GIT PATCHES FOR 2.6.35] gspca development
Hi Mauro, Sorry, the last pull request for 2.6.35. The following changes since commit 942ab4762505a51a7a433a7608ba5d3eed6e4f8b: Jean Delvare (1): V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135 variants are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.35 Olivier Lorin (2): gspca - gl860: Updates to prepare the new driver for MI2020 sensor. gspca - gl860: New driver for MI2020 sensor. drivers/media/video/gspca/gl860/gl860-mi1320.c |1 + drivers/media/video/gspca/gl860/gl860-mi2020.c | 731 +--- drivers/media/video/gspca/gl860/gl860-ov2640.c |1 + drivers/media/video/gspca/gl860/gl860-ov9655.c |5 +- drivers/media/video/gspca/gl860/gl860.c| 52 +-- drivers/media/video/gspca/gl860/gl860.h|6 +- 6 files changed, 288 insertions(+), 508 deletions(-) Thanks. -- 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: Excessive rc polling interval in dvb_usb_dib0700 causes interference with USB soundcard
On 15 March 2010 03:55, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Sun, Mar 14, 2010 at 11:06 AM, Pedro Ribeiro ped...@gmail.com wrote: Hi Devin, after some through investigation I found that your patch solves the continuous interference. However, I have a second problem. It is also interference but appears to be quite random, by which I mean it is not at a fixed interval, sometimes it happens past 10 seconds, other times past 30 seconds, other times 2 to 5 seconds. One thing is sure - it only happens when I'm actually streaming from the DVB adapter. If I just plug it in, there is no interference. But when I start vdr (for example) the interference starts. The DVB adapter and the sound card are not sharing irq's or anything like that, and there is no system freeze when the interference happens. I also thought it was either my docking bay or power supply, but definitely it isn't. Any idea what can this be? Thank you for your help, Pedro Hello Pedro, Could you describe in more detail what you mean by interference? Do you mean that you get corrupted audio for short bursts? Or do you mean the audio is dropping out for periods of time? Can you elaborate on how long the problem occurs for, and how often it occurs? For example, do you get corrupted audio for 1 second at a time every ten or fifteen seconds? Hi Devin, by interference I mean cracks and pops in the sound. These occur rather randomly, and they are regular but not periodic, by which I mean there is no defined timeframe between them. Sometimes there are 2 or 3 in a row, other times 10 seconds between them, other times 30 seconds or 1 minute. These cracks and pops only last for a fraction of a second and they do not interfere with the audio playing. Its like some kind of static interference, really high pitched and loud. This is a USB audio device, correct? Are both devices on the same USB bus? Is there a USB hub involved? Yes they are both USB devices. There is no USB hub involved, and they are in different ports with different interrupts assigned to them. It's also possible that this is just a general latency problem - where the CPU becomes too busy, it does not service the sound card often enough and PCM data is being dropped. Have you tried running top? What does your CPU utilization look like when you are experiencing the problem? There is no jump in cpu utilization when the spikes occur. I am running a realtime kernel and I also don't see any latency spikes when the interferences occur. The problem occurs with both realtime and normal kernels, on 2.6.31, .32 and .33. Without your patch (commit 6a2071006b72bf887e38c025c60f98d2998ceacb) the problem is aggravated as the interference is constant. Something fishy is going on. I've spent countless hours trying to figure out the problem it is really hard to find a pattern. This is what I know till now: - the first time both devices are connected to the laptop after a fresh boot, usually there is no problem and they work nicely - the keyword here is usually, it has happened a few times - if i unplug and replug the dib0700 adapter, then the cracks and pops immediately start - stopping vdr seems to stop the cracks and pops MOST of the time - though sometimes it also cracks without it One thing I'm sure - without the dib0700 adapter connected to the USB bus there is cracking at all. This is a tough nut to crack. Thanks for the help, Pedro PS: This is probably unrelated, but here is a bug report: if I boot with the dib0700 adapter connected to the computer, the remote control does not work. Note what dmesg says: [ 13.033653] dib0700: loaded with support for 14 different device-types [ 13.035185] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state. [ 13.036516] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 13.038045] DVB: registering new adapter (Hauppauge Nova-T Stick) [ 13.235713] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [ 13.438312] DiB0070: successfully identified [ 13.439741] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-1/input/input13 [ 13.441301] dvb-usb: schedule remote query interval to 50 msecs. [ 13.442742] dvb-usb: Hauppauge Nova-T Stick successfully initialized and connected. [ 13.444577] dib0700: rc submit urb failed [ 13.444579] [ 13.447573] usbcore: registered new interface driver dvb_usb_dib0700 -- 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: Capturing raw JPEG stream from webcam
Hi Basil,
On Monday 15 March 2010 16:09:49 Basil Mohamed Gohar wrote:
On 03/15/2010 05:40 AM, Laurent Pinchart wrote:
On Saturday 13 March 2010 02:55:47 Basil Mohamed Gohar wrote:
I originally posted this to the video4linux mailing list, but I've since
discovered that this is the appropriate place (or so I understand) for
video4linux questions. My question is how can I capture the raw JPEG
image stream (e.g., MJPEG) from my webcam, which reports through v4l2
that it is capable of. I am using the gst-launch cli to gstreamer,
which confirms that my webcam has this capability:
image/jpeg, width=(int)640, height=(int)480, framerate=(fraction){
30/1, 25/1, 20/1, 15/1, 10/1, 5/1 }
And, indeed, I can capture using this capability, but the framerate is
not at the specified rate, but at a much lower value (half or less).
So, even if I specify 30fps, I get something less. I can capture the
full 30fps when I use one of the yuv modes, though, so it's clearly
capable of delivering that framerate.
My webcam is a Logitech QuickCam Pro 5000. The lsusb output is:
046d:08ce Logitech, Inc. QuickCam Pro 5000
An example command line I try is as follows:
gst-launch-0.10 v4l2src device=/dev/video0 ! 'image/jpeg, width=640,
height=480, framerate=30/1' ! jpegdec ! xvimagesink
Have you tried disabling auto-exposure ? The camera is allowed to reduce
the frame rate in low-light conditions if auto-exposure is turned on.
Thanks for replying. I haven't actually tried this yet (I am currently
at work), but I do not think this is the issue, because when I choose
the YUV-style modes, I can capture at the full framerates. It's only
when I select the image/jpeg mode that I get the lower framerates,
despite explicitly requesting the higher ones.
I suppose it's not impossible that the camera is opting for different
behavior depending on the mode of the request, but I think that is not
likely the case. I do appreciate the suggestion, though, and I'll try
it when I get home.
It could, but that indeed seems unlikely. The USB descriptors advertise 30fps
in MJPEG mode. Unless the information is wrong (in which case this would be a
firmware bug), 30fps should be achievable.
Meanwhile, does anyone else have any other ideas?
--
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: terratec hybrid xs fm
Il 03/12/2010 01:56 PM, Adriano Gigante ha scritto: Devin, I know I'm boring... any news about 0072/terratec hybrid xs fm driver develop progress? Thanks Adri -- 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 hi, i'm interested too, i've seen catimmi has successfully implemented the Cinergy Hybrid T USB XS FR driver, maybe the hardware is very similar to the Cinergy Hybrid T USB XS FM ? it will be great to get at least dvb-t support. Thanks bye! -- 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
Fwd: Delivery Status Notification (Failure)
OK, only text this time :) -- Forwarded message -- From: Mail Delivery Subsystem mailer-dae...@googlemail.com Date: Mon, Mar 15, 2010 at 10:17 PM Subject: Delivery Status Notification (Failure) To: mightyiamprese...@gmail.com Delivery to the following recipient failed permanently: linux-media@vger.kernel.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 Content-Policy reject msg: The message contains HTML subpart, therefore we consider it SPAM or Outlook Virus. TEXT/PLAIN is accepted.! BF:U 0.498823; S936641Ab0COURI (state 18). - Original message - MIME-Version: 1.0 Received: by 10.216.178.70 with SMTP id e48mr24691wem.0.1268684226676; Mon, 15 Mar 2010 13:17:06 -0700 (PDT) In-Reply-To: 20100315191239.54f4c...@tele References: bf87febf1003151024k7987318bv6f76a40c4d7da...@mail.gmail.com 20100315191239.54f4c...@tele Date: Mon, 15 Mar 2010 22:17:06 +0200 Message-ID: bf87febf1003151317y4f15ef1fs1c1de6bca0360...@mail.gmail.com Subject: Re: [Spca50x-devs] 17a1:0118 From: Shahar Or mightyiamprese...@gmail.com To: Jean-Francois Moine moin...@free.fr Cc: SPCA50x Linux Device Driver Development spca50x-d...@lists.sourceforge.net, r...@lecurie.org, ropers rop...@gmail.com, Jean-Yves Lamoureux jy...@lnxscene.org, linux-media@vger.kernel.org Content-Type: multipart/mixed; boundary=001485f274c8a9ca510481dc90b5 On Mon, Mar 15, 2010 at 8:12 PM, Jean-Francois Moine moin...@free.frwrote: On Mon, 15 Mar 2010 19:24:24 +0200 Shahar Or em...@shahar-or.co.il wrote: I have a non-supported one, with the ID 17a1:0118. Data attached. I am willing to cooperate with anything that I can, including testing patches. I've noticed there's one here related: http://lists-archives.org/spca50x-devs/01649-patch-for-17a1-0128-xpx-jpeg-webcam-tascorp.html I can also send the cam over by mail, if that is necessary. I'm subscribed to the list. Hello Shahar, A driver for this webcam is available (you may find it in the last gspca version that I have just uploaded - 2.9.6 - the subdriver is 'gspca_tasc.ko'). The only problem is that nobody could yet decode the images! (Jens, Jean-Yves, any news?) About the list, all the linux video stuff is hosted at LinuxTv.org and the linux-media mailing-list at vger.kernel.org (see Cc:). Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ Yo, I've installed 2.6.9 and tested with vlc. Theres no image but /dev/video0 exists. Here's dmesg attached. BTW, I didn't get the part in the README about If you used a distribution from a LinuxTv mercurial repository,[...]. -- 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: WARNINGS
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 15 19:00:27 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14461:88b0610d72ec git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 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.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS 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
ATSC substreams
Hello, I have my channels.conf set up for use with my TV tuner, to receive over-the-air ATSC broadcasts in the USA. Some of my local channels have multiple substreams, which are configured in channels.conf like this: --- 21.1:509028615:8VSB:49:52:3 21.2:509028615:8VSB:65:68:4 21.3:509028615:8VSB:81:84:5 --- I can record video from a channel using the command-line: $ azap -r 21.1 $ dd if=/dev/dvb/adapter0/dvr0 of=video.ts My question is this: How can I configure it so that I am recording all 3 substreams at the same time, multiplexed into a single MPEG TS? I know this is physically possible, because the old pre-DVB V4L interface I used several years ago did that, recording the raw ATSC signal from channel 21, with all of the channels included as mpeg substreams. -- 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: Ubuntu and AverMedia DVD EZMaker USB Gold
On 04/03/2010, Jorge Cabrera jorge.cabr...@andago.com wrote: Hello again, I was wrong here, the driver works, the device works great but what's going on is that it uses the tuner as the default input, when I run mplayer with input=1 (composite video) or input=2 (s-video) it works good: mplayer tv:// -tv input=1:device=/dev/video0 But this isn't good enough because cheese and camorama and flash use the default input. How can I set up default input to composite video or s-video? Should I add something to the options that the Avermedia kernel module uses? Try using the v4lctl command. Something like v4lctl setinput Composite1 will do. You can replace Composite1 with other names like Television etc. The manpage has more information. -- Adrian. http://elesquinazotango.com.ar http://www.noalcodigodescioli.blogspot.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: Capturing raw JPEG stream from webcam
Message bounced the first time because I had HTML on. Here it is again.
I have the same camera (Logi 5000). There's an ordering issue of ioctl
calls that you have to make to get the frame rate set properly. But I'm
away from my home computer and code, so I can't quote the solution to
you yet. I can't speak about gst-launch, but I do I recall fixing
this exact bug in my own code.
I figured out the frame rate issue by examing the code to luvcview.
That sample app can capture jpegs at 640x480x30fps no problem.
I'll post sample code to you later tonight.
From: laurent.pinch...@ideasonboard.com
To: abu_huray...@hidayahonline.org
Subject: Re: Capturing raw JPEG stream from webcam
Date: Mon, 15 Mar 2010 21:00:05 +0100
CC: linux-media@vger.kernel.org
Hi Basil,
On Monday 15 March 2010 16:09:49 Basil Mohamed Gohar wrote:
On 03/15/2010 05:40 AM, Laurent Pinchart wrote:
On Saturday 13 March 2010 02:55:47 Basil Mohamed Gohar wrote:
I originally posted this to the video4linux mailing list, but I've since
discovered that this is the appropriate place (or so I understand) for
video4linux questions. My question is how can I capture the raw JPEG
image stream (e.g., MJPEG) from my webcam, which reports through v4l2
that it is capable of. I am using the gst-launch cli to gstreamer,
which confirms that my webcam has this capability:
image/jpeg, width=(int)640, height=(int)480, framerate=(fraction){
30/1, 25/1, 20/1, 15/1, 10/1, 5/1 }
And, indeed, I can capture using this capability, but the framerate is
not at the specified rate, but at a much lower value (half or less).
So, even if I specify 30fps, I get something less. I can capture the
full 30fps when I use one of the yuv modes, though, so it's clearly
capable of delivering that framerate.
My webcam is a Logitech QuickCam Pro 5000. The lsusb output is:
046d:08ce Logitech, Inc. QuickCam Pro 5000
An example command line I try is as follows:
gst-launch-0.10 v4l2src device=/dev/video0 ! 'image/jpeg, width=640,
height=480, framerate=30/1' ! jpegdec ! xvimagesink
Have you tried disabling auto-exposure ? The camera is allowed to reduce
the frame rate in low-light conditions if auto-exposure is turned on.
Thanks for replying. I haven't actually tried this yet (I am currently
at work), but I do not think this is the issue, because when I choose
the YUV-style modes, I can capture at the full framerates. It's only
when I select the image/jpeg mode that I get the lower framerates,
despite explicitly requesting the higher ones.
I suppose it's not impossible that the camera is opting for different
behavior depending on the mode of the request, but I think that is not
likely the case. I do appreciate the suggestion, though, and I'll try
it when I get home.
It could, but that indeed seems unlikely. The USB descriptors advertise 30fps
in MJPEG mode. Unless the information is wrong (in which case this would be a
firmware bug), 30fps should be achievable.
Meanwhile, does anyone else have any other ideas?
--
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
_
Lauren found her dream laptop. Find the PC that’s right for you.
http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290--
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
891,934.000GBP has been awarded to you.
Submit Name:Address:Age:Sex:Occupation:Tel:Country This is to notify you. -- 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: Magic in videobuf
On Mon, 2010-03-15 at 14:26 -0300, Mauro Carvalho Chehab wrote: Hans Verkuil wrote: Hans Verkuil wrote: Pawel Osciak wrote: is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code besides driver debugging? I intend to remove them, as we weren't able to find any particular use for them when we were discussing this at the memory handling meeting in Norway... It is a sort of paranoid check to avoid the risk of mass memory corruption if something goes deadly wrong with the video buffers. What on earth does this magic check have to do with possible DMA overruns/memory corruption? This assumes that somehow exactly these magic fields are overwritten and that you didn't crash because of memory corruption elsewhere much earlier. All it does is oops anyway, so it really doesn't 'avoid' a crash (as if you could in such scenarios). And most likely the damage has been done already in that case. It won't avoid the damage, but the error message could potentially help to track the issue. It will also likely limit the damage. Please let us get rid of this. It makes no sense whatsoever. I don't have a strong opinion about this subject, but if this code might help to avoid propagating the damage and to track the issue, I don't see why we need to remove it, especially since it is easy to disable the entire logic by just adding a few #if's to remove this code on environments where no problem is expected. It is highly unlikely that this code ever prevented these issues. Especially given the places where the check is done. I think this is just debug code that has been dragged along for all these years without anyone bothering to remove it. I remember I had to re-format one disk, during that time, due to a videobuf issue. So, those checks help people that are touching at the videobuf code, reducing the chances of damaging their disk partitions when trying to implement overlay mode and userptr on the videobuf implementations that misses those features, or when working on a different mmap() logic at the driver. In a previous job, working on a particularly large application, I had occasional corruption in a shared memory segment that was shared by many writer processes and 2 readers. A simple checksum on the data header (and contents if appropriate) was enough to detect corrpution and avoid dereferencing a corrupted pointer to the next data element (when walking a data area filled with Key-Length-Value encoded data). This forward error detection was inelegant to me - kind of like putting armor on one's car instead of learning to drive properly. I only resorted to using the checksum because there was almost no way to find which process was corrupting shared memory in a reasonable amount of time. It allowed me to change a show stopper bug into an annoying data presentation bug, so the product could be released to a production environment. In a development environment, it would be much better to disable such defensive coding and let the kernel Oops. You'll never find the problems if you keep hiding them from yourself. Regards, Andy -- 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] Add SPI support to V4L2
Hi
Add support SPI bus to v4l2. Useful for control some device with SPI bus like
hardware MPEG2 encoders and etc.
diff -r b6b82258cf5e linux/drivers/media/video/v4l2-common.c
--- a/linux/drivers/media/video/v4l2-common.c Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/drivers/media/video/v4l2-common.c Tue Mar 16 05:06:04 2010 +0900
@@ -63,6 +63,10 @@
#include linux/videodev2.h
#include compat.h
+
+#if defined(CONFIG_SPI)
+#include linux/spi/spi.h
+#endif
MODULE_AUTHOR(Bill Dirks, Justin Schoeman, Gerd Knorr);
MODULE_DESCRIPTION(misc helper functions for v4l2 device drivers);
@@ -1069,6 +1073,66 @@
#endif /* defined(CONFIG_I2C) */
+#if defined(CONFIG_SPI)
+
+/* Load a spi sub-device. */
+
+void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct spi_device *spi,
+ const struct v4l2_subdev_ops *ops)
+{
+ v4l2_subdev_init(sd, ops);
+ sd-flags |= V4L2_SUBDEV_FL_IS_SPI;
+ /* the owner is the same as the spi_device's driver owner */
+ sd-owner = spi-dev.driver-owner;
+ /* spi_device and v4l2_subdev point to one another */
+ v4l2_set_subdevdata(sd, spi);
+ spi_set_drvdata(spi, sd);
+ /* initialize name */
+ strlcpy(sd-name, spi-dev.driver-name, sizeof(sd-name));
+}
+EXPORT_SYMBOL_GPL(v4l2_spi_subdev_init);
+
+struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device *v4l2_dev,
+ struct spi_master *master, struct spi_board_info *info)
+{
+ struct v4l2_subdev *sd = NULL;
+ struct spi_device *spi = NULL;
+
+ BUG_ON(!v4l2_dev);
+
+ if (info-modalias)
+ request_module(info-modalias);
+
+ spi = spi_new_device(master, info);
+
+ if (spi == NULL || spi-dev.driver == NULL)
+ goto error;
+
+ if (!try_module_get(spi-dev.driver-owner))
+ goto error;
+
+ sd = spi_get_drvdata(spi);
+
+ /* Register with the v4l2_device which increases the module's
+ use count as well. */
+ if (v4l2_device_register_subdev(v4l2_dev, sd))
+ sd = NULL;
+
+ /* Decrease the module use count to match the first try_module_get. */
+ module_put(spi-dev.driver-owner);
+
+error:
+ /* If we have a client but no subdev, then something went wrong and
+ we must unregister the client. */
+ if (spi sd == NULL)
+ spi_unregister_device(spi);
+
+ return sd;
+}
+EXPORT_SYMBOL_GPL(v4l2_spi_new_subdev);
+
+#endif /* defined(CONFIG_SPI) */
+
/* Clamp x to be between min and max, aligned to a multiple of 2^align. min
* and max don't have to be aligned, but there must be at least one valid
* value. E.g., min=17,max=31,align=4 is not allowed as there are no multiples
diff -r b6b82258cf5e linux/drivers/media/video/v4l2-device.c
--- a/linux/drivers/media/video/v4l2-device.c Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/drivers/media/video/v4l2-device.c Tue Mar 16 05:06:04 2010 +0900
@@ -24,6 +24,10 @@
#include linux/videodev2.h
#include media/v4l2-device.h
#include compat.h
+
+#if defined(CONFIG_SPI)
+#include linux/spi/spi.h
+#endif
int v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev)
{
@@ -100,6 +104,14 @@
}
#endif
#endif
+#if defined(CONFIG_SPI)
+ if (sd-flags V4L2_SUBDEV_FL_IS_SPI) {
+ struct spi_device *spi = v4l2_get_subdevdata(sd);
+
+ if (spi)
+ spi_unregister_device(spi);
+ }
+#endif
}
}
EXPORT_SYMBOL_GPL(v4l2_device_unregister);
diff -r b6b82258cf5e linux/include/media/v4l2-common.h
--- a/linux/include/media/v4l2-common.h Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/include/media/v4l2-common.h Tue Mar 16 05:06:04 2010 +0900
@@ -191,6 +191,24 @@
/* - */
+/* SPI Helper functions */
+#if defined(CONFIG_SPI)
+
+#include linux/spi/spi.h
+
+struct spi_device;
+
+/* Load an spi module and return an initialized v4l2_subdev struct.
+ The client_type argument is the name of the chip that's on the adapter. */
+struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device *v4l2_dev,
+ struct spi_master *master, struct spi_board_info *info);
+
+/* Initialize an v4l2_subdev with data from an spi_device struct */
+void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct spi_device *spi,
+ const struct v4l2_subdev_ops *ops);
+#endif
+/* - */
+
/* Note: these remaining ioctls/structs should be removed as well, but they are
still used in tuner-simple.c (TUNER_SET_CONFIG), cx18/ivtv (RESET) and
v4l2-int-device.h (v4l2_routing). To remove these ioctls some more cleanup
diff -r b6b82258cf5e linux/include/media/v4l2-subdev.h
--- a/linux/include/media/v4l2-subdev.h Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/include/media/v4l2-subdev.h Tue Mar 16 05:06:04 2010 +0900
@@
Re: [BUGFIX][PATCH] change some parameters for tlg2300
Hi Mauro:
This patch has side effect : the radio does not run well with this patch.
I tested the patch carefully.
If I listen the radio with mplayer in the root account, the radio does
not run well ( a xrun occurs);
if I listen the radio with mplayer in the normal account (not root). the
radio runs well.
Do you have any advice ? Do you think this is a problem?
thanks.
Best Regards
Huang Shijie.
The orgin parameters may cause a bug : The audio may lost in certain
situation (such as open the VLC at the first time).
The origin parameters set a small stop_threshold for snd_pcm_runtime{}.
So a xrun occurs in some situation.
Signed-off-by: Huang Shijie shij...@gmail.com
---
drivers/media/video/tlg2300/pd-alsa.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/tlg2300/pd-alsa.c
b/drivers/media/video/tlg2300/pd-alsa.c
index 6f42621..e9ad715 100644
--- a/drivers/media/video/tlg2300/pd-alsa.c
+++ b/drivers/media/video/tlg2300/pd-alsa.c
@@ -21,9 +21,6 @@
static void complete_handler_audio(struct urb *urb);
#define AUDIO_EP(0x83)
#define AUDIO_BUF_SIZE (512)
-#define PERIOD_SIZE (1024 * 8)
-#define PERIOD_MIN (4)
-#define PERIOD_MAX PERIOD_MIN
static struct snd_pcm_hardware snd_pd_hw_capture = {
.info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
@@ -38,18 +35,11 @@ static struct snd_pcm_hardware snd_pd_hw_capture = {
.rate_max = 48000,
.channels_min = 2,
.channels_max = 2,
-.buffer_bytes_max = PERIOD_SIZE * PERIOD_MIN,
-.period_bytes_min = PERIOD_SIZE,
-.period_bytes_max = PERIOD_SIZE,
-.periods_min = PERIOD_MIN,
-.periods_max = PERIOD_MAX,
-/*
.buffer_bytes_max = 62720 * 8,
.period_bytes_min = 64,
.period_bytes_max = 12544,
.periods_min = 2,
.periods_max = 98
-*/
};
static int snd_pd_capture_open(struct snd_pcm_substream *substream)
--
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
