VBI support for em2870 (Kworld UB435-Q)
HI, I can successfully use my Kworld UB435-Q for OTA capture thanks to the development work in this thread: http://www.mail-archive.com/linux-media@vger.kernel.org/msg10472.html however I 'd like to get closed captioning support if possible. I don't get a /dev/vbi device with the current em28xx driver. Does the em2870 chip support VBI in the first place? If yes, is there vbi-ntsc support for it in a development branch somewhere? thanks for your help, - Vasilis -- 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: v4l-dvb - Is it still usable for a distribution ?
Hello >> Is your imon driver fully compatible with the lirc_imon in the display part ? > > Yes, works perfectly fine with the exact same lcdproc setup here -- > both vfd and lcd tested. > fine - I will give it a try ! >> It would be very helpful to add a parameter for disabling the IR Part, I >> have many users which >> are using only the display part. > > Hm. I was going to suggest that if people aren't using the receiver, > there should be no need to disable IR, but I guess someone might want > to use an mce remote w/an mce receiver, and that would have > interesting results if they had one of the imon IR receivers > programmed for mce mode. > Thats what I meant :) > I'll keep it in mind for the next time I'm > poking at the imon code in depth. Maybe you can use the already available ir_protocol parameter. -- Helmut Auer, hel...@helmutauer.de -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add the viafb video capture driver
Em 07-06-2010 23:31, Jonathan Corbet escreveu: > On Tue, 8 Jun 2010 03:03:14 +0200 > Laurent Pinchart wrote: > >> If it's not too late for review, here are some comments. I've reviewed the >> code from bottom to top, so comments might be a bit inconsistent sometimes. > > Never too late to make the code better. These are good comments, thanks. > Mauro, I guess I've got another version coming...:) Ok, I'll be waiting for it ;) 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
[PATCH] libv4l1: move VIDIOCGAUDIO,VIDIOCSAUDIO,VIDIOCGVBIFMT,VIDIOCSVBIFMT
From: Huzaifa Sidhpurwala
merged two previous patches, now uses v4l2_set_control and
v4l2_get_control
Signed-of-by: Huzaifa Sidhpurwala
---
lib/libv4l1/libv4l1-priv.h |7 ++
lib/libv4l1/libv4l1.c | 172
2 files changed, 179 insertions(+), 0 deletions(-)
diff --git a/lib/libv4l1/libv4l1-priv.h b/lib/libv4l1/libv4l1-priv.h
index 11f4fd0..11ee57a 100644
--- a/lib/libv4l1/libv4l1-priv.h
+++ b/lib/libv4l1/libv4l1-priv.h
@@ -60,6 +60,13 @@ extern FILE *v4l1_log_file;
#define min(a, b) (((a) < (b)) ? (a) : (b))
#endif
+#define DIV_ROUND_CLOSEST(x, divisor)( \
+{ \
+ typeof(divisor) __divisor = divisor;\
+ (((x) + ((__divisor) / 2)) / (__divisor)); \
+} \
+)
+
struct v4l1_dev_info {
int fd;
int flags;
diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c
index 2981c40..830ed6b 100644
--- a/lib/libv4l1/libv4l1.c
+++ b/lib/libv4l1/libv4l1.c
@@ -983,6 +983,178 @@ int v4l1_ioctl(int fd, unsigned long int request, ...)
break;
}
+
+ case VIDIOCSAUDIO: {
+ struct video_audio *aud = arg;
+ struct v4l2_audio aud2 = { 0, };
+ struct v4l2_tuner tun2 = { 0, };
+
+ aud2.index = aud->audio;
+ result = v4l2_ioctl(fd, VIDIOC_S_AUDIO, &aud2);
+ if (result < 0)
+ break;
+
+ v4l2_set_control(fd, V4L2_CID_AUDIO_VOLUME,
+ aud->volume);
+ v4l2_set_control(fd, V4L2_CID_AUDIO_BASS,
+ aud->bass);
+ v4l2_set_control(fd, V4L2_CID_AUDIO_TREBLE,
+ aud->treble);
+ v4l2_set_control(fd, V4L2_CID_AUDIO_BALANCE,
+ aud->balance);
+ v4l2_set_control(fd, V4L2_CID_AUDIO_MUTE,
+ !!(aud->flags & VIDEO_AUDIO_MUTE));
+
+ result = v4l2_ioctl(fd, VIDIOC_G_TUNER, &tun2);
+ if (result < 0)
+ break;
+ if (result == 0) {
+ switch (aud->mode) {
+ default:
+ case VIDEO_SOUND_MONO:
+ case VIDEO_SOUND_LANG1:
+ tun2.audmode = V4L2_TUNER_MODE_MONO;
+ break;
+ case VIDEO_SOUND_STEREO:
+ tun2.audmode = V4L2_TUNER_MODE_STEREO;
+ break;
+ case VIDEO_SOUND_LANG2:
+ tun2.audmode = V4L2_TUNER_MODE_LANG2;
+ break;
+ }
+ result = v4l2_ioctl(fd, VIDIOC_S_TUNER, &tun2);
+ }
+ break;
+ }
+
+ case VIDIOCGAUDIO: {
+ int i;
+ struct video_audio *aud = arg;
+ struct v4l2_queryctrl qctrl2;
+ struct v4l2_audio aud2 = { 0, };
+ struct v4l2_tuner tun2;
+
+ result = v4l2_ioctl(fd, VIDIOC_G_AUDIO, &aud2);
+ if (result < 0)
+ break;
+
+ memcpy(aud->name, aud2.name,
+ min(sizeof(aud->name), sizeof(aud2.name)));
+ aud->name[sizeof(aud->name) - 1] = 0;
+ aud->audio = aud2.index;
+ aud->flags = 0;
+ i = v4l2_get_control(fd, V4L2_CID_AUDIO_VOLUME);
+ if (i >= 0) {
+ aud->volume = i;
+ aud->flags |= VIDEO_AUDIO_VOLUME;
+ }
+ i = v4l2_get_control(fd, V4L2_CID_AUDIO_BASS);
+ if (i >= 0) {
+ aud->bass = i;
+ aud->flags |= VIDEO_AUDIO_BASS;
+ }
+ i = v4l2_get_control(fd, V4L2_CID_AUDIO_TREBLE);
+ if (i >= 0) {
+ aud->treble = i;
+ aud->flags |= VIDEO_AUDIO_TREBLE;
+ }
+ i = v4l2_get_control(fd, V4L2_CID_AUDIO_BALANCE);
+ if (i >= 0) {
+ aud->balance = i;
+ aud->flags |= VIDEO_AUDIO_BALANCE;
+ }
+ i = v4l2_get_control(fd, V4L2_CID_AUDIO_MUTE);
+ if (i >= 0) {
+ if (i)
+ aud->flags |= VIDEO_AUDIO_MUTE;
+
+ aud->flags |= VIDEO_AUDIO_MUTABLE;
+ }
+ aud->step = 1;
+ qctrl2.id = V4L2_CID_AUDIO_VOLUME;
+ if (v4l2_ioctl(fd, VIDIOC_QUERYCTRL, &qctrl2) == 0 &&
+ !(qctrl2.flags & V4L2_CTRL_FLAG_DISABLED))
+ aud->step = qctrl2.step;
+ aud->mode = 0;
+
+ r
Re: v4l-dvb - Is it still usable for a distribution ?
On Mon, Jun 7, 2010 at 5:25 PM, Helmut Auer wrote: ... > Is your imon driver fully compatible with the lirc_imon in the display part ? Yes, works perfectly fine with the exact same lcdproc setup here -- both vfd and lcd tested. > It would be very helpful to add a parameter for disabling the IR Part, I have > many users which > are using only the display part. Hm. I was going to suggest that if people aren't using the receiver, there should be no need to disable IR, but I guess someone might want to use an mce remote w/an mce receiver, and that would have interesting results if they had one of the imon IR receivers programmed for mce mode. I'll keep it in mind for the next time I'm poking at the imon code in depth. Need to finish work on some of the other new ir/rc bits first (you'll soon be seeing the mceusb driver ported to the new infra also in v4l-dvb hg, as well as an lirc bridge driver, which is currently my main focal point). -- Jarod Wilson ja...@wilsonet.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] Add the viafb video capture driver
On Tue, 8 Jun 2010 03:03:14 +0200
Laurent Pinchart wrote:
> If it's not too late for review, here are some comments. I've reviewed the
> code from bottom to top, so comments might be a bit inconsistent sometimes.
Never too late to make the code better. These are good comments, thanks.
Mauro, I guess I've got another version coming...:) It will take me a bit,
I've got another ocean to cross tomorrow.
Specific responses below. I've snipped out a fair number of comments; that
means "you're right, I'll fix it."
> Don't define device structures as static object. You must kmalloc the
> via_camera structure in probe and set the pointer as driver private data to
> access it later in V4L2 operations and device core callbacks. Otherwise Bad
> Things (TM) will happen if the device is removed while the video device node
> is opened.
I understand the comment...but this device is blasted onto the system's
base silicon. It's not going to be removed in a way which leaves a
functioning computer. Still, dynamic allocation is easy enough to do.
> > +/*
> > + * Configure the sensor. It's up to the caller to ensure
> > + * that the camera is in the correct operating state.
> > + */
> > +static int viacam_configure_sensor(struct via_camera *cam)
> > +{
> > + struct v4l2_format fmt;
> > + int ret;
> > +
> > + fmt.fmt.pix = cam->sensor_format;
> > + ret = sensor_call(cam, core, init, 0);
> > + if (ret == 0)
> > + ret = sensor_call(cam, video, s_fmt, &fmt);
> > + /*
> > +* OV7670 does weird things if flip is set *before* format...
>
> What if the user sets vflip using VIDIOC_S_CTRL directly before setting the
> format ?
All is well; we remember the setting and set the flip properly afterward.
> > + /*
> > +* Copy over the data and let any waiters know.
> > +*/
> > + vdma = videobuf_to_dma(vb);
> > + viafb_dma_copy_out_sg(cam->cb_offsets[bufn], vdma->sglist, vdma->sglen);
>
> Ouch that's going to hurt performances !
>
> What are the hardware restrictions regarding the memory it can capture images
> to ? Does it just have to be physically contiguous, or does the memory need
> to
> come from a specific memory area ? In the first case you could use
> videobuf_dma_contig and avoid the memcpy completely. In the second case you
> should still mmap the memory to userspace when using kernel-allocated buffers
> instead of memcpying the data. If you really need a memcpy, you should then
> probably use videobuf_vmalloc instead of videobuf_dma_sg.
It's a DMA copy, so performance is actually not a problem.
The video capture engine grabs frames into a three-buffer ring stored in
viafb framebuffer memory. I *could* let user space map that memory
directly, but it would be an eternal race with the engine and would not end
well. We really do have to do the copy. In a sense, the framebuffer
memory is just part of the capture device; the DMA operation is how we make
data available to the rest of the system.
[Incidentally, the biggest cost here, I think, is setting up 150 DMA
descriptors for each transfer. That's an artifact of the page-at-a-time
memory allocation used by videobuf_dma_sg. I have a branch with an SG
variant which tries to allocate the largest contiguous buffers possible
without going over; it reduces the number of descriptors to about five. It
didn't change my life a whole lot, so I back-burnered it, but I might
send that patch out one of these days.]
> > + viacam_write_reg(cam, VCR_CAPINTC, ~VCR_CI_ENABLE);
> > + viacam_write_reg(cam, VCR_CAPINTC, ~(VCR_CI_ENABLE|VCR_CI_CLKEN));
>
> I don't know how the VCR_CAPINTC register works, but did you really mean to
> write all bits to 1 except VCR_CI_ENABLE and VCR_CI_CLKEN ?
Ouch, no, I don't; that's meant to be a mask operation.
> > + /*
> > +* Disable a bunch of stuff.
> > +*/
> > + viacam_write_reg(cam, VCR_HORRANGE, 0x06200120);
> > + viacam_write_reg(cam, VCR_VERTRANGE, 0x01de);
>
> Any idea what that bunch of stuff is ? Replacing the magic numbers by
> #define'd constants would be nice.
It's 640x480, modulo weird VIA magic. I got it straight from them. I can
add a comment, though.
> > + (void) viacam_read_reg(cam, VCR_CAPINTC); /* Force post */
>
> Why a (void) cast ?
It's my way of saying that I meant to ignore the return value of a function
whose purpose is to return a value.
> > +static int viacam_vb_buf_setup(struct videobuf_queue *q,
> > + unsigned int *count, unsigned int *size)
> > +{
> > + struct via_camera *cam = q->priv_data;
> > +
> > + *size = cam->user_format.sizeimage;
> > + if (*count == 0 || *count > 6) /* Arbitrary number */
> > + *count = 6;
>
> Shouldn't the limit should be computed from the available fb memory ?
That would always be three, but user space might well want more buffering
than that. I don't quite see why the two need to be tied.
> > +static void viacam_vb_buf_queue(struct videobuf_queue *q,
> > + s
Re: cam max width and height
Hi, On Tuesday 08 June 2010 02:09:39 linux newbie wrote: > Hi, > > I am using linux 2.6.26.3. I connected "microsoft live cam" and its > max supported resolution is 1280x800. If I use VIDIOC_G_FMT, > fmt.fmt.pix.width, fmt.fmt.pix.height returns 640x480. > > How to get the maximum supported resolution?? You can use VIDIOC_ENUM_FRAMESIZES to enumeration all the supported resolutions. -- 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] Add the viafb video capture driver
Hi Jonathan,
On Tuesday 08 June 2010 01:26:15 Jonathan Corbet wrote:
> Hi, Mauro,
>
> Linus has quietly ignored a couple of pull requests for this driver; I
> guess he's gotten tired of me this time around or something. There's
> little profit in pushing the issue, so, can you just send it up through
> your tree (for 2.6.36 at this point) instead?
If it's not too late for review, here are some comments. I've reviewed the
code from bottom to top, so comments might be a bit inconsistent sometimes.
[snip]
> diff --git a/drivers/media/video/via-camera.c
> b/drivers/media/video/via-camera.c new file mode 100644
> index 000..7b1ff0c
> --- /dev/null
> +++ b/drivers/media/video/via-camera.c
[snip]
> +/*
> + * Basic window sizes.
> + */
> +#define VGA_WIDTH640
> +#define VGA_HEIGHT 480
That's already defined in include/linux/via-core.h (ugly defines though). It
would be better to define constants such as VIA_SENSOR_WIDTH,
VIA_xxx_MIN_WIDTH, VIA_xxx_MAX_WIDTH, ...
> +#define QCIF_WIDTH 176
> +#define QCIF_HEIGHT 144
> +
> +/*
> + * The structure describing our camera.
> + */
> +enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
> +
> +static struct via_camera {
> + struct v4l2_device v4l2_dev;
> + struct video_device vdev;
> + struct v4l2_subdev *sensor;
> + struct platform_device *platdev;
> + struct viafb_dev *viadev;
> + struct mutex lock;
> + enum viacam_opstate opstate;
> + unsigned long flags;
> + /*
> + * GPIO info for power/reset management
> + */
> + int power_gpio;
> + int reset_gpio;
> + /*
> + * I/O memory stuff.
> + */
> + void __iomem *mmio; /* Where the registers live */
> + void __iomem *fbmem;/* Frame buffer memory */
> + u32 fb_offset; /* Reserved memory offset (FB) */
> + /*
> + * Capture buffers and related. The controller supports
> + * up to three, so that's what we have here. These buffers
> + * live in frame buffer memory, so we don't call them "DMA".
> + */
> + unsigned int cb_offsets[3]; /* offsets into fb mem */
> + u8 *cb_addrs[3];/* Kernel-space addresses */
> + int n_cap_bufs; /* How many are we using? */
> + int next_buf;
> + struct videobuf_queue vb_queue;
> + struct list_head buffer_queue; /* prot. by reg_lock */
> + /*
> + * User tracking.
> + */
> + int users;
> + struct file *owner;
> + /*
> + * Video format information. sensor_format is kept in a form
> + * that we can use to pass to the sensor. We always run the
> + * sensor in VGA resolution, though, and let the controller
> + * downscale things if need be. So we keep the "real*
> + * dimensions separately.
> + */
> + struct v4l2_pix_format sensor_format;
> + struct v4l2_pix_format user_format;
> +} via_cam_info;
Don't define device structures as static object. You must kmalloc the
via_camera structure in probe and set the pointer as driver private data to
access it later in V4L2 operations and device core callbacks. Otherwise Bad
Things (TM) will happen if the device is removed while the video device node
is opened.
[snip]
> +/*
> + * Configure the sensor. It's up to the caller to ensure
> + * that the camera is in the correct operating state.
> + */
> +static int viacam_configure_sensor(struct via_camera *cam)
> +{
> + struct v4l2_format fmt;
> + int ret;
> +
> + fmt.fmt.pix = cam->sensor_format;
> + ret = sensor_call(cam, core, init, 0);
> + if (ret == 0)
> + ret = sensor_call(cam, video, s_fmt, &fmt);
> + /*
> + * OV7670 does weird things if flip is set *before* format...
What if the user sets vflip using VIDIOC_S_CTRL directly before setting the
format ?
> + */
> + if (ret == 0)
> + ret = viacam_set_flip(cam);
> + return ret;
> +}
[snip]
> +/*
> + * The threaded IRQ handler.
> + */
> +static irqreturn_t viacam_irq(int irq, void *data)
> +{
> + int bufn;
> + struct videobuf_buffer *vb;
> + struct via_camera *cam = data;
> + struct videobuf_dmabuf *vdma;
> +
> + /*
> + * If there is no place to put the data frame, don't bother
> + * with anything else.
> + */
> + vb = viacam_next_buffer(cam);
> + if (vb == NULL)
> + goto done;
> + /*
> + * Figure out which buffer we just completed.
> + */
> + bufn = (viacam_read_reg(cam, VCR_INTCTRL) & VCR_IC_ACTBUF) >> 3;
> + bufn -= 1;
> + if (bufn < 0)
> + bufn = cam->n_cap_bufs - 1;
> + /*
> + * Copy over the data and let any waiters know.
> + */
> + vdma = videobuf_to_dma(vb);
> + viafb_dma_copy_out_sg(cam->cb_offsets[bufn], vdma->sglist, vdma->sglen);
Ouch that's going to hurt performances !
What are the hardware restrictions regarding the memory it can capture images
to ? Does it just have to be physically conti
Re: [Linux-uvc-devel] cam max width and height
Hi, El 08/06/2010, a las 01:09, linux newbie escribió: > Hi, > > I am using linux 2.6.26.3. I connected "microsoft live cam" and its > max supported resolution is 1280x800. If I use VIDIOC_G_FMT, > fmt.fmt.pix.width, fmt.fmt.pix.height returns 640x480. > > How to get the maximum supported resolution?? You should check in Microsoft's webpage or included documentation that 1280x800 is a video resolution and not only a still image resolution. It is common for many cameras to do that. > Thanks > ___ > Linux-uvc-devel mailing list > linux-uvc-de...@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/linux-uvc-devel -- 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
cam max width and height
Hi, I am using linux 2.6.26.3. I connected "microsoft live cam" and its max supported resolution is 1280x800. If I use VIDIOC_G_FMT, fmt.fmt.pix.width, fmt.fmt.pix.height returns 640x480. How to get the maximum supported resolution?? Thanks -- 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 the viafb video capture driver
Hi, Mauro,
Linus has quietly ignored a couple of pull requests for this driver; I
guess he's gotten tired of me this time around or something. There's
little profit in pushing the issue, so, can you just send it up through
your tree (for 2.6.36 at this point) instead?
Thanks,
jon
---
Add the viafb video capture driver
Add a driver for the video capture port on VIA integrated chipsets. This
version has a remaining OLPCism or two and expects to be talking to an
ov7670; those can be improved as the need arises.
This work was supported by the One Laptop Per Child project.
Signed-off-by: Jonathan Corbet
---
drivers/media/video/Kconfig | 10 +
drivers/media/video/Makefile |2 +
drivers/media/video/via-camera.c | 1368 ++
drivers/media/video/via-camera.h | 93 +++
drivers/video/via/accel.c|2 +-
drivers/video/via/via-core.c | 16 +-
include/linux/via-core.h |4 +-
include/media/v4l2-chip-ident.h |4 +
8 files changed, 1495 insertions(+), 4 deletions(-)
create mode 100644 drivers/media/video/via-camera.c
create mode 100644 drivers/media/video/via-camera.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bdbc9d3..a26ded1 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -853,6 +853,16 @@ config VIDEO_CAFE_CCIC
CMOS camera controller. This is the controller found on first-
generation OLPC systems.
+config VIDEO_VIA_CAMERA
+ tristate "VIAFB camera controller support"
+ depends on FB_VIA
+ select VIDEOBUF_DMA_SG
+ select VIDEO_OV7670
+ help
+ Driver support for the integrated camera controller in VIA
+ Chrome9 chipsets. Currently only tested on OLPC xo-1.5 systems
+ with ov7670 sensors.
+
config SOC_CAMERA
tristate "SoC camera support"
depends on VIDEO_V4L2 && HAS_DMA && I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index cc93859..47fa0c0 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -126,6 +126,8 @@ obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
+obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
+
obj-$(CONFIG_USB_DABUSB)+= dabusb.o
obj-$(CONFIG_USB_OV511) += ov511.o
obj-$(CONFIG_USB_SE401) += se401.o
diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c
new file mode 100644
index 000..7b1ff0c
--- /dev/null
+++ b/drivers/media/video/via-camera.c
@@ -0,0 +1,1368 @@
+/*
+ * Driver for the VIA Chrome integrated camera controller.
+ *
+ * Copyright 2009,2010 Jonathan Corbet
+ * Distributable under the terms of the GNU General Public License, version 2
+ *
+ * This work was supported by the One Laptop Per Child project
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "via-camera.h"
+
+MODULE_AUTHOR("Jonathan Corbet ");
+MODULE_DESCRIPTION("VIA framebuffer-based camera controller driver");
+MODULE_LICENSE("GPL");
+
+static int flip_image;
+module_param(flip_image, bool, 0444);
+MODULE_PARM_DESC(flip_image,
+ "If set, the sensor will be instructed to flip the image "
+ "vertically.");
+
+#ifdef CONFIG_OLPC_XO_1_5
+static int override_serial;
+module_param(override_serial, bool, 0444);
+MODULE_PARM_DESC(override_serial,
+ "The camera driver will normally refuse to load if "
+ "the XO 1.5 serial port is enabled. Set this option "
+ "to force the issue.");
+#endif
+
+/*
+ * Basic window sizes.
+ */
+#define VGA_WIDTH 640
+#define VGA_HEIGHT 480
+#define QCIF_WIDTH 176
+#defineQCIF_HEIGHT 144
+
+/*
+ * The structure describing our camera.
+ */
+enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
+
+static struct via_camera {
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct v4l2_subdev *sensor;
+ struct platform_device *platdev;
+ struct viafb_dev *viadev;
+ struct mutex lock;
+ enum viacam_opstate opstate;
+ unsigned long flags;
+ /*
+* GPIO info for power/reset management
+*/
+ int power_gpio;
+ int reset_gpio;
+ /*
+* I/O memory stuff.
+*/
+ void __iomem *mmio; /* Where the registers live */
+ void __iomem *fbmem;/* Frame buffer memory */
+ u32 fb_offset; /* Reserved memory offset (FB) */
+ /*
+* Capture buffers and related. The controller supports
+* up to three, so that's what we have here. These buffers
+* live in frame buffer memory, so we don't call them "DMA".
+*/
+ unsigned int cb_offsets[3]; /* offsets into fb me
Re: v4l-dvb - Is it still usable for a distribution ?
Em 07-06-2010 18:33, Helmut Auer escreveu: > Hello > >>> Now with kernel 2.6.34 this doesn't work anymore, because v4l-dvb doesn't >>> compile. >> >> Douglas returned from this 2 week trip abroad and he is backporting the >> upstream stuff. Yesterday, he >> reported to me that the tree is now compiling with 2.6.34. >> > Ok - I also got it compiling, but budget-ci is causing kernel oops (see other > ML thread) There's already a patch for it at -git, but I suspect that Douglas didn't have time to backport the newer 87 patches that were committed there. >>> The final question for me: >>> Does it make any sense anymore to stay with v4l-dvb or do I have to change >>> to the kernel drivers ? >>> The major disadvantage of the kernel drivers is the fact that I cannot >>> switch to newer dvb drivers, I am stuck to the ones included in the kernel. >> >> Well, this is something that you need to answer by yourself ;) >> > Thats not what I wanted to hear ;) :) >> I don't recommend using a random snapshot of the tree on a distro package, >> as regressions may >> happen during the development period. >> >> Also, the backports are done at best efforts. There are no warranties, no QA >> and generally no >> tests with real hardware when a backport is done. So, while we hope that the >> backport will work, >> you may have a bug introduced on the backport stuff that may affect your >> card, not present >> upstream. >> >> IMHO, the better is to just upgrade to the next stable kernel. >> > Ok - that what I also thought > formerly v4l-dvb was the bleeding edge and the kernel draivers were about 2 > Versions behind. > Now the kernel drivers are often the newer ones, so I have to switch. There's still a delay if you're getting the latest stable kernel, that ranges from 1 to 2 versions for improvements, and a few weeks, for bug fixes. Eventually, you may provide -rc kernels as an alternative for those that needs the bleeding edge kernels and are brave enough ;) >> Another alternative is to manually apply on your distro the patches that you >> need there. >> All patches with c/c to sta...@kernel.org are bug fixes that needs to be >> backported to older >> (stable) kernels. So, a good hint is to check for those stable patches. >> Unfortunately, not all >> developers remind to add a c/c to stable. I try to do my best to re-tag >> those emails when >> sending the patches upstream, but I generally opt to trust on the >> developers, since a fix may >> apply only at the latest upstream kernel. >> > Thats surely an option, but an average user of my distri can't compile a > kernel ;) > Emerging v4l-dvb is much easier ;) Yes, but you may manually apply those patches from my git tree on your distro kernels. User will need to emerge the kernel package. It will require you a little more work, or some magic script. You may also keep using the -hg backport tree, but the delay is higher than before, since the patches go first to -git. 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: v4l-dvb - Is it still usable for a distribution ?
Hello >> Now with kernel 2.6.34 this doesn't work anymore, because v4l-dvb doesn't >> compile. > > Douglas returned from this 2 week trip abroad and he is backporting the > upstream stuff. Yesterday, he > reported to me that the tree is now compiling with 2.6.34. > Ok - I also got it compiling, but budget-ci is causing kernel oops (see other ML thread) > >> The final question for me: >> Does it make any sense anymore to stay with v4l-dvb or do I have to change >> to the kernel drivers ? >> The major disadvantage of the kernel drivers is the fact that I cannot >> switch to newer dvb drivers, I am stuck to the ones included in the kernel. > > Well, this is something that you need to answer by yourself ;) > Thats not what I wanted to hear ;) > I don't recommend using a random snapshot of the tree on a distro package, as > regressions may > happen during the development period. > > Also, the backports are done at best efforts. There are no warranties, no QA > and generally no > tests with real hardware when a backport is done. So, while we hope that the > backport will work, > you may have a bug introduced on the backport stuff that may affect your > card, not present > upstream. > > IMHO, the better is to just upgrade to the next stable kernel. > Ok - that what I also thought formerly v4l-dvb was the bleeding edge and the kernel draivers were about 2 Versions behind. Now the kernel drivers are often the newer ones, so I have to switch. > Another alternative is to manually apply on your distro the patches that you > need there. > All patches with c/c to sta...@kernel.org are bug fixes that needs to be > backported to older > (stable) kernels. So, a good hint is to check for those stable patches. > Unfortunately, not all > developers remind to add a c/c to stable. I try to do my best to re-tag those > emails when > sending the patches upstream, but I generally opt to trust on the developers, > since a fix may > apply only at the latest upstream kernel. > Thats surely an option, but an average user of my distri can't compile a kernel ;) Emerging v4l-dvb is much easier ;) -- Helmut Auer, hel...@helmutauer.de -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
zvbi-atsc-cc Time-stamps?
Hi everyone, I need help figure out a way to get accurate time stamps on my closed captioning files using zvbi-atsc-cc. I have Hauppauge HVR-1850 cards working in digital mode. I need separate recordings of the video/audio file (mpeg2) and the closed captioning (plain text). I can capture a plain mpeg stream by issuing this in one console: * azap -r KOCE-HD And this in a second console: * cat /dev/dvb/adapter0/dvr0 > test-cat3.mpeg I tested this file and it plays fine. To generate the closed captioning, I feed this file into zvbi-atsc-cc: * zvbi-atsc-cc --atsc -c KCAL-HD -T < test-cat3.mpeg "KCAL-HD" being the the channel in my channels.conf that I captured from. The problem: I need accurate time stamps. Normally, I add the time stamps during capture, so they match reality. If I get the closed captioning from a file, the information is still in the file (I just need to set the start time), but how do I get that information out? Our system relies on the time stamps in the closed captioning to cue the video, so they need to be accurate. One-second accuracy is adequate, so if I can get the STT information from the PSIP info, that would be good enough. I'm using an off-air signal, so these are ATSC 8VSB channels: LA18.8:49700:8VSB:161:164:8 KBEH-DT:53300:8VSB:49:52:1 KCET-HD:55700:8VSB:49:52:1 A typical closed captioning file should end up looking like this: 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:02 % Communication Studies Archive, UCLA % 87e70c70-5614-11df-b2f7-00e0815fe826 % Video length 0:59:54.024 % Christiane Amanpour 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:12 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:22 A HIGH STAKES INVESTIGATION IS STARTED AFTER A CAR BOMB IS 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:32 FOUND IN NEW YORK'S TIMES SQUARE. WHO WANTED TO ATTACK THE CROSSROADS OF THE WORLD AND WHY. PRESIDENT OBAMA HEADS TO THE GULF COAST FOR A FIRSTHAND LOOK 2010-05-02_1100_CNN_Amanpour_2010-05-02_11:00:42 AT DESPERATE EFFORTS TO MAINTAIN AN OIL SPILL. -- in other words, a time stamp every ten seconds, which is then used by our search engine to link to the video. The header (%) is added afterward. Ideally for us, then, I would get the STT stamp at ten-second intervals inserted into the closed captioning file. Are there command-line Linux tools for reading PSIP? (There are also other possible uses of PSIP. xds information is too unreliable and inconsistent for us to use, but if PSIP is reliable, I'd like to use it to verify that I'm getting the recording I intended to get (channel and program name). I could potentially use this information to crop the video to the exact program -- but it would have to be reliable enough to be automated, I don't have staff to do anything manual with individual recordings.) Alternatively, Devin Heitmueller tells us that there is also the PTS (presentation timestamp), which should be pretty easy to modify zlib-atsc-cc to show. Since the PTS can be used to synchronize the video to the CC info is it possible to make a small modification to zvbi-atsc-cc to log the CC info with the PTS, and then write a really simple utility to seek to a given PTS and play the video? Could someone help me out with accurate timestamps in relation to PSIP info and PTS? Warm wishes, Santino -- 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: v4l-dvb - Is it still usable for a distribution ?
Hi > ... >>> Another problem (after fixing the compile issues) is the IR Part of v4l-dvb >>> which includes an Imon module. >>> This module doesn't provide any lirc devices, so how can this oe be used as >>> an IR device ? >> >> You don't need lirc to use imon, since it now provides a standard >> input/event interface. So, the driver >> currently can be used with lirc event interface, or alone. > > See http://wilsonet.com/jarod/imon_stuff/imon-devinput-lirc/ for the > config I use w/my own imon hardware. > Tanks for the hint ! >>> Til now I am using lirc_imon which fit all my needs. >> >> Lirc-dev patches are currently being discussed. There are just a few >> adjustments on it, in order to get it >> finally merged. The kernel-userspace interface will likely need a few >> changes, so you'll likely need to update >> lirc after the merge. Better to follow the IR threads at linux-media ML, in >> order to be in-tune with the changes. > > I've considered adding lirc_dev support back to the imon driver when > we get it merged, but it really doesn't make a whole lot of sense, > given that the imon devices do all IR decoding in hardware. As long as > the keymap is complete, there's no benefit to wiring up lirc_dev vs. > just using lircd's devinput access method for imon devices. > You're right, also inputlircd can do the job. Is your imon driver fully compatible with the lirc_imon in the display part ? It would be very helpful to add a parameter for disabling the IR Part, I have many users which are using only the display part. -- Helmut Auer, hel...@helmutauer.de -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: What ever happened to standardizing signal level?
Hi Manu, - Original Nachricht Von: Manu Abraham An: hermann pitton Datum: 07.06.2010 05:04 Betreff: Re: What ever happened to standardizing signal level? > On Mon, Jun 7, 2010 at 2:01 AM, hermann pitton > wrote: > > > > Am Donnerstag, den 03.06.2010, 22:18 -0700 schrieb VDR User: > >> hermann pitton , you are contributing > >> absolutely nothing to this thread aside of annoying people with your > >> by trolling and half incoherent nonsense. It's quite ironic you > >> suggest _I_ am the one trolling when this is a thread _I_ created. > >> And further, several people have posted legitimate responses to -- > >> clearly you are the only one suffering from your delusion. > > > > Dream on. > > > > The question never was, if you are trolling from time to time, but only > > if you are a duplicate of another troll or on your own. > > > > I have talked with Mauro about that and since then I ask you to provide > > your full name or point at least to a patch from you, where you have to > > agree to provide your real name in your SOB line. > > > > There was none and you also did not point to somebody else, to confirm > > for us, that you are known and on kernel development not only as a > > troll. > > > > You did not give an sufficient answer during the last two years. > > > >> Additionally you've been stalking me in email as well. Your behavior > >> is not only uncalled for, it's abusive of both this mailing list and > >> the people willingly participating in the discussion. As I understand > >> it, this is not the first time you've been the source of harassment. > > > > The opposite again is true, you stalked me by private e-mail and > > therefor my reply went as copy also to Mauro and Manu. If even Manu does > > not have your contact data, who else? Please provide them at least to > > him or someone else you trust and you are free for rants, within > > limitations. > > > Sorry, that I could not reply in-time. I had been traveling and hence. > Also, with little free time in between additionally. Hermann, what's > going on ? I don't see the reason for such a long thread, nor can't > believe that time is so cheap .. > > Anyway ... He doesn't do much of coding, or maybe next to nothing. But > he does test hardware and drivers, from what I know, for quite a long > time from the time of the FF cards. I know his real name as Derek > Kelly and on IRC as hotwings. Well, I do appreciate the time he puts > into testing, as it helps to make realize code better, or identify > hardware bugs etc. At least a couple of times, I was able to find bugs > in my own code, thanks to him. But the other side, unlike most people, > he seemed to not have a taste for taking credits at all (don't know > why, eventhough I had pointed out to him a few times) .. > > Regards, > Manu many thanks for your time and help. Ah. Derek please take some credits. I suspected him to be a troll only, since for more than two years he refused to provide at least a full name. There was also no single patch with a valid SOB. This has changed now and there should be no reasons for any further clashes. His temper and harshness, when me was insisting on a full name, did always remind me on Uwe, who is using multiple email accounts on his attempts to "improve" development. If you trust him, I'll trust him too. Derek, sorry for have being preemptive on you. Thanks, Hermann Und was machen Sie heute abend? Alles Events Ihrer Gegend auf einen Blick im Arcor.de-Veranstaltungskalender: http://www.arcor.de/rd/footer.events -- 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
Pinnacle PCTV 70e Support question
Hi, i wonder what needs to be done to support this usb stick also know as Pinnacle PCTV DVB-T (usb: eb1a:2870). The stick has a MT2060 tuner and a Zarlink ZL10353 dvb frontend. My kernel (2.6.32) does not "know" this board out-of-the-box but mention it as card=45 in dmesg. But it does not work - using 45 as card type this is the result: The support for this board weren't valid yet. So what does it need to get stick and IR control working? Torsten -- 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 3/4] ir-core: move decoding state to ir_raw_event_ctrl
On Mon, Jun 07, 2010 at 09:00:03PM +0200, David Härdeman wrote:
> On Mon, May 03, 2010 at 05:00:05PM -0300, Mauro Carvalho Chehab wrote:
> > David Härdeman wrote:
> > > This patch moves the state from each raw decoder into the
> > > ir_raw_event_ctrl struct.
> > >
> > > This allows the removal of code like this:
> > >
> > > spin_lock(&decoder_lock);
> > > list_for_each_entry(data, &decoder_list, list) {
> > > if (data->ir_dev == ir_dev)
> > > break;
> > > }
> > > spin_unlock(&decoder_lock);
> > > return data;
> > >
> > > which is currently run for each decoder on each event in order
> > > to get the client-specific decoding state data.
> > >
> > > In addition, ir decoding modules and ir driver module load
> > > order is now independent. Centralizing the data also allows
> > > for a nice code reduction of about 30% per raw decoder as
> > > client lists and client registration callbacks are no longer
> > > necessary.
> >
> > The registration callbacks will likely still be needed by lirc,
> > as you need to create/delete lirc_dev interfaces, when the module
> > is registered, but I might be wrong. It would be interesting to
> > add lirc_dev first, in order to be sure about the better interfaces
> > for it.
>
> Or the lirc_dev patch can add whatever interfaces it needs. Anyway, the
> current interfaces are not good enough since it'll break if lirc_dev is
> loaded after the hardware modules.
This is something I've been meaning to mention myself. On system boot, if
an mceusb device is connected, it pretty regularly only has the NEC
decoder available to use. I have to reload mceusb, or make sure ir-core is
explicitly loaded, wait a bit, then load mceusb, if I want to have all of
the protocol handlers available -- which includes the needed-by-default
rc6 one. I've only briefly tinkered with trying to fix it, sounds like you
may already have fixage within this patchset.
...
> In addition, random module load order is currently broken (try loading
> decoders first and hardware later and you'll see). With this patch, it
> works again.
Want.
> Anyway, I'll post a new patch series this evening and then we can go
> back to our regular arguing :)
Hey, at least we're making progress too! :)
--
Jarod Wilson
ja...@redhat.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: Is anybody working on TechniSat CableStar Combo HD CI USB device?
On 06/07/2010 09:01 AM, Tobias Maier wrote: > on the card is a Micronas DRX 3913 JKA2 which is a combined analog > cable, DVB-C and DVB-T Demodulator. > any chance this device is supported soon? Anything i can do to get > this going? > Hi Tobias, I'm in the market for a USB DVB-C device, and I've been looking into this device. I've added it to the linuxtv.org wiki (http://www.linuxtv.org/wiki/index.php/TechniSat_CableStar_Combo_HD_CI). It seems the Windows drivers for this device are very similar to those of the (supported) Terratec S7 DVB-S device. No quite sure that to make of that, though. The Micronas DRX series seems to 'evil' in that there is only a closed-source driver and the manufacturer doesn't cooperate with open source developers. Jan-Pascal signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/3] IR: add core lirc device interface
On Mon, Jun 7, 2010 at 2:44 PM, David Härdeman wrote:
> On Fri, Jun 04, 2010 at 03:38:35PM -0300, Mauro Carvalho Chehab wrote:
>> Em 04-06-2010 12:51, Christoph Bartelmus escreveu:
>> > Hi Mauro,
>> >
>> > on 04 Jun 10 at 01:10, Mauro Carvalho Chehab wrote:
>> >> Em 03-06-2010 19:06, Jarod Wilson escreveu:
>> > [...]
>> >>> As for the compat bits... I actually pulled them out of the Fedora kernel
>> >>> and userspace for a while, and there were only a few people who really
>> >>> ran
>> >>> into issues with it, but I think if the new userspace and kernel are
>> >>> rolled
>> >>> out at the same time in a new distro release (i.e., Fedora 14, in our
>> >>> particular case), it should be mostly transparent to users.
>> >
>> >> For sure this will happen on all distros that follows upstream: they'll
>> >> update lirc to fulfill the minimal requirement at Documentation/Changes.
>> >>
>> >> The issue will appear only to people that manually compile kernel and
>> >> lirc.
>> >> Those users are likely smart enough to upgrade to a newer lirc version if
>> >> they notice a trouble, and to check at the forums.
>> >
>> >>> Christoph
>> >>> wasn't a fan of the change, and actually asked me to revert it, so I'm
>> >>> cc'ing him here for further feedback, but I'm inclined to say that if
>> >>> this
>> >>> is the price we pay to get upstream, so be it.
>> >
>> >> I understand Christoph view, but I think that having to deal with compat
>> >> stuff forever is a high price to pay, as the impact of this change is
>> >> transitory and shouldn't be hard to deal with.
>> >
>> > I'm not against doing this change, but it has to be coordinated between
>> > drivers and user-space.
>> > Just changing lirc.h is not enough. You also have to change all user-space
>> > applications that use the affected ioctls to use the correct types.
>> > That's what Jarod did not address last time so I asked him to revert the
>> > change.
>>
>> For sure coordination between kernel and userspace is very important. I'm
>> sure
>> that Jarod can help with this sync. Also, after having the changes
>> implemented
>> on userspace, I expect one patch from you adding the minimal lirc requirement
>> at Documentation/Changes.
>>
>> > And I'd also like to collect all other change request to the API
>> > if there are any and do all changes in one go.
>>
>> You and Jarod are the most indicated people to point for such needs. Also,
>> Jon
>> and David may have some comments.
>
> David (who has been absent, sorry about that, life got in the way)
> thinks that the lirc raw decoder should implement the minimum amount of
> ioctl's possible while still being usable by the lirc userspace and
> without going beyond being a raw pulse/space "decoder" or we'll risk
> having to extend the entire decoder API just to support the lirc
> compatability decoder.
Thus far, I can get 100% feature-parity w/lirc_mceusb in my ir-core
mceusb driver by adding only 3 tx-specific callbacks to ir_dev_props,
and they're all callbacks (set output mask, set carrier and ir tx
function) that any rc-core native tx solution is also going to need.
On the receive side, zero modifications were made to enable the bridge
driver, outside of the minimal bits to load and register the
"decoder". I definitely don't want to burden {ir,rc}-core with
anything that is lirc-specific. Andy's cx23888 driver seems to have a
whole lot more functionality that it might be desirable to adjust via
userspace than mceusb does, but I think that can still be done w/o any
hooks in the core that are inherently lirc-specific.
For reference, this is the entire diff for what was added to ir-core
to enable tx on the mceusb driver:
http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=commitdiff;h=73d631214ed75003bb73e3303819748b47303fd6
Most of the heavy lifting was done in ir-lirc-codec and mceusb, and
the mceusb parts are all non-lirc-specific (hopefully), and thus ready
to be utilized by a "native" tx solution as well.
> Over time, I hope that rc-core will grow it's own chardev with a clean
> set of ioctls (or sysfs controls, the jury hasn't returned a verdict
> yet). lircd can then be upgraded to support both the in-kernel native
> mode and the legacy lirc mode, and with time, the lirc raw decoder can
> be phased out.
Works for me.
--
Jarod Wilson
ja...@wilsonet.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 8/8] ir-core: merge rc-map.h into ir-core.h
Haven't discussed this patch on the linux-media list yet, but merging rc-map.h into ir-core.h at least makes it much easier for me to get a good overview of the entire rc-core subsystem (and to make sweeping changes). Not sure if everyone agrees? Signed-off-by: David Härdeman --- drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c|2 drivers/media/IR/keymaps/rc-apac-viewcomp.c|2 drivers/media/IR/keymaps/rc-asus-pc39.c|2 drivers/media/IR/keymaps/rc-ati-tv-wonder-hd-600.c |2 drivers/media/IR/keymaps/rc-avermedia-a16d.c |2 drivers/media/IR/keymaps/rc-avermedia-cardbus.c|2 drivers/media/IR/keymaps/rc-avermedia-dvbt.c |2 .../media/IR/keymaps/rc-avermedia-m135a-rm-jx.c|2 drivers/media/IR/keymaps/rc-avermedia.c|2 drivers/media/IR/keymaps/rc-avertv-303.c |2 drivers/media/IR/keymaps/rc-behold-columbus.c |2 drivers/media/IR/keymaps/rc-behold.c |2 drivers/media/IR/keymaps/rc-budget-ci-old.c|2 drivers/media/IR/keymaps/rc-cinergy-1400.c |2 drivers/media/IR/keymaps/rc-cinergy.c |2 drivers/media/IR/keymaps/rc-dm1105-nec.c |2 drivers/media/IR/keymaps/rc-dntv-live-dvb-t.c |2 drivers/media/IR/keymaps/rc-dntv-live-dvbt-pro.c |2 drivers/media/IR/keymaps/rc-em-terratec.c |2 drivers/media/IR/keymaps/rc-empty.c|2 drivers/media/IR/keymaps/rc-encore-enltv-fm53.c|2 drivers/media/IR/keymaps/rc-encore-enltv.c |2 drivers/media/IR/keymaps/rc-encore-enltv2.c|2 drivers/media/IR/keymaps/rc-evga-indtube.c |2 drivers/media/IR/keymaps/rc-eztv.c |2 drivers/media/IR/keymaps/rc-flydvb.c |2 drivers/media/IR/keymaps/rc-flyvideo.c |2 drivers/media/IR/keymaps/rc-fusionhdtv-mce.c |2 drivers/media/IR/keymaps/rc-gadmei-rm008z.c|2 drivers/media/IR/keymaps/rc-genius-tvgo-a11mce.c |2 drivers/media/IR/keymaps/rc-gotview7135.c |2 drivers/media/IR/keymaps/rc-hauppauge-new.c|2 drivers/media/IR/keymaps/rc-imon-mce.c |2 drivers/media/IR/keymaps/rc-imon-pad.c |2 drivers/media/IR/keymaps/rc-iodata-bctv7e.c|2 drivers/media/IR/keymaps/rc-kaiomy.c |2 drivers/media/IR/keymaps/rc-kworld-315u.c |2 .../media/IR/keymaps/rc-kworld-plus-tv-analog.c|2 drivers/media/IR/keymaps/rc-manli.c|2 drivers/media/IR/keymaps/rc-msi-tvanywhere-plus.c |2 drivers/media/IR/keymaps/rc-msi-tvanywhere.c |2 drivers/media/IR/keymaps/rc-nebula.c |2 .../media/IR/keymaps/rc-nec-terratec-cinergy-xs.c |2 drivers/media/IR/keymaps/rc-norwood.c |2 drivers/media/IR/keymaps/rc-npgtech.c |2 drivers/media/IR/keymaps/rc-pctv-sedna.c |2 drivers/media/IR/keymaps/rc-pinnacle-color.c |2 drivers/media/IR/keymaps/rc-pinnacle-grey.c|2 drivers/media/IR/keymaps/rc-pinnacle-pctv-hd.c |2 drivers/media/IR/keymaps/rc-pixelview-mk12.c |2 drivers/media/IR/keymaps/rc-pixelview-new.c|2 drivers/media/IR/keymaps/rc-pixelview.c|2 .../media/IR/keymaps/rc-powercolor-real-angel.c|2 drivers/media/IR/keymaps/rc-proteus-2309.c |2 drivers/media/IR/keymaps/rc-purpletv.c |2 drivers/media/IR/keymaps/rc-pv951.c|2 drivers/media/IR/keymaps/rc-rc5-hauppauge-new.c|2 drivers/media/IR/keymaps/rc-rc5-tv.c |2 .../media/IR/keymaps/rc-real-audio-220-32-keys.c |2 drivers/media/IR/keymaps/rc-tbs-nec.c |2 drivers/media/IR/keymaps/rc-terratec-cinergy-xs.c |2 drivers/media/IR/keymaps/rc-tevii-nec.c|2 drivers/media/IR/keymaps/rc-tt-1500.c |2 drivers/media/IR/keymaps/rc-videomate-s350.c |2 drivers/media/IR/keymaps/rc-videomate-tv-pvr.c |2 drivers/media/IR/keymaps/rc-winfast-usbii-deluxe.c |2 drivers/media/IR/keymaps/rc-winfast.c |2 include/media/ir-core.h| 112 ++- include/media/rc-map.h | 121 69 files changed, 178 insertions(+), 189 deletions(-) delete mode 100644 include/media/rc-map.h diff --git a/drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c b/drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c index b172831..8d5655a 100644 --- a/drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c +++ b/drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c @@ -10,7 +10,7 @@ * (at your option) any later version. */ -#include +#include /* ADS Tech Instant TV DVB-T PCI Remote */ diff --git a/drivers/media/IR/keymaps/rc-apac-viewcom
[PATCH 7/8] ir-core: move decoding state to ir_raw_event_ctrl
This patch moves the state from each raw decoder into the
ir_raw_event_ctrl struct.
This allows the removal of code like this:
spin_lock(&decoder_lock);
list_for_each_entry(data, &decoder_list, list) {
if (data->ir_dev == ir_dev)
break;
}
spin_unlock(&decoder_lock);
return data;
which is currently run for each decoder on each event in order
to get the client-specific decoding state data.
In addition, ir decoding modules and ir driver module load
order is now independent. Centralizing the data also allows
for a nice code reduction of about 30% per raw decoder as
client lists and client registration callbacks are no longer
necessary.
Out-of-tree modules can still use a similar trick to what
the raw decoders did before this patch until they are merged.
Signed-off-by: David Härdeman
---
drivers/media/IR/ir-core-priv.h| 37 -
drivers/media/IR/ir-jvc-decoder.c | 90 ++-
drivers/media/IR/ir-nec-decoder.c | 89 +++
drivers/media/IR/ir-raw-event.c| 48 +++--
drivers/media/IR/ir-rc5-decoder.c | 103 +---
drivers/media/IR/ir-rc6-decoder.c | 92 ++--
drivers/media/IR/ir-sony-decoder.c | 93 +++--
7 files changed, 87 insertions(+), 465 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 3072e55..d19d819 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -23,8 +23,6 @@ struct ir_raw_handler {
u64 protocols; /* which are handled by this handler */
int (*decode)(struct input_dev *input_dev, struct ir_raw_event event);
- int (*raw_register)(struct input_dev *input_dev);
- int (*raw_unregister)(struct input_dev *input_dev);
};
struct ir_raw_event_ctrl {
@@ -34,6 +32,41 @@ struct ir_raw_event_ctrl {
enum raw_event_type last_type; /* last event type */
struct input_dev*input_dev; /* pointer to the
parent input_dev */
u64 enabled_protocols; /* enabled raw
protocol decoders */
+
+ /* raw decoder state follows */
+ struct ir_raw_event prev_ev;
+ struct nec_dec {
+ int state;
+ unsigned count;
+ u32 bits;
+ } nec;
+ struct rc5_dec {
+ int state;
+ u32 bits;
+ unsigned count;
+ unsigned wanted_bits;
+ } rc5;
+ struct rc6_dec {
+ int state;
+ u8 header;
+ u32 body;
+ bool toggle;
+ unsigned count;
+ unsigned wanted_bits;
+ } rc6;
+ struct sony_dec {
+ int state;
+ u32 bits;
+ unsigned count;
+ } sony;
+ struct jvc_dec {
+ int state;
+ u16 bits;
+ u16 old_bits;
+ unsigned count;
+ bool first;
+ bool toggle;
+ } jvc;
};
/* macros for IR decoders */
diff --git a/drivers/media/IR/ir-jvc-decoder.c
b/drivers/media/IR/ir-jvc-decoder.c
index 1055de4..8894d8b 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -25,10 +25,6 @@
#define JVC_TRAILER_PULSE (1 * JVC_UNIT)
#defineJVC_TRAILER_SPACE (35 * JVC_UNIT)
-/* Used to register jvc_decoder clients */
-static LIST_HEAD(decoder_list);
-DEFINE_SPINLOCK(decoder_lock);
-
enum jvc_state {
STATE_INACTIVE,
STATE_HEADER_SPACE,
@@ -38,39 +34,6 @@ enum jvc_state {
STATE_TRAILER_SPACE,
};
-struct decoder_data {
- struct list_headlist;
- struct ir_input_dev *ir_dev;
-
- /* State machine control */
- enum jvc_state state;
- u16 jvc_bits;
- u16 jvc_old_bits;
- unsignedcount;
- boolfirst;
- booltoggle;
-};
-
-
-/**
- * get_decoder_data() - gets decoder data
- * @input_dev: input device
- *
- * Returns the struct decoder_data that corresponds to a device
- */
-static struct decoder_data *get_decoder_data(struct ir_input_dev *ir_dev)
-{
- struct decoder_data *data = NULL;
-
- spin_lock(&decoder_lock);
- list_for_each_entry(data, &decoder_list, list) {
- if (data->ir_dev == ir_dev)
- break;
- }
- spin_unlock(&decoder_lock);
- return data;
-}
-
/**
* ir_jvc_decode() - Decode one JVC pulse or space
* @input_dev: the struct input_dev descriptor of the device
@@ -80,12 +43,8 @@ static struct decoder_data *get_decoder_data(struct
ir_input_dev *ir_dev)
*/
static int ir_jvc_decode(struct input_dev *input_dev, struct ir_raw
[PATCH 6/8] ir-core: centralize sysfs raw decoder enabling/disabling
With the current logic, each raw decoder needs to add a copy of the exact
same sysfs code. This is both unnecessary and also means that (re)loading
an IR driver after raw decoder modules have been loaded won't work as
expected.
This patch moves that logic into ir-raw-event and adds a single sysfs
file per device.
Reading that file returns something like:
"rc5 [rc6] nec jvc [sony]"
(with enabled protocols in [] brackets)
Writing either "+protocol" or "-protocol" to that file will
enable or disable the according protocol decoder.
An additional benefit is that the disabling of a decoder will be
remembered across module removal/insertion so a previously
disabled decoder won't suddenly be activated again. The default
setting is to enable all decoders.
This is also necessary for the next patch which moves even more decoder
state into the central raw decoding structs.
Signed-off-by: David Härdeman
---
drivers/media/IR/ir-core-priv.h|3
drivers/media/IR/ir-jvc-decoder.c | 64 -
drivers/media/IR/ir-nec-decoder.c | 64 -
drivers/media/IR/ir-raw-event.c| 112 +---
drivers/media/IR/ir-rc5-decoder.c | 64 -
drivers/media/IR/ir-rc6-decoder.c | 64 -
drivers/media/IR/ir-sony-decoder.c | 64 -
drivers/media/IR/ir-sysfs.c| 252 +---
8 files changed, 231 insertions(+), 456 deletions(-)
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index b79446f..3072e55 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -21,6 +21,7 @@
struct ir_raw_handler {
struct list_head list;
+ u64 protocols; /* which are handled by this handler */
int (*decode)(struct input_dev *input_dev, struct ir_raw_event event);
int (*raw_register)(struct input_dev *input_dev);
int (*raw_unregister)(struct input_dev *input_dev);
@@ -32,6 +33,7 @@ struct ir_raw_event_ctrl {
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
struct input_dev*input_dev; /* pointer to the
parent input_dev */
+ u64 enabled_protocols; /* enabled raw
protocol decoders */
};
/* macros for IR decoders */
@@ -73,6 +75,7 @@ void ir_unregister_class(struct input_dev *input_dev);
/*
* Routines from ir-raw-event.c to be used internally and by decoders
*/
+u64 ir_raw_get_allowed_protocols(void);
int ir_raw_event_register(struct input_dev *input_dev);
void ir_raw_event_unregister(struct input_dev *input_dev);
int ir_raw_handler_register(struct ir_raw_handler *ir_raw_handler);
diff --git a/drivers/media/IR/ir-jvc-decoder.c
b/drivers/media/IR/ir-jvc-decoder.c
index 0b80494..1055de4 100644
--- a/drivers/media/IR/ir-jvc-decoder.c
+++ b/drivers/media/IR/ir-jvc-decoder.c
@@ -41,7 +41,6 @@ enum jvc_state {
struct decoder_data {
struct list_headlist;
struct ir_input_dev *ir_dev;
- int enabled:1;
/* State machine control */
enum jvc_state state;
@@ -72,53 +71,6 @@ static struct decoder_data *get_decoder_data(struct
ir_input_dev *ir_dev)
return data;
}
-static ssize_t store_enabled(struct device *d,
-struct device_attribute *mattr,
-const char *buf,
-size_t len)
-{
- unsigned long value;
- struct ir_input_dev *ir_dev = dev_get_drvdata(d);
- struct decoder_data *data = get_decoder_data(ir_dev);
-
- if (!data)
- return -EINVAL;
-
- if (strict_strtoul(buf, 10, &value) || value > 1)
- return -EINVAL;
-
- data->enabled = value;
-
- return len;
-}
-
-static ssize_t show_enabled(struct device *d,
-struct device_attribute *mattr, char *buf)
-{
- struct ir_input_dev *ir_dev = dev_get_drvdata(d);
- struct decoder_data *data = get_decoder_data(ir_dev);
-
- if (!data)
- return -EINVAL;
-
- if (data->enabled)
- return sprintf(buf, "1\n");
- else
- return sprintf(buf, "0\n");
-}
-
-static DEVICE_ATTR(enabled, S_IRUGO | S_IWUSR, show_enabled, store_enabled);
-
-static struct attribute *decoder_attributes[] = {
- &dev_attr_enabled.attr,
- NULL
-};
-
-static struct attribute_group decoder_attribute_group = {
- .name = "jvc_decoder",
- .attrs = decoder_attributes,
-};
-
/**
* ir_jvc_decode() - Decode one JVC pulse or space
* @input_dev: the struct input_dev descriptor of the device
@@ -135,7 +87,7 @@ static int ir_jvc_decode(struct input_dev *input_dev, struct
ir_raw_event ev)
if (!data)
return -EINVAL;
- if (!data->enabled)
+ if (!(ir_dev->raw->enabled_protocols & IR_TYPE_JVC))
[PATCH 5/8] ir-core: partially convert bt8xx to not use ir-functions.c
Partially convert drivers/media/video/bt8xx/bttv-input.c to
not use ir-functions.c.
Since the last user is gone with this patch, also remove a
bunch of code from ir-functions.c.
Signed-off-by: David Härdeman
---
drivers/media/IR/ir-functions.c | 89 +--
drivers/media/video/bt8xx/bttv-input.c | 35 ++-
drivers/media/video/bt8xx/bttv.h|1
drivers/media/video/bt8xx/bttvp.h | 11 ---
drivers/media/video/cx23885/cx23885-input.c | 51 +--
drivers/media/video/saa7134/saa7134-input.c | 61 +++
include/media/ir-common.h | 22 ---
include/media/ir-kbd-i2c.h |1
8 files changed, 27 insertions(+), 244 deletions(-)
diff --git a/drivers/media/IR/ir-functions.c b/drivers/media/IR/ir-functions.c
index db591e4..d7f47b2 100644
--- a/drivers/media/IR/ir-functions.c
+++ b/drivers/media/IR/ir-functions.c
@@ -31,67 +31,6 @@
MODULE_AUTHOR("Gerd Knorr [SuSE Labs]");
MODULE_LICENSE("GPL");
-static int repeat = 1;
-module_param(repeat, int, 0444);
-MODULE_PARM_DESC(repeat,"auto-repeat for IR keys (default: on)");
-
-/* --
*/
-
-static void ir_input_key_event(struct input_dev *dev, struct ir_input_state
*ir)
-{
- if (KEY_RESERVED == ir->keycode) {
- printk(KERN_INFO "%s: unknown key: key=0x%02x down=%d\n",
- dev->name, ir->ir_key, ir->keypressed);
- return;
- }
- IR_dprintk(1,"%s: key event code=%d down=%d\n",
- dev->name,ir->keycode,ir->keypressed);
- input_report_key(dev,ir->keycode,ir->keypressed);
- input_sync(dev);
-}
-
-/* --
*/
-
-int ir_input_init(struct input_dev *dev, struct ir_input_state *ir,
- const u64 ir_type)
-{
- ir->ir_type = ir_type;
-
- if (repeat)
- set_bit(EV_REP, dev->evbit);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(ir_input_init);
-
-
-void ir_input_nokey(struct input_dev *dev, struct ir_input_state *ir)
-{
- if (ir->keypressed) {
- ir->keypressed = 0;
- ir_input_key_event(dev,ir);
- }
-}
-EXPORT_SYMBOL_GPL(ir_input_nokey);
-
-void ir_input_keydown(struct input_dev *dev, struct ir_input_state *ir,
- u32 ir_key)
-{
- u32 keycode = ir_g_keycode_from_table(dev, ir_key);
-
- if (ir->keypressed && ir->keycode != keycode) {
- ir->keypressed = 0;
- ir_input_key_event(dev,ir);
- }
- if (!ir->keypressed) {
- ir->ir_key = ir_key;
- ir->keycode = keycode;
- ir->keypressed = 1;
- ir_input_key_event(dev,ir);
- }
-}
-EXPORT_SYMBOL_GPL(ir_input_keydown);
-
/* --
*/
/* extract mask bits out of data and pack them into the result */
u32 ir_extract_bits(u32 data, u32 mask)
@@ -284,12 +223,10 @@ void ir_rc5_timer_end(unsigned long data)
{
struct card_ir *ir = (struct card_ir *)data;
struct timeval tv;
- unsigned long current_jiffies, timeout;
u32 gap;
u32 rc5 = 0;
/* get time */
- current_jiffies = jiffies;
do_gettimeofday(&tv);
/* avoid overflow with gap >1s */
@@ -325,32 +262,10 @@ void ir_rc5_timer_end(unsigned long data)
u32 toggle = RC5_TOGGLE(rc5);
u32 instr = RC5_INSTR(rc5);
- /* Good code, decide if repeat/repress */
- if (toggle != RC5_TOGGLE(ir->last_rc5) ||
- instr != RC5_INSTR(ir->last_rc5)) {
- IR_dprintk(1, "ir-common: instruction %x,
toggle %x\n", instr,
- toggle);
- ir_input_nokey(ir->dev, &ir->ir);
- ir_input_keydown(ir->dev, &ir->ir, instr);
- }
-
- /* Set/reset key-up timer */
- timeout = current_jiffies +
- msecs_to_jiffies(ir->rc5_key_timeout);
- mod_timer(&ir->timer_keyup, timeout);
-
- /* Save code for repeat test */
- ir->last_rc5 = rc5;
+ /* Good code */
+ ir_keydown(ir->dev, instr, toggle);
}
}
}
EXPORT_SYMBOL_GPL(ir_rc5_timer_end);
-void ir_rc5_timer_keyup(unsigned long data)
-{
- struct card_ir *ir = (struct card_ir *)data;
-
- IR_dprintk(1, "ir-common: key released\n");
- ir_input_nokey(ir->dev, &ir->ir);
-}
-EXPORT_SYMBOL_GPL(ir_rc5_timer_keyup);
diff --git a/drivers/media/video/bt8xx/bttv-input.c
b/drivers/media/video/bt8xx/bttv-input.c
index
[PATCH 4/8] ir-core: partially convert ir-kbd-i2c.c to not use ir-functions.c
Partially convert drivers/media/video/ir-kbd-i2c.c to
not use ir-functions.c
Signed-off-by: David Härdeman
---
drivers/media/video/ir-kbd-i2c.c | 14 --
include/media/ir-kbd-i2c.h |2 +-
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index 29d4397..27ae8bb 100644
--- a/drivers/media/video/ir-kbd-i2c.c
+++ b/drivers/media/video/ir-kbd-i2c.c
@@ -47,7 +47,7 @@
#include
#include
-#include
+#include
#include
/* --- */
@@ -272,11 +272,8 @@ static void ir_key_poll(struct IR_i2c *ir)
return;
}
- if (0 == rc) {
- ir_input_nokey(ir->input, &ir->ir);
- } else {
- ir_input_keydown(ir->input, &ir->ir, ir_key);
- }
+ if (rc)
+ ir_keydown(ir->input, ir_key, 0);
}
static void ir_work(struct work_struct *work)
@@ -439,10 +436,7 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
dev_name(&client->dev));
/* init + register input device */
- err = ir_input_init(input_dev, &ir->ir, ir_type);
- if (err < 0)
- goto err_out_free;
-
+ ir->ir_type = ir_type;
input_dev->id.bustype = BUS_I2C;
input_dev->name = ir->name;
input_dev->phys = ir->phys;
diff --git a/include/media/ir-kbd-i2c.h b/include/media/ir-kbd-i2c.h
index 0506e45..5e96d7a 100644
--- a/include/media/ir-kbd-i2c.h
+++ b/include/media/ir-kbd-i2c.h
@@ -11,7 +11,7 @@ struct IR_i2c {
struct i2c_client *c;
struct input_dev *input;
struct ir_input_state ir;
-
+ u64ir_type;
/* Used to avoid fast repeating */
unsigned char old;
--
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 3/8] ir-core: partially convert cx88 to not use ir-functions.c
Partially convert drivers/media/video/cx88/cx88-input.c to
not use ir-functions.c
Signed-off-by: David Härdeman
---
drivers/media/video/cx88/cx88-input.c | 46 +++--
1 files changed, 16 insertions(+), 30 deletions(-)
diff --git a/drivers/media/video/cx88/cx88-input.c
b/drivers/media/video/cx88/cx88-input.c
index 0de9bdf..e6ecbf8 100644
--- a/drivers/media/video/cx88/cx88-input.c
+++ b/drivers/media/video/cx88/cx88-input.c
@@ -29,6 +29,7 @@
#include
#include "cx88.h"
+#include
#include
#define MODULE_NAME "cx88xx"
@@ -38,8 +39,8 @@
struct cx88_IR {
struct cx88_core *core;
struct input_dev *input;
- struct ir_input_state ir;
struct ir_dev_props props;
+ u64 ir_type;
int users;
@@ -50,7 +51,6 @@ struct cx88_IR {
u32 sampling;
u32 samples[16];
int scount;
- unsigned long release;
/* poll external decoder */
int polling;
@@ -124,29 +124,21 @@ static void cx88_ir_handle_key(struct cx88_IR *ir)
data = (data << 4) | ((gpio_key & 0xf0) >> 4);
- ir_input_keydown(ir->input, &ir->ir, data);
- ir_input_nokey(ir->input, &ir->ir);
+ ir_keydown(ir->input, data, 0);
} else if (ir->mask_keydown) {
/* bit set on keydown */
- if (gpio & ir->mask_keydown) {
- ir_input_keydown(ir->input, &ir->ir, data);
- } else {
- ir_input_nokey(ir->input, &ir->ir);
- }
+ if (gpio & ir->mask_keydown)
+ ir_keydown(ir->input, data, 0);
} else if (ir->mask_keyup) {
/* bit cleared on keydown */
- if (0 == (gpio & ir->mask_keyup)) {
- ir_input_keydown(ir->input, &ir->ir, data);
- } else {
- ir_input_nokey(ir->input, &ir->ir);
- }
+ if (0 == (gpio & ir->mask_keyup))
+ ir_keydown(ir->input, data, 0);
} else {
/* can't distinguish keydown/up :-/ */
- ir_input_keydown(ir->input, &ir->ir, data);
- ir_input_nokey(ir->input, &ir->ir);
+ ir_keydown(ir->input, data, 0);
}
}
@@ -438,9 +430,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev
*pci)
snprintf(ir->name, sizeof(ir->name), "cx88 IR (%s)", core->board.name);
snprintf(ir->phys, sizeof(ir->phys), "pci-%s/ir0", pci_name(pci));
- err = ir_input_init(input_dev, &ir->ir, ir_type);
- if (err < 0)
- goto err_out_free;
+ ir->ir_type = ir_type;
input_dev->name = ir->name;
input_dev->phys = ir->phys;
@@ -515,8 +505,6 @@ void cx88_ir_irq(struct cx88_core *core)
}
if (!ir->scount) {
/* nothing to sample */
- if (ir->ir.keypressed && time_after(jiffies, ir->release))
- ir_input_nokey(ir->input, &ir->ir);
return;
}
@@ -552,7 +540,7 @@ void cx88_ir_irq(struct cx88_core *core)
if (ircode == 0) { /* key still pressed */
ir_dprintk("pulse distance decoded repeat code\n");
- ir->release = jiffies + msecs_to_jiffies(120);
+ ir_repeat(ir->input);
break;
}
@@ -566,10 +554,8 @@ void cx88_ir_irq(struct cx88_core *core)
break;
}
- ir_dprintk("Key Code: %x\n", (ircode >> 16) & 0x7f);
-
- ir_input_keydown(ir->input, &ir->ir, (ircode >> 16) & 0x7f);
- ir->release = jiffies + msecs_to_jiffies(120);
+ ir_dprintk("Key Code: %x\n", (ircode >> 16) & 0xff);
+ ir_keydown(ir->input, (ircode >> 16) & 0xff, 0);
break;
case CX88_BOARD_HAUPPAUGE:
case CX88_BOARD_HAUPPAUGE_DVB_T1:
@@ -605,16 +591,16 @@ void cx88_ir_irq(struct cx88_core *core)
if ( dev != 0x1e && dev != 0x1f )
/* not a hauppauge remote */
break;
- ir_input_keydown(ir->input, &ir->ir, code);
- ir->release = jiffies + msecs_to_jiffies(120);
+ ir_keydown(ir->input, code, toggle);
break;
case CX88_BOARD_PINNACLE_PCTV_HD_800i:
ircode = ir_decode_biphase(ir->samples, ir->scount, 5, 7);
ir_dprintk("biphase decoded: %x\n", ircode);
if ((ircode & 0xf000) != 0x3000)
break;
- ir_input_keydown(ir->input, &ir->ir, ircode & 0x3f);
- ir->release = jiffies + msecs_to_jiffies(120);
+ /* Note: bit 0x800 being the toggle is assumed, not checked
+ with real hardware */
+ ir_keydown(ir->input, ircode & 0x3f, ircode
[PATCH 1/8] ir-core: convert mantis to not use ir-functions.c
Convert drivers/media/dvb/mantis/mantis_input.c to not use ir-functions.c
Signed-off-by: David Härdeman
---
drivers/media/dvb/mantis/mantis_input.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/mantis/mantis_input.c
b/drivers/media/dvb/mantis/mantis_input.c
index 3d4e466..a99489b 100644
--- a/drivers/media/dvb/mantis/mantis_input.c
+++ b/drivers/media/dvb/mantis/mantis_input.c
@@ -19,7 +19,7 @@
*/
#include
-#include
+#include
#include
#include "dmxdev.h"
@@ -104,7 +104,6 @@ EXPORT_SYMBOL_GPL(ir_mantis);
int mantis_input_init(struct mantis_pci *mantis)
{
struct input_dev *rc;
- struct ir_input_state rc_state;
char name[80], dev[80];
int err;
@@ -120,8 +119,6 @@ int mantis_input_init(struct mantis_pci *mantis)
rc->name = name;
rc->phys = dev;
- ir_input_init(rc, &rc_state, IR_TYPE_OTHER);
-
rc->id.bustype = BUS_PCI;
rc->id.vendor = mantis->vendor_id;
rc->id.product = mantis->device_id;
--
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 2/8] ir-core: convert em28xx to not use ir-functions.c
Convert drivers/media/video/em28xx/em28xx-input.c to not use ir-functions.c
Signed-off-by: David Härdeman
---
drivers/media/video/em28xx/em28xx-input.c | 65 +++--
drivers/media/video/em28xx/em28xx.h |1
2 files changed, 17 insertions(+), 49 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-input.c
b/drivers/media/video/em28xx/em28xx-input.c
index dffd026..c4d6027 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -64,17 +64,14 @@ struct em28xx_ir_poll_result {
struct em28xx_IR {
struct em28xx *dev;
struct input_dev *input;
- struct ir_input_state ir;
char name[32];
char phys[32];
/* poll external decoder */
int polling;
struct delayed_work work;
- unsigned int last_toggle:1;
unsigned int full_code:1;
unsigned int last_readcount;
- unsigned int repeat_interval;
int (*get_key)(struct em28xx_IR *, struct em28xx_ir_poll_result *);
@@ -290,7 +287,6 @@ static int em2874_polling_getkey(struct em28xx_IR *ir,
static void em28xx_ir_handle_key(struct em28xx_IR *ir)
{
int result;
- int do_sendkey = 0;
struct em28xx_ir_poll_result poll_result;
/* read the registers containing the IR status */
@@ -305,52 +301,28 @@ static void em28xx_ir_handle_key(struct em28xx_IR *ir)
ir->last_readcount, poll_result.rc_address,
poll_result.rc_data[0]);
- if (ir->dev->chip_id == CHIP_ID_EM2874) {
+ if (poll_result.read_count > 0 &&
+ poll_result.read_count != ir->last_readcount) {
+ if (ir->full_code)
+ ir_keydown(ir->input,
+ poll_result.rc_address << 8 |
+ poll_result.rc_data[0],
+ poll_result.toggle_bit);
+ else
+ ir_keydown(ir->input,
+ poll_result.rc_data[0],
+ poll_result.toggle_bit);
+ }
+
+ if (ir->dev->chip_id == CHIP_ID_EM2874)
/* The em2874 clears the readcount field every time the
register is read. The em2860/2880 datasheet says that it
is supposed to clear the readcount, but it doesn't. So with
the em2874, we are looking for a non-zero read count as
opposed to a readcount that is incrementing */
ir->last_readcount = 0;
- }
-
- if (poll_result.read_count == 0) {
- /* The button has not been pressed since the last read */
- } else if (ir->last_toggle != poll_result.toggle_bit) {
- /* A button has been pressed */
- dprintk("button has been pressed\n");
- ir->last_toggle = poll_result.toggle_bit;
- ir->repeat_interval = 0;
- do_sendkey = 1;
- } else if (poll_result.toggle_bit == ir->last_toggle &&
- poll_result.read_count > 0 &&
- poll_result.read_count != ir->last_readcount) {
- /* The button is still being held down */
- dprintk("button being held down\n");
-
- /* Debouncer for first keypress */
- if (ir->repeat_interval++ > 9) {
- /* Start repeating after 1 second */
- do_sendkey = 1;
- }
- }
-
- if (do_sendkey) {
- dprintk("sending keypress\n");
-
- if (ir->full_code)
- ir_input_keydown(ir->input, &ir->ir,
-poll_result.rc_address << 8 |
-poll_result.rc_data[0]);
- else
- ir_input_keydown(ir->input, &ir->ir,
-poll_result.rc_data[0]);
-
- ir_input_nokey(ir->input, &ir->ir);
- }
-
- ir->last_readcount = poll_result.read_count;
- return;
+ else
+ ir->last_readcount = poll_result.read_count;
}
static void em28xx_ir_work(struct work_struct *work)
@@ -465,11 +437,6 @@ int em28xx_ir_init(struct em28xx *dev)
usb_make_path(dev->udev, ir->phys, sizeof(ir->phys));
strlcat(ir->phys, "/input0", sizeof(ir->phys));
- /* Set IR protocol */
- err = ir_input_init(input_dev, &ir->ir, IR_TYPE_OTHER);
- if (err < 0)
- goto err_out_free;
-
input_dev->name = ir->name;
input_dev->phys = ir->phys;
input_dev->id.bustype = BUS_USB;
diff --git a/drivers/media/video/em28xx/em28xx.h
b/drivers/media/video/em28xx/em28xx.h
index b252d1b..6216786 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#if defined(CONFI
[PATCH 0/8] rc-core cleanups
The following series is my current patch queue. The first five patches remove some of the ir-functions.c legacy from hardware drivers (sadly I don't have the hardware so I can only compile test the resulting code). The next two patches are the same sysfs centralization patches I've sent before (see discussion in that thread). The last patch merges the two main rc-core (ir-core) headers, which helps readability for me at least... Net result - 900 lines less code. --- David Härdeman (8): ir-core: convert mantis to not use ir-functions.c ir-core: convert em28xx to not use ir-functions.c ir-core: partially convert cx88 to not use ir-functions.c ir-core: partially convert ir-kbd-i2c.c to not use ir-functions.c ir-core: partially convert bt8xx to not use ir-functions.c ir-core: centralize sysfs raw decoder enabling/disabling ir-core: move decoding state to ir_raw_event_ctrl ir-core: merge rc-map.h into ir-core.h drivers/media/IR/ir-core-priv.h| 40 +++ drivers/media/IR/ir-functions.c| 89 --- drivers/media/IR/ir-jvc-decoder.c | 152 +--- drivers/media/IR/ir-nec-decoder.c | 151 +--- drivers/media/IR/ir-raw-event.c| 136 +-- drivers/media/IR/ir-rc5-decoder.c | 165 + drivers/media/IR/ir-rc6-decoder.c | 154 +--- drivers/media/IR/ir-sony-decoder.c | 155 +--- drivers/media/IR/ir-sysfs.c| 252 drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c|2 drivers/media/IR/keymaps/rc-apac-viewcomp.c|2 drivers/media/IR/keymaps/rc-asus-pc39.c|2 drivers/media/IR/keymaps/rc-ati-tv-wonder-hd-600.c |2 drivers/media/IR/keymaps/rc-avermedia-a16d.c |2 drivers/media/IR/keymaps/rc-avermedia-cardbus.c|2 drivers/media/IR/keymaps/rc-avermedia-dvbt.c |2 .../media/IR/keymaps/rc-avermedia-m135a-rm-jx.c|2 drivers/media/IR/keymaps/rc-avermedia.c|2 drivers/media/IR/keymaps/rc-avertv-303.c |2 drivers/media/IR/keymaps/rc-behold-columbus.c |2 drivers/media/IR/keymaps/rc-behold.c |2 drivers/media/IR/keymaps/rc-budget-ci-old.c|2 drivers/media/IR/keymaps/rc-cinergy-1400.c |2 drivers/media/IR/keymaps/rc-cinergy.c |2 drivers/media/IR/keymaps/rc-dm1105-nec.c |2 drivers/media/IR/keymaps/rc-dntv-live-dvb-t.c |2 drivers/media/IR/keymaps/rc-dntv-live-dvbt-pro.c |2 drivers/media/IR/keymaps/rc-em-terratec.c |2 drivers/media/IR/keymaps/rc-empty.c|2 drivers/media/IR/keymaps/rc-encore-enltv-fm53.c|2 drivers/media/IR/keymaps/rc-encore-enltv.c |2 drivers/media/IR/keymaps/rc-encore-enltv2.c|2 drivers/media/IR/keymaps/rc-evga-indtube.c |2 drivers/media/IR/keymaps/rc-eztv.c |2 drivers/media/IR/keymaps/rc-flydvb.c |2 drivers/media/IR/keymaps/rc-flyvideo.c |2 drivers/media/IR/keymaps/rc-fusionhdtv-mce.c |2 drivers/media/IR/keymaps/rc-gadmei-rm008z.c|2 drivers/media/IR/keymaps/rc-genius-tvgo-a11mce.c |2 drivers/media/IR/keymaps/rc-gotview7135.c |2 drivers/media/IR/keymaps/rc-hauppauge-new.c|2 drivers/media/IR/keymaps/rc-imon-mce.c |2 drivers/media/IR/keymaps/rc-imon-pad.c |2 drivers/media/IR/keymaps/rc-iodata-bctv7e.c|2 drivers/media/IR/keymaps/rc-kaiomy.c |2 drivers/media/IR/keymaps/rc-kworld-315u.c |2 .../media/IR/keymaps/rc-kworld-plus-tv-analog.c|2 drivers/media/IR/keymaps/rc-manli.c|2 drivers/media/IR/keymaps/rc-msi-tvanywhere-plus.c |2 drivers/media/IR/keymaps/rc-msi-tvanywhere.c |2 drivers/media/IR/keymaps/rc-nebula.c |2 .../media/IR/keymaps/rc-nec-terratec-cinergy-xs.c |2 drivers/media/IR/keymaps/rc-norwood.c |2 drivers/media/IR/keymaps/rc-npgtech.c |2 drivers/media/IR/keymaps/rc-pctv-sedna.c |2 drivers/media/IR/keymaps/rc-pinnacle-color.c |2 drivers/media/IR/keymaps/rc-pinnacle-grey.c|2 drivers/media/IR/keymaps/rc-pinnacle-pctv-hd.c |2 drivers/media/IR/keymaps/rc-pixelview-mk12.c |2 drivers/media/IR/keymaps/rc-pixelview-new.c|2 drivers/media/IR/keymaps/rc-pixelview.c|2 .../media/IR/keymaps/rc-powercolor-real-angel.c|2 drivers/media/IR/keymaps/rc-proteus-2309.c |2 drivers/media/IR/keymaps/rc-purpletv.c |2 drivers/media/IR/keymaps/rc-pv951.c|2 drivers/media/IR/key
Re: tm6000 audio buffer
Am 06.06.2010 17:19, schrieb Mauro Carvalho Chehab:
> Hi Luis,
>
> Em 04-06-2010 16:39, Luis Henrique Fagundes escreveu:
>
>> Hi,
>>
>> I'm sending a patch that hypothetically would allocate a memory buffer
>> for the audio and copy the data from urb to buffer. It doesn't work,
>> so I'm not putting a [PATCH] in subject and send it just for feedback.
>> Am I going on the right way of implementing this? The patch was made
>> against the mercurial version at http://linuxtv.org/hg/v4l-dvb.
>>
>> I can see the audio packets at tm6000-video.c. Mauro said that the urb
>> audio packets had just 4 bytes of relevant data, 2 for each channel,
>> but the audio buffer has 128Kb and I see too few packets. Anyway, the
>> tm6000_audio_isocirq function receives the size of the packet and now
>> is copying everything to the buffer, I guess next step will be to find
>> what is relevant in this stream and make sure I have all packets here.
>>
>> I haven't applied all the recent patches from Stefan yet.
>>
> I found some time to fix several bugs at the alsa driver, and to properly
> add a function to copy the audio data into the buffers. It seems to be
> working, but I found the same problem as you: the number of packages is
> incredibly small. So, or the audio is not properly programmed on the
> device or the routine that decodes the URB packages are wrong. Yet, if you
> wait for enough time (several minutes), with for example:
> $ arecord -D hw:1,0 -r 48000 -c 2 -f S16_LE -M
>
>
Mauro, if I recorded I have this log with mencoder:
Not enough audio samples!
Error reading audio: Broken pipe
ALSA xrun!!! (at least 1275923299492.352 ms long)
ALSA Status:
state : XRUN
trigger_time: 13520.253382890
tstamp : 13520.253544610
delay : 0
avail : 77920
avail_max : 77920
> You'll see some random data at stdout. So, the alsa code seems to be ok.
>
> As I'm preparing to travel to V4L mini-summit, I doubt I would have any
> time to touch on the code during the next weeks, but maybe one of you
> may find some time to fix.
>
> I suggest to use some USB traffic analyzer to see what is happening,
> comparing the results on Linux and with the original driver, using the
> same source (for example, you may use one test signal with some audio
> buzz inside).
>
> As reference for you, I'm enclosing a patch that adds some additional debug
> code at copy_streams(), plus a trial I did, in order to play with some bits
> related to audio, but it didn't help.
>
> All the patches are at "staging/tm6000" branch, on my tree.
>
> Cheers,
> Mauro.
>
>
> diff --git a/drivers/staging/tm6000/tm6000-alsa.c
> b/drivers/staging/tm6000/tm6000-alsa.c
> index d31b525..aa38577 100644
> --- a/drivers/staging/tm6000/tm6000-alsa.c
> +++ b/drivers/staging/tm6000/tm6000-alsa.c
> @@ -84,6 +84,8 @@ static int _tm6000_start_audio_dma(struct snd_tm6000_card
> *chip)
> val |= 0x20;
> tm6000_set_reg(core, TM6010_REQ07_RCC_ACTIVE_VIDEO_IF, val);
>
> + tm6000_set_audio_bitrate(core, 48000);
> +
> tm6000_set_reg(core, TM6010_REQ08_R01_A_INIT, 0x80);
>
> return 0;
> diff --git a/drivers/staging/tm6000/tm6000-core.c
> b/drivers/staging/tm6000/tm6000-core.c
> index 46b9ec5..1fea5a0 100644
> --- a/drivers/staging/tm6000/tm6000-core.c
> +++ b/drivers/staging/tm6000/tm6000-core.c
> @@ -602,8 +602,17 @@ int tm6000_set_audio_bitrate(struct tm6000_core *dev,
> int bitrate)
> {
> int val;
>
> + if (dev->dev_type == TM6010) {
> + val = tm6000_get_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD, 0);
> + if (val < 0)
> + return val;
> + val = (val & 0xf0) | 0x1;
> + val = tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD, val);
> + if (val < 0)
> + return val;
> + }
> +
> val = tm6000_get_reg(dev, REQ_07_SET_GET_AVREG, 0xeb, 0x0);
> - printk("Original value=%d\n", val);
> if (val < 0)
> return val;
>
> diff --git a/drivers/staging/tm6000/tm6000-video.c
> b/drivers/staging/tm6000/tm6000-video.c
> index 34e8ef5..cc4298e 100644
> --- a/drivers/staging/tm6000/tm6000-video.c
> +++ b/drivers/staging/tm6000/tm6000-video.c
> @@ -303,6 +304,15 @@ static int copy_streams(u8 *data, unsigned long len,
> break;
> case TM6000_URB_MSG_AUDIO:
> tm6000_call_fillbuf(dev, TM6000_AUDIO, ptr,
> cpysize);
> +if (cpysize < pktsize) {
> +printk("Audio[%d] = %02x %02x %02x %02x\n",
> +cpysize,
> +ptr[cpysize],
> +ptr[cpysize+1],
> +ptr[cpysize+2],
> +ptr[cpysize+3]);
> +}
> +
> break;
> case TM6000_URB_MSG_VBI:
> /* Need some code to copy vbi buffer */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.or
Re: [PATCH 3/4] ir-core: move decoding state to ir_raw_event_ctrl
On Mon, May 03, 2010 at 05:00:05PM -0300, Mauro Carvalho Chehab wrote:
> David Härdeman wrote:
> > This patch moves the state from each raw decoder into the
> > ir_raw_event_ctrl struct.
> >
> > This allows the removal of code like this:
> >
> > spin_lock(&decoder_lock);
> > list_for_each_entry(data, &decoder_list, list) {
> > if (data->ir_dev == ir_dev)
> > break;
> > }
> > spin_unlock(&decoder_lock);
> > return data;
> >
> > which is currently run for each decoder on each event in order
> > to get the client-specific decoding state data.
> >
> > In addition, ir decoding modules and ir driver module load
> > order is now independent. Centralizing the data also allows
> > for a nice code reduction of about 30% per raw decoder as
> > client lists and client registration callbacks are no longer
> > necessary.
>
> The registration callbacks will likely still be needed by lirc,
> as you need to create/delete lirc_dev interfaces, when the module
> is registered, but I might be wrong. It would be interesting to
> add lirc_dev first, in order to be sure about the better interfaces
> for it.
Or the lirc_dev patch can add whatever interfaces it needs. Anyway, the
current interfaces are not good enough since it'll break if lirc_dev is
loaded after the hardware modules.
> Also, from one side, you reduced the code size, but, on the other hand,
> you've increased the memory usage, as now the protocol data will be
> stored even for protocols that weren't compiled/loaded.
In <4bbf3309.6020...@infradead.org>, Mauro Carvalho Chehab wrote:
>> Andy Walls wrote:
>>> Encoding pulse vs space with a negative sign, even if now hidden
>>> with macros, is still just using a sign instead of a boolean.
>>> Memory in modern computers (and now microcontrollers) is cheap and
>>> only getting cheaper. Don't give up readability, flexibility, or
>>> mainatainability, for the sake of saving memory.
>
> That was my point since the beginning: the amount of saved memory
> doesn't justify the lack of readability.
Are you worried about memory usage now?
> Probably, the code size savings are big enough to justify the runtime
> memory footprint, at least with the current decoders. Not sure how big
> this will become when we add lirc_dev and other decoders that might be
> missing.
Right now, the "reasonable default" is a user machine with one hardware
decoder and with all of the rc-core decoders loaded (cause that's how
his/her distro will set it up). For that machine, the patch will save a
lot of memory, not waste it (~380 lines less code...I'll assure you it's
a net gain).
In addition, random module load order is currently broken (try loading
decoders first and hardware later and you'll see). With this patch, it
works again.
Anyway, I'll post a new patch series this evening and then we can go
back to our regular arguing :)
--
David Härdeman
--
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 2/4] ir-core: centralize sysfs raw decoder enabling/disabling
On Mon, May 03, 2010 at 04:49:20PM -0300, Mauro Carvalho Chehab wrote:
> Hi David,
Hi, sorry for dropping off the radar...life has been hetic...daughter in
hospital (she's fine now).
> David Härdeman wrote:
> > With the current logic, each raw decoder needs to add a copy of the exact
> > same sysfs code. This is both unnecessary and also means that (re)loading
> > an IR driver after raw decoder modules have been loaded won't work as
> > expected.
> >
> > This patch moves that logic into ir-raw-event and adds a single sysfs
> > file per device.
> >
> > Reading that file returns something like:
> >
> > "rc5 [rc6] nec jvc [sony]"
> >
> > (with enabled protocols in [] brackets)
> >
> > Writing either "+protocol" or "-protocol" to that file will
> > enable or disable the according protocol decoder.
> >
> > An additional benefit is that the disabling of a decoder will be
> > remembered across module removal/insertion so a previously
> > disabled decoder won't suddenly be activated again. The default
> > setting is to enable all decoders.
> >
> > This is also necessary for the next patch which moves even more decoder
> > state into the central raw decoding structs.
>
> I liked the idea of your redesign, but I didn't like the removal of
> a per-decoder sysfs entry. As already discussed, there are cases where
> we'll need a per-decoder sysfs entry (lirc_dev is probably one of those
> cases - also Jarod's imon driver is currently implementing a modprobe
> parameter that needs to be moved to the driver).
per-decoder or per-decoder-per-receiver sysfs entries? If you want the
latter, you'll need much more code than what is currently there to not
break random module load order (which doesn't work with the current
code). Additionally, *if* imon and lirc_dev really need something like
that, those modules should carry the burden.
> So, while we can implement some core support at the raw event core, we should
> keep the decoder attributes internally inside the driver.
Why?
> So, each decoder
> may have his own code like:
>
> static struct attribute *decoder_attributes[] = {
>&dev_attr_enabled.attr,
>&dev_attr_bar1.attr,
>&dev_attr_bar2.attr,
>&dev_attr_bar3.attr,
>NULL
> };
>
> static struct attribute_group decoder_attribute_group = {
>.name = "foo_decoder",
>.attrs = decoder_attributes,
> };
>
> As the attr_enabled is common to all, maybe we can have a default enable
> code at the .h or inside the core.
Smells like lots of duplicated code with no gain for the current set of
decoders.
--
David Härdeman
--
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] IR: add core lirc device interface
On Fri, Jun 04, 2010 at 03:38:35PM -0300, Mauro Carvalho Chehab wrote: > Em 04-06-2010 12:51, Christoph Bartelmus escreveu: > > Hi Mauro, > > > > on 04 Jun 10 at 01:10, Mauro Carvalho Chehab wrote: > >> Em 03-06-2010 19:06, Jarod Wilson escreveu: > > [...] > >>> As for the compat bits... I actually pulled them out of the Fedora kernel > >>> and userspace for a while, and there were only a few people who really ran > >>> into issues with it, but I think if the new userspace and kernel are > >>> rolled > >>> out at the same time in a new distro release (i.e., Fedora 14, in our > >>> particular case), it should be mostly transparent to users. > > > >> For sure this will happen on all distros that follows upstream: they'll > >> update lirc to fulfill the minimal requirement at Documentation/Changes. > >> > >> The issue will appear only to people that manually compile kernel and lirc. > >> Those users are likely smart enough to upgrade to a newer lirc version if > >> they notice a trouble, and to check at the forums. > > > >>> Christoph > >>> wasn't a fan of the change, and actually asked me to revert it, so I'm > >>> cc'ing him here for further feedback, but I'm inclined to say that if this > >>> is the price we pay to get upstream, so be it. > > > >> I understand Christoph view, but I think that having to deal with compat > >> stuff forever is a high price to pay, as the impact of this change is > >> transitory and shouldn't be hard to deal with. > > > > I'm not against doing this change, but it has to be coordinated between > > drivers and user-space. > > Just changing lirc.h is not enough. You also have to change all user-space > > applications that use the affected ioctls to use the correct types. > > That's what Jarod did not address last time so I asked him to revert the > > change. > > For sure coordination between kernel and userspace is very important. I'm sure > that Jarod can help with this sync. Also, after having the changes implemented > on userspace, I expect one patch from you adding the minimal lirc requirement > at Documentation/Changes. > > > And I'd also like to collect all other change request to the API > > if there are any and do all changes in one go. > > You and Jarod are the most indicated people to point for such needs. Also, Jon > and David may have some comments. David (who has been absent, sorry about that, life got in the way) thinks that the lirc raw decoder should implement the minimum amount of ioctl's possible while still being usable by the lirc userspace and without going beyond being a raw pulse/space "decoder" or we'll risk having to extend the entire decoder API just to support the lirc compatability decoder. Over time, I hope that rc-core will grow it's own chardev with a clean set of ioctls (or sysfs controls, the jury hasn't returned a verdict yet). lircd can then be upgraded to support both the in-kernel native mode and the legacy lirc mode, and with time, the lirc raw decoder can be phased out. -- David Härdeman -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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 Jun 7 19:00:23 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14886:24ea80f2631f git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 4fcfa8824391ef0f9cff82122067f31c6d920921 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-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: ERRORS linux-2.6.27.44-i686: ERRORS linux-2.6.28.10-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30.10-i686: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: ERRORS linux-2.6.33-mips: ERRORS linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-powerpc64: ERRORS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: ERRORS linux-2.6.27.44-x86_64: ERRORS linux-2.6.28.10-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30.10-x86_64: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS 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: Version 2: Tentative agenda for Helsinki mini-summit
> -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Monday, June 07, 2010 3:20 PM > To: Guennadi Liakhovetski > Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org > Subject: RE: Version 2: Tentative agenda for Helsinki mini-summit > > > > On Mon, 7 Jun 2010, Hiremath, Vaibhav wrote: > > > >> > 14) V4L2 video output vs. framebuffer. Guennadi Liakhovetski. > >> > > >> [Hiremath, Vaibhav] Guennadi, > >> > >> Do you have anything in your mind on this? Are you preparing any slides > >> for this? Do you want me to have something from OMAP side which we can > >> use as a use-case? > > > > Yes, I will prepare some introduction, maybe a couple of slides. My > > impression is, that we shall be making all topics as short as possible, > > so, I'll try to make it concise, but I don't know exactly yet how much > > time we'd get. > > Concise would be good: the first day will be packed, so I prefer to have > short presentations, and a Q&A session afterwards in case there are things > that need clarification. But I think that on Tuesday we can talk a lot > more about this. I think this is a very relevant issue for embedded > systems. > > >> I can make couple of slides on this. > > > > In principle - yes, sure, I'd love you to present your use-case, but as I > > said - no idea whether we'll have time for this. So, definitely, would be > > great if you could comment on the topic, if we get time, slides would be > > great too, so, if it's not too complicated for you - please prepare them, > > but unfortunately I do not know yet whether we'll get a chance to go > > through them. In fact, I'm not quite sure how topics without an explicitly > > mentioned presentation should work - there would be some introduction in > > any case, right, Hans? Just not as long as a "proper presentation?" And > > the mentioned 10 minutes are only for the presentation, the discussion > > comes on top of that? So, I think, we should have time for your slides, > > Vaibhav, Hans can correct me if I'm wrong;) > > For simple topics a presentation is overkill and you can just say what the > status and/or plan is. For more complex issues a presentation helps to > understand the problems quicker. And yes, the discussion comes on top of > the presentation. > > The reason I want to keep the presentations short on Monday is that we > have some 15 topics or so to go through in, say, 7 hours. And of those 7 > hours one to two hours are reserved for anything to do with memory > handling. That does not leave a lot of time for the other 14 topics. > > Now, remember that on Tuesday and to a lesser extent on Wednesday we will > have more time to discuss some of these topics in more depth. And this > topic is one that deserves to be discussed more extensively. It would be > interesting to hear the views of several of the companies that have to > work with the framebuffer API: what are their experiences, ideas on how to > improve it, building a fb driver on top of a v4l driver, etc. > [Hiremath, Vaibhav] I completely aligned with this, I will prepare the slides and if we have time and need for this we can talk about it. Also I will have to prepare couple of slide presenting current status of OMAP drivers (for me it is Display Driver), should be re-used here. Thanks, Vaibhav > 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: Kernel oops with current hg (ir-sysfs.c ?)
Am 24.05.2010 17:26, schrieb Martin Dauskardt: > I guess it is a similar problem like the one that was solved a few months ago > with this patch: > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14232 > > I compiled the current v4l-dvb hg against the 2.6.32 Ubuntu 10.04 kernel > > > May 24 13:30:22 ubuntuvdr1 kernel: [5.629408] DVB: registering new > adapter (TT-Budget C-1501 PCI) > May 24 13:30:22 ubuntuvdr1 kernel: [5.646949] tda9887 3-0043: i2c i/o > error: rc == -5 (should be 4) > May 24 13:30:22 ubuntuvdr1 kernel: [5.649823] tda9887 3-0043: i2c i/o > error: rc == -5 (should be 4) > May 24 13:30:22 ubuntuvdr1 kernel: [5.666028] adapter has MAC addr = > 00:d0:5c:c6:5a:11 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692518] Registered IR keymap > rc-tt-1500 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692545] BUG: unable to handle > kernel NULL pointer dereference at (null) > May 24 13:30:22 ubuntuvdr1 kernel: [5.692554] IP: [] > ir_register_class+0x3e/0x190 [ir_core] > May 24 13:30:22 ubuntuvdr1 kernel: [5.692566] *pde = > May 24 13:30:22 ubuntuvdr1 kernel: [5.692571] Oops: [#1] SMP > May 24 13:30:22 ubuntuvdr1 kernel: [5.692575] last sysfs file: > /sys/module/ir_core/initstate > May 24 13:30:22 ubuntuvdr1 kernel: [5.692580] Modules linked in: > rc_tt_1500 tda10021 snd_hda_codec_realtek tuner_simple tuner_types tda9887 > tda8290 tuner msp3400 snd_hda_intel$ > May 24 13:30:22 ubuntuvdr1 kernel: [5.692659] > May 24 13:30:22 ubuntuvdr1 kernel: [5.692663] Pid: 375, comm: modprobe > Not tainted (2.6.32-22-generic #33-Ubuntu) M56S-S3 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692669] EIP: 0060:[] > EFLAGS: 00010246 CPU: 0 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692677] EIP is at > ir_register_class+0x3e/0x190 [ir_core] > May 24 13:30:22 ubuntuvdr1 kernel: [5.692681] EAX: EBX: f6375000 > ECX: EDX: 0100 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692686] ESI: f4fa6000 EDI: > EBP: f61d5d78 ESP: f61d5d4c > May 24 13:30:22 ubuntuvdr1 kernel: [5.692691] DS: 007b ES: 007b FS: 00d8 > GS: 00e0 SS: 0068 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692697] Process modprobe (pid: 375, > ti=f61d4000 task=f61b6680 task.ti=f61d4000) > May 24 13:30:22 ubuntuvdr1 kernel: [5.692704] Stack: > May 24 13:30:22 ubuntuvdr1 kernel: [5.692707] 0246 f825ba47 c24054e0 > f825ba47 001d5d64 0128 f4fa6000 003f > May 24 13:30:22 ubuntuvdr1 kernel: [5.692717] <0> faee9068 0027 > f4fa6000 f61d5db0 f825bb7c 009f f8ce32ef > May 24 13:30:22 ubuntuvdr1 kernel: [5.692728] <0> c0588f82 f825cc11 > 0296 f637513c f6375120 f6375000 f6827000 f4fa6000 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692741] Call Trace: > May 24 13:30:22 ubuntuvdr1 kernel: [5.692750] [] ? > __ir_input_register+0x167/0x350 [ir_core] > May 24 13:30:22 ubuntuvdr1 kernel: [5.692759] [] ? > __ir_input_register+0x167/0x350 [ir_core] > May 24 13:30:22 ubuntuvdr1 kernel: [5.692769] [] ? > __ir_input_register+0x29c/0x350 [ir_core] > May 24 13:30:22 ubuntuvdr1 kernel: [5.692779] [] ? > printk+0x1d/0x23 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692789] [] ? > budget_ci_attach+0x193/0xd80 [budget_ci] > May 24 13:30:22 ubuntuvdr1 kernel: [5.692800] [] ? > saa7146_init_one+0x7dc/0x860 [saa7146] > May 24 13:30:22 ubuntuvdr1 kernel: [5.692811] [] ? > dma_generic_alloc_coherent+0x0/0xc0 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692821] [] ? > local_pci_probe+0x13/0x20 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692827] [] ? > pci_device_probe+0x68/0x90 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692835] [] ? > really_probe+0x4d/0x140 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692843] [] ? > pm_runtime_barrier+0x4e/0xc0 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692850] [] ? > driver_probe_device+0x3c/0x60 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692857] [] ? > __driver_attach+0x81/0x90 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692864] [] ? > bus_for_each_dev+0x53/0x80 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692871] [] ? > driver_attach+0x1e/0x20 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692877] [] ? > __driver_attach+0x0/0x90 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692884] [] ? > bus_add_driver+0xd5/0x280 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692890] [] ? > pci_device_remove+0x0/0x40 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692897] [] ? > driver_register+0x6a/0x130 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692903] [] ? > __pci_register_driver+0x45/0xb0 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692913] [] ? > saa7146_register_extension+0x53/0x90 [saa7146] > May 24 13:30:22 ubuntuvdr1 kernel: [5.692923] [] ? > budget_ci_init+0xd/0xf [budget_ci] > May 24 13:30:22 ubuntuvdr1 kernel: [5.692929] [] ? > do_one_initcall+0x31/0x190 > May 24 13:30:22 ubuntuvdr1 kernel: [5.692937] [] ? > budge
Re: kernel oops with TT S2-3200
Am 23.05.2010 01:15, schrieb dave cunningham: > I'm running debian testing on an AMD Sempron box, kernel 2.6.32-3amd64, > with a TT S2-3200. > > I've been setting the box up as a Myth TV backend. > > The stock kernel drivers for the S2-3200 appear to work (to the extent > that I was able to scan for channels in Myth TV) however I was getting > errors during channel scan (fec_inner not supported in the mythtv log) > so I updated to v4l-dvb tip to see if this error disappeared. > > I now get a kernel oops on loading budget_ci as below. > > This is changeset 14873:b576509ea6d2. > > I see on the wiki that there is an hg bisect utility that I can use to > narrow down where this has been introduced. Would it be useful I do so? > > Would any more information be useful? > > > May 22 23:19:31 beta kernel: [ 98.394646] IR NEC protocol handler > initialized > May 22 23:19:31 beta kernel: [ 98.394857] saa7146: register extension > 'budget_ci dvb'. > May 22 23:19:31 beta kernel: [ 98.394966] budget_ci dvb :04:05.0: PCI > INT A -> GSI 20 (level, low) -> IRQ 20 > May 22 23:19:31 beta kernel: [ 98.395020] IRQ 20/: IRQF_DISABLED is not > guaranteed on shared IRQs > May 22 23:19:31 beta kernel: [ 98.395055] saa7146: found saa7146 @ mem > c900116f8c00 (revision 1, irq 20) (0x13c2,0x1019). > May 22 23:19:31 beta kernel: [ 98.395069] saa7146 (0): dma buffer size > 192512 > May 22 23:19:31 beta kernel: [ 98.395074] DVB: registering new adapter > (TT-Budget S2-3200 PCI) > May 22 23:19:31 beta kernel: [ 98.399843] IR RC5(x) protocol handler > initialized > May 22 23:19:31 beta kernel: [ 98.404301] IR RC6 protocol handler > initialized > May 22 23:19:31 beta kernel: [ 98.408724] IR JVC protocol handler > initialized > May 22 23:19:31 beta kernel: [ 98.413024] IR Sony protocol handler > initialized > May 22 23:19:31 beta kernel: [ 98.429164] adapter has MAC addr = > 00:d0:5c:68:2c:ca > May 22 23:19:31 beta kernel: [ 98.468015] Registered IR keymap > rc-budget-ci-old > May 22 23:19:31 beta kernel: [ 98.468261] PGD 0 > May 22 23:19:31 beta kernel: [ 98.468479] CPU 0 > May 22 23:19:31 beta kernel: [ 98.468549] Modules linked in: > rc_budget_ci_old ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder > ir_nec_decoder budget_ci(+) ir_core budget_core ttpci_eeprom dvb_core saa7146 > cryptd aes_x86_64 aes_generic xt_mac xt_TCPMSS xt_tcpudp ipt_LOG > iptable_raw xt_conntrack xt_comment iptable_nat nf_nat xt_MARK ipt_REJECT > ipt_addrtype xt_multiport iptable_mangle nf_conntrack_ipv4 > nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables fuse > nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc pppoatm > ppp_generic slhc powernow_k8 it87 hwmon_vid loop arc4 ecb ath9k ath9k_common > mac80211 ath9k_hw ath snd_hda_codec_realtek amd64_edac_mod shpchp > cfg80211 i2c_piix4 edac_core k10temp edac_mce_amd i2c_core pci_hotplug rfkill > snd_hda_intel parport_pc led_class snd_hda_codec snd_hwdep > snd_pcm_oss snd_mixer_oss snd_pcm evdev parport snd_timer snd soundcore > snd_page_alloc speedtch usbatm pcspkr atm psmouse processor serio_raw > ext3 jbd mbcache fan ide_gd_mod ata_generic > May 22 23:19:31 beta kernel: ohci_hcd ide_pci_generic ahci libata atiixp > button thermal thermal_sys r8169 mii ehci_hcd scsi_mod ide_core usbcore > nls_base [last unloaded: scsi_wait_scan] > May 22 23:19:31 beta kernel: [ 98.472002] Pid: 2746, comm: work_for_cpu Not > tainted 2.6.32-3-amd64 #1 A760G M2+ > May 22 23:19:31 beta kernel: [ 98.472002] RIP: 0010:[] > [] ir_register_class+0x4d/0x18f [ir_core] > May 22 23:19:31 beta kernel: [ 98.472002] RSP: 0018:88007cf67db0 > EFLAGS: 00010246 > May 22 23:19:31 beta kernel: [ 98.472002] RAX: RBX: > 88007c1a5400 RCX: a068ee60 > May 22 23:19:31 beta kernel: [ 98.472002] RDX: RSI: > a068e94a RDI: 88007c1a5400 > May 22 23:19:31 beta kernel: [ 98.472002] RBP: R08: > R09: 0073 > May 22 23:19:31 beta kernel: [ 98.472002] R10: R11: > 00dc R12: a06c0060 > May 22 23:19:31 beta kernel: [ 98.472002] R13: 88007cf4c000 R14: > 0286 R15: a0698ed3 > May 22 23:19:31 beta kernel: [ 98.472002] FS: 7f498d78c6f0() > GS:88000180() knlGS: > May 22 23:19:31 beta kernel: [ 98.472002] CS: 0010 DS: 0018 ES: 0018 CR0: > 8005003b > May 22 23:19:31 beta kernel: [ 98.472002] CR2: CR3: > 01001000 CR4: 06f0 > May 22 23:19:31 beta kernel: [ 98.472002] DR0: DR1: > DR2: > May 22 23:19:31 beta kernel: [ 98.472002] DR3: DR6: > 0ff0 DR7: 0400 > May 22 23:19:31 beta kernel: [ 98.472002] Process work_for_cpu (pid: 2746, > threadinfo 88007cf66000, task 88007b67cdb0) > May 2
Re: linuxtv.org Wiki pages not found by Google
On Mon, 07 Jun 2010 09:07:24 +0200, Jan-Pascal van Best wrote: Hi all, Not sure if this is the right list, but here it goes: Google does not seem to find pages in the linuxtv.org wiki. Nor does any of the other search Hi, I'm not an expert, but I read somewhere that's happening because there's to many subbranches. If there's more than tree search engines will not look for pages behind it. I know one site that dealed with it by removing index.php from the wiki path and that way allowing search engine to find the pages. Best regards, Samuel -- 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: v4l-dvb - Is it still usable for a distribution ?
On Mon, Jun 7, 2010 at 9:16 AM, Mauro Carvalho Chehab wrote: > Em 07-06-2010 08:27, v...@helmutauer.de escreveu: ... >> Another problem (after fixing the compile issues) is the IR Part of v4l-dvb >> which includes an Imon module. >> This module doesn't provide any lirc devices, so how can this oe be used as >> an IR device ? > > You don't need lirc to use imon, since it now provides a standard input/event > interface. So, the driver > currently can be used with lirc event interface, or alone. See http://wilsonet.com/jarod/imon_stuff/imon-devinput-lirc/ for the config I use w/my own imon hardware. >> Til now I am using lirc_imon which fit all my needs. > > Lirc-dev patches are currently being discussed. There are just a few > adjustments on it, in order to get it > finally merged. The kernel-userspace interface will likely need a few > changes, so you'll likely need to update > lirc after the merge. Better to follow the IR threads at linux-media ML, in > order to be in-tune with the changes. I've considered adding lirc_dev support back to the imon driver when we get it merged, but it really doesn't make a whole lot of sense, given that the imon devices do all IR decoding in hardware. As long as the keymap is complete, there's no benefit to wiring up lirc_dev vs. just using lircd's devinput access method for imon devices. -- Jarod Wilson ja...@wilsonet.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: v4l-dvb - Is it still usable for a distribution ?
Em 07-06-2010 08:27, v...@helmutauer.de escreveu: > Hello List, > > I have a Gentoo based VDR Distribution named Gen2VDR. > As the name said its main application is VDR. > Until kernel 2.6.33 I bundled the v4l-dvb drivers emerged via the gentoo > ebuild with my distribution. > Now with kernel 2.6.34 this doesn't work anymore, because v4l-dvb doesn't > compile. Douglas returned from this 2 week trip abroad and he is backporting the upstream stuff. Yesterday, he reported to me that the tree is now compiling with 2.6.34. > Another problem (after fixing the compile issues) is the IR Part of v4l-dvb > which includes an Imon module. > This module doesn't provide any lirc devices, so how can this oe be used as > an IR device ? You don't need lirc to use imon, since it now provides a standard input/event interface. So, the driver currently can be used with lirc event interface, or alone. > Til now I am using lirc_imon which fit all my needs. Lirc-dev patches are currently being discussed. There are just a few adjustments on it, in order to get it finally merged. The kernel-userspace interface will likely need a few changes, so you'll likely need to update lirc after the merge. Better to follow the IR threads at linux-media ML, in order to be in-tune with the changes. > The final question for me: > Does it make any sense anymore to stay with v4l-dvb or do I have to change to > the kernel drivers ? > The major disadvantage of the kernel drivers is the fact that I cannot switch > to newer dvb drivers, I am stuck to the ones included in the kernel. Well, this is something that you need to answer by yourself ;) I don't recommend using a random snapshot of the tree on a distro package, as regressions may happen during the development period. Also, the backports are done at best efforts. There are no warranties, no QA and generally no tests with real hardware when a backport is done. So, while we hope that the backport will work, you may have a bug introduced on the backport stuff that may affect your card, not present upstream. IMHO, the better is to just upgrade to the next stable kernel. Another alternative is to manually apply on your distro the patches that you need there. All patches with c/c to sta...@kernel.org are bug fixes that needs to be backported to older (stable) kernels. So, a good hint is to check for those stable patches. Unfortunately, not all developers remind to add a c/c to stable. I try to do my best to re-tag those emails when sending the patches upstream, but I generally opt to trust on the developers, since a fix may apply only at the latest upstream kernel. 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 2.6.34] schedule inside spin_lock_irqsave
On Sun, Jun 06, 2010 at 07:51:56PM +0200, Jiri Slaby wrote:
> On 06/06/2010 02:43 PM, Richard Zidlicky wrote:
> > Hi,
> >
> > I have done a minimaly invasive patch for the stable 2.6.34 kernel and
> > stress-tested
> > it for many hours, definitely seems to improve the behaviour.
> >
> > I have left out your beautification suggestion for now, want to do more
> > playing with
> > other aspects of the driver. There still seem to be issues when the device
> > is unplugged
> > while in use and such.
> >
> > --- linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c.rz2010-06-03
> > 21:58:11.0 +0200
> > +++ linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c 2010-06-04
> > 23:00:35.0 +0200
> > @@ -1100,31 +1100,26 @@
> > *
> > * @return pointer to descriptor on success, NULL on error.
> > */
> > -struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t
> > *coredev)
> > +
> > +struct smscore_buffer_t *get_entry(void)
> > {
> > struct smscore_buffer_t *cb = NULL;
> > unsigned long flags;
> >
> > - DEFINE_WAIT(wait);
> > -
> > spin_lock_irqsave(&coredev->bufferslock, flags);
>
> Sorry, maybe I'm just blind, but where is 'coredev' defined in this
> scope? You probably forgot to pass it to get_entry?
>
> How could this be compiled? Is there coredev defined globally?
good catch. I think it failed and despite a different kernel id the old module
was
loaded.
Here is the new version, this time lightly tested
--- linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c.rz2010-06-03
21:58:11.0 +0200
+++ linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c 2010-06-07
14:32:06.0 +0200
@@ -1100,31 +1100,26 @@
*
* @return pointer to descriptor on success, NULL on error.
*/
-struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+
+struct smscore_buffer_t *get_entry(struct smscore_device_t *coredev)
{
struct smscore_buffer_t *cb = NULL;
unsigned long flags;
- DEFINE_WAIT(wait);
-
spin_lock_irqsave(&coredev->bufferslock, flags);
-
- /* This function must return a valid buffer, since the buffer list is
-* finite, we check that there is an available buffer, if not, we wait
-* until such buffer become available.
-*/
-
- prepare_to_wait(&coredev->buffer_mng_waitq, &wait, TASK_INTERRUPTIBLE);
-
- if (list_empty(&coredev->buffers))
- schedule();
-
- finish_wait(&coredev->buffer_mng_waitq, &wait);
-
+ if (!list_empty(&coredev->buffers)) {
cb = (struct smscore_buffer_t *) coredev->buffers.next;
list_del(&cb->entry);
-
+ }
spin_unlock_irqrestore(&coredev->bufferslock, flags);
+ return cb;
+}
+
+struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+{
+ struct smscore_buffer_t *cb = NULL;
+
+ wait_event(coredev->buffer_mng_waitq, (cb = get_entry(coredev)));
return cb;
}
Richard
--
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] libv4l1: move VIDIOCGAUDIO and VIDIOCSAUDIO to libv4l1
Hi,
See comments inline.
On 06/07/2010 11:50 AM, huzai...@redhat.com wrote:
From: Huzaifa Sidhpurwala
move VIDIOCGAUDIO and VIDIOCSAUDIO to libv4l1
Signed-of-by: Huzaifa Sidhpurwala
---
lib/libv4l1/libv4l1-priv.h |7 ++
lib/libv4l1/libv4l1.c | 160
2 files changed, 167 insertions(+), 0 deletions(-)
diff --git a/lib/libv4l1/libv4l1-priv.h b/lib/libv4l1/libv4l1-priv.h
index 11f4fd0..11ee57a 100644
--- a/lib/libv4l1/libv4l1-priv.h
+++ b/lib/libv4l1/libv4l1-priv.h
@@ -60,6 +60,13 @@ extern FILE *v4l1_log_file;
#define min(a, b) (((a)< (b)) ? (a) : (b))
#endif
+#define DIV_ROUND_CLOSEST(x, divisor)( \
+{ \
+ typeof(divisor) __divisor = divisor;\
+ (((x) + ((__divisor) / 2)) / (__divisor)); \
+} \
+)
+
struct v4l1_dev_info {
int fd;
int flags;
diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c
index 2981c40..263d564 100644
--- a/lib/libv4l1/libv4l1.c
+++ b/lib/libv4l1/libv4l1.c
@@ -233,6 +233,59 @@ static int v4l1_set_format(int index, unsigned int width,
return result;
}
+static int set_v4l_control(int fd, int cid, int value)
+{
+ struct v4l2_queryctrl qctrl2;
+ struct v4l2_control ctrl2;
+ int result;
+
+ qctrl2.id = cid;
+ result = v4l2_ioctl(fd, VIDIOC_QUERYCTRL,&qctrl2);
+ if (result< 0)
+ return 0;
+ if (result == 0&&
+ !(qctrl2.flags& V4L2_CTRL_FLAG_DISABLED)&&
+ !(qctrl2.flags& V4L2_CTRL_FLAG_GRABBED)) {
+ if (value< 0)
+ value = 0;
+ if (value> 65535)
+ value = 65535;
+ if (value&& qctrl2.type == V4L2_CTRL_TYPE_BOOLEAN)
+ value = 65535;
+ ctrl2.id = qctrl2.id;
+ ctrl2.value =
+ (value * (qctrl2.maximum - qctrl2.minimum)
+ + 32767)
+ / 65535;
+ ctrl2.value += qctrl2.minimum;
+ result = v4l2_ioctl(fd, VIDIOC_S_CTRL,&ctrl2);
+ }
+ return 0;
+}
+
+static int get_v4l_control(int fd, int cid)
+{
+ struct v4l2_queryctrl qctrl2;
+ struct v4l2_control ctrl2;
+ int result;
+
+ qctrl2.id = cid;
+ result = v4l2_ioctl(fd, VIDIOC_QUERYCTRL,&qctrl2);
+ if (result< 0)
+ return 0;
+ if (result == 0&& !(qctrl2.flags& V4L2_CTRL_FLAG_DISABLED)) {
+ ctrl2.id = qctrl2.id;
+ result = v4l2_ioctl(fd, VIDIOC_G_CTRL,&ctrl2);
+ if (result< 0)
+ return 0;
+
+ return DIV_ROUND_CLOSEST((ctrl2.value-qctrl2.minimum) * 65535,
+ qctrl2.maximum - qctrl2.minimum);
+ }
+ return 0;
+}
+
+
These 2 functions are already present in libv4l2, they are called
v4l2_set_control and v4l2_get_control resp.
Regards,
Hans
static void v4l1_find_min_and_max_size(int index, struct v4l2_format *fmt2)
{
int i;
@@ -983,6 +1036,113 @@ int v4l1_ioctl(int fd, unsigned long int request, ...)
break;
}
+
+ case VIDIOCSAUDIO: {
+ struct video_audio *aud = arg;
+ struct v4l2_audio aud2 = { 0, };
+ struct v4l2_tuner tun2 = { 0, };
+
+ aud2.index = aud->audio;
+ result = v4l2_ioctl(fd, VIDIOC_S_AUDIO,&aud2);
+ if (result< 0)
+ break;
+
+ set_v4l_control(fd, V4L2_CID_AUDIO_VOLUME,
+ aud->volume);
+ set_v4l_control(fd, V4L2_CID_AUDIO_BASS,
+ aud->bass);
+ set_v4l_control(fd, V4L2_CID_AUDIO_TREBLE,
+ aud->treble);
+ set_v4l_control(fd, V4L2_CID_AUDIO_BALANCE,
+ aud->balance);
+ set_v4l_control(fd, V4L2_CID_AUDIO_MUTE,
+ !!(aud->flags& VIDEO_AUDIO_MUTE));
+
+ result = v4l2_ioctl(fd, VIDIOC_G_TUNER,&tun2);
+ if (result< 0)
+ break;
+ if (result == 0) {
+ switch (aud->mode) {
+ default:
+ case VIDEO_SOUND_MONO:
+ case VIDEO_SOUND_LANG1:
+ tun2.audmode = V4L2_TUNER_MODE_MONO;
+ break;
+ case VIDEO_SOUND_STEREO:
+ tun2.audmode = V4L2_TUNER_MODE_STEREO;
+ break;
+ case VIDEO_SOUND_LANG2:
+ tun2.audmode = V4L2_TUNER_MODE_LANG2;
+ break;
+ }
+ result = v4l2_ioctl(fd, VIDIOC_S_TUNER,&
v4l-dvb - Is it still usable for a distribution ?
Hello List, I have a Gentoo based VDR Distribution named Gen2VDR. As the name said its main application is VDR. Until kernel 2.6.33 I bundled the v4l-dvb drivers emerged via the gentoo ebuild with my distribution. Now with kernel 2.6.34 this doesn't work anymore, because v4l-dvb doesn't compile. Another problem (after fixing the compile issues) is the IR Part of v4l-dvb which includes an Imon module. This module doesn't provide any lirc devices, so how can this oe be used as an IR device ? Til now I am using lirc_imon which fit all my needs. The final question for me: Does it make any sense anymore to stay with v4l-dvb or do I have to change to the kernel drivers ? The major disadvantage of the kernel drivers is the fact that I cannot switch to newer dvb drivers, I am stuck to the ones included in the kernel. Any comments are very welcome Helmut Auer -- 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] libv4l1: move VIDIOCGVBIFMT and VIDIOCSVBIFMT into libv4l1
From: Huzaifa Sidhpurwala
move VIDIOCGVBIFMT and VIDIOCSVBIFMT into libv4l1
Signed-of-by: Huzaifa Sidhpurwala
---
lib/libv4l1/libv4l1.c | 65 +
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c
index 263d564..6d6caa6 100644
--- a/lib/libv4l1/libv4l1.c
+++ b/lib/libv4l1/libv4l1.c
@@ -1143,6 +1143,71 @@ int v4l1_ioctl(int fd, unsigned long int request, ...)
}
+ case VIDIOCSVBIFMT: {
+ struct vbi_format *fmt = arg;
+ struct v4l2_format fmt2;
+
+ if (VIDEO_PALETTE_RAW != fmt->sample_format) {
+ result = -EINVAL;
+ break;
+ }
+
+ fmt2.type = V4L2_BUF_TYPE_VBI_CAPTURE;
+ fmt2.fmt.vbi.samples_per_line = fmt->samples_per_line;
+ fmt2.fmt.vbi.sampling_rate= fmt->sampling_rate;
+ fmt2.fmt.vbi.sample_format= V4L2_PIX_FMT_GREY;
+ fmt2.fmt.vbi.start[0] = fmt->start[0];
+ fmt2.fmt.vbi.count[0] = fmt->count[0];
+ fmt2.fmt.vbi.start[1] = fmt->start[1];
+ fmt2.fmt.vbi.count[1] = fmt->count[1];
+ fmt2.fmt.vbi.flags= fmt->flags;
+
+ result = v4l2_ioctl(fd, VIDIOC_TRY_FMT, fmt2);
+ if (result < 0)
+ break;
+
+ if (fmt2.fmt.vbi.samples_per_line != fmt->samples_per_line ||
+ fmt2.fmt.vbi.sampling_rate!= fmt->sampling_rate||
+ fmt2.fmt.vbi.sample_format!= V4L2_PIX_FMT_GREY ||
+ fmt2.fmt.vbi.start[0] != fmt->start[0] ||
+ fmt2.fmt.vbi.count[0] != fmt->count[0] ||
+ fmt2.fmt.vbi.start[1] != fmt->start[1] ||
+ fmt2.fmt.vbi.count[1] != fmt->count[1] ||
+ fmt2.fmt.vbi.flags!= fmt->flags) {
+ result = -EINVAL;
+ break;
+ }
+ result = v4l2_ioctl(fd, VIDIOC_S_FMT, fmt2);
+
+ }
+
+ case VIDIOCGVBIFMT: {
+ struct vbi_format *fmt = arg;
+ struct v4l2_format fmt2 = { 0, };
+
+ fmt2.type = V4L2_BUF_TYPE_VBI_CAPTURE;
+ result = v4l2_ioctl(fd, VIDIOC_G_FMT, &fmt2);
+
+ if (result < 0)
+ break;
+
+ if (fmt2.fmt.vbi.sample_format != V4L2_PIX_FMT_GREY) {
+ result = -EINVAL;
+ break;
+ }
+
+ fmt->samples_per_line = fmt2.fmt.vbi.samples_per_line;
+ fmt->sampling_rate= fmt2.fmt.vbi.sampling_rate;
+ fmt->sample_format= VIDEO_PALETTE_RAW;
+ fmt->start[0] = fmt2.fmt.vbi.start[0];
+ fmt->count[0] = fmt2.fmt.vbi.count[0];
+ fmt->start[1] = fmt2.fmt.vbi.start[1];
+ fmt->count[1] = fmt2.fmt.vbi.count[1];
+ fmt->flags= fmt2.fmt.vbi.flags & 0x03;
+
+ break;
+ }
+
default:
/* Pass through libv4l2 for applications which are using v4l2
through
libv4l1 (this can happen with the v4l1compat.so wrapper
preloaded */
--
1.6.6.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
Re: question about v4l2_subdev
Hi, Look at drivers/media/video/cafe_ccic.c And examine cafe_pci_probe() and the definition and use of the sensor_call() macro. Also note $ grep -Ril ov7670 drivers/media/video/* will show you in what drivers, the ov7670 might be used. I had a look at cafe_ccic.c and also at vpif_capture.c. I tried to use "v4l2_i2c_new_subdev_board", but at boot time I have the following error: i2c i2c-0: Failed to register i2c client ov2640 at 0x30 (-16) I don't understand where it could come from, I pass the proper i2c_board_info struct, and it seems to check the proper i2c address, since it is not working. Basically I do like cafe_ccic.c execpt that I use the v4l2_i2c_new_subdev_board instead of v4l2_i2c_new_subdev... Any idea why I can't detect the sensor here? Regards, Sedji -- 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] libv4l1: move VIDIOCGAUDIO and VIDIOCSAUDIO to libv4l1
From: Huzaifa Sidhpurwala
move VIDIOCGAUDIO and VIDIOCSAUDIO to libv4l1
Signed-of-by: Huzaifa Sidhpurwala
---
lib/libv4l1/libv4l1-priv.h |7 ++
lib/libv4l1/libv4l1.c | 160
2 files changed, 167 insertions(+), 0 deletions(-)
diff --git a/lib/libv4l1/libv4l1-priv.h b/lib/libv4l1/libv4l1-priv.h
index 11f4fd0..11ee57a 100644
--- a/lib/libv4l1/libv4l1-priv.h
+++ b/lib/libv4l1/libv4l1-priv.h
@@ -60,6 +60,13 @@ extern FILE *v4l1_log_file;
#define min(a, b) (((a) < (b)) ? (a) : (b))
#endif
+#define DIV_ROUND_CLOSEST(x, divisor)( \
+{ \
+ typeof(divisor) __divisor = divisor;\
+ (((x) + ((__divisor) / 2)) / (__divisor)); \
+} \
+)
+
struct v4l1_dev_info {
int fd;
int flags;
diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c
index 2981c40..263d564 100644
--- a/lib/libv4l1/libv4l1.c
+++ b/lib/libv4l1/libv4l1.c
@@ -233,6 +233,59 @@ static int v4l1_set_format(int index, unsigned int width,
return result;
}
+static int set_v4l_control(int fd, int cid, int value)
+{
+ struct v4l2_queryctrl qctrl2;
+ struct v4l2_control ctrl2;
+ int result;
+
+ qctrl2.id = cid;
+ result = v4l2_ioctl(fd, VIDIOC_QUERYCTRL, &qctrl2);
+ if (result < 0)
+ return 0;
+ if (result == 0 &&
+ !(qctrl2.flags & V4L2_CTRL_FLAG_DISABLED) &&
+ !(qctrl2.flags & V4L2_CTRL_FLAG_GRABBED)) {
+ if (value < 0)
+ value = 0;
+ if (value > 65535)
+ value = 65535;
+ if (value && qctrl2.type == V4L2_CTRL_TYPE_BOOLEAN)
+ value = 65535;
+ ctrl2.id = qctrl2.id;
+ ctrl2.value =
+ (value * (qctrl2.maximum - qctrl2.minimum)
+ + 32767)
+ / 65535;
+ ctrl2.value += qctrl2.minimum;
+ result = v4l2_ioctl(fd, VIDIOC_S_CTRL, &ctrl2);
+ }
+ return 0;
+}
+
+static int get_v4l_control(int fd, int cid)
+{
+ struct v4l2_queryctrl qctrl2;
+ struct v4l2_control ctrl2;
+ int result;
+
+ qctrl2.id = cid;
+ result = v4l2_ioctl(fd, VIDIOC_QUERYCTRL, &qctrl2);
+ if (result < 0)
+ return 0;
+ if (result == 0 && !(qctrl2.flags & V4L2_CTRL_FLAG_DISABLED)) {
+ ctrl2.id = qctrl2.id;
+ result = v4l2_ioctl(fd, VIDIOC_G_CTRL, &ctrl2);
+ if (result < 0)
+ return 0;
+
+ return DIV_ROUND_CLOSEST((ctrl2.value-qctrl2.minimum) * 65535,
+ qctrl2.maximum - qctrl2.minimum);
+ }
+ return 0;
+}
+
+
static void v4l1_find_min_and_max_size(int index, struct v4l2_format *fmt2)
{
int i;
@@ -983,6 +1036,113 @@ int v4l1_ioctl(int fd, unsigned long int request, ...)
break;
}
+
+ case VIDIOCSAUDIO: {
+ struct video_audio *aud = arg;
+ struct v4l2_audio aud2 = { 0, };
+ struct v4l2_tuner tun2 = { 0, };
+
+ aud2.index = aud->audio;
+ result = v4l2_ioctl(fd, VIDIOC_S_AUDIO, &aud2);
+ if (result < 0)
+ break;
+
+ set_v4l_control(fd, V4L2_CID_AUDIO_VOLUME,
+ aud->volume);
+ set_v4l_control(fd, V4L2_CID_AUDIO_BASS,
+ aud->bass);
+ set_v4l_control(fd, V4L2_CID_AUDIO_TREBLE,
+ aud->treble);
+ set_v4l_control(fd, V4L2_CID_AUDIO_BALANCE,
+ aud->balance);
+ set_v4l_control(fd, V4L2_CID_AUDIO_MUTE,
+ !!(aud->flags & VIDEO_AUDIO_MUTE));
+
+ result = v4l2_ioctl(fd, VIDIOC_G_TUNER, &tun2);
+ if (result < 0)
+ break;
+ if (result == 0) {
+ switch (aud->mode) {
+ default:
+ case VIDEO_SOUND_MONO:
+ case VIDEO_SOUND_LANG1:
+ tun2.audmode = V4L2_TUNER_MODE_MONO;
+ break;
+ case VIDEO_SOUND_STEREO:
+ tun2.audmode = V4L2_TUNER_MODE_STEREO;
+ break;
+ case VIDEO_SOUND_LANG2:
+ tun2.audmode = V4L2_TUNER_MODE_LANG2;
+ break;
+ }
+ result = v4l2_ioctl(fd, VIDIOC_S_TUNER, &tun2);
+ }
+ break;
+ }
+
+ case VIDIOCGAUDIO: {
+ int i;
+ struct video_audio *aud = arg;
+ struct v4l2_queryctrl qctrl2;
+
RE: Version 2: Tentative agenda for Helsinki mini-summit
> On Mon, 7 Jun 2010, Hiremath, Vaibhav wrote: > >> > 14) V4L2 video output vs. framebuffer. Guennadi Liakhovetski. >> > >> [Hiremath, Vaibhav] Guennadi, >> >> Do you have anything in your mind on this? Are you preparing any slides >> for this? Do you want me to have something from OMAP side which we can >> use as a use-case? > > Yes, I will prepare some introduction, maybe a couple of slides. My > impression is, that we shall be making all topics as short as possible, > so, I'll try to make it concise, but I don't know exactly yet how much > time we'd get. Concise would be good: the first day will be packed, so I prefer to have short presentations, and a Q&A session afterwards in case there are things that need clarification. But I think that on Tuesday we can talk a lot more about this. I think this is a very relevant issue for embedded systems. >> I can make couple of slides on this. > > In principle - yes, sure, I'd love you to present your use-case, but as I > said - no idea whether we'll have time for this. So, definitely, would be > great if you could comment on the topic, if we get time, slides would be > great too, so, if it's not too complicated for you - please prepare them, > but unfortunately I do not know yet whether we'll get a chance to go > through them. In fact, I'm not quite sure how topics without an explicitly > mentioned presentation should work - there would be some introduction in > any case, right, Hans? Just not as long as a "proper presentation?" And > the mentioned 10 minutes are only for the presentation, the discussion > comes on top of that? So, I think, we should have time for your slides, > Vaibhav, Hans can correct me if I'm wrong;) For simple topics a presentation is overkill and you can just say what the status and/or plan is. For more complex issues a presentation helps to understand the problems quicker. And yes, the discussion comes on top of the presentation. The reason I want to keep the presentations short on Monday is that we have some 15 topics or so to go through in, say, 7 hours. And of those 7 hours one to two hours are reserved for anything to do with memory handling. That does not leave a lot of time for the other 14 topics. Now, remember that on Tuesday and to a lesser extent on Wednesday we will have more time to discuss some of these topics in more depth. And this topic is one that deserves to be discussed more extensively. It would be interesting to hear the views of several of the companies that have to work with the framebuffer API: what are their experiences, ideas on how to improve it, building a fb driver on top of a v4l driver, etc. 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: Version 2: Tentative agenda for Helsinki mini-summit
On Mon, 7 Jun 2010, Hiremath, Vaibhav wrote: > > 14) V4L2 video output vs. framebuffer. Guennadi Liakhovetski. > > > [Hiremath, Vaibhav] Guennadi, > > Do you have anything in your mind on this? Are you preparing any slides > for this? Do you want me to have something from OMAP side which we can > use as a use-case? Yes, I will prepare some introduction, maybe a couple of slides. My impression is, that we shall be making all topics as short as possible, so, I'll try to make it concise, but I don't know exactly yet how much time we'd get. > I can make couple of slides on this. In principle - yes, sure, I'd love you to present your use-case, but as I said - no idea whether we'll have time for this. So, definitely, would be great if you could comment on the topic, if we get time, slides would be great too, so, if it's not too complicated for you - please prepare them, but unfortunately I do not know yet whether we'll get a chance to go through them. In fact, I'm not quite sure how topics without an explicitly mentioned presentation should work - there would be some introduction in any case, right, Hans? Just not as long as a "proper presentation?" And the mentioned 10 minutes are only for the presentation, the discussion comes on top of that? So, I think, we should have time for your slides, Vaibhav, Hans can correct me if I'm wrong;) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 2: Tentative agenda for Helsinki mini-summit
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Hans Verkuil > Sent: Sunday, May 30, 2010 1:46 PM > To: linux-media@vger.kernel.org > Subject: Version 2: Tentative agenda for Helsinki mini-summit > > Hi all, > > This is the second version of a tentative agenda for the Helsinki mini- > summit > on June 14-16. > > Please reply to this thread if you have comments or want to add topics. > > If you want to attend the summit then contact Sakari Ailus > (sakari.ai...@maxwell.research.nokia.com). We are very full already (over 20 > attendees), so I'm not sure if there is still room left. > > The overall layout of the summit is to use the first day to go through all > topics and either come to a conclusion quickly for the 'simple' topics, or > discuss enough so that everyone understands the problem for the more complex > issues. > > The second day will be used for in-depth discussions on those complex topics > and on the third day we will go through all topics again and translate the > discussions into something concrete like a time-line, action items, etc. > > We have a lot to discuss, so we almost certainly have to split the second > day > into two tracks, each discussing different topics. If we do split up, then > one > track will touch on the videobuf-related topics and the other on the > remaining > topics. > > The first day will also feature a few short presentations on various topics. > Presentations shouldn't be longer than, say, 10 minutes tops. Please keep > them > as short and to the point as possible. These presentations are meant to get > everyone up to speed quickly. Most of us have an extensive background in > video > hardware and the v4l subsystem, so you don't need to spend time explaining > things. > > After each topic I've put the names of the main developers active in that > area. > If you see your name, then make sure you know the status of that topic so > you > can explain it to everyone else. If I think it warrants a presentation, then > I > will mention that. Of course, if you disagree, or want/don't want to do a > presentation then just say so. It's a tentative agenda only. > > The topics below are in no particular order except for the first one. I am > very pleased that Qualcomm has joined this project so I think it would be > nice to start the meeting off with a presentation on their HW architecture. > > 1) Presentation on the Qualcomm video hw architecture. Most of us have no >experience with Qualcomm hardware, so I've asked Jeff Zhong to give a > short >overview of their video hardware. > > 2) Removal of V4L1: status of driver conversion in the kernel, status of >moving v4l1->v4l2 conversion into libv4l1. What needs to be done, when >will it be done and who will do it. Driver conversion: Hans Verkuil, >libv4l1 conversion: Hans de Goede. > > 3) videobuf/videobuf2: what are the shortcomings, what are the requirements > for >a 'proper' videobuf implementation, can the existing videobuf be fixed or > do >we need a videobuf2. If the latter, what would be needed to convert > existing >drivers over to a videobuf2. Related topics (custom/pluggable allocators, >out-of-order buffer dequeuing and per-buffer wait queues) will also be > part >of this topic. >Laurent Pinchart and Pawel Osciak with presentations. > > 4) Multi-planar support. Pawel Osciak. > > 5) Media Controller Roadmap. Laurent Pinchart has a presentation. > > 6) TO DO list regarding V4L2 core framework including the new control > framework. >Hans Verkuil. Will be a presentation. > > 7) Status of the Texas Instruments drivers: omapX (Laurent Pinchart/Hiremath > Vaibhav) >and DM (Sergio Aguirre). Probably should be a short presentation. > > 8) soc-camera status. Particularly with regards to the remaining soc-camera >dependencies in sensor drivers. Guennadi Liakhovetski. > > 9) Driver compliance. We need a framework for V4L2 driver compliance. Hans >Verkuil. > > 10) Discuss list of 'reference' programs to test against. Mauro Carvalho > Chehab. > > 11) Adopting old V4L1 programs and converting to V4L2. Hans de Goede? > > 12) Status of intel drivers. Xiaolin Zhang. > > 13) Remote Controllers. Presentation by Mauro Carvalho Chehab. > > 14) V4L2 video output vs. framebuffer. Guennadi Liakhovetski. > [Hiremath, Vaibhav] Guennadi, Do you have anything in your mind on this? Are you preparing any slides for this? Do you want me to have something from OMAP side which we can use as a use-case? I can make couple of slides on this. Thanks, Vaibhav > 15) A processing plugin API for libv4l. Hans de Goede. > See: http://www.mail-archive.com/linux- > me...@vger.kernel.org/msg18993.html > > It is my understanding that we will also have X11 and gstreamer experts on > hand. > Topics relating to that are welcome. > > During the memory handling brainstorming session earlier t
Re: [PATCH] libv4l1: move VIDIOCCAPTURE to libv4l1
Hi,
Looks good, applied
Thanks!
Regards,
Hans
On 06/04/2010 09:40 AM, huzai...@redhat.com wrote:
From: Huzaifa Sidhpurwala
move VIDIOCCAPTURE to libv4l1
Signed-of-by: Huzaifa Sidhpurwala
---
lib/libv4l1/libv4l1.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c
index 579f13b..2981c40 100644
--- a/lib/libv4l1/libv4l1.c
+++ b/lib/libv4l1/libv4l1.c
@@ -967,6 +967,22 @@ int v4l1_ioctl(int fd, unsigned long int request, ...)
break;
}
+
+ case VIDIOCCAPTURE: {
+ int *on = arg;
+ enum v4l2_buf_type captype = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+
+ if (0 == *on) {
+ /* dirty hack time. But v4l1 has no STREAMOFF
+ * equivalent in the API, and this one at
+ * least comes close ... */
+ v4l2_ioctl(fd, VIDIOC_STREAMOFF,&captype);
+ }
+
+ result = v4l2_ioctl(fd, VIDIOC_OVERLAY, on);
+
+ break;
+ }
default:
/* Pass through libv4l2 for applications which are using v4l2
through
libv4l1 (this can happen with the v4l1compat.so wrapper
preloaded */
--
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] libv4l1: move VIDIOCGFREQ and VIDIOCSFREQ to libv4l1
Hi,
Looks good, applied
Thanks!
Regards,
Hans
On 06/04/2010 09:23 AM, huzai...@redhat.com wrote:
From: Huzaifa Sidhpurwala
move VIDIOCGFREQ and VIDIOCSFREQ to libv4l1
Signed-of-by: Huzaifa Sidhpurwala
---
lib/libv4l1/libv4l1.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/lib/libv4l1/libv4l1.c b/lib/libv4l1/libv4l1.c
index 081ed0a..579f13b 100644
--- a/lib/libv4l1/libv4l1.c
+++ b/lib/libv4l1/libv4l1.c
@@ -939,6 +939,34 @@ int v4l1_ioctl(int fd, unsigned long int request, ...)
break;
}
+ case VIDIOCSFREQ: {
+ unsigned long *freq = arg;
+ struct v4l2_frequency freq2 = { 0, };
+
+ result = v4l2_ioctl(fd, VIDIOC_G_FREQUENCY,&freq2);
+ if (result< 0)
+ break;
+
+ freq2.frequency = *freq;
+
+ result = v4l2_ioctl(fd, VIDIOC_S_FREQUENCY,&freq2);
+
+ break;
+ }
+
+ case VIDIOCGFREQ: {
+ unsigned long *freq = arg;
+ struct v4l2_frequency freq2 = { 0, };
+
+ freq2.tuner = 0;
+ result = v4l2_ioctl(fd, VIDIOC_G_FREQUENCY,&freq2);
+ if (result< 0)
+ break;
+ if (0 == result)
+ *freq = freq2.frequency;
+
+ break;
+ }
default:
/* Pass through libv4l2 for applications which are using v4l2
through
libv4l1 (this can happen with the v4l1compat.so wrapper
preloaded */
--
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
Is anybody working on TechniSat CableStar Combo HD CI USB device?
This is the device: http://www.technisat.com/index9332.html?nav=PC_products,en,76-229 lsusb: Bus 001 Device 005: ID 14f7:0003 on the card is a Micronas DRX 3913 JKA2 which is a combined analog cable, DVB-C and DVB-T Demodulator. best hit I can get with google is http://www.tridentmicro.com/producttree/tv/dtv/drx/drx-39xyk/ any chance this device is supported soon? Anything i can do to get this going? -- 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
linuxtv.org Wiki pages not found by Google
Hi all, Not sure if this is the right list, but here it goes: Google does not seem to find pages in the linuxtv.org wiki. Nor does any of the other search engines I've tried. It seems indexers are blocker by robots.txt: User-agent: * Disallow: /cgi-bin/ Disallow: /hg/ Disallow: /git/ Disallow: /wiki/ Disallow: /irc/ Disallow: /irc/linuxtv/ Disallow: /irc/v4l/ I would think information in the wiki (such as on a DVB-C USB box I'm researching, http://www.linuxtv.org/wiki/index.php/TechniSat_CableStar_Combo_HD_CI ) should be findable by search engines! Could the "Disallow: /wiki/" line please be removed from robots.txt? Cheers Jan-Pascal -- 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
