Re: RFC: exposing controls in sysfs
On Wednesday 07 April 2010 00:39:20 Hans Verkuil wrote:
> On Tuesday 06 April 2010 17:16:17 Mike Isely wrote:
> > On Tue, 6 Apr 2010, Laurent Pinchart wrote:
> >
> > > Hi Andy,
> > >
> > > On Tuesday 06 April 2010 13:06:18 Andy Walls wrote:
> > > > On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote:
> > >
> > > [snip]
> > >
> > > > > Again, I still don't know whether we should do this. It is dangerously
> > > > > seductive because it would be so trivial to implement.
> > > >
> > > > It's like watching ships run aground on a shallow sandbar that all the
> > > > locals know about. The waters off of 'Point /sys' are full of usability
> > > > shipwrecks. I don't know if it's some siren's song, the lack of a light
> > > > house, or just strange currents that deceive even seasoned
> > > > navigators
> > > >
> > > > Let the user run 'v4l2-ctl -d /dev/videoN -L' to learn about the control
> > > > metatdata. It's not as easy as typing 'cat', but the user base using
> > > > sysfs in an interactive shell or shell script should also know how to
> > > > use v4l2-ctl. In embedded systems, the final system deployment should
> > > > not need the control metadata available from sysfs in a command shell
> > > > anyway.
> > >
> > > I fully agree with this. If we push the idea one step further, why do we
> > > need
> > > to expose controls in sysfs at all ?
> >
> > I have found it useful to have the sysfs interface within the pvrusb2
> > driver.
> >
> > If it is going to take a lot of work to specifically craft a sysfs
> > interface that exports the V4L API, then it will probably be a pain to
> > maintain going forward. By "a lot of work" I mean that each V4L API
> > function would have to be explicitly coded for in this interface, thus
> > as the V4L API evolves over time then extra work must be expended each
> > time to keep the sysfs interface in step. If that is to be the case
> > then it may not be worth it.
>
> No, that is no work at all. For all practical purposes there are two objects
> (OK, really three, but the node object is just internal). The first object
> is the control handler, the second is the control object. Handlers have
> controls. Handlers can also inherit controls from other handlers. If they
> already had the same control, then they effectively override the inherited
> control. Controls can also be private to a handler, i.e. they will never be
> inherited by other handlers.
>
> Sound familiar? It's your basic C++ class inheritance scheme with public
> and private fields (or controls in this case).
>
> The sysfs implementation is just bolted on top of this: each video_device
> struct is associated with a control handler and sysfs will expose all controls
> that that handler references.
>
> You can take a look at the header of the control framework:
>
> http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/raw-file/bf7cd2fb7a35/linux/include/media/v4l2-ctrls.h
>
>
>
> It would be trivial to add e.g. a V4L2 control class that could be used
> to expose all sorts of V4L2 functionality to sysfs. It would be handled
> differently in that you don't want to expose those through VIDIOC_QUERYCTRL
> and friends, just to sysfs. Heck, it could be implemented almost completely
> transparently from drivers. For example, an 'echo 1 >/sys//v4l2_input'
> could be converted automatically to a VIDIOC_S_INPUT command that's issued
> to the driver. Similar to what you did in pvrusb2, except you went the other
> way around: ioctls are converted to controls. That is not feasible, though,
> since you do not want to completely redo all drivers.
>
> There are definitely some snags, but the basic premise is sound.
>
> Of course, just the fact that you can easily do something does not mean that
> you should. The first version of the framework will not contain any sysfs. It
> is clear that the last word has not been said on this. It's not a big deal,
> sysfs was just an add-on and not part of the core.
>
> But having it in the kernel will make it a nice foundation on which to
> experiment.
>
> Just a thought experiment: take VIDIOC_S_FREQUENCY. The struct has three
> fields: tuner, type, frequency. So that's a cluster of three controls. So you
> would need a 's_ctrl' function like this:
>
> switch (id) {
> /* handle the frequency cluster */
> case V4L2_CID_V4L_FREQ_TUNER:
> struct v4l2_frequency f;
> f.tuner = freq_tuner->cur.val;
> f.type = freq_type->cur.val;
> f.frequency = freq_freq->cur.val;
> return vdev->ioctl_ops->s_frequency(&f);
> }
>
> Pseudo-code, of course, and there are some little things like the 'file' and
> 'fh'
> args to s_frequency, but you could use the framework to make a very clean
> implementation of this. Especially since the framework supports 'clustering'
> of
> controls. Effectively creating a single composite control from the point of
> view
> of the driver. Hmm, sounds a
Re: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
hvaib...@ti.com wrote:
From: Vaibhav Hiremath
Features Supported -
1. Provides V4L2 user interface for the video pipelines of DSS
2. Basic streaming working on LCD, DVI and TV.
3. Works on latest DSS2 library from Tomi
4. Support for various pixel formats like YUV, UYVY, RGB32, RGB24,
RGB565
5. Supports Alpha blending.
6. Supports Color keying both source and destination.
7. Supports rotation.
8. Supports cropping.
9. Supports Background color setting.
10. Allocated buffers to only needed size
Signed-off-by: Vaibhav Hiremath
diff --git a/drivers/media/video/omap/omap_voutlib.c
b/drivers/media/video/omap/omap_voutlib.c
new file mode 100644
index 000..05c0e17
--- /dev/null
+++ b/drivers/media/video/omap/omap_voutlib.c
@@ -0,0 +1,258 @@
+/*
+ * omap_voutlib.c
+ *
+ * Copyright (C) 2005-2010 Texas Instruments.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * Based on the OMAP2 camera driver
+ * Video-for-Linux (Version 2) camera capture driver for
+ * the OMAP24xx camera controller.
+ *
+ * Author: Andy Lowe (sou...@mvista.com)
+ *
+ * Copyright (C) 2004 MontaVista Software, Inc.
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Texas Instruments");
+MODULE_DESCRIPTION("OMAP Video library");
+MODULE_LICENSE("GPL");
+
+/* Return the default overlay cropping rectangle in crop given the image
+ * size in pix and the video display size in fbuf. The default
+ * cropping rectangle is the largest rectangle no larger than the capture size
+ * that will fit on the display. The default cropping rectangle is centered in
+ * the image. All dimensions and offsets are rounded down to even numbers.
+ */
+void omap_vout_default_crop(struct v4l2_pix_format *pix,
+ struct v4l2_framebuffer *fbuf, struct v4l2_rect *crop)
+{
+ crop->width = (pix->width< fbuf->fmt.width) ?
+ pix->width : fbuf->fmt.width;
+ crop->height = (pix->height< fbuf->fmt.height) ?
+ pix->height : fbuf->fmt.height;
+ crop->width&= ~1;
+ crop->height&= ~1;
+ crop->left = ((pix->width - crop->width)>> 1)& ~1;
+ crop->top = ((pix->height - crop->height)>> 1)& ~1;
+}
+EXPORT_SYMBOL_GPL(omap_vout_default_crop);
+
+/* Given a new render window in new_win, adjust the window to the
+ * nearest supported configuration. The adjusted window parameters are
+ * returned in new_win.
+ * Returns zero if succesful, or -EINVAL if the requested window is
+ * impossible and cannot reasonably be adjusted.
+ */
+int omap_vout_try_window(struct v4l2_framebuffer *fbuf,
+ struct v4l2_window *new_win)
+{
+ struct v4l2_rect try_win;
+
+ /* make a working copy of the new_win rectangle */
+ try_win = new_win->w;
+
+ /* adjust the preview window so it fits on the display by clipping any
+* offscreen areas
+*/
+ if (try_win.left< 0) {
+ try_win.width += try_win.left;
+ try_win.left = 0;
+ }
+ if (try_win.top< 0) {
+ try_win.height += try_win.top;
+ try_win.top = 0;
+ }
+ try_win.width = (try_win.width< fbuf->fmt.width) ?
+ try_win.width : fbuf->fmt.width;
+ try_win.height = (try_win.height< fbuf->fmt.height) ?
+ try_win.height : fbuf->fmt.height;
+ if (try_win.left + try_win.width> fbuf->fmt.width)
+ try_win.width = fbuf->fmt.width - try_win.left;
+ if (try_win.top + try_win.height> fbuf->fmt.height)
+ try_win.height = fbuf->fmt.height - try_win.top;
+ try_win.width&= ~1;
+ try_win.height&= ~1;
+
+ if (try_win.width<= 0 || try_win.height<= 0)
+ return -EINVAL;
+
+ /* We now have a valid preview window, so go with it */
+ new_win->w = try_win;
+ new_win->field = V4L2_FIELD_ANY;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_vout_try_window);
+
+/* Given a new render window in new_win, adjust the window to the
+ * nearest supported configuration. The image cropping window in crop
+ * will also be adjusted if necessary. Preference is given to keeping the
+ * the window as close to the requested configuration as possible. If
+ * successful, new_win, vout->win, and crop are updated.
+ * Returns zero if succesful, or -EINVAL if the requested preview window is
+ * impossible and cannot reasonably be adjusted.
+ */
+int omap_vout_new_window(struct v4l2_rect *crop,
+ struct v4l2_window *win, struct v4l2_framebuffer *fbuf,
+ struct v4l2_window *new_win)
+{
+ int err;
+
+ err = omap_vout_try_window(fbuf, new_win);
+ if (err)
+ return err;
+
+ /* upda
Help needed in understanding v4l2_device_call_all
Hi, I am trying to understand how the subdev function are triggered when I use v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_tuner,t) on tm600-video. How am i able to link the callback from the tuner_xc2028 function? Please help me to understand or directly me to any documentation that I can read up? thanks, Hock. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://www.linuxtv.org/hg/~dougsland/v4l-dvb for the following: - FusionHDTV: Use quick reads for I2C IR device probingdefault tip - vpfe capture - fix for kernel crash - ov511: Fix continuation lines - saa7134-cards: Add support new TV cards - saa7134: add support for Avermedia M733A - saa7134: fix GPIO HW-404M7 - drivers/media/video: avoid NULL dereference - Fix Warning ISO C90 forbids mixed declarations and code - cx88-dvb - cx88-dvb: fix on switch identation - cx23885: strcpy() => strlcpy() - cx25821: fix coding style issues in cx25821-video-upstream.c Thanks Douglas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: exposing controls in sysfs
Hi, Am Mittwoch, den 07.04.2010, 00:39 +0200 schrieb Hans Verkuil: > On Tuesday 06 April 2010 17:16:17 Mike Isely wrote: > > On Tue, 6 Apr 2010, Laurent Pinchart wrote: > > > > > Hi Andy, > > > > > > On Tuesday 06 April 2010 13:06:18 Andy Walls wrote: > > > > On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote: > > > > > > [snip] [snip] > > code. I don't know if that same strategy could be done in the V4L core. > > If it could, then this would probably alleviate a lot of concerns about > > testing / maintenance going forward. > > In other words, yes, it could do this. And with relatively little work and > completely transparent to all drivers. > > But I have a big question mark whether we really want to go that way. The > good thing about it is that the ioctls remain the primary API, as they should > be. Anything like this will definitely be a phase 3 (or 4, or...), but it > is at least nice to realize how easy it would be. That's a good sign of the > quality of the code. > > Regards, > > Hans that all looks really good now and quite promising, also IR/remote. Maybe too good? About what might be upcoming problems nobody is talking about currently. Never seen before ... I would wonder a lot, if we really should have made it close to such with a lot of buffering all around ;) Well, I guess the time on that beach might be short. Manu gave some pointers previously that HD+ is a serious issue for us, also it seems, that some lower level of firmware starts to hide GPIO's and i2c addresses on recent boards. We likely should stay hackish and able for quick responses and not over-engineer convenience we do not really have. Just my two cents. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: exposing controls in sysfs
On Tuesday 06 April 2010 18:19:30 Jonathan Cameron wrote: > On 04/06/10 15:41, Mike Isely wrote: > > On Tue, 6 Apr 2010, Hans Verkuil wrote: > > > >[...] > > > >> > >> One thing that might be useful is to prefix the name with the control class > >> name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It > >> would > >> groups them better. Or one could make a controls/user and controls/mpeg > >> directory. That might not be such a bad idea actually. > > > > I agree with grouping in concept, and using subdirectories is not a bad > > thing. Probably however you'd want to ensure that in the end all the > > controls end up logically at the same depth in the tree. > > > > > >[...] > > > >> > >> An in between solution would be to add _type files. So you would have > >> 'hue' and 'hue_type'. 'cat hue_type' would give something like: > >> > >> int 0 255 1 128 0x Hue > >> > >> In other words 'type min max step flags name'. > > > > There was I thought at some point in the past a kernel policy that sysfs > > controls were supposed to limit themselves to one value per node. > It's usually considered to be one 'conceptual' value per node, though > this falls fowl of that rule too. So you could have one file with a list > of possible values, or even one for say hue_range 0...255 but people are > going to through a wobbly about antyhing with as much data in it as above. > > The debate on this was actually pretty well covered in an lwn article the > other week. http://lwn.net/Articles/378884/ > > So the above hue type would probably need: > > hue_type (int) > hue_range (0...255) > hue_step (1) > hue_flags (128) > hue_name (Hue) > > Of those, hue_name doesn't in this case tell us anything and hue_step could > be suppressed as an obvious default. It could be argued that parts of the > above could be considered a single 'conceptual' value but I don't think the > whole can be. The reasoning behind this (and it is definitely true with > your above example) is that sysfs should be human readable without needing > to reach for the documentation. > > > >> > >> And for menu controls like stream_type (hmm, that would become > >> stream_type_type...) you would get: > >> > >> menu 0 5 1 0 Stream Type > > >> MPEG-2 Program Stream > >> > >> MPEG-1 System Stream > >> MPEG-2 DVD-compatible Stream > >> MPEG-1 VCD-compatible Stream > >> MPEG-2 SVCD-compatible Stream > >> > >> Note the empty line to denote the unsupported menu item (transport stream). > >> > >> This would give the same information with just a single extra file. Still > >> not > >> sure whether it is worth it though. > > > > Just remember that the more complex / subtle you make the node contents, > > then the more parsing will be required for any program that tries to use > > it. I also think it's probably a bad idea for example to define a > > format where the whitespace conveys additional information. The case > > where I've seen whitespace as part of the syntax actually work cleanly > > is in Python. You are correct, it should be one value per item. It would become a really big mess, though :-( I don't see much of an advantage to doing this in sysfs. If you need to know the type, then use v4l2-ctl. We could make a simple option for v4l2-ctl, or write a new tool that does this in a format that's easy to handle by scripting languages. Creating a zillion sysfs files strikes me as major overkill (not to mention the additional resources it would claim). Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: exposing controls in sysfs
On Tuesday 06 April 2010 17:16:17 Mike Isely wrote:
> On Tue, 6 Apr 2010, Laurent Pinchart wrote:
>
> > Hi Andy,
> >
> > On Tuesday 06 April 2010 13:06:18 Andy Walls wrote:
> > > On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote:
> >
> > [snip]
> >
> > > > Again, I still don't know whether we should do this. It is dangerously
> > > > seductive because it would be so trivial to implement.
> > >
> > > It's like watching ships run aground on a shallow sandbar that all the
> > > locals know about. The waters off of 'Point /sys' are full of usability
> > > shipwrecks. I don't know if it's some siren's song, the lack of a light
> > > house, or just strange currents that deceive even seasoned
> > > navigators
> > >
> > > Let the user run 'v4l2-ctl -d /dev/videoN -L' to learn about the control
> > > metatdata. It's not as easy as typing 'cat', but the user base using
> > > sysfs in an interactive shell or shell script should also know how to
> > > use v4l2-ctl. In embedded systems, the final system deployment should
> > > not need the control metadata available from sysfs in a command shell
> > > anyway.
> >
> > I fully agree with this. If we push the idea one step further, why do we
> > need
> > to expose controls in sysfs at all ?
>
> I have found it useful to have the sysfs interface within the pvrusb2
> driver.
>
> If it is going to take a lot of work to specifically craft a sysfs
> interface that exports the V4L API, then it will probably be a pain to
> maintain going forward. By "a lot of work" I mean that each V4L API
> function would have to be explicitly coded for in this interface, thus
> as the V4L API evolves over time then extra work must be expended each
> time to keep the sysfs interface in step. If that is to be the case
> then it may not be worth it.
No, that is no work at all. For all practical purposes there are two objects
(OK, really three, but the node object is just internal). The first object
is the control handler, the second is the control object. Handlers have
controls. Handlers can also inherit controls from other handlers. If they
already had the same control, then they effectively override the inherited
control. Controls can also be private to a handler, i.e. they will never be
inherited by other handlers.
Sound familiar? It's your basic C++ class inheritance scheme with public
and private fields (or controls in this case).
The sysfs implementation is just bolted on top of this: each video_device
struct is associated with a control handler and sysfs will expose all controls
that that handler references.
You can take a look at the header of the control framework:
http://linuxtv.org/hg/~hverkuil/v4l-dvb-fw/raw-file/bf7cd2fb7a35/linux/include/media/v4l2-ctrls.h
It would be trivial to add e.g. a V4L2 control class that could be used
to expose all sorts of V4L2 functionality to sysfs. It would be handled
differently in that you don't want to expose those through VIDIOC_QUERYCTRL
and friends, just to sysfs. Heck, it could be implemented almost completely
transparently from drivers. For example, an 'echo 1 >/sys//v4l2_input'
could be converted automatically to a VIDIOC_S_INPUT command that's issued
to the driver. Similar to what you did in pvrusb2, except you went the other
way around: ioctls are converted to controls. That is not feasible, though,
since you do not want to completely redo all drivers.
There are definitely some snags, but the basic premise is sound.
Of course, just the fact that you can easily do something does not mean that
you should. The first version of the framework will not contain any sysfs. It
is clear that the last word has not been said on this. It's not a big deal,
sysfs was just an add-on and not part of the core.
But having it in the kernel will make it a nice foundation on which to
experiment.
Just a thought experiment: take VIDIOC_S_FREQUENCY. The struct has three
fields: tuner, type, frequency. So that's a cluster of three controls. So you
would need a 's_ctrl' function like this:
switch (id) {
/* handle the frequency cluster */
case V4L2_CID_V4L_FREQ_TUNER:
struct v4l2_frequency f;
f.tuner = freq_tuner->cur.val;
f.type = freq_type->cur.val;
f.frequency = freq_freq->cur.val;
return vdev->ioctl_ops->s_frequency(&f);
}
Pseudo-code, of course, and there are some little things like the 'file' and
'fh'
args to s_frequency, but you could use the framework to make a very clean
implementation of this. Especially since the framework supports 'clustering' of
controls. Effectively creating a single composite control from the point of view
of the driver. Hmm, sounds awfully like a struct, doesn't it? :-)
> In the pvrusb2 driver this has not been the case because the code I
> wrote which implements the sysfs interface for the driver does this
> programmatically. That is, there is nothing in the pvrusb2-sysfs
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Apr 6 19:00:27 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14561:7c0b887911cf git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: a6eb7bc8e0eea78f96ad1b0f0195ec52b88c6a00 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: 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: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec: ERRORS spec-git: ERRORS sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec 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
Removing deprecated drivers and videotext API
Hi Mauro, What is a good time for you to receive patches for the old webcam drivers that HdG marked for removal in 2.6.35 and the videotext API that I marked for removal for 2.6.35 as well? Just before the next merge window opens? Or can we push patches for this earlier? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/26] V4L/DVB: ir-core: improve keyup/keydown logic
From: David Härdeman
Rewrites the keyup/keydown logic in drivers/media/IR/ir-keytable.c.
All knowledge of keystates etc is now internal to ir-keytable.c
and not scattered around ir-raw-event.c and ir-nec-decoder.c (where
it doesn't belong).
In addition, I've changed the API slightly so that ir_input_dev is
passed as the first argument rather than input_dev. If we're ever
going to support multiple keytables we need to move towards making
ir_input_dev the main interface from a driver POV and obscure away
the input_dev as an implementational detail in ir-core.
Signed-off-by: David Härdeman
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 00db928..39d8fcb 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -20,6 +20,9 @@
#define IR_TAB_MIN_SIZE256
#define IR_TAB_MAX_SIZE8192
+/* FIXME: IR_KEYPRESS_TIMEOUT should be protocol specific */
+#define IR_KEYPRESS_TIMEOUT 250
+
/**
* ir_resize_table() - resizes a scancode table if necessary
* @rc_tab:the ir_scancode_table to resize
@@ -262,56 +265,124 @@ EXPORT_SYMBOL_GPL(ir_g_keycode_from_table);
/**
* ir_keyup() - generates input event to cleanup a key press
- * @input_dev: the struct input_dev descriptor of the device
+ * @ir: the struct ir_input_dev descriptor of the device
*
- * This routine is used by the input routines when a key is pressed at the
- * IR. It reports a keyup input event via input_report_key().
+ * This routine is used to signal that a key has been released on the
+ * remote control. It reports a keyup input event via input_report_key().
*/
-void ir_keyup(struct input_dev *dev)
+static void ir_keyup(struct ir_input_dev *ir)
{
- struct ir_input_dev *ir = input_get_drvdata(dev);
-
if (!ir->keypressed)
return;
- IR_dprintk(1, "keyup key 0x%04x\n", ir->keycode);
- input_report_key(dev, ir->keycode, 0);
- input_sync(dev);
- ir->keypressed = 0;
+ IR_dprintk(1, "keyup key 0x%04x\n", ir->last_keycode);
+ input_report_key(ir->input_dev, ir->last_keycode, 0);
+ input_sync(ir->input_dev);
+ ir->keypressed = false;
}
-EXPORT_SYMBOL_GPL(ir_keyup);
+
+/**
+ * ir_timer_keyup() - generates a keyup event after a timeout
+ * @cookie: a pointer to struct ir_input_dev passed to setup_timer()
+ *
+ * This routine will generate a keyup event some time after a keydown event
+ * is generated when no further activity has been detected.
+ */
+static void ir_timer_keyup(unsigned long cookie)
+{
+ struct ir_input_dev *ir = (struct ir_input_dev *)cookie;
+ unsigned long flags;
+
+ /*
+* ir->keyup_jiffies is used to prevent a race condition if a
+* hardware interrupt occurs at this point and the keyup timer
+* event is moved further into the future as a result.
+*
+* The timer will then be reactivated and this function called
+* again in the future. We need to exit gracefully in that case
+* to allow the input subsystem to do its auto-repeat magic or
+* a keyup event might follow immediately after the keydown.
+*/
+ spin_lock_irqsave(&ir->keylock, flags);
+ if (time_is_after_eq_jiffies(ir->keyup_jiffies))
+ ir_keyup(ir);
+ spin_unlock_irqrestore(&ir->keylock, flags);
+}
+
+/**
+ * ir_repeat() - notifies the IR core that a key is still pressed
+ * @dev:the struct input_dev descriptor of the device
+ *
+ * This routine is used by IR decoders when a repeat message which does
+ * not include the necessary bits to reproduce the scancode has been
+ * received.
+ */
+void ir_repeat(struct input_dev *dev)
+{
+ unsigned long flags;
+ struct ir_input_dev *ir = input_get_drvdata(dev);
+
+ spin_lock_irqsave(&ir->keylock, flags);
+
+ if (!ir->keypressed)
+ goto out;
+
+ ir->keyup_jiffies = jiffies + msecs_to_jiffies(IR_KEYPRESS_TIMEOUT);
+ mod_timer(&ir->timer_keyup, ir->keyup_jiffies);
+
+out:
+ spin_unlock_irqrestore(&ir->keylock, flags);
+}
+EXPORT_SYMBOL_GPL(ir_repeat);
/**
* ir_keydown() - generates input event for a key press
- * @input_dev: the struct input_dev descriptor of the device
- * @scancode: the scancode that we're seeking
+ * @dev:the struct input_dev descriptor of the device
+ * @scancode: the scancode that we're seeking
+ * @toggle: the toggle value (protocol dependent, if the protocol doesn't
+ * support toggle values, this should be set to zero)
*
* This routine is used by the input routines when a key is pressed at the
* IR. It gets the keycode for a scancode and reports an input event via
* input_report_key().
*/
-void ir_keydown(struct input_dev *dev, int scancode)
+void ir_keydown(struct input_dev *dev, int scancode, u8 toggle)
{
+ unsigned long flags;
struct ir_input_
[PATCH 17/26] V4L/DVB: Convert drivers/media/dvb/ttpci/budget-ci.c to use ir-core
From: David Härdeman
Converts drivers/media/dvb/ttpci/budget-ci.c to use ir-core rather than
rolling its own keydown timeout handler and reporting keys via
drivers/media/IR/ir-functions.c.
Signed-off-by: David Härdeman
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/ttpci/budget-ci.c
b/drivers/media/dvb/ttpci/budget-ci.c
index be20749..8950df1 100644
--- a/drivers/media/dvb/ttpci/budget-ci.c
+++ b/drivers/media/dvb/ttpci/budget-ci.c
@@ -35,7 +35,7 @@
#include
#include
#include
-#include
+#include
#include "budget.h"
@@ -82,12 +82,6 @@
#define SLOTSTATUS_READY 8
#define SLOTSTATUS_OCCUPIED
(SLOTSTATUS_PRESENT|SLOTSTATUS_RESET|SLOTSTATUS_READY)
-/*
- * Milliseconds during which a key is regarded as pressed.
- * If an identical command arrives within this time, the timer will start over.
- */
-#define IR_KEYPRESS_TIMEOUT250
-
/* RC5 device wildcard */
#define IR_DEVICE_ANY 255
@@ -104,12 +98,9 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
struct budget_ci_ir {
struct input_dev *dev;
struct tasklet_struct msp430_irq_tasklet;
- struct timer_list timer_keyup;
char name[72]; /* 40 + 32 for (struct saa7146_dev).name */
char phys[32];
- struct ir_input_state state;
int rc5_device;
- u32 last_raw;
u32 ir_key;
bool have_command;
};
@@ -124,18 +115,11 @@ struct budget_ci {
u8 tuner_pll_address; /* used for philips_tdm1316l configs */
};
-static void msp430_ir_keyup(unsigned long data)
-{
- struct budget_ci_ir *ir = (struct budget_ci_ir *) data;
- ir_input_nokey(ir->dev, &ir->state);
-}
-
static void msp430_ir_interrupt(unsigned long data)
{
struct budget_ci *budget_ci = (struct budget_ci *) data;
struct input_dev *dev = budget_ci->ir.dev;
u32 command = ttpci_budget_debiread(&budget_ci->budget, DEBINOSWAP,
DEBIADDR_IR, 2, 1, 0) >> 8;
- u32 raw;
/*
* The msp430 chip can generate two different bytes, command and device
@@ -171,20 +155,12 @@ static void msp430_ir_interrupt(unsigned long data)
return;
budget_ci->ir.have_command = false;
+ /* FIXME: We should generate complete scancodes with device info */
if (budget_ci->ir.rc5_device != IR_DEVICE_ANY &&
budget_ci->ir.rc5_device != (command & 0x1f))
return;
- /* Is this a repeated key sequence? (same device, command, toggle) */
- raw = budget_ci->ir.ir_key | (command << 8);
- if (budget_ci->ir.last_raw != raw ||
!timer_pending(&budget_ci->ir.timer_keyup)) {
- ir_input_nokey(dev, &budget_ci->ir.state);
- ir_input_keydown(dev, &budget_ci->ir.state,
-budget_ci->ir.ir_key);
- budget_ci->ir.last_raw = raw;
- }
-
- mod_timer(&budget_ci->ir.timer_keyup, jiffies +
msecs_to_jiffies(IR_KEYPRESS_TIMEOUT));
+ ir_keydown(dev, budget_ci->ir.ir_key, (command & 0x20) ? 1 : 0);
}
static int msp430_ir_init(struct budget_ci *budget_ci)
@@ -251,11 +227,6 @@ static int msp430_ir_init(struct budget_ci *budget_ci)
ir_input_init(input_dev, &budget_ci->ir.state, IR_TYPE_RC5);
- /* initialise the key-up timeout handler */
- init_timer(&budget_ci->ir.timer_keyup);
- budget_ci->ir.timer_keyup.function = msp430_ir_keyup;
- budget_ci->ir.timer_keyup.data = (unsigned long) &budget_ci->ir;
- budget_ci->ir.last_raw = 0x; /* An impossible value */
error = ir_input_register(input_dev, ir_codes, NULL, MODULE_NAME);
if (error) {
printk(KERN_ERR "budget_ci: could not init driver for IR device
(code %d)\n", error);
@@ -284,9 +255,6 @@ static void msp430_ir_deinit(struct budget_ci *budget_ci)
saa7146_setgpio(saa, 3, SAA7146_GPIO_INPUT);
tasklet_kill(&budget_ci->ir.msp430_irq_tasklet);
- del_timer_sync(&dev->timer);
- ir_input_nokey(dev, &budget_ci->ir.state);
-
ir_input_unregister(dev);
}
--
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
[PATCH 14/26] V4L/DVB: drivers/media/IR - improve keytable code
From: David Härdeman
The attached patch rewrites much of the keytable code in
drivers/media/IR/ir-keytable.c.
The scancodes are now inserted into the array in sorted
order which allows for a binary search on lookup.
The code has also been shrunk by about 150 lines.
In addition it fixes the following bugs:
Any use of ir_seek_table() was racy.
ir_dev->driver_name is leaked between ir_input_register() and
ir_input_unregister().
ir_setkeycode() unconditionally does clear_bit() on dev->keybit
when removing a mapping, but there might be another mapping with
a different scancode and the same keycode.
This version has been updated to incorporate patch feedback from
Mauro Carvalho Chehab.
[mche...@redhat.com: Fix a conflict with RC keytable breakup patches]
Signed-off-by: David Härdeman
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 1d9c467..d3bc909 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -16,344 +16,214 @@
#include
#include
-#define IR_TAB_MIN_SIZE32
-#define IR_TAB_MAX_SIZE1024
+/* Sizes are in bytes, 256 bytes allows for 32 entries on x64 */
+#define IR_TAB_MIN_SIZE256
+#define IR_TAB_MAX_SIZE8192
/**
- * ir_seek_table() - returns the element order on the table
- * @rc_tab:the ir_scancode_table with the keymap to be used
- * @scancode: the scancode that we're seeking
+ * ir_resize_table() - resizes a scancode table if necessary
+ * @rc_tab:the ir_scancode_table to resize
+ * @return:zero on success or a negative error code
*
- * This routine is used by the input routines when a key is pressed at the
- * IR. The scancode is received and needs to be converted into a keycode.
- * If the key is not found, it returns KEY_UNKNOWN. Otherwise, returns the
- * corresponding keycode from the table.
+ * This routine will shrink the ir_scancode_table if it has lots of
+ * unused entries and grow it if it is full.
*/
-static int ir_seek_table(struct ir_scancode_table *rc_tab, u32 scancode)
+static int ir_resize_table(struct ir_scancode_table *rc_tab)
{
- int rc;
- unsigned long flags;
- struct ir_scancode *keymap = rc_tab->scan;
+ unsigned int oldalloc = rc_tab->alloc;
+ unsigned int newalloc = oldalloc;
+ struct ir_scancode *oldscan = rc_tab->scan;
+ struct ir_scancode *newscan;
- spin_lock_irqsave(&rc_tab->lock, flags);
+ if (rc_tab->size == rc_tab->len) {
+ /* All entries in use -> grow keytable */
+ if (rc_tab->alloc >= IR_TAB_MAX_SIZE)
+ return -ENOMEM;
- /* FIXME: replace it by a binary search */
+ newalloc *= 2;
+ IR_dprintk(1, "Growing table to %u bytes\n", newalloc);
+ }
- for (rc = 0; rc < rc_tab->size; rc++)
- if (keymap[rc].scancode == scancode)
- goto exit;
+ if ((rc_tab->len * 3 < rc_tab->size) && (oldalloc > IR_TAB_MIN_SIZE)) {
+ /* Less than 1/3 of entries in use -> shrink keytable */
+ newalloc /= 2;
+ IR_dprintk(1, "Shrinking table to %u bytes\n", newalloc);
+ }
- /* Not found */
- rc = -EINVAL;
+ if (newalloc == oldalloc)
+ return 0;
-exit:
- spin_unlock_irqrestore(&rc_tab->lock, flags);
- return rc;
-}
-
-/**
- * ir_roundup_tablesize() - gets an optimum value for the table size
- * @n_elems: minimum number of entries to store keycodes
- *
- * This routine is used to choose the keycode table size.
- *
- * In order to have some empty space for new keycodes,
- * and knowing in advance that kmalloc allocates only power of two
- * segments, it optimizes the allocated space to have some spare space
- * for those new keycodes by using the maximum number of entries that
- * will be effectively be allocated by kmalloc.
- * In order to reduce the quantity of table resizes, it has a minimum
- * table size of IR_TAB_MIN_SIZE.
- */
-static int ir_roundup_tablesize(int n_elems)
-{
- size_t size;
-
- if (n_elems < IR_TAB_MIN_SIZE)
- n_elems = IR_TAB_MIN_SIZE;
+ newscan = kmalloc(newalloc, GFP_ATOMIC);
+ if (!newscan) {
+ IR_dprintk(1, "Failed to kmalloc %u bytes\n", newalloc);
+ return -ENOMEM;
+ }
- /*
-* As kmalloc only allocates sizes of power of two, get as
-* much entries as possible for the allocated memory segment
-*/
- size = roundup_pow_of_two(n_elems * sizeof(struct ir_scancode));
- n_elems = size / sizeof(struct ir_scancode);
-
- return n_elems;
+ memcpy(newscan, rc_tab->scan, rc_tab->len * sizeof(struct ir_scancode));
+ rc_tab->scan = newscan;
+ rc_tab->alloc = newalloc;
+ rc_tab->size = rc_tab->alloc / sizeof(struct ir_scancode);
+ kfree(oldscan);
+
Re: [PATCH] Fix Warning ISO C90 forbids mixed declarations and code - cx88-dvb
On Wednesday 24 March 2010 14:45:50 Douglas Schilling Landgraf wrote: > Hello Ricardo, > > On Wed, Mar 24, 2010 at 10:27 AM, Ricardo Maraschini > wrote: > > Signed-off-by: Ricardo Maraschini > > > > --- a/linux/drivers/media/video/cx88/cx88-dvb.c Tue Mar 23 17:52:23 2010 > > -0300 > > +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Wed Mar 24 09:57:06 2010 > > -0300 > > @@ -1401,8 +1401,6 @@ > >case CX88_BOARD_SAMSUNG_SMT_7020: > >dev->ts_gen_cntrl = 0x08; > > > > - struct cx88_core *core = dev->core; > > - > >cx_set(MO_GP0_IO, 0x0101); > > > >cx_clear(MO_GP0_IO, 0x01); > > > > This version seems ok to my eyes. And also to my eyes. Mauro, can you please merge this? This patch didn't turn up in patchwork for some reason. This will fix an annoying compile warning. Regards, Hans > > Thanks > Douglas > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.35] Various fixes
The following changes since commit a6eb7bc8e0eea78f96ad1b0f0195ec52b88c6a00: Laurent Pinchart (1): V4L/DVB: uvcvideo: Use POLLOUT and POLLWRNORM for output devices are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git fixes Hans Verkuil (10): V4L2 Spec: fix V4L2_CTRL_TYPE_CTRL_CLASS documentation. videodev2.h: move definition of enum v4l2_ctrl_type to the other control types video_ioctl2: do not replace arg with NULL for _IO() ioctls video_ioctl2: don't return, use break. usbvision: remove non-working vbi device DocBook/v4l/compat.xml: add missing w9966: convert to V4L2 v4l2-framework.txt: fix incorrect statement video_ioctl2: handle the v4l1 compat bit first and move VIDIOCGMBUF into the switch ivtv: move the _IO() decoder ioctls into vidioc_default. It's all over the board these patches. Basically cleaning up a bunch of loose ends. Of particular interest are the w9966 conversion. It's untested. I've tried to contact the author or to find this hardware, but without luck. The conversion is pretty trivial, though, so I think we should just go for it. The other interesting patches are those for video_ioctl2. It's basically stuff I found when prototyping the pre/post hooks. Regards, Hans Documentation/DocBook/v4l/compat.xml| 115 +++--- Documentation/DocBook/v4l/vidioc-queryctrl.xml |2 +- Documentation/video4linux/v4l2-framework.txt| 11 +- drivers/media/video/Kconfig |2 +- drivers/media/video/ivtv/ivtv-ioctl.c | 65 ++-- drivers/media/video/usbvision/usbvision-video.c | 77 drivers/media/video/usbvision/usbvision.h |1 - drivers/media/video/v4l2-ioctl.c| 50 ++-- drivers/media/video/w9966.c | 435 +-- include/linux/videodev2.h | 20 +- 10 files changed, 377 insertions(+), 401 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
Vaibhav,
>>
>[Hiremath, Vaibhav] Thanks Murali, I really appreciate your comments here.
>Please find response below -
You had responded only to some comments. Can I assume that you are taking care
of the other comments as well? I have also asked Hans to provide
his comments since this is a new driver that he might have to approve. Did he
review the code in the past?
-Murali
>
>> > +
>> > +#include
>>
>> Add a line here??
>>
>> > +#include
>> > +#include
>> > +#include
>> > +#include
>> > +
>> > +#include "omap_voutlib.h"
>> > +#include "omap_voutdef.h"
>> > +
>> > +MODULE_AUTHOR("Texas Instruments");
>> > +MODULE_DESCRIPTION("OMAP Video for Linux Video out driver");
>> > +MODULE_LICENSE("GPL");
>> > +
>> > +
>> > +/* Driver Configuration macros */
>> > +#define VOUT_NAME "omap_vout"
>> > +
>> > +enum omap_vout_channels {
>> > + OMAP_VIDEO1 = 0,
>> Why do we have to initialize this to 0. It always start with a value 0
>> by default.
>>
>> > + OMAP_VIDEO2,
>> > +};
>> > +
>> > +enum dma_channel_state {
>> > + DMA_CHAN_NOT_ALLOTED = 0,
>>
>> Ditto.
>>
>> > + DMA_CHAN_ALLOTED,
>> > +};
>> > +
>> > +#define QQVGA_WIDTH160
>> > +#define QQVGA_HEIGHT 120
>> > +
>> > +/* Max Resolution supported by the driver */
>> > +#define VID_MAX_WIDTH 1280/* Largest width */
>> > +#define VID_MAX_HEIGHT 720 /* Largest height */
>> > +
>>
>> -
>>
>> > +
>> > +module_param(debug, bool, S_IRUGO);
>> > +MODULE_PARM_DESC(debug, "Debug level (0-1)");
>> > +
>> > +/* Local Helper functions */
>> > +static void omap_vout_isr(void *arg, unsigned int irqstatus);
>> > +static void omap_vout_cleanup_device(struct omap_vout_device *vout);
>> > +
>>
>> Is there a reason why you need these prototypes? I think we could
>> remove these prototypes and move the function ahead in the file before
>> it is called.
>>
>[Hiremath, Vaibhav] Do you see any harm with this? I think its only
>implementation part. But still I will incorporate in next version.
>
>> > +/* list of image formats supported by OMAP2 video pipelines */
>> > +const static struct v4l2_fmtdesc omap_formats[] = {
>> > + {
>> > + /* Note: V4L2 defines RGB565 as:
>> > +*
>> > +* Byte 0Byte 1
>> > +* g2 g1 g0 r4 r3 r2 r1 r0 b4 b3 b2 b1 b0 g5 g4
>g3
>> > +*
>> > +* We interpret RGB565 as:
>> > +*
>> > +* Byte 0Byte 1
>> > +* g2 g1 g0 b4 b3 b2 b1 b0 r4 r3 r2 r1 r0 g5 g4
>g3
>> > +*/
>> > + .description = "RGB565, le",
>> > + .pixelformat = V4L2_PIX_FMT_RGB565,
>> > + },
>> > + {
>> > + /* Note: V4L2 defines RGB32 as: RGB-8-8-8-8 we use
>> > +* this for RGB24 unpack mode, the last 8 bits are
>> ignored
>> > +* */
>> > + .description = "RGB32, le",
>> > + .pixelformat = V4L2_PIX_FMT_RGB32,
>> > + },
>> > + {
>> > + /* Note: V4L2 defines RGB24 as: RGB-8-8-8 we use
>> > +*this for RGB24 packed mode
>> > +*
>> > +*/
>> > + .description = "RGB24, le",
>> > + .pixelformat = V4L2_PIX_FMT_RGB24,
>> > + },
>> > + {
>> > + .description = "YUYV (YUV 4:2:2), packed",
>> > + .pixelformat = V4L2_PIX_FMT_YUYV,
>> > + },
>> > + {
>> > + .description = "UYVY, packed",
>> > + .pixelformat = V4L2_PIX_FMT_UYVY,
>> > + },
>> > +};
>> > +
>> > +#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
>> > +
>> > +/*
>> > + * Allocate buffers
>> > + */
>>
>> --
>>
>> > +
>> > +/*
>> > + * omap_vout_uservirt_to_phys: This inline function is used to convert
>> user
>> > + * space virtual address to physical address.
>> > + */
>> > +static u32 omap_vout_uservirt_to_phys(u32 virtp)
>> > +{
>> > + unsigned long physp = 0;
>> > + struct vm_area_struct *vma;
>> > + struct mm_struct *mm = current->mm;
>> > +
>> > + vma = find_vma(mm, virtp);
>> > + /* For kernel direct-mapped memory, take the easy way */
>> > + if (virtp >= PAGE_OFFSET) {
>> > + physp = virt_to_phys((void *) virtp);
>> > + } else if (vma && (vma->vm_flags & VM_IO)
>> > + && vma->vm_pgoff) {
>> > + /* this will catch, kernel-allocated,
>> > + mmaped-to-usermode addresses */
>> > + physp = (vma->vm_pgoff << PAGE_SHIFT) + (virtp - vma-
>> >vm_start);
>> > + } else {
>> > + /* otherwise, use get_user_pages() for general userland
>> pages */
>> > + int res, nr_pages = 1;
>> > + struct page *pages;
>
[PATCH 15/26] V4L/DVB: ir-core: re-add some debug functions for keytable changes
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index d3bc909..00db928 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -99,6 +99,8 @@ static int ir_do_setkeycode(struct input_dev *dev,
/* Did the user wish to remove the mapping? */
if (keycode == KEY_RESERVED || keycode == KEY_UNKNOWN) {
+ IR_dprintk(1, "#%d: Deleting scan 0x%04x\n",
+ i, scancode);
rc_tab->len--;
memmove(&rc_tab->scan[i], &rc_tab->scan[i + 1],
(rc_tab->len - i) * sizeof(struct ir_scancode));
@@ -114,6 +116,9 @@ static int ir_do_setkeycode(struct input_dev *dev,
if (ir_resize_table(rc_tab))
return -ENOMEM;
+ IR_dprintk(1, "#%d: New scan 0x%04x with key 0x%04x\n",
+ i, scancode, keycode);
+
/* i is the proper index to insert our new keycode */
memmove(&rc_tab->scan[i + 1], &rc_tab->scan[i],
(rc_tab->len - i) * sizeof(struct ir_scancode));
@@ -122,6 +127,8 @@ static int ir_do_setkeycode(struct input_dev *dev,
rc_tab->len++;
set_bit(keycode, dev->keybit);
} else {
+ IR_dprintk(1, "#%d: Replacing scan 0x%04x with key 0x%04x\n",
+ i, scancode, keycode);
/* A previous mapping was updated... */
clear_bit(old_keycode, dev->keybit);
/* ...but another scancode might use the same keycode */
@@ -223,6 +230,10 @@ static int ir_getkeycode(struct input_dev *dev,
}
spin_unlock_irqrestore(&rc_tab->lock, flags);
+ if (key == KEY_RESERVED)
+ IR_dprintk(1, "unknown key for scancode 0x%04x\n",
+ scancode);
+
*keycode = key;
return 0;
}
@@ -242,8 +253,9 @@ u32 ir_g_keycode_from_table(struct input_dev *dev, u32
scancode)
int keycode;
ir_getkeycode(dev, scancode, &keycode);
- IR_dprintk(1, "%s: scancode 0x%04x keycode 0x%02x\n",
- dev->name, scancode, keycode);
+ if (keycode != KEY_RESERVED)
+ IR_dprintk(1, "%s: scancode 0x%04x keycode 0x%02x\n",
+ dev->name, scancode, keycode);
return keycode;
}
EXPORT_SYMBOL_GPL(ir_g_keycode_from_table);
@@ -385,6 +397,9 @@ int __ir_input_register(struct input_dev *input_dev,
if (rc < 0)
goto out_table;
+ IR_dprintk(1, "Registered input device on %s for %s remote.\n",
+ driver_name, rc_tab->name);
+
return 0;
out_table:
--
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
[PATCH 07/26] V4L/DVB: ir-core: Add support for RC map code register
Instead of having all RC tables hardcoded on one file with
all tables there, add infrastructure for registering and dynamically
load the table(s) when needed.
Signed-off-by: Mauro Carvalho Chehab
create mode 100644 drivers/media/IR/rc-map.c
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 6140b27..3a4f590 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -1,5 +1,5 @@
ir-common-objs := ir-functions.o ir-keymaps.o
-ir-core-objs := ir-keytable.o ir-sysfs.o ir-raw-event.o
+ir-core-objs := ir-keytable.o ir-sysfs.o ir-raw-event.o rc-map.o
obj-$(CONFIG_IR_CORE) += ir-core.o
obj-$(CONFIG_VIDEO_IR) += ir-common.o
diff --git a/drivers/media/IR/rc-map.c b/drivers/media/IR/rc-map.c
new file mode 100644
index 000..aa269f5
--- /dev/null
+++ b/drivers/media/IR/rc-map.c
@@ -0,0 +1,75 @@
+/* ir-raw-event.c - handle IR Pulse/Space event
+ *
+ * Copyright (C) 2010 by Mauro Carvalho Chehab
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+
+/* Used to handle IR raw handler extensions */
+static LIST_HEAD(rc_map_list);
+static spinlock_t rc_map_lock;
+
+
+static struct rc_keymap *seek_rc_map(const char *name)
+{
+ struct rc_keymap *map = NULL;
+
+ spin_lock(&rc_map_lock);
+ list_for_each_entry(map, &rc_map_list, list) {
+ if (!strcmp(name, map->map.name))
+ break;
+ }
+ spin_unlock(&rc_map_lock);
+
+ return map;
+}
+
+struct ir_scancode_table *get_rc_map(const char *name)
+{
+ int rc = 0;
+
+ struct rc_keymap *map;
+
+ map = seek_rc_map(name);
+#ifdef MODULE
+ if (!map) {
+ rc = request_module("name");
+ if (rc < 0)
+ return NULL;
+
+ map = seek_rc_map(name);
+ }
+#endif
+ if (!map)
+ return NULL;
+
+ return &map->map;
+}
+EXPORT_SYMBOL_GPL(get_rc_map);
+
+int ir_register_map(struct rc_keymap *map)
+{
+ spin_lock(&rc_map_lock);
+ list_add_tail(&map->list, &rc_map_list);
+ spin_unlock(&rc_map_lock);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ir_raw_handler_register);
+
+void ir_unregister_map(struct rc_keymap *map)
+{
+ spin_lock(&rc_map_lock);
+ list_del(&map->list);
+ spin_unlock(&rc_map_lock);
+}
+EXPORT_SYMBOL_GPL(ir_raw_handler_unregister);
diff --git a/include/media/ir-core.h b/include/media/ir-core.h
index 643ff25..39df3cf 100644
--- a/include/media/ir-core.h
+++ b/include/media/ir-core.h
@@ -52,6 +52,11 @@ struct ir_scancode_table {
spinlock_t lock;
};
+struct rc_keymap {
+ struct list_head list;
+ struct ir_scancode_table map;
+};
+
struct ir_dev_props {
unsigned long allowed_protos;
void*priv;
@@ -126,6 +131,12 @@ int ir_input_register(struct input_dev *dev,
const char *driver_name);
void ir_input_unregister(struct input_dev *input_dev);
+/* Routines from rc-map.c */
+
+int ir_register_map(struct rc_keymap *map);
+void ir_unregister_map(struct rc_keymap *map);
+struct ir_scancode_table *get_rc_map(const char *name);
+
/* Routines from ir-sysfs.c */
int ir_register_class(struct input_dev *input_dev);
--
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
[PATCH 18/26] V4L/DVB: ir-nec-decoder: Reimplement the entire decoder
Thanks to Andy Walls for pointing me his
code, that gave me some ideas to better implement it.
After some work with saa7134 bits, I found a way to catch both IRQ
edge pulses. By enabling it, the NEC decoder can now take both
pulse and spaces into account, making it more precise.
Instead of the old strategy of handling the events all at once,
this code implements a state machine. Due to that, it handles
individual pulse or space events, validating them against the
protocol, producing a much more reliable decoding.
With the new implementation, the protocol trailer bits are properly
handled, making possible for the repeat key to work.
Also, the code is now capable of handling both NEC and NEC extended
IR devices. With NEC, it produces a 16 bits code, while with NEC
extended, a 24 bits code is returned.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-nec-decoder.c
b/drivers/media/IR/ir-nec-decoder.c
index 0b50060..33b260f 100644
--- a/drivers/media/IR/ir-nec-decoder.c
+++ b/drivers/media/IR/ir-nec-decoder.c
@@ -14,6 +14,14 @@
#include
+#define NEC_UNIT 559979 /* ns */
+#define NEC_HEADER_MARK(16 * NEC_UNIT)
+#define NEC_HEADER_SPACE (8 * NEC_UNIT)
+#define NEC_REPEAT_SPACE (4 * NEC_UNIT)
+#define NEC_MARK (NEC_UNIT)
+#define NEC_0_SYMBOL (NEC_UNIT)
+#define NEC_1_SYMBOL (3 * NEC_UNIT)
+
/* Start time: 4.5 ms + 560 us of the next pulse */
#define MIN_START_TIME (390 + 56)
#define MAX_START_TIME (510 + 56)
@@ -43,10 +51,32 @@
static LIST_HEAD(decoder_list);
static spinlock_t decoder_lock;
+enum nec_state {
+ STATE_INACTIVE,
+ STATE_HEADER_MARK,
+ STATE_HEADER_SPACE,
+ STATE_MARK,
+ STATE_SPACE,
+ STATE_TRAILER_MARK,
+ STATE_TRAILER_SPACE,
+};
+
+struct nec_code {
+ u8 address;
+ u8 not_address;
+ u8 command;
+ u8 not_command;
+};
+
struct decoder_data {
struct list_headlist;
struct ir_input_dev *ir_dev;
int enabled:1;
+
+ /* State machine control */
+ enum nec_state state;
+ struct nec_code nec_code;
+ unsignedcount;
};
@@ -118,139 +148,173 @@ static struct attribute_group decoder_attribute_group =
{
};
-/** is_repeat - Check if it is a NEC repeat event
- * @input_dev: the struct input_dev descriptor of the device
- * @pos: the position of the first event
- * @len: the length of the buffer
- */
-static int is_repeat(struct ir_raw_event *evs, int len, int pos)
-{
- if ((evs[pos].delta.tv_nsec < MIN_REPEAT_START_TIME) ||
- (evs[pos].delta.tv_nsec > MAX_REPEAT_START_TIME))
- return 0;
-
- if (++pos >= len)
- return 0;
-
- if ((evs[pos].delta.tv_nsec < MIN_REPEAT_TIME) ||
- (evs[pos].delta.tv_nsec > MAX_REPEAT_TIME))
- return 0;
-
- return 1;
-}
-
/**
- * __ir_nec_decode() - Decode one NEC pulsecode
+ * handle_event() - Decode one NEC pulse or space
* @input_dev: the struct input_dev descriptor of the device
- * @evs: event array with type/duration of pulse/space
- * @len: length of the array
- * @pos: position to start seeking for a code
- * This function returns -EINVAL if no pulse got decoded,
- * 0 if buffer is empty and 1 if one keycode were handled.
+ * @ev:event array with type/duration of pulse/space
+ *
+ * This function returns -EINVAL if the pulse violates the state machine
*/
-static int __ir_nec_decode(struct input_dev *input_dev,
- struct ir_raw_event *evs,
- int len, int *pos)
+static int handle_event(struct input_dev *input_dev,
+ struct ir_raw_event *ev)
{
- struct ir_input_dev *ir = input_get_drvdata(input_dev);
- int count = -1;
- int ircode = 0, not_code = 0;
-
- /* Be sure that the first event is an start one and is a pulse */
- for (; *pos < len; (*pos)++) {
- /* Very long delays are considered as start events */
- if (evs[*pos].delta.tv_nsec > MAX_NEC_TIME)
- break;
- if (evs[*pos].type & IR_START_EVENT)
- break;
- IR_dprintk(1, "%luus: Spurious NEC %s\n",
- (evs[*pos].delta.tv_nsec + 500) / 1000,
- (evs[*pos].type & IR_SPACE) ? "space" : "pulse");
-
- }
- if (*pos >= len)
- return 0;
+ struct decoder_data *data;
+ struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
+ int bit, last_bit;
+
+ data = get_decoder_data(ir_dev);
+ if (!data)
+ return -EINVAL;
+
+ /* Except for the initial event, what matters is the previous bit */
+ bit = (ev->type & IR_PULSE) ? 1 : 0;
+
+ last_bit
[PATCH 19/26] ir-nec-decoder: Cleanups
Remove dead code and properly name a few constants
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-nec-decoder.c
b/drivers/media/IR/ir-nec-decoder.c
index 33b260f..087211c 100644
--- a/drivers/media/IR/ir-nec-decoder.c
+++ b/drivers/media/IR/ir-nec-decoder.c
@@ -14,38 +14,14 @@
#include
+#define NEC_NBITS 32
#define NEC_UNIT 559979 /* ns */
#define NEC_HEADER_MARK(16 * NEC_UNIT)
#define NEC_HEADER_SPACE (8 * NEC_UNIT)
#define NEC_REPEAT_SPACE (4 * NEC_UNIT)
#define NEC_MARK (NEC_UNIT)
-#define NEC_0_SYMBOL (NEC_UNIT)
-#define NEC_1_SYMBOL (3 * NEC_UNIT)
-
-/* Start time: 4.5 ms + 560 us of the next pulse */
-#define MIN_START_TIME (390 + 56)
-#define MAX_START_TIME (510 + 56)
-
-/* Bit 1 time: 2.25ms us */
-#define MIN_BIT1_TIME 205
-#define MAX_BIT1_TIME 245
-
-/* Bit 0 time: 1.12ms us */
-#define MIN_BIT0_TIME 92
-#define MAX_BIT0_TIME 132
-
-/* Total IR code is 110 ms, including the 9 ms for the start pulse */
-#define MAX_NEC_TIME 400
-
-/* Total IR code is 110 ms, including the 9 ms for the start pulse */
-#define MIN_REPEAT_TIME9900
-#define MAX_REPEAT_TIME11200
-
-/* Repeat time: 2.25ms us */
-#define MIN_REPEAT_START_TIME 205
-#define MAX_REPEAT_START_TIME 300
-
-#define REPEAT_TIME240 /* ms */
+#define NEC_0_SPACE(NEC_UNIT)
+#define NEC_1_SPACE(3 * NEC_UNIT)
/* Used to register nec_decoder clients */
static LIST_HEAD(decoder_list);
@@ -223,11 +199,11 @@ static int handle_event(struct input_dev *input_dev,
if (last_bit)
goto err;
- if ((ev->delta.tv_nsec >= NEC_0_SYMBOL - NEC_UNIT / 2) &&
- (ev->delta.tv_nsec < NEC_0_SYMBOL + NEC_UNIT / 2))
+ if ((ev->delta.tv_nsec >= NEC_0_SPACE - NEC_UNIT / 2) &&
+ (ev->delta.tv_nsec < NEC_0_SPACE + NEC_UNIT / 2))
bit = 0;
- else if ((ev->delta.tv_nsec >= NEC_1_SYMBOL - NEC_UNIT / 2) &&
-(ev->delta.tv_nsec < NEC_1_SYMBOL + NEC_UNIT / 2))
+ else if ((ev->delta.tv_nsec >= NEC_1_SPACE - NEC_UNIT / 2) &&
+(ev->delta.tv_nsec < NEC_1_SPACE + NEC_UNIT / 2))
bit = 1;
else {
IR_dprintk(1, "Decode failed at %d-th bit (%s)
@%luus\n",
@@ -256,7 +232,7 @@ static int handle_event(struct input_dev *input_dev,
data->nec_code.not_command |= 1 << (shift - 24);
}
}
- if (++data->count == 32) {
+ if (++data->count == NEC_NBITS) {
u32 scancode;
/*
* Fixme: may need to accept Extended NEC protocol?
--
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
[PATCH 09/26] V4L/DVB: ir: prepare IR code for a parameter change at register function
A latter patch will reuse the ir_input_register with a different meaning.
Before it, change all occurrences to a temporary name.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index db54562..1d9c467 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -460,7 +460,7 @@ static void ir_close(struct input_dev *input_dev)
}
/**
- * ir_input_register() - sets the IR keycode table and add the handlers
+ * __ir_input_register() - sets the IR keycode table and add the handlers
* for keymap table get/set
* @input_dev: the struct input_dev descriptor of the device
* @rc_tab:the struct ir_scancode_table table of scancode/keymap
@@ -470,7 +470,7 @@ static void ir_close(struct input_dev *input_dev)
* It will register the input/evdev interface for the device and
* register the syfs code for IR class
*/
-int ir_input_register(struct input_dev *input_dev,
+int __ir_input_register(struct input_dev *input_dev,
const struct ir_scancode_table *rc_tab,
const struct ir_dev_props *props,
const char *driver_name)
@@ -538,7 +538,7 @@ err:
kfree(ir_dev);
return rc;
}
-EXPORT_SYMBOL_GPL(ir_input_register);
+EXPORT_SYMBOL_GPL(__ir_input_register);
/**
* ir_input_unregister() - unregisters IR and frees resources
diff --git a/drivers/media/dvb/dm1105/dm1105.c
b/drivers/media/dvb/dm1105/dm1105.c
index 17003ed..3a67f30 100644
--- a/drivers/media/dvb/dm1105/dm1105.c
+++ b/drivers/media/dvb/dm1105/dm1105.c
@@ -629,7 +629,7 @@ int __devinit dm1105_ir_init(struct dm1105_dev *dm1105)
INIT_WORK(&dm1105->ir.work, dm1105_emit_key);
- err = ir_input_register(input_dev, ir_codes, NULL, MODULE_NAME);
+ err = __ir_input_register(input_dev, ir_codes, NULL, MODULE_NAME);
return err;
}
diff --git a/drivers/media/dvb/mantis/mantis_input.c
b/drivers/media/dvb/mantis/mantis_input.c
index 6baf302..3d4e466 100644
--- a/drivers/media/dvb/mantis/mantis_input.c
+++ b/drivers/media/dvb/mantis/mantis_input.c
@@ -128,7 +128,7 @@ int mantis_input_init(struct mantis_pci *mantis)
rc->id.version = 1;
rc->dev = mantis->pdev->dev;
- err = ir_input_register(rc, &ir_mantis, NULL, MODULE_NAME);
+ err = __ir_input_register(rc, &ir_mantis, NULL, MODULE_NAME);
if (err) {
dprintk(MANTIS_ERROR, 1, "IR device registration failed, ret =
%d", err);
input_free_device(rc);
diff --git a/drivers/media/dvb/ttpci/budget-ci.c
b/drivers/media/dvb/ttpci/budget-ci.c
index 75c640e..ab7479a 100644
--- a/drivers/media/dvb/ttpci/budget-ci.c
+++ b/drivers/media/dvb/ttpci/budget-ci.c
@@ -256,7 +256,7 @@ static int msp430_ir_init(struct budget_ci *budget_ci)
budget_ci->ir.timer_keyup.function = msp430_ir_keyup;
budget_ci->ir.timer_keyup.data = (unsigned long) &budget_ci->ir;
budget_ci->ir.last_raw = 0x; /* An impossible value */
- error = ir_input_register(input_dev, ir_codes, NULL, MODULE_NAME);
+ error = __ir_input_register(input_dev, ir_codes, NULL, MODULE_NAME);
if (error) {
printk(KERN_ERR "budget_ci: could not init driver for IR device
(code %d)\n", error);
return error;
diff --git a/drivers/media/video/bt8xx/bttv-input.c
b/drivers/media/video/bt8xx/bttv-input.c
index d5d26e6..eae4925 100644
--- a/drivers/media/video/bt8xx/bttv-input.c
+++ b/drivers/media/video/bt8xx/bttv-input.c
@@ -391,7 +391,7 @@ int bttv_input_init(struct bttv *btv)
bttv_ir_start(btv, ir);
/* all done */
- err = ir_input_register(btv->remote->dev, ir_codes, NULL, MODULE_NAME);
+ err = __ir_input_register(btv->remote->dev, ir_codes, NULL,
MODULE_NAME);
if (err)
goto err_out_stop;
diff --git a/drivers/media/video/cx231xx/cx231xx-input.c
b/drivers/media/video/cx231xx/cx231xx-input.c
index 1cbfba1..dbd6218 100644
--- a/drivers/media/video/cx231xx/cx231xx-input.c
+++ b/drivers/media/video/cx231xx/cx231xx-input.c
@@ -218,7 +218,7 @@ int cx231xx_ir_init(struct cx231xx *dev)
cx231xx_ir_start(ir);
/* all done */
- err = ir_input_register(ir->input, dev->board.ir_codes,
+ err = __ir_input_register(ir->input, dev->board.ir_codes,
NULL, MODULE_NAME);
if (err)
goto err_out_stop;
diff --git a/drivers/media/video/cx23885/cx23885-input.c
b/drivers/media/video/cx23885/cx23885-input.c
index c7e854d..5767d3e 100644
--- a/drivers/media/video/cx23885/cx23885-input.c
+++ b/drivers/media/video/cx23885/cx23885-input.c
@@ -399,7 +399,7 @@ int cx23885_input_init(struct cx23885_dev *dev)
dev->ir_input = ir;
cx23885_input_ir_start(dev);
- ret = ir_input_register(ir->dev, ir_codes, NULL, MODULE_NAME);
+ ret = __ir_input_register(ir->dev, ir_codes, NULL,
[PATCH 00/26] IR core improvements
This is the new set of ir-core changes, with several new improvements. The most remarkable one is that the IR keymaps were removed from ir-common module. Now, they are mapped as separate kernel modules, that can be disabled or enabled as a hole. A future patch may be add a specific CONFIG_foo var for each one, but I think that the better is to first rework on them, removing duplicated keymaps and fixing some key bindings. With the current model, all that a driver needs to know about a table map is its name. As the same model name is passed via sysfs to userspace, it is easy to fully implement the tables on userspace. Also, several devices are provided with more than one IR model. So, it makes sense to group some of the entries into families. This series also adds a working decoder for RC-5 protocol, and re-implements the scancode to keycode conversion using a binary search algorithm that costs log2(n), thanks to David patches. David Härdeman (3): V4L/DVB: drivers/media/IR - improve keytable code V4L/DVB: ir-core: improve keyup/keydown logic V4L/DVB: Convert drivers/media/dvb/ttpci/budget-ci.c to use ir-core Mauro Carvalho Chehab (23): V4L/DVB: ir-common: Use a function to declare an IR table V4L/DVB: ir-common: re-order keytables by name and remove duplicates V4L/DVB: IR: use IR_KEYTABLE where an IR table is needed V4L/DVB: rename all *_rc_keys to ir_codes_*_nec_table V4L/DVB: ir-common: Use macros to define the keytables V4L/DVB: ir-common: move IR tables from ir-keymaps.c to a separate file V4L/DVB: ir-core: Add support for RC map code register V4L/DVB: Break Remote Controller keymaps into modules V4L/DVB: ir: prepare IR code for a parameter change at register function V4L/DVB: ir-core: Make use of the new IR keymap modules V4L/DVB: ir-common: remove keymap tables from the module V4L/DVB: saa7134: Fix IRQ2 bit names for the register map V4L/DVB: saa7134: Add support for both positive and negative edge IRQ V4L/DVB: ir-core: re-add some debug functions for keytable changes V4L/DVB: ir-nec-decoder: Reimplement the entire decoder ir-nec-decoder: Cleanups V4L-DVB: ir-rc5-decoder: Add a decoder for RC-5 IR protocol V4L/DVB: cx88: don't handle IR on Pixelview too fast V4L-DVB: ir-core: remove the ancillary buffer V4L/DVB: ir-core: move rc map code to rc-map.h V4L/DVB: ir-core: Add support for badly-implemented hardware decoders V4L/DVB: re-add enable/disable check to the IR decoders V4L/DVB: ir-rc5-decoder: fix state machine drivers/media/IR/Kconfig | 11 + drivers/media/IR/Makefile |7 +- drivers/media/IR/ir-keymaps.c | 3203 drivers/media/IR/ir-keytable.c | 709 ++--- drivers/media/IR/ir-nec-decoder.c | 323 +- drivers/media/IR/ir-raw-event.c| 35 +- drivers/media/IR/ir-rc5-decoder.c | 291 ++ drivers/media/IR/ir-sysfs.c|4 +- drivers/media/IR/keymaps/Kconfig | 15 + drivers/media/IR/keymaps/Makefile | 65 + drivers/media/IR/keymaps/rc-adstech-dvb-t-pci.c| 89 + drivers/media/IR/keymaps/rc-apac-viewcomp.c| 80 + drivers/media/IR/keymaps/rc-asus-pc39.c| 91 + drivers/media/IR/keymaps/rc-ati-tv-wonder-hd-600.c | 69 + drivers/media/IR/keymaps/rc-avermedia-a16d.c | 75 + drivers/media/IR/keymaps/rc-avermedia-cardbus.c| 97 + drivers/media/IR/keymaps/rc-avermedia-dvbt.c | 78 + .../media/IR/keymaps/rc-avermedia-m135a-rm-jx.c| 90 + drivers/media/IR/keymaps/rc-avermedia.c| 86 + drivers/media/IR/keymaps/rc-avertv-303.c | 85 + drivers/media/IR/keymaps/rc-behold-columbus.c | 108 + drivers/media/IR/keymaps/rc-behold.c | 141 + drivers/media/IR/keymaps/rc-budget-ci-old.c| 92 + drivers/media/IR/keymaps/rc-cinergy-1400.c | 84 + drivers/media/IR/keymaps/rc-cinergy.c | 78 + drivers/media/IR/keymaps/rc-dm1105-nec.c | 76 + drivers/media/IR/keymaps/rc-dntv-live-dvb-t.c | 78 + drivers/media/IR/keymaps/rc-dntv-live-dvbt-pro.c | 97 + drivers/media/IR/keymaps/rc-em-terratec.c | 69 + drivers/media/IR/keymaps/rc-empty.c| 44 + drivers/media/IR/keymaps/rc-encore-enltv-fm53.c| 81 + drivers/media/IR/keymaps/rc-encore-enltv.c | 112 + drivers/media/IR/keymaps/rc-encore-enltv2.c| 90 + drivers/media/IR/keymaps/rc-evga-indtube.c | 61 + drivers/media/IR/keymaps/rc-eztv.c | 96 + drivers/media/IR/keymaps/rc-flydvb.c | 77 + drivers/media/IR/keymaps/rc-flyvideo.c | 70 + drivers/media/IR/keymaps/rc-fusionhdtv-mce.c | 98 + drivers/media/IR/keymaps/rc-gadmei-rm008z.c| 81 + drivers/media/IR/keymaps/rc-genius-tvgo-a11mce.c | 84 + dr
[PATCH 20/26] V4L-DVB: ir-rc5-decoder: Add a decoder for RC-5 IR protocol
This decoder is also based on a state machine, just like the NEC protocol
decoder. It is pedantic in the sense that accepts only 14 bits. As there
are some variants that outputs less bits, it needs to be improved to also
handle those.
Signed-off-by: Mauro Carvalho Chehab
create mode 100644 drivers/media/IR/ir-rc5-decoder.c
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index 0c557b8..ba81bda 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -18,3 +18,12 @@ config IR_NEC_DECODER
---help---
Enable this option if you have IR with NEC protocol, and
if the IR is decoded in software
+
+config IR_RC5_DECODER
+ tristate "Enable IR raw decoder for RC-5 protocol"
+ depends on IR_CORE
+ default y
+
+ ---help---
+ Enable this option if you have IR with RC-5 protocol, and
+ if the IR is decoded in software
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 0e3f912..62e12d5 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -6,3 +6,4 @@ obj-y += keymaps/
obj-$(CONFIG_IR_CORE) += ir-core.o
obj-$(CONFIG_VIDEO_IR) += ir-common.o
obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
+obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index 59f2054..617e437 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -200,6 +200,7 @@ static void init_decoders(struct work_struct *work)
/* Load the decoder modules */
load_nec_decode();
+ load_rc5_decode();
/* If needed, we may later add some init code. In this case,
it is needed to change the CONFIG_MODULE test at ir-core.h
diff --git a/drivers/media/IR/ir-rc5-decoder.c
b/drivers/media/IR/ir-rc5-decoder.c
new file mode 100644
index 000..4b7eafe
--- /dev/null
+++ b/drivers/media/IR/ir-rc5-decoder.c
@@ -0,0 +1,371 @@
+/* ir-rc5-decoder.c - handle RC-5 IR Pulse/Space protocol
+ *
+ * Copyright (C) 2010 by Mauro Carvalho Chehab
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * This code only handles 14 bits RC-5 protocols. There are other variants
+ * that use a different number of bits. This is currently unsupported
+ */
+
+#include
+
+#define RC5_NBITS 14
+#define RC5_HALFBIT88 /* ns */
+#define RC5_BIT(RC5_HALFBIT * 2)
+#define RC5_DURATION (RC5_BIT * RC5_NBITS)
+
+#define is_rc5_halfbit(nsec) ((ev->delta.tv_nsec >= RC5_HALFBIT / 2) &&
\
+ (ev->delta.tv_nsec < RC5_HALFBIT + RC5_HALFBIT / 2))
+
+#define n_half(nsec) ((ev->delta.tv_nsec + RC5_HALFBIT / 2) / RC5_HALFBIT)
+
+/* Used to register rc5_decoder clients */
+static LIST_HEAD(decoder_list);
+static spinlock_t decoder_lock;
+
+enum rc5_state {
+ STATE_INACTIVE,
+ STATE_START2_SPACE,
+ STATE_START2_MARK,
+ STATE_MARKSPACE,
+ STATE_TRAILER_MARK,
+};
+
+static char *st_name[] = {
+ "Inactive",
+ "start2 sapce",
+ "start2 mark",
+ "mark",
+ "space",
+ "trailer"
+};
+
+struct rc5_code {
+ u8 address;
+ u8 command;
+};
+
+struct decoder_data {
+ struct list_headlist;
+ struct ir_input_dev *ir_dev;
+ int enabled:1;
+
+ /* State machine control */
+ enum rc5_state state;
+ struct rc5_code rc5_code;
+ unsignedn_half;
+ unsignedcount;
+};
+
+
+/**
+ * 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;
+}
+
+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
[PATCH 21/26] V4L/DVB: cx88: don't handle IR on Pixelview too fast
Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/cx88/cx88-input.c b/drivers/media/video/cx88/cx88-input.c index f5d6130..9dbec1c 100644 --- a/drivers/media/video/cx88/cx88-input.c +++ b/drivers/media/video/cx88/cx88-input.c @@ -315,9 +315,9 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev *pci) case CX88_BOARD_PIXELVIEW_PLAYTV_ULTRA_PRO: ir_codes = RC_MAP_PIXELVIEW; ir->gpio_addr = MO_GP1_IO; - ir->mask_keycode = 0x1f; + ir->mask_keycode = 0x1f;/* Only command is retrieved */ ir->mask_keyup = 0x80; - ir->polling = 1; /* ms */ + ir->polling = 10; /* ms */ break; case CX88_BOARD_PROLINK_PV_8000GT: case CX88_BOARD_PROLINK_PV_GLOBAL_XTREME: -- 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
[PATCH 22/26] V4L-DVB: ir-core: remove the ancillary buffer
Now that the decoders are state machine, there's no need to create
an ancillary buffer while decoding the protocol. Just call the decoders
code directly, event by event.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-nec-decoder.c
b/drivers/media/IR/ir-nec-decoder.c
index 087211c..28d7735 100644
--- a/drivers/media/IR/ir-nec-decoder.c
+++ b/drivers/media/IR/ir-nec-decoder.c
@@ -125,14 +125,14 @@ static struct attribute_group decoder_attribute_group = {
/**
- * handle_event() - Decode one NEC pulse or space
+ * ir_nec_decode() - Decode one NEC pulse or space
* @input_dev: the struct input_dev descriptor of the device
* @ev:event array with type/duration of pulse/space
*
* This function returns -EINVAL if the pulse violates the state machine
*/
-static int handle_event(struct input_dev *input_dev,
- struct ir_raw_event *ev)
+static int ir_nec_decode(struct input_dev *input_dev,
+struct ir_raw_event *ev)
{
struct decoder_data *data;
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
@@ -289,32 +289,6 @@ checksum_err:
return -EINVAL;
}
-/**
- * ir_nec_decode() - Decodes all NEC pulsecodes on a given array
- * @input_dev: the struct input_dev descriptor of the device
- * @evs: event array with type/duration of pulse/space
- * @len: length of the array
- * This function returns the number of decoded pulses
- */
-static int ir_nec_decode(struct input_dev *input_dev,
-struct ir_raw_event *evs,
-int len)
-{
- struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
- struct decoder_data *data;
- int pos = 0;
- int rc = 0;
-
- data = get_decoder_data(ir_dev);
- if (!data || !data->enabled)
- return 0;
-
- for (pos = 0; pos < len; pos++)
- handle_event(input_dev, &evs[pos]);
-
- return rc;
-}
-
static int ir_nec_register(struct input_dev *input_dev)
{
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
diff --git a/drivers/media/IR/ir-raw-event.c b/drivers/media/IR/ir-raw-event.c
index 617e437..57990a3 100644
--- a/drivers/media/IR/ir-raw-event.c
+++ b/drivers/media/IR/ir-raw-event.c
@@ -138,37 +138,33 @@ int ir_raw_event_handle(struct input_dev *input_dev)
{
struct ir_input_dev *ir = input_get_drvdata(input_dev);
int rc;
- struct ir_raw_event *evs;
+ struct ir_raw_event ev;
int len, i;
/*
* Store the events into a temporary buffer. This allows calling more
than
* one decoder to deal with the received data
*/
- len = kfifo_len(&ir->raw->kfifo) / sizeof(*evs);
+ len = kfifo_len(&ir->raw->kfifo) / sizeof(ev);
if (!len)
return 0;
- evs = kmalloc(len * sizeof(*evs), GFP_ATOMIC);
for (i = 0; i < len; i++) {
- rc = kfifo_out(&ir->raw->kfifo, &evs[i], sizeof(*evs));
- if (rc != sizeof(*evs)) {
+ rc = kfifo_out(&ir->raw->kfifo, &ev, sizeof(ev));
+ if (rc != sizeof(ev)) {
IR_dprintk(1, "overflow error: received %d instead of
%zd\n",
- rc, sizeof(*evs));
+ rc, sizeof(ev));
return -EINVAL;
}
IR_dprintk(2, "event type %d, time before event: %07luus\n",
- evs[i].type, (evs[i].delta.tv_nsec + 500) / 1000);
+ ev.type, (ev.delta.tv_nsec + 500) / 1000);
+ rc = RUN_DECODER(decode, input_dev, &ev);
}
/*
* Call all ir decoders. This allows decoding the same event with
-* more than one protocol handler. It returns the number of keystrokes
-* sent to the event interface
+* more than one protocol handler.
*/
- rc = RUN_DECODER(decode, input_dev, evs, len);
-
- kfree(evs);
return rc;
}
diff --git a/drivers/media/IR/ir-rc5-decoder.c
b/drivers/media/IR/ir-rc5-decoder.c
index 4b7eafe..61b5839 100644
--- a/drivers/media/IR/ir-rc5-decoder.c
+++ b/drivers/media/IR/ir-rc5-decoder.c
@@ -142,7 +142,7 @@ static struct attribute_group decoder_attribute_group = {
*
* This function returns -EINVAL if the pulse violates the state machine
*/
-static int handle_event(struct input_dev *input_dev,
+static int ir_rc5_decode(struct input_dev *input_dev,
struct ir_raw_event *ev)
{
struct decoder_data *data;
@@ -273,32 +273,6 @@ err2:
return -EINVAL;
}
-/**
- * ir_rc5_decode() - Decodes all RC-5 pulsecodes on a given array
- * @input_dev: the struct input_dev descriptor of the device
- * @evs: event array with type/duration of pulse/space
- * @len: length
[PATCH 03/26] V4L/DVB: IR: use IR_KEYTABLE where an IR table is needed
Replaces most of the occurences of IR keytables on V4L drivers by a macro
that evaluates to provide the name of the exported symbol.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/dm1105/dm1105.c
b/drivers/media/dvb/dm1105/dm1105.c
index f1721e9..17003ed 100644
--- a/drivers/media/dvb/dm1105/dm1105.c
+++ b/drivers/media/dvb/dm1105/dm1105.c
@@ -595,7 +595,7 @@ static irqreturn_t dm1105_irq(int irq, void *dev_id)
int __devinit dm1105_ir_init(struct dm1105_dev *dm1105)
{
struct input_dev *input_dev;
- struct ir_scancode_table *ir_codes = &ir_codes_dm1105_nec_table;
+ struct ir_scancode_table *ir_codes = &IR_KEYTABLE(dm1105_nec);
u64 ir_type = IR_TYPE_OTHER;
int err = -ENOMEM;
diff --git a/drivers/media/dvb/ttpci/budget-ci.c
b/drivers/media/dvb/ttpci/budget-ci.c
index ec89afd..75c640e 100644
--- a/drivers/media/dvb/ttpci/budget-ci.c
+++ b/drivers/media/dvb/ttpci/budget-ci.c
@@ -232,7 +232,7 @@ static int msp430_ir_init(struct budget_ci *budget_ci)
case 0x1011:
case 0x1012:
/* The hauppauge keymap is a superset of these remotes */
- ir_codes = &ir_codes_hauppauge_new_table;
+ ir_codes = &IR_KEYTABLE(hauppauge_new);
if (rc5_device < 0)
budget_ci->ir.rc5_device = 0x1f;
@@ -241,11 +241,11 @@ static int msp430_ir_init(struct budget_ci *budget_ci)
case 0x1017:
case 0x101a:
/* for the Technotrend 1500 bundled remote */
- ir_codes = &ir_codes_tt_1500_table;
+ ir_codes = &IR_KEYTABLE(tt_1500);
break;
default:
/* unknown remote */
- ir_codes = &ir_codes_budget_ci_old_table;
+ ir_codes = &IR_KEYTABLE(budget_ci_old);
break;
}
diff --git a/drivers/media/video/bt8xx/bttv-input.c
b/drivers/media/video/bt8xx/bttv-input.c
index 6c11687..d5d26e6 100644
--- a/drivers/media/video/bt8xx/bttv-input.c
+++ b/drivers/media/video/bt8xx/bttv-input.c
@@ -265,7 +265,7 @@ int bttv_input_init(struct bttv *btv)
case BTTV_BOARD_AVERMEDIA:
case BTTV_BOARD_AVPHONE98:
case BTTV_BOARD_AVERMEDIA98:
- ir_codes = &ir_codes_avermedia_table;
+ ir_codes = &IR_KEYTABLE(avermedia);
ir->mask_keycode = 0xf88000;
ir->mask_keydown = 0x01;
ir->polling = 50; // ms
@@ -273,14 +273,14 @@ int bttv_input_init(struct bttv *btv)
case BTTV_BOARD_AVDVBT_761:
case BTTV_BOARD_AVDVBT_771:
- ir_codes = &ir_codes_avermedia_dvbt_table;
+ ir_codes = &IR_KEYTABLE(avermedia_dvbt);
ir->mask_keycode = 0x0f00c0;
ir->mask_keydown = 0x20;
ir->polling = 50; // ms
break;
case BTTV_BOARD_PXELVWPLTVPAK:
- ir_codes = &ir_codes_pixelview_table;
+ ir_codes = &IR_KEYTABLE(pixelview);
ir->mask_keycode = 0x003e00;
ir->mask_keyup = 0x01;
ir->polling = 50; // ms
@@ -288,24 +288,24 @@ int bttv_input_init(struct bttv *btv)
case BTTV_BOARD_PV_M4900:
case BTTV_BOARD_PV_BT878P_9B:
case BTTV_BOARD_PV_BT878P_PLUS:
- ir_codes = &ir_codes_pixelview_table;
+ ir_codes = &IR_KEYTABLE(pixelview);
ir->mask_keycode = 0x001f00;
ir->mask_keyup = 0x008000;
ir->polling = 50; // ms
break;
case BTTV_BOARD_WINFAST2000:
- ir_codes = &ir_codes_winfast_table;
+ ir_codes = &IR_KEYTABLE(winfast);
ir->mask_keycode = 0x1f8;
break;
case BTTV_BOARD_MAGICTVIEW061:
case BTTV_BOARD_MAGICTVIEW063:
- ir_codes = &ir_codes_winfast_table;
+ ir_codes = &IR_KEYTABLE(winfast);
ir->mask_keycode = 0x0008e000;
ir->mask_keydown = 0x0020;
break;
case BTTV_BOARD_APAC_VIEWCOMP:
- ir_codes = &ir_codes_apac_viewcomp_table;
+ ir_codes = &IR_KEYTABLE(apac_viewcomp);
ir->mask_keycode = 0x001f00;
ir->mask_keyup = 0x008000;
ir->polling = 50; // ms
@@ -313,30 +313,30 @@ int bttv_input_init(struct bttv *btv)
case BTTV_BOARD_ASKEY_CPH03X:
case BTTV_BOARD_CONCEPTRONIC_CTVFMI2:
case BTTV_BOARD_CONTVFMI:
- ir_codes = &ir_codes_pixelview_table;
+ ir_codes = &IR_KEYTABLE(pixelview);
ir->mask_keycode = 0x001F00;
ir->mask_keyup = 0x006000;
ir->polling = 50; // ms
break;
case BTTV_BOARD_NEBULA_DIG
[PATCH 24/26] V4L/DVB: ir-core: Add support for badly-implemented hardware decoders
A few hardware Remote Controller decoders, even using a standard protocol,
aren't able to provide the entire scancode. Due to that, the capability
of using other IR's are limited on those hardware.
Adds a way to indicate to ir-core what are the bits that the hardware
provides, from a scancode, allowing the addition of a complete IR table
to the kernel and allowing a limited support for changing the Remote
Controller on those devices.
Signed-off-by: Mauro Carvalho Chehab
create mode 100644 drivers/media/IR/keymaps/rc-pixelview-mk12.c
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 39d8fcb..f509be2 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -88,6 +88,18 @@ static int ir_do_setkeycode(struct input_dev *dev,
{
unsigned int i;
int old_keycode = KEY_RESERVED;
+ struct ir_input_dev *ir_dev = input_get_drvdata(dev);
+
+ /*
+* Unfortunately, some hardware-based IR decoders don't provide
+* all bits for the complete IR code. In general, they provide only
+* the command part of the IR code. Yet, as it is possible to replace
+* the provided IR with another one, it is needed to allow loading
+* IR tables from other remotes. So,
+*/
+ if (ir_dev->props && ir_dev->props->scanmask) {
+ scancode &= ir_dev->props->scanmask;
+ }
/* First check if we already have a mapping for this ir command */
for (i = 0; i < rc_tab->len; i++) {
@@ -447,6 +459,13 @@ int __ir_input_register(struct input_dev *input_dev,
sizeof(struct ir_scancode));
ir_dev->rc_tab.scan = kmalloc(ir_dev->rc_tab.alloc, GFP_KERNEL);
ir_dev->rc_tab.size = ir_dev->rc_tab.alloc / sizeof(struct ir_scancode);
+ if (props) {
+ ir_dev->props = props;
+ if (props->open)
+ input_dev->open = ir_open;
+ if (props->close)
+ input_dev->close = ir_close;
+ }
if (!ir_dev->rc_tab.scan) {
rc = -ENOMEM;
@@ -464,12 +483,6 @@ int __ir_input_register(struct input_dev *input_dev,
goto out_table;
}
- ir_dev->props = props;
- if (props && props->open)
- input_dev->open = ir_open;
- if (props && props->close)
- input_dev->close = ir_close;
-
rc = ir_register_class(input_dev);
if (rc < 0)
goto out_table;
diff --git a/drivers/media/IR/keymaps/Makefile
b/drivers/media/IR/keymaps/Makefile
index 937b7db..c4d891d 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-pinnacle-grey.o \
rc-pinnacle-pctv-hd.o \
rc-pixelview.o \
+ rc-pixelview-mk12.o \
rc-pixelview-new.o \
rc-powercolor-real-angel.o \
rc-proteus-2309.o \
diff --git a/drivers/media/IR/keymaps/rc-pixelview-mk12.c
b/drivers/media/IR/keymaps/rc-pixelview-mk12.c
new file mode 100644
index 000..5a735d5
--- /dev/null
+++ b/drivers/media/IR/keymaps/rc-pixelview-mk12.c
@@ -0,0 +1,83 @@
+/* rc-pixelview-mk12.h - Keytable for pixelview Remote Controller
+ *
+ * keymap imported from ir-keymaps.c
+ *
+ * Copyright (c) 2010 by Mauro Carvalho Chehab
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+
+/*
+ * Keytable for MK-F12 IR remote provided together with Pixelview
+ * Ultra Pro Remote Controller. Uses NEC extended format.
+ */
+static struct ir_scancode pixelview_mk12[] = {
+ { 0x866b03, KEY_TUNER },/* Timeshift */
+ { 0x866b1e, KEY_POWER2 }, /* power */
+
+ { 0x866b01, KEY_1 },
+ { 0x866b0b, KEY_2 },
+ { 0x866b1b, KEY_3 },
+ { 0x866b05, KEY_4 },
+ { 0x866b09, KEY_5 },
+ { 0x866b15, KEY_6 },
+ { 0x866b06, KEY_7 },
+ { 0x866b0a, KEY_8 },
+ { 0x866b12, KEY_9 },
+ { 0x866b02, KEY_0 },
+
+ { 0x866b13, KEY_AGAIN },/* loop */
+ { 0x866b10, KEY_DIGITS }, /* +100 */
+
+ { 0x866b00, KEY_MEDIA },/* source */
+ { 0x866b18, KEY_MUTE }, /* mute */
+ { 0x866b19, KEY_CAMERA }, /* snapshot */
+ { 0x866b1a, KEY_SEARCH }, /* scan */
+
+ { 0x866b16, KEY_CHANNELUP },/* chn + */
+ { 0x866b14, KEY_CHANNELDOWN }, /* chn - */
+ { 0x866b1f, KEY_VOLUMEUP }, /* vol + */
+ { 0x866b17, KEY_VOLUMEDOWN }, /* vol - */
+ { 0x866b1c, KEY_ZOOM }, /* zoom */
+
+ { 0x866b04, KEY_R
[PATCH 01/26] V4L/DVB: ir-common: Use a function to declare an IR table
This is the first patch of a series of changes that will break the IR tables into a series of small modules that can be dynamically loaded, or just loaded from userspace. Signed-off-by: Mauro Carvalho Chehab diff --git a/include/media/ir-common.h b/include/media/ir-common.h index e403a9a..800fc98 100644 --- a/include/media/ir-common.h +++ b/include/media/ir-common.h @@ -106,69 +106,75 @@ void ir_rc5_timer_keyup(unsigned long data); /* scancode->keycode map tables from ir-keymaps.c */ -extern struct ir_scancode_table ir_codes_empty_table; -extern struct ir_scancode_table ir_codes_avermedia_table; -extern struct ir_scancode_table ir_codes_avermedia_dvbt_table; -extern struct ir_scancode_table ir_codes_avermedia_m135a_rm_jx_table; -extern struct ir_scancode_table ir_codes_avermedia_cardbus_table; -extern struct ir_scancode_table ir_codes_apac_viewcomp_table; -extern struct ir_scancode_table ir_codes_pixelview_table; -extern struct ir_scancode_table ir_codes_pixelview_new_table; -extern struct ir_scancode_table ir_codes_nebula_table; -extern struct ir_scancode_table ir_codes_dntv_live_dvb_t_table; -extern struct ir_scancode_table ir_codes_iodata_bctv7e_table; -extern struct ir_scancode_table ir_codes_adstech_dvb_t_pci_table; -extern struct ir_scancode_table ir_codes_msi_tvanywhere_table; -extern struct ir_scancode_table ir_codes_cinergy_1400_table; -extern struct ir_scancode_table ir_codes_avertv_303_table; -extern struct ir_scancode_table ir_codes_dntv_live_dvbt_pro_table; -extern struct ir_scancode_table ir_codes_em_terratec_table; -extern struct ir_scancode_table ir_codes_pinnacle_grey_table; -extern struct ir_scancode_table ir_codes_flyvideo_table; -extern struct ir_scancode_table ir_codes_flydvb_table; -extern struct ir_scancode_table ir_codes_cinergy_table; -extern struct ir_scancode_table ir_codes_eztv_table; -extern struct ir_scancode_table ir_codes_avermedia_table; -extern struct ir_scancode_table ir_codes_videomate_tv_pvr_table; -extern struct ir_scancode_table ir_codes_manli_table; -extern struct ir_scancode_table ir_codes_gotview7135_table; -extern struct ir_scancode_table ir_codes_purpletv_table; -extern struct ir_scancode_table ir_codes_pctv_sedna_table; -extern struct ir_scancode_table ir_codes_pv951_table; -extern struct ir_scancode_table ir_codes_rc5_tv_table; -extern struct ir_scancode_table ir_codes_winfast_table; -extern struct ir_scancode_table ir_codes_pinnacle_color_table; -extern struct ir_scancode_table ir_codes_hauppauge_new_table; -extern struct ir_scancode_table ir_codes_rc5_hauppauge_new_table; -extern struct ir_scancode_table ir_codes_npgtech_table; -extern struct ir_scancode_table ir_codes_norwood_table; -extern struct ir_scancode_table ir_codes_proteus_2309_table; -extern struct ir_scancode_table ir_codes_budget_ci_old_table; -extern struct ir_scancode_table ir_codes_asus_pc39_table; -extern struct ir_scancode_table ir_codes_encore_enltv_table; -extern struct ir_scancode_table ir_codes_encore_enltv2_table; -extern struct ir_scancode_table ir_codes_tt_1500_table; -extern struct ir_scancode_table ir_codes_fusionhdtv_mce_table; -extern struct ir_scancode_table ir_codes_behold_table; -extern struct ir_scancode_table ir_codes_behold_columbus_table; -extern struct ir_scancode_table ir_codes_pinnacle_pctv_hd_table; -extern struct ir_scancode_table ir_codes_genius_tvgo_a11mce_table; -extern struct ir_scancode_table ir_codes_powercolor_real_angel_table; -extern struct ir_scancode_table ir_codes_avermedia_a16d_table; -extern struct ir_scancode_table ir_codes_encore_enltv_fm53_table; -extern struct ir_scancode_table ir_codes_real_audio_220_32_keys_table; -extern struct ir_scancode_table ir_codes_msi_tvanywhere_plus_table; -extern struct ir_scancode_table ir_codes_ati_tv_wonder_hd_600_table; -extern struct ir_scancode_table ir_codes_kworld_plus_tv_analog_table; -extern struct ir_scancode_table ir_codes_kaiomy_table; -extern struct ir_scancode_table ir_codes_dm1105_nec_table; -extern struct ir_scancode_table ir_codes_tevii_nec_table; -extern struct ir_scancode_table ir_codes_tbs_nec_table; -extern struct ir_scancode_table ir_codes_evga_indtube_table; -extern struct ir_scancode_table ir_codes_terratec_cinergy_xs_table; -extern struct ir_scancode_table ir_codes_videomate_s350_table; -extern struct ir_scancode_table ir_codes_gadmei_rm008z_table; -extern struct ir_scancode_table ir_codes_nec_terratec_cinergy_xs_table; -extern struct ir_scancode_table ir_codes_winfast_usbii_deluxe_table; -extern struct ir_scancode_table ir_codes_kworld_315u_table; +#define IR_KEYTABLE(a) \ +(ir_codes_ ## a ## _table) + +#define DECLARE_IR_KEYTABLE(a) \ +extern struct ir_scancode_table IR_KEYTABLE(a) + +DECLARE_IR_KEYTABLE(empty); +DECLARE_IR_KEYTABLE(avermedia); +DECLARE_IR_KEYTABLE(avermedia_dvbt); +DECLARE_IR_KEYTABLE(avermedia_m135a_rm_jx); +DECLARE_IR_KEYTABLE(avermedia_cardbus); +DECLARE_IR_KEYTABLE(apac_viewcomp); +DECLARE_IR_KEYTABLE(p
[PATCH 10/26] V4L/DVB: ir-core: Make use of the new IR keymap modules
Instead of using the ugly keymap sequences, use the new rc-*.ko keymap
files. For now, it is still needed to have one keymap loaded, for the
RC code to work. Later patches will remove this depenency.
Signed-off-by: Mauro Carvalho Chehab
create mode 100644 include/media/rc-map.h
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 3a4f590..3d8dd30 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -1,6 +1,8 @@
ir-common-objs := ir-functions.o ir-keymaps.o
ir-core-objs := ir-keytable.o ir-sysfs.o ir-raw-event.o rc-map.o
+obj-y += keymaps/
+
obj-$(CONFIG_IR_CORE) += ir-core.o
obj-$(CONFIG_VIDEO_IR) += ir-common.o
obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index 435d83e..0b05c7b 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -250,8 +250,10 @@ static int __init ir_core_init(void)
return rc;
}
- /* Initialize/load the decoders that will be used */
+ /* Initialize/load the decoders/keymap code that will be used */
ir_raw_init();
+ rc_map_init();
+
return 0;
}
diff --git a/drivers/media/IR/rc-map.c b/drivers/media/IR/rc-map.c
index 02c72f0..2f6201c 100644
--- a/drivers/media/IR/rc-map.c
+++ b/drivers/media/IR/rc-map.c
@@ -26,12 +26,14 @@ static struct rc_keymap *seek_rc_map(const char *name)
spin_lock(&rc_map_lock);
list_for_each_entry(map, &rc_map_list, list) {
- if (!strcmp(name, map->map.name))
- break;
+ if (!strcmp(name, map->map.name)) {
+ spin_unlock(&rc_map_lock);
+ return map;
+ }
}
spin_unlock(&rc_map_lock);
- return map;
+ return NULL;
}
struct ir_scancode_table *get_rc_map(const char *name)
@@ -43,15 +45,22 @@ struct ir_scancode_table *get_rc_map(const char *name)
map = seek_rc_map(name);
#ifdef MODULE
if (!map) {
- rc = request_module("name");
- if (rc < 0)
+ rc = request_module(name);
+ if (rc < 0) {
+ printk(KERN_ERR "Couldn't load IR keymap %s\n", name);
return NULL;
+ }
+ msleep(20); /* Give some time for IR to register */
map = seek_rc_map(name);
}
#endif
- if (!map)
+ if (!map) {
+ printk(KERN_ERR "IR keymap %s not found\n", name);
return NULL;
+ }
+
+ printk(KERN_INFO "Registered IR keymap %s\n", map->map.name);
return &map->map;
}
@@ -73,3 +82,9 @@ void ir_unregister_map(struct rc_keymap *map)
spin_unlock(&rc_map_lock);
}
EXPORT_SYMBOL_GPL(ir_unregister_map);
+
+void rc_map_init(void)
+{
+ spin_lock_init(&rc_map_lock);
+
+}
diff --git a/drivers/media/dvb/dm1105/dm1105.c
b/drivers/media/dvb/dm1105/dm1105.c
index 3a67f30..333d7b1 100644
--- a/drivers/media/dvb/dm1105/dm1105.c
+++ b/drivers/media/dvb/dm1105/dm1105.c
@@ -595,7 +595,7 @@ static irqreturn_t dm1105_irq(int irq, void *dev_id)
int __devinit dm1105_ir_init(struct dm1105_dev *dm1105)
{
struct input_dev *input_dev;
- struct ir_scancode_table *ir_codes = &IR_KEYTABLE(dm1105_nec);
+ char *ir_codes = NULL;
u64 ir_type = IR_TYPE_OTHER;
int err = -ENOMEM;
@@ -629,7 +629,7 @@ int __devinit dm1105_ir_init(struct dm1105_dev *dm1105)
INIT_WORK(&dm1105->ir.work, dm1105_emit_key);
- err = __ir_input_register(input_dev, ir_codes, NULL, MODULE_NAME);
+ err = ir_input_register(input_dev, ir_codes, NULL, MODULE_NAME);
return err;
}
diff --git a/drivers/media/dvb/ttpci/budget-ci.c
b/drivers/media/dvb/ttpci/budget-ci.c
index ab7479a..be20749 100644
--- a/drivers/media/dvb/ttpci/budget-ci.c
+++ b/drivers/media/dvb/ttpci/budget-ci.c
@@ -192,7 +192,7 @@ static int msp430_ir_init(struct budget_ci *budget_ci)
struct saa7146_dev *saa = budget_ci->budget.dev;
struct input_dev *input_dev = budget_ci->ir.dev;
int error;
- struct ir_scancode_table *ir_codes;
+ char *ir_codes = NULL;
budget_ci->ir.dev = input_dev = input_allocate_device();
@@ -232,7 +232,7 @@ static int msp430_ir_init(struct budget_ci *budget_ci)
case 0x1011:
case 0x1012:
/* The hauppauge keymap is a superset of these remotes */
- ir_codes = &IR_KEYTABLE(hauppauge_new);
+ ir_codes = RC_MAP_HAUPPAUGE_NEW;
if (rc5_device < 0)
budget_ci->ir.rc5_device = 0x1f;
@@ -241,11 +241,11 @@ static int msp430_ir_init(struct budget_ci *budget_ci)
case 0x1017:
case 0x101a:
/* for the Technotrend 1500 bundled remote */
- ir_codes = &IR_KEYTABLE(tt_1500);
+ ir_codes = RC_MAP_TT_1500;
[PATCH 02/26] V4L/DVB: ir-common: re-order keytables by name and remove duplicates
Signed-off-by: Mauro Carvalho Chehab diff --git a/include/media/ir-common.h b/include/media/ir-common.h index 800fc98..2e27515 100644 --- a/include/media/ir-common.h +++ b/include/media/ir-common.h @@ -112,69 +112,69 @@ void ir_rc5_timer_keyup(unsigned long data); #define DECLARE_IR_KEYTABLE(a) \ extern struct ir_scancode_table IR_KEYTABLE(a) -DECLARE_IR_KEYTABLE(empty); +DECLARE_IR_KEYTABLE(adstech_dvb_t_pci); +DECLARE_IR_KEYTABLE(apac_viewcomp); +DECLARE_IR_KEYTABLE(asus_pc39); +DECLARE_IR_KEYTABLE(ati_tv_wonder_hd_600); DECLARE_IR_KEYTABLE(avermedia); +DECLARE_IR_KEYTABLE(avermedia_a16d); +DECLARE_IR_KEYTABLE(avermedia_cardbus); DECLARE_IR_KEYTABLE(avermedia_dvbt); DECLARE_IR_KEYTABLE(avermedia_m135a_rm_jx); -DECLARE_IR_KEYTABLE(avermedia_cardbus); -DECLARE_IR_KEYTABLE(apac_viewcomp); -DECLARE_IR_KEYTABLE(pixelview); -DECLARE_IR_KEYTABLE(pixelview_new); -DECLARE_IR_KEYTABLE(nebula); -DECLARE_IR_KEYTABLE(dntv_live_dvb_t); -DECLARE_IR_KEYTABLE(iodata_bctv7e); -DECLARE_IR_KEYTABLE(adstech_dvb_t_pci); -DECLARE_IR_KEYTABLE(msi_tvanywhere); -DECLARE_IR_KEYTABLE(cinergy_1400); DECLARE_IR_KEYTABLE(avertv_303); +DECLARE_IR_KEYTABLE(behold); +DECLARE_IR_KEYTABLE(behold_columbus); +DECLARE_IR_KEYTABLE(budget_ci_old); +DECLARE_IR_KEYTABLE(cinergy); +DECLARE_IR_KEYTABLE(cinergy_1400); +DECLARE_IR_KEYTABLE(dm1105_nec); +DECLARE_IR_KEYTABLE(dntv_live_dvb_t); DECLARE_IR_KEYTABLE(dntv_live_dvbt_pro); +DECLARE_IR_KEYTABLE(empty); DECLARE_IR_KEYTABLE(em_terratec); -DECLARE_IR_KEYTABLE(pinnacle_grey); -DECLARE_IR_KEYTABLE(flyvideo); -DECLARE_IR_KEYTABLE(flydvb); -DECLARE_IR_KEYTABLE(cinergy); +DECLARE_IR_KEYTABLE(encore_enltv); +DECLARE_IR_KEYTABLE(encore_enltv2); +DECLARE_IR_KEYTABLE(encore_enltv_fm53); +DECLARE_IR_KEYTABLE(evga_indtube); DECLARE_IR_KEYTABLE(eztv); -DECLARE_IR_KEYTABLE(avermedia); -DECLARE_IR_KEYTABLE(videomate_tv_pvr); -DECLARE_IR_KEYTABLE(manli); +DECLARE_IR_KEYTABLE(flydvb); +DECLARE_IR_KEYTABLE(flyvideo); +DECLARE_IR_KEYTABLE(fusionhdtv_mce); +DECLARE_IR_KEYTABLE(gadmei_rm008z); +DECLARE_IR_KEYTABLE(genius_tvgo_a11mce); DECLARE_IR_KEYTABLE(gotview7135); -DECLARE_IR_KEYTABLE(purpletv); -DECLARE_IR_KEYTABLE(pctv_sedna); -DECLARE_IR_KEYTABLE(pv951); -DECLARE_IR_KEYTABLE(rc5_tv); -DECLARE_IR_KEYTABLE(winfast); -DECLARE_IR_KEYTABLE(pinnacle_color); DECLARE_IR_KEYTABLE(hauppauge_new); -DECLARE_IR_KEYTABLE(rc5_hauppauge_new); -DECLARE_IR_KEYTABLE(npgtech); +DECLARE_IR_KEYTABLE(iodata_bctv7e); +DECLARE_IR_KEYTABLE(kaiomy); +DECLARE_IR_KEYTABLE(kworld_315u); +DECLARE_IR_KEYTABLE(kworld_plus_tv_analog); +DECLARE_IR_KEYTABLE(manli); +DECLARE_IR_KEYTABLE(msi_tvanywhere); +DECLARE_IR_KEYTABLE(msi_tvanywhere_plus); +DECLARE_IR_KEYTABLE(nebula); +DECLARE_IR_KEYTABLE(nec_terratec_cinergy_xs); DECLARE_IR_KEYTABLE(norwood); -DECLARE_IR_KEYTABLE(proteus_2309); -DECLARE_IR_KEYTABLE(budget_ci_old); -DECLARE_IR_KEYTABLE(asus_pc39); -DECLARE_IR_KEYTABLE(encore_enltv); -DECLARE_IR_KEYTABLE(encore_enltv2); -DECLARE_IR_KEYTABLE(tt_1500); -DECLARE_IR_KEYTABLE(fusionhdtv_mce); -DECLARE_IR_KEYTABLE(behold); -DECLARE_IR_KEYTABLE(behold_columbus); +DECLARE_IR_KEYTABLE(npgtech); +DECLARE_IR_KEYTABLE(pctv_sedna); +DECLARE_IR_KEYTABLE(pinnacle_color); +DECLARE_IR_KEYTABLE(pinnacle_grey); DECLARE_IR_KEYTABLE(pinnacle_pctv_hd); -DECLARE_IR_KEYTABLE(genius_tvgo_a11mce); +DECLARE_IR_KEYTABLE(pixelview); +DECLARE_IR_KEYTABLE(pixelview_new); DECLARE_IR_KEYTABLE(powercolor_real_angel); -DECLARE_IR_KEYTABLE(avermedia_a16d); -DECLARE_IR_KEYTABLE(encore_enltv_fm53); +DECLARE_IR_KEYTABLE(proteus_2309); +DECLARE_IR_KEYTABLE(purpletv); +DECLARE_IR_KEYTABLE(pv951); +DECLARE_IR_KEYTABLE(rc5_hauppauge_new); +DECLARE_IR_KEYTABLE(rc5_tv); DECLARE_IR_KEYTABLE(real_audio_220_32_keys); -DECLARE_IR_KEYTABLE(msi_tvanywhere_plus); -DECLARE_IR_KEYTABLE(ati_tv_wonder_hd_600); -DECLARE_IR_KEYTABLE(kworld_plus_tv_analog); -DECLARE_IR_KEYTABLE(kaiomy); -DECLARE_IR_KEYTABLE(dm1105_nec); -DECLARE_IR_KEYTABLE(tevii_nec); DECLARE_IR_KEYTABLE(tbs_nec); -DECLARE_IR_KEYTABLE(evga_indtube); DECLARE_IR_KEYTABLE(terratec_cinergy_xs); +DECLARE_IR_KEYTABLE(tevii_nec); +DECLARE_IR_KEYTABLE(tt_1500); DECLARE_IR_KEYTABLE(videomate_s350); -DECLARE_IR_KEYTABLE(gadmei_rm008z); -DECLARE_IR_KEYTABLE(nec_terratec_cinergy_xs); +DECLARE_IR_KEYTABLE(videomate_tv_pvr); +DECLARE_IR_KEYTABLE(winfast); DECLARE_IR_KEYTABLE(winfast_usbii_deluxe); -DECLARE_IR_KEYTABLE(kworld_315u); + #endif -- 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
[PATCH 23/26] V4L/DVB: ir-core: move rc map code to rc-map.h
The keymaps don't need to be recompiled every time a change at ir-core.h
happens, since it only depends on rc-map defines. By moving those
definitions to the proper header, the code became cleaner, and avoids
needing to recompile all the RC maps every time a non-related change
is introduced.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/include/media/ir-core.h b/include/media/ir-core.h
index 1c1e8d9..0f64b48 100644
--- a/include/media/ir-core.h
+++ b/include/media/ir-core.h
@@ -16,7 +16,6 @@
#ifndef _IR_CORE
#define _IR_CORE
-#include
#include
#include
#include
@@ -27,12 +26,6 @@ extern int ir_core_debug;
#define IR_dprintk(level, fmt, arg...) if (ir_core_debug >= level) \
printk(KERN_DEBUG "%s: " fmt , __func__, ## arg)
-#define IR_TYPE_UNKNOWN0
-#define IR_TYPE_RC5(1 << 0) /* Philips RC5 protocol */
-#define IR_TYPE_PD (1 << 1) /* Pulse distance encoded IR */
-#define IR_TYPE_NEC(1 << 2)
-#define IR_TYPE_OTHER (((u64)1) << 63l)
-
enum raw_event_type {
IR_SPACE= (1 << 0),
IR_PULSE= (1 << 1),
@@ -40,26 +33,6 @@ enum raw_event_type {
IR_STOP_EVENT = (1 << 3),
};
-struct ir_scancode {
- u16 scancode;
- u32 keycode;
-};
-
-struct ir_scancode_table {
- struct ir_scancode *scan;
- unsigned intsize; /* Max number of entries */
- unsigned intlen;/* Used number of entries */
- unsigned intalloc; /* Size of *scan in bytes */
- u64 ir_type;
- char*name;
- spinlock_t lock;
-};
-
-struct rc_keymap {
- struct list_head list;
- struct ir_scancode_table map;
-};
-
struct ir_dev_props {
unsigned long allowed_protos;
void*priv;
@@ -108,13 +81,6 @@ struct ir_raw_handler {
#define to_ir_input_dev(_attr) container_of(_attr, struct ir_input_dev, attr)
-/* Routines from rc-map.c */
-
-int ir_register_map(struct rc_keymap *map);
-void ir_unregister_map(struct rc_keymap *map);
-struct ir_scancode_table *get_rc_map(const char *name);
-void rc_map_init(void);
-
/* Routines from ir-keytable.c */
u32 ir_g_keycode_from_table(struct input_dev *input_dev,
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 9ea0033..b10990d 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -9,7 +9,42 @@
* (at your option) any later version.
*/
-#include
+#include
+
+#define IR_TYPE_UNKNOWN0
+#define IR_TYPE_RC5(1 << 0) /* Philips RC5 protocol */
+#define IR_TYPE_PD (1 << 1) /* Pulse distance encoded IR */
+#define IR_TYPE_NEC(1 << 2)
+#define IR_TYPE_OTHER (1u << 31)
+
+struct ir_scancode {
+ u16 scancode;
+ u32 keycode;
+};
+
+struct ir_scancode_table {
+ struct ir_scancode *scan;
+ unsigned intsize; /* Max number of entries */
+ unsigned intlen;/* Used number of entries */
+ unsigned intalloc; /* Size of *scan in bytes */
+ u64 ir_type;
+ char*name;
+ spinlock_t lock;
+};
+
+struct rc_keymap {
+ struct list_head list;
+ struct ir_scancode_table map;
+};
+
+/* Routines from rc-map.c */
+
+int ir_register_map(struct rc_keymap *map);
+void ir_unregister_map(struct rc_keymap *map);
+struct ir_scancode_table *get_rc_map(const char *name);
+void rc_map_init(void);
+
+/* Names of the several keytables defined in-kernel */
#define RC_MAP_ADSTECH_DVB_T_PCI "rc-adstech-dvb-t-pci"
#define RC_MAP_APAC_VIEWCOMP "rc-apac-viewcomp"
--
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
[PATCH 25/26] V4L/DVB: re-add enable/disable check to the IR decoders
A previous cleanup patch removed more than needed. Re-add the logic that disable the decoders. Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/IR/ir-nec-decoder.c b/drivers/media/IR/ir-nec-decoder.c index 28d7735..9d1ada9 100644 --- a/drivers/media/IR/ir-nec-decoder.c +++ b/drivers/media/IR/ir-nec-decoder.c @@ -142,6 +142,9 @@ static int ir_nec_decode(struct input_dev *input_dev, if (!data) return -EINVAL; + if (!data->enabled) + return 0; + /* Except for the initial event, what matters is the previous bit */ bit = (ev->type & IR_PULSE) ? 1 : 0; diff --git a/drivers/media/IR/ir-rc5-decoder.c b/drivers/media/IR/ir-rc5-decoder.c index 61b5839..4fb3ce4 100644 --- a/drivers/media/IR/ir-rc5-decoder.c +++ b/drivers/media/IR/ir-rc5-decoder.c @@ -153,6 +153,9 @@ static int ir_rc5_decode(struct input_dev *input_dev, if (!data) return -EINVAL; + if (!data->enabled) + return 0; + /* Except for the initial event, what matters is the previous bit */ bit = (ev->type & IR_PULSE) ? 1 : 0; -- 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
[PATCH 04/26] V4L/DVB: rename all *_rc_keys to ir_codes_*_nec_table
Several DVB drivers use a different name convention. As we're moving
the keytables, we need to use the same convention on all places.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/dvb/dvb-usb/a800.c b/drivers/media/dvb/dvb-usb/a800.c
index 6247239..b6cbb1d 100644
--- a/drivers/media/dvb/dvb-usb/a800.c
+++ b/drivers/media/dvb/dvb-usb/a800.c
@@ -37,7 +37,7 @@ static int a800_identify_state(struct usb_device *udev,
struct dvb_usb_device_pr
return 0;
}
-static struct dvb_usb_rc_key a800_rc_keys[] = {
+static struct dvb_usb_rc_key ir_codes_a800_table[] = {
{ 0x0201, KEY_PROG1 }, /* SOURCE */
{ 0x0200, KEY_POWER }, /* POWER */
{ 0x0205, KEY_1 }, /* 1 */
@@ -147,8 +147,8 @@ static struct dvb_usb_device_properties a800_properties = {
.identify_state = a800_identify_state,
.rc_interval = DEFAULT_RC_INTERVAL,
- .rc_key_map = a800_rc_keys,
- .rc_key_map_size = ARRAY_SIZE(a800_rc_keys),
+ .rc_key_map = ir_codes_a800_table,
+ .rc_key_map_size = ARRAY_SIZE(ir_codes_a800_table),
.rc_query = a800_rc_query,
.i2c_algo = &dibusb_i2c_algo,
diff --git a/drivers/media/dvb/dvb-usb/af9005-remote.c
b/drivers/media/dvb/dvb-usb/af9005-remote.c
index f4379c6..b41fa87 100644
--- a/drivers/media/dvb/dvb-usb/af9005-remote.c
+++ b/drivers/media/dvb/dvb-usb/af9005-remote.c
@@ -33,7 +33,7 @@ MODULE_PARM_DESC(debug,
#define deb_decode(args...) dprintk(dvb_usb_af9005_remote_debug,0x01,args)
-struct dvb_usb_rc_key af9005_rc_keys[] = {
+struct dvb_usb_rc_key ir_codes_af9005_table[] = {
{0x01b7, KEY_POWER},
{0x01a7, KEY_VOLUMEUP},
@@ -74,7 +74,7 @@ struct dvb_usb_rc_key af9005_rc_keys[] = {
{0x00d5, KEY_GOTO}, /* marked jump on the remote */
};
-int af9005_rc_keys_size = ARRAY_SIZE(af9005_rc_keys);
+int ir_codes_af9005_table_size = ARRAY_SIZE(ir_codes_af9005_table);
static int repeatable_keys[] = {
KEY_VOLUMEUP,
@@ -130,10 +130,10 @@ int af9005_rc_decode(struct dvb_usb_device *d, u8 * data,
int len, u32 * event,
deb_decode("code != inverted code\n");
return 0;
}
- for (i = 0; i < af9005_rc_keys_size; i++) {
- if (rc5_custom(&af9005_rc_keys[i]) == cust
- && rc5_data(&af9005_rc_keys[i]) == dat) {
- *event = af9005_rc_keys[i].event;
+ for (i = 0; i < ir_codes_af9005_table_size; i++) {
+ if (rc5_custom(&ir_codes_af9005_table[i]) ==
cust
+ && rc5_data(&ir_codes_af9005_table[i]) ==
dat) {
+ *event = ir_codes_af9005_table[i].event;
*state = REMOTE_KEY_PRESSED;
deb_decode
("key pressed, event %x\n", *event);
@@ -146,8 +146,8 @@ int af9005_rc_decode(struct dvb_usb_device *d, u8 * data,
int len, u32 * event,
return 0;
}
-EXPORT_SYMBOL(af9005_rc_keys);
-EXPORT_SYMBOL(af9005_rc_keys_size);
+EXPORT_SYMBOL(ir_codes_af9005_table);
+EXPORT_SYMBOL(ir_codes_af9005_table_size);
EXPORT_SYMBOL(af9005_rc_decode);
MODULE_AUTHOR("Luca Olivetti ");
diff --git a/drivers/media/dvb/dvb-usb/af9005.c
b/drivers/media/dvb/dvb-usb/af9005.c
index ca5a0a4..cfd6107 100644
--- a/drivers/media/dvb/dvb-usb/af9005.c
+++ b/drivers/media/dvb/dvb-usb/af9005.c
@@ -1109,8 +1109,8 @@ static int __init af9005_usb_module_init(void)
return result;
}
rc_decode = symbol_request(af9005_rc_decode);
- rc_keys = symbol_request(af9005_rc_keys);
- rc_keys_size = symbol_request(af9005_rc_keys_size);
+ rc_keys = symbol_request(ir_codes_af9005_table);
+ rc_keys_size = symbol_request(ir_codes_af9005_table_size);
if (rc_decode == NULL || rc_keys == NULL || rc_keys_size == NULL) {
err("af9005_rc_decode function not found, disabling remote");
af9005_properties.rc_query = NULL;
@@ -1128,9 +1128,9 @@ static void __exit af9005_usb_module_exit(void)
if (rc_decode != NULL)
symbol_put(af9005_rc_decode);
if (rc_keys != NULL)
- symbol_put(af9005_rc_keys);
+ symbol_put(ir_codes_af9005_table);
if (rc_keys_size != NULL)
- symbol_put(af9005_rc_keys_size);
+ symbol_put(ir_codes_af9005_table_size);
/* deregister this driver from the USB subsystem */
usb_deregister(&af9005_usb_driver);
}
diff --git a/drivers/media/dvb/dvb-usb/af9005.h
b/drivers/media/dvb/dvb-usb/af9005.h
index 0bc48a0..088e708 100644
--- a/drivers/media/dvb/dvb-usb/af9005.h
+++ b/drivers/media/dvb/dvb-usb/af9005.h
@@ -3490,7 +3490,7 @@ extern u8 regmask[8
[PATCH 12/26] V4L/DVB: saa7134: Fix IRQ2 bit names for the register map
There's an error at the IRQ2 bit map registers. Also, it doesn't
show what bits are needed for positive and for negative edge.
In the case of IR raw decoding, for some protocols, it is important
to detect both positive and negative edges. So, a latter patch
will need to use the other values.
Also, the code that detects problems on IRQ handling is incomplete,
as it disables only one of the IRQ bits for GPIO16 and GPIO18.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/saa7134/saa7134-core.c
b/drivers/media/video/saa7134/saa7134-core.c
index 68cda10..0612fff 100644
--- a/drivers/media/video/saa7134/saa7134-core.c
+++ b/drivers/media/video/saa7134/saa7134-core.c
@@ -471,7 +471,7 @@ static char *irqbits[] = {
"DONE_RA0", "DONE_RA1", "DONE_RA2", "DONE_RA3",
"AR", "PE", "PWR_ON", "RDCAP", "INTL", "FIDT", "MMC",
"TRIG_ERR", "CONF_ERR", "LOAD_ERR",
- "GPIO16?", "GPIO18", "GPIO22", "GPIO23"
+ "GPIO16", "GPIO18", "GPIO22", "GPIO23"
};
#define IRQBITS ARRAY_SIZE(irqbits)
@@ -601,12 +601,14 @@ static irqreturn_t saa7134_irq(int irq, void *dev_id)
/* disable gpio16 IRQ */
printk(KERN_WARNING "%s/irq: looping -- "
"clearing GPIO16 enable bit\n",dev->name);
- saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO16);
+ saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO16_P);
+ saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO16_N);
} else if (report & SAA7134_IRQ_REPORT_GPIO18) {
/* disable gpio18 IRQs */
printk(KERN_WARNING "%s/irq: looping -- "
"clearing GPIO18 enable bit\n",dev->name);
- saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO18);
+ saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO18_P);
+ saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO18_N);
} else {
/* disable all irqs */
printk(KERN_WARNING "%s/irq: looping -- "
@@ -698,11 +700,11 @@ static int saa7134_hw_enable2(struct saa7134_dev *dev)
if (dev->has_remote == SAA7134_REMOTE_GPIO && dev->remote) {
if (dev->remote->mask_keydown & 0x1)
- irq2_mask |= SAA7134_IRQ2_INTE_GPIO16;
+ irq2_mask |= SAA7134_IRQ2_INTE_GPIO16_N;
else if (dev->remote->mask_keydown & 0x4)
- irq2_mask |= SAA7134_IRQ2_INTE_GPIO18;
+ irq2_mask |= SAA7134_IRQ2_INTE_GPIO18_P;
else if (dev->remote->mask_keyup & 0x4)
- irq2_mask |= SAA7134_IRQ2_INTE_GPIO18A;
+ irq2_mask |= SAA7134_IRQ2_INTE_GPIO18_N;
}
if (dev->has_remote == SAA7134_REMOTE_I2C) {
diff --git a/drivers/media/video/saa7134/saa7134-input.c
b/drivers/media/video/saa7134/saa7134-input.c
index 0459ae6..fd3225c 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -1188,14 +1188,14 @@ static void nec_task(unsigned long data)
/* Keep repeating the last key */
mod_timer(&ir->timer_keyup, jiffies + msecs_to_jiffies(150));
- saa_setl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO18);
+ saa_setl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO18_P);
}
static int saa7134_nec_irq(struct saa7134_dev *dev)
{
struct card_ir *ir = dev->remote;
- saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO18);
+ saa_clearl(SAA7134_IRQ2, SAA7134_IRQ2_INTE_GPIO18_P);
tasklet_schedule(&ir->tlet);
return 1;
diff --git a/drivers/media/video/saa7134/saa7134-reg.h
b/drivers/media/video/saa7134/saa7134-reg.h
index cf89d96..e7e0af1 100644
--- a/drivers/media/video/saa7134/saa7134-reg.h
+++ b/drivers/media/video/saa7134/saa7134-reg.h
@@ -112,17 +112,17 @@
#define SAA7134_IRQ1_INTE_RA0_0 (1 << 0)
#define SAA7134_IRQ2(0x2c8 >> 2)
-#define SAA7134_IRQ2_INTE_GPIO23A (1 << 17)
-#define SAA7134_IRQ2_INTE_GPIO23 (1 << 16)
-#define SAA7134_IRQ2_INTE_GPIO22A (1 << 15)
-#define SAA7134_IRQ2_INTE_GPIO22 (1 << 14)
-#define SAA7134_IRQ2_INTE_GPIO18A (1 << 13)
-#define SAA7134_IRQ2_INTE_GPIO18 (1 << 12)
-#define SAA7134_IRQ2_INTE_GPIO16 (1 << 11) /* not certain */
-#define SAA7134_IRQ2_INTE_SC2 (1 << 10)
-#define SAA7134_IRQ2_INTE_SC1 (1 << 9)
-#define SAA7134_IRQ2_INTE_SC0 (1 << 8)
-#define SAA7134_IRQ2_INTE_DEC5(1 << 7)
+#define SAA7134_IRQ2_INTE_GPIO23_N (1 << 17) /* negative
edge */
+#define SAA7134_IRQ2_INTE_GPIO23_P (1 << 16) /* positive
edge */
+#define SAA7134_IRQ2_INTE_GPIO2
[PATCH 26/26] V4L/DVB: ir-rc5-decoder: fix state machine
Reimplement the RC-5 decoder state machine. Code is now clear, and works
properly. It is also simpler than the previous implementations.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-rc5-decoder.c
b/drivers/media/IR/ir-rc5-decoder.c
index 4fb3ce4..a62277b 100644
--- a/drivers/media/IR/ir-rc5-decoder.c
+++ b/drivers/media/IR/ir-rc5-decoder.c
@@ -15,19 +15,17 @@
/*
* This code only handles 14 bits RC-5 protocols. There are other variants
* that use a different number of bits. This is currently unsupported
+ * It considers a carrier of 36 kHz, with a total of 14 bits, where
+ * the first two bits are start bits, and a third one is a filing bit
*/
#include
+static unsigned int ir_rc5_remote_gap = 88;
+
#define RC5_NBITS 14
-#define RC5_HALFBIT88 /* ns */
-#define RC5_BIT(RC5_HALFBIT * 2)
-#define RC5_DURATION (RC5_BIT * RC5_NBITS)
-
-#define is_rc5_halfbit(nsec) ((ev->delta.tv_nsec >= RC5_HALFBIT / 2) &&
\
- (ev->delta.tv_nsec < RC5_HALFBIT + RC5_HALFBIT / 2))
-
-#define n_half(nsec) ((ev->delta.tv_nsec + RC5_HALFBIT / 2) / RC5_HALFBIT)
+#define RC5_BIT(ir_rc5_remote_gap * 2)
+#define RC5_DURATION (ir_rc5_remote_gap * RC5_NBITS)
/* Used to register rc5_decoder clients */
static LIST_HEAD(decoder_list);
@@ -35,19 +33,8 @@ static spinlock_t decoder_lock;
enum rc5_state {
STATE_INACTIVE,
- STATE_START2_SPACE,
- STATE_START2_MARK,
STATE_MARKSPACE,
- STATE_TRAILER_MARK,
-};
-
-static char *st_name[] = {
- "Inactive",
- "start2 sapce",
- "start2 mark",
- "mark",
- "space",
- "trailer"
+ STATE_TRAILER,
};
struct rc5_code {
@@ -63,8 +50,7 @@ struct decoder_data {
/* State machine control */
enum rc5_state state;
struct rc5_code rc5_code;
- unsignedn_half;
- unsignedcount;
+ unsignedcode, elapsed, last_bit, last_code;
};
@@ -147,7 +133,7 @@ static int ir_rc5_decode(struct input_dev *input_dev,
{
struct decoder_data *data;
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
- int bit, last_bit, n_half;
+ int is_pulse, scancode, delta, toggle;
data = get_decoder_data(ir_dev);
if (!data)
@@ -156,122 +142,79 @@ static int ir_rc5_decode(struct input_dev *input_dev,
if (!data->enabled)
return 0;
- /* Except for the initial event, what matters is the previous bit */
- bit = (ev->type & IR_PULSE) ? 1 : 0;
+ delta = DIV_ROUND_CLOSEST(ev->delta.tv_nsec, ir_rc5_remote_gap);
- last_bit = !bit;
-
- /* Discards spurious space last_bits when inactive */
+ /* The duration time refers to the last bit time */
+ is_pulse = (ev->type & IR_PULSE) ? 1 : 0;
/* Very long delays are considered as start events */
- if (ev->delta.tv_nsec > RC5_DURATION + RC5_HALFBIT / 2)
- data->state = STATE_INACTIVE;
-
- if (ev->type & IR_START_EVENT)
+ if (delta > RC5_DURATION || (ev->type & IR_START_EVENT))
data->state = STATE_INACTIVE;
switch (data->state) {
case STATE_INACTIVE:
-IR_dprintk(1, "currently inative. Received bit (%s) @%luus\n",
- last_bit ? "pulse" : "space",
- (ev->delta.tv_nsec + 500) / 1000);
+ IR_dprintk(2, "currently inative. Start bit (%s) @%uus\n",
+ is_pulse ? "pulse" : "space",
+ (unsigned)(ev->delta.tv_nsec + 500) / 1000);
/* Discards the initial start space */
- if (bit)
- return 0;
- data->count = 0;
- data->n_half = 0;
- memset (&data->rc5_code, 0, sizeof(data->rc5_code));
-
- data->state = STATE_START2_SPACE;
- return 0;
- case STATE_START2_SPACE:
- if (last_bit)
+ if (!is_pulse)
goto err;
- if (!is_rc5_halfbit(ev->delta.tv_nsec))
- goto err;
- data->state = STATE_START2_MARK;
- return 0;
- case STATE_START2_MARK:
- if (!last_bit)
- goto err;
-
- if (!is_rc5_halfbit(ev->delta.tv_nsec))
- goto err;
-
+ data->code = 1;
+ data->last_bit = 1;
+ data->elapsed = 0;
+ memset(&data->rc5_code, 0, sizeof(data->rc5_code));
data->state = STATE_MARKSPACE;
return 0;
case STATE_MARKSPACE:
- n_half = n_half(ev->delta.tv_nsec);
- if (n_half < 1 || n_half > 3) {
- IR_dprintk(1, "Decode failed at %d-th bit (%s)
@%luus\n",
- data->count,
-
[PATCH 05/26] V4L/DVB: ir-common: Use macros to define the keytables
The usage of macros ensures that the proper namespace is being used
by all tables. It also makes easier to associate a keytable with
the name used inside the drivers.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/IR/ir-keymaps.c b/drivers/media/IR/ir-keymaps.c
index 55e7acd..1ba9285 100644
--- a/drivers/media/IR/ir-keymaps.c
+++ b/drivers/media/IR/ir-keymaps.c
@@ -35,24 +35,15 @@
* to define the proper IR_TYPE (IR_TYPE_RC5/IR_TYPE_NEC).
* The deprecated tables should use IR_TYPE_UNKNOWN
*/
-#define IR_TABLE(irname, type, tabname)\
-struct ir_scancode_table tabname ## _table = { \
- .scan = tabname,\
- .size = ARRAY_SIZE(tabname),\
- .ir_type = type,\
- .name = #irname,\
-}; \
-EXPORT_SYMBOL_GPL(tabname ## _table)
-
/* empty keytable, can be used as placeholder for not-yet created keytables */
-static struct ir_scancode ir_codes_empty[] = {
+static struct ir_scancode empty[] = {
{ 0x2a, KEY_COFFEE },
};
-IR_TABLE(empty, IR_TYPE_UNKNOWN, ir_codes_empty);
+DEFINE_LEGACY_IR_KEYTABLE(empty);
/* Michal Majchrowicz */
-static struct ir_scancode ir_codes_proteus_2309[] = {
+static struct ir_scancode proteus_2309[] = {
/* numeric */
{ 0x00, KEY_0 },
{ 0x01, KEY_1 },
@@ -80,10 +71,10 @@ static struct ir_scancode ir_codes_proteus_2309[] = {
{ 0x1e, KEY_VOLUMEUP }, /* volume +*/
{ 0x14, KEY_F1 },
};
-IR_TABLE(proteus_2309, IR_TYPE_UNKNOWN, ir_codes_proteus_2309);
+DEFINE_LEGACY_IR_KEYTABLE(proteus_2309);
/* Matt Jesson
*/
-static struct ir_scancode ir_codes_avermedia_m135a_rm_jx[] = {
+static struct ir_scancode avermedia_m135a_rm_jx[] = {
{ 0x0200, KEY_POWER2 },
{ 0x022e, KEY_DOT },/* '.' */
{ 0x0201, KEY_MODE }, /* TV/FM or SOURCE */
@@ -172,10 +163,10 @@ static struct ir_scancode
ir_codes_avermedia_m135a_rm_jx[] = {
{ 0x0218, KEY_PLAY },
{ 0x021b, KEY_STOP },
};
-IR_TABLE(aver-m135a-RM-JX, IR_TYPE_NEC, ir_codes_avermedia_m135a_rm_jx);
+DEFINE_IR_KEYTABLE(avermedia_m135a_rm_jx, IR_TYPE_NEC);
/* Oldrich Jedlicka */
-static struct ir_scancode ir_codes_avermedia_cardbus[] = {
+static struct ir_scancode avermedia_cardbus[] = {
{ 0x00, KEY_POWER },
{ 0x01, KEY_TUNER },/* TV/FM */
{ 0x03, KEY_TEXT }, /* Teletext */
@@ -231,10 +222,10 @@ static struct ir_scancode ir_codes_avermedia_cardbus[] = {
{ 0x42, KEY_CHANNELDOWN }, /* Channel down */
{ 0x43, KEY_CHANNELUP },/* Channel up */
};
-IR_TABLE(avermedia_cardbus, IR_TYPE_UNKNOWN, ir_codes_avermedia_cardbus);
+DEFINE_LEGACY_IR_KEYTABLE(avermedia_cardbus);
/* Attila Kondoros */
-static struct ir_scancode ir_codes_apac_viewcomp[] = {
+static struct ir_scancode apac_viewcomp[] = {
{ 0x01, KEY_1 },
{ 0x02, KEY_2 },
@@ -273,11 +264,11 @@ static struct ir_scancode ir_codes_apac_viewcomp[] = {
{ 0x0c, KEY_KPPLUS }, /* fine tune */
{ 0x18, KEY_KPMINUS }, /* fine tune */
};
-IR_TABLE(apac_viewcomp, IR_TYPE_UNKNOWN, ir_codes_apac_viewcomp);
+DEFINE_LEGACY_IR_KEYTABLE(apac_viewcomp);
/* -- */
-static struct ir_scancode ir_codes_pixelview[] = {
+static struct ir_scancode pixelview[] = {
{ 0x1e, KEY_POWER },/* power */
{ 0x07, KEY_MEDIA },/* source */
@@ -320,13 +311,13 @@ static struct ir_scancode ir_codes_pixelview[] = {
{ 0x1d, KEY_REFRESH }, /* reset */
{ 0x18, KEY_MUTE }, /* mute/unmute */
};
-IR_TABLE(pixelview, IR_TYPE_UNKNOWN, ir_codes_pixelview);
+DEFINE_LEGACY_IR_KEYTABLE(pixelview);
/*
Mauro Carvalho Chehab
present on PV MPEG 8000GT
*/
-static struct ir_scancode ir_codes_pixelview_new[] = {
+static struct ir_scancode pixelview_new[] = {
{ 0x3c, KEY_TIME }, /* Timeshift */
{ 0x12, KEY_POWER },
@@ -365,9 +356,9 @@ static struct ir_scancode ir_codes_pixelview_new[] = {
{ 0x31, KEY_TV },
{ 0x34, KEY_RADIO },
};
-IR_TABLE(pixelview_new, IR_TYPE_UNKNOWN, ir_codes_pixelview_new);
+DEFINE_LEGACY_IR_KEYTABLE(pixelview_new);
-static struct ir_scancode ir_codes_nebula[] = {
+static struct ir_scancode nebula[] = {
{ 0x00, KEY_0 },
{ 0x01, KEY_1 },
{ 0x02, KEY_2 },
@@ -424,10 +415,10 @@ static struct ir_scancode ir_codes_nebula[] = {
{ 0x35, KEY_PHONE },
{ 0x36, KEY_PC },
};
-IR_TABLE(nebula, IR_TYPE_UNKNOWN, ir_codes_nebula);
+DEFINE_LEGACY_IR_KEYTABLE(nebula);
/* DigitalNow DNTV Live DVB-T Remote */
-static struct ir_scancode ir_codes_dntv_live_dvb_t[] = {
+static
[PATCH 13/26] V4L/DVB: saa7134: Add support for both positive and negative edge IRQ
The code that enables IRQ for the Remote Controller on saa7134 is a little
messy: it is outside saa7134-input, it checks if RC is GPIO based, and
it mixes both serial raw decode with parallel reads from a hardware-based
IR decoder.
Also, currently, it doesn't allow to trigger both transition edges at GPIO16
and GPIO18 lines. A rework on the code is needed to provide a better way
to specify what saa7134-input needs, maybe even moving part of the code from
saa7134-core and saa7134-cards into saa7134-input.
Yet, as a large rework is happening at RC core, it is better to wait until
the core changes stablize, in order to rework saa7134 RC internals.While
this don't happen, let's just change the logic a little bit to allow
enabling IRQ to be generated on both edge transitions, in order to better
support pulse/space raw decoders.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/saa7134/saa7134-core.c
b/drivers/media/video/saa7134/saa7134-core.c
index 0612fff..90f2318 100644
--- a/drivers/media/video/saa7134/saa7134-core.c
+++ b/drivers/media/video/saa7134/saa7134-core.c
@@ -701,10 +701,12 @@ static int saa7134_hw_enable2(struct saa7134_dev *dev)
if (dev->has_remote == SAA7134_REMOTE_GPIO && dev->remote) {
if (dev->remote->mask_keydown & 0x1)
irq2_mask |= SAA7134_IRQ2_INTE_GPIO16_N;
- else if (dev->remote->mask_keydown & 0x4)
- irq2_mask |= SAA7134_IRQ2_INTE_GPIO18_P;
- else if (dev->remote->mask_keyup & 0x4)
- irq2_mask |= SAA7134_IRQ2_INTE_GPIO18_N;
+ else { /* Allow enabling both IRQ edge triggers */
+ if (dev->remote->mask_keydown & 0x4)
+ irq2_mask |= SAA7134_IRQ2_INTE_GPIO18_P;
+ if (dev->remote->mask_keyup & 0x4)
+ irq2_mask |= SAA7134_IRQ2_INTE_GPIO18_N;
+ }
}
if (dev->has_remote == SAA7134_REMOTE_I2C) {
--
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: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
> -Original Message-
> From: Muralidharan Karicheri [mailto:mkarich...@gmail.com]
> Sent: Saturday, April 03, 2010 1:33 AM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org; Karicheri, Muralidharan;
> mche...@redhat.com; linux-o...@vger.kernel.org; t...@atomide.com
> Subject: Re: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver
> on top of DSS2
>
> Vaibhav,
>
> I have some comments on this patch. Please address them.
>
[Hiremath, Vaibhav] Thanks Murali, I really appreciate your comments here.
Please find response below -
> > +
> > +#include
>
> Add a line here??
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "omap_voutlib.h"
> > +#include "omap_voutdef.h"
> > +
> > +MODULE_AUTHOR("Texas Instruments");
> > +MODULE_DESCRIPTION("OMAP Video for Linux Video out driver");
> > +MODULE_LICENSE("GPL");
> > +
> > +
> > +/* Driver Configuration macros */
> > +#define VOUT_NAME "omap_vout"
> > +
> > +enum omap_vout_channels {
> > + OMAP_VIDEO1 = 0,
> Why do we have to initialize this to 0. It always start with a value 0
> by default.
>
> > + OMAP_VIDEO2,
> > +};
> > +
> > +enum dma_channel_state {
> > + DMA_CHAN_NOT_ALLOTED = 0,
>
> Ditto.
>
> > + DMA_CHAN_ALLOTED,
> > +};
> > +
> > +#define QQVGA_WIDTH160
> > +#define QQVGA_HEIGHT 120
> > +
> > +/* Max Resolution supported by the driver */
> > +#define VID_MAX_WIDTH 1280/* Largest width */
> > +#define VID_MAX_HEIGHT 720 /* Largest height */
> > +
>
> -
>
> > +
> > +module_param(debug, bool, S_IRUGO);
> > +MODULE_PARM_DESC(debug, "Debug level (0-1)");
> > +
> > +/* Local Helper functions */
> > +static void omap_vout_isr(void *arg, unsigned int irqstatus);
> > +static void omap_vout_cleanup_device(struct omap_vout_device *vout);
> > +
>
> Is there a reason why you need these prototypes? I think we could
> remove these prototypes and move the function ahead in the file before
> it is called.
>
[Hiremath, Vaibhav] Do you see any harm with this? I think its only
implementation part. But still I will incorporate in next version.
> > +/* list of image formats supported by OMAP2 video pipelines */
> > +const static struct v4l2_fmtdesc omap_formats[] = {
> > + {
> > + /* Note: V4L2 defines RGB565 as:
> > +*
> > +* Byte 0Byte 1
> > +* g2 g1 g0 r4 r3 r2 r1 r0 b4 b3 b2 b1 b0 g5 g4 g3
> > +*
> > +* We interpret RGB565 as:
> > +*
> > +* Byte 0Byte 1
> > +* g2 g1 g0 b4 b3 b2 b1 b0 r4 r3 r2 r1 r0 g5 g4 g3
> > +*/
> > + .description = "RGB565, le",
> > + .pixelformat = V4L2_PIX_FMT_RGB565,
> > + },
> > + {
> > + /* Note: V4L2 defines RGB32 as: RGB-8-8-8-8 we use
> > +* this for RGB24 unpack mode, the last 8 bits are
> ignored
> > +* */
> > + .description = "RGB32, le",
> > + .pixelformat = V4L2_PIX_FMT_RGB32,
> > + },
> > + {
> > + /* Note: V4L2 defines RGB24 as: RGB-8-8-8 we use
> > +*this for RGB24 packed mode
> > +*
> > +*/
> > + .description = "RGB24, le",
> > + .pixelformat = V4L2_PIX_FMT_RGB24,
> > + },
> > + {
> > + .description = "YUYV (YUV 4:2:2), packed",
> > + .pixelformat = V4L2_PIX_FMT_YUYV,
> > + },
> > + {
> > + .description = "UYVY, packed",
> > + .pixelformat = V4L2_PIX_FMT_UYVY,
> > + },
> > +};
> > +
> > +#define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
> > +
> > +/*
> > + * Allocate buffers
> > + */
>
> --
>
> > +
> > +/*
> > + * omap_vout_uservirt_to_phys: This inline function is used to convert
> user
> > + * space virtual address to physical address.
> > + */
> > +static u32 omap_vout_uservirt_to_phys(u32 virtp)
> > +{
> > + unsigned long physp = 0;
> > + struct vm_area_struct *vma;
> > + struct mm_struct *mm = current->mm;
> > +
> > + vma = find_vma(mm, virtp);
> > + /* For kernel direct-mapped memory, take the easy way */
> > + if (virtp >= PAGE_OFFSET) {
> > + physp = virt_to_phys((void *) virtp);
> > + } else if (vma && (vma->vm_flags & VM_IO)
> > + && vma->vm_pgoff) {
> > + /* this will catch, kernel-allocated,
> > + mmaped-to-usermode addresses */
> > + physp = (vma->vm_pgoff << PAGE_SHIFT) + (virtp - vma-
> >vm_start);
> > + } else {
> > + /* otherwise, use get_user_pages() for general userland
> pages */
> > + int res, nr_pages = 1;
> > +
Re: RFC: exposing controls in sysfs
On 6 April 2010 18:06, Jonathan Cameron wrote: > On 04/06/10 15:32, Mauro Carvalho Chehab wrote: >> Hans Verkuil wrote: Hans Verkuil wrote: > $ ls /sys/class/video4linux/video1/controls > balance mpeg_insert_navigation_packets > mpeg_video_aspect > brightness mpeg_median_chroma_filter_maximum > mpeg_video_b_frames > chroma_agc mpeg_median_chroma_filter_minimum > mpeg_video_bitrate > chroma_gain mpeg_median_filter_type > mpeg_video_bitrate_mode > contrast mpeg_median_luma_filter_maximum > mpeg_video_encoding > hue mpeg_median_luma_filter_minimum > mpeg_video_gop_closure > mpeg_audio_crc mpeg_spatial_chroma_filter_type > mpeg_video_gop_size > mpeg_audio_emphasis mpeg_spatial_filter > mpeg_video_mute > mpeg_audio_encoding mpeg_spatial_filter_mode > mpeg_video_mute_yuv > mpeg_audio_layer_ii_bitrate mpeg_spatial_luma_filter_type > mpeg_video_peak_bitrate > mpeg_audio_mute mpeg_stream_type > mpeg_video_temporal_decimation > mpeg_audio_sampling_frequency mpeg_stream_vbi_format > mute > mpeg_audio_stereo_mode mpeg_temporal_filter > saturation > mpeg_audio_stereo_mode_extension mpeg_temporal_filter_mode > volume It would be more intuitive if you group the classes with a few subdirs: /video/balance /video/brightness ... /mpeg_audio/crc /mpeg_audio/mute ... /audio/volume /audio/bass /audio/treble >>> >>> 1) We don't have that information. >>> 2) It would make a simple scheme suddenly a lot more complicated (see >>> Andy's comments) >>> 3) The main interface is always the application's GUI through ioctls, not >>> sysfs. >>> 4) Remember that ivtv has an unusually large number of controls. Most >>> drivers will just have the usual audio and video controls, perhaps 10 at >>> most. >> >> Ok. >> >>> I think we should just ditch this for the first implementation of the >>> control framework. It can always be added later, but once added it is >>> *much* harder to remove again. It's a nice proof-of-concept, though :-) >> >> I like the concept, especially if we can get rid of other similar sysfs >> interfaces >> that got added on a few drivers (pvrusb2 and some non-gspca drivers have >> it, for sure). I think I saw some of the gspca patches also touching on >> sysfs. >> Having this unified into a common interface is a bonus. > > Obviously it adds to the review burden, but perhaps we can state that the > sysfs > interface is only an additional option (and personally I think I'd find it > pretty > helpful for debugging if nothing else) and that all functionality there MUST > be > available through the normal routes? If any functionality only supported via > sysfs is seen as a bug, then we can point it out in reviews etc. > > I agree with Mauro that it would be really handy to unify any interfaces that > are > going to turn up there anyway. > > Generally I'm personally in favor with the convenience of sysfs interfaces > for quick > and dirty debugging purposes but perhaps this isn't the time to do it here. Hi all, I'm a newbie but I have to ask: how about using debugfs instead of sysfs? Then everyone will know that the interface is for debugging only and not production code :-) Best regards, Bjørn Forsman -- 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/2] V4L/DVB: Use custom I2C probing function mechanism
Hi Mauro,
On Tue, 06 Apr 2010 02:34:46 -0300, Mauro Carvalho Chehab wrote:
> Jean Delvare wrote:
> > On Mon, 05 Apr 2010 15:26:32 -0300, Mauro Carvalho Chehab wrote:
> >> Please, don't add new things at ir-common module. It basically contains the
> >> decoding functions for RC5 and pulse/distance, plus several IR keymaps.
> >> With
> >> the IR rework I'm doing, this module will go away, after having all the
> >> current
> >> IR decoders implemented via ir-raw-input binding.
> >>
> >> The keymaps were already removed from it, on my experimental tree
> >> (http://git.linuxtv.org/mchehab/ir.git), and rc5 decoder is already written
> >> (but still needs a few fixes).
> >>
> >> The new ir-core is creating an abstract way to deal with Remote
> >> Controllers,
> >> meant to be used not only by IR's, but also for other types of RC, like,
> >> bluetooth and USB HID. It will also export a raw event interface, for use
> >> with lirc. As this is the core of the RC subsystem, a i2c-specific binding
> >> method also doesn't seem to belong there. SO, IMO, the better place is to
> >> add
> >> it as a static inline function at ir-kbd-i2c.h.
> >
> > Ever tried to pass the address of an inline function as another
> > function's parameter? :)
>
> :) Never tried... maybe gcc would to the hard thing, de-inlining it ;)
>
> Well, we need to put this code somewhere. Where are the other probing
> codes? Probably the better is to put them together.
There are no other probing functions yet, this is the first one. I have
added the mechanism to i2c-core for these very IR chips.
Putting all probe functions together would mean moving them to
i2c-core. This wasn't my original intent, but after all, it makes some
sense. Would you be happy with the following?
* * * * *
From: Jean Delvare
Subject: V4L/DVB: Use custom I2C probing function mechanism
Now that i2c-core offers the possibility to provide custom probing
function for I2C devices, let's make use of it.
Signed-off-by: Jean Delvare
---
drivers/i2c/i2c-core.c|7 +++
drivers/media/video/cx23885/cx23885-i2c.c | 15 ---
drivers/media/video/cx88/cx88-i2c.c | 19 ---
include/linux/i2c.h |3 +++
4 files changed, 18 insertions(+), 26 deletions(-)
--- linux-2.6.34-rc3.orig/drivers/media/video/cx23885/cx23885-i2c.c
2010-04-06 11:31:20.0 +0200
+++ linux-2.6.34-rc3/drivers/media/video/cx23885/cx23885-i2c.c 2010-04-06
12:28:09.0 +0200
@@ -365,17 +365,10 @@ int cx23885_i2c_register(struct cx23885_
memset(&info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
- /*
-* We can't call i2c_new_probed_device() because it uses
-* quick writes for probing and the IR receiver device only
-* replies to reads.
-*/
- if (i2c_smbus_xfer(&bus->i2c_adap, addr_list[0], 0,
- I2C_SMBUS_READ, 0, I2C_SMBUS_QUICK,
- NULL) >= 0) {
- info.addr = addr_list[0];
- i2c_new_device(&bus->i2c_adap, &info);
- }
+ /* Use quick read command for probe, some IR chips don't
+* support writes */
+ i2c_new_probed_device(&bus->i2c_adap, &info, addr_list,
+ i2c_probe_func_quick_read);
}
return bus->i2c_rc;
--- linux-2.6.34-rc3.orig/drivers/media/video/cx88/cx88-i2c.c 2010-04-06
11:31:20.0 +0200
+++ linux-2.6.34-rc3/drivers/media/video/cx88/cx88-i2c.c2010-04-06
12:28:06.0 +0200
@@ -188,24 +188,13 @@ int cx88_i2c_init(struct cx88_core *core
0x18, 0x6b, 0x71,
I2C_CLIENT_END
};
- const unsigned short *addrp;
memset(&info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
- /*
-* We can't call i2c_new_probed_device() because it uses
-* quick writes for probing and at least some R receiver
-* devices only reply to reads.
-*/
- for (addrp = addr_list; *addrp != I2C_CLIENT_END; addrp++) {
- if (i2c_smbus_xfer(&core->i2c_adap, *addrp, 0,
- I2C_SMBUS_READ, 0,
- I2C_SMBUS_QUICK, NULL) >= 0) {
- info.addr = *addrp;
- i2c_new_device(&core->i2c_adap, &info);
- break;
- }
- }
+ /* Use quick read command for probe, some IR chips don't
+* support writes */
+ i2c_new_probed_device(&core->i2c_adap, &info, addr_list,
+
Re: RFC: exposing controls in sysfs
On 04/06/10 15:41, Mike Isely wrote: > On Tue, 6 Apr 2010, Hans Verkuil wrote: > >[...] > >> >> One thing that might be useful is to prefix the name with the control class >> name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It >> would >> groups them better. Or one could make a controls/user and controls/mpeg >> directory. That might not be such a bad idea actually. > > I agree with grouping in concept, and using subdirectories is not a bad > thing. Probably however you'd want to ensure that in the end all the > controls end up logically at the same depth in the tree. > > >[...] > >> >> An in between solution would be to add _type files. So you would have >> 'hue' and 'hue_type'. 'cat hue_type' would give something like: >> >> int 0 255 1 128 0x Hue >> >> In other words 'type min max step flags name'. > > There was I thought at some point in the past a kernel policy that sysfs > controls were supposed to limit themselves to one value per node. It's usually considered to be one 'conceptual' value per node, though this falls fowl of that rule too. So you could have one file with a list of possible values, or even one for say hue_range 0...255 but people are going to through a wobbly about antyhing with as much data in it as above. The debate on this was actually pretty well covered in an lwn article the other week. http://lwn.net/Articles/378884/ So the above hue type would probably need: hue_type (int) hue_range (0...255) hue_step (1) hue_flags (128) hue_name (Hue) Of those, hue_name doesn't in this case tell us anything and hue_step could be suppressed as an obvious default. It could be argued that parts of the above could be considered a single 'conceptual' value but I don't think the whole can be. The reasoning behind this (and it is definitely true with your above example) is that sysfs should be human readable without needing to reach for the documentation. > >> >> And for menu controls like stream_type (hmm, that would become >> stream_type_type...) you would get: >> >> menu 0 5 1 0 Stream Type >> MPEG-2 Program Stream >> >> MPEG-1 System Stream >> MPEG-2 DVD-compatible Stream >> MPEG-1 VCD-compatible Stream >> MPEG-2 SVCD-compatible Stream >> >> Note the empty line to denote the unsupported menu item (transport stream). >> >> This would give the same information with just a single extra file. Still not >> sure whether it is worth it though. > > Just remember that the more complex / subtle you make the node contents, > then the more parsing will be required for any program that tries to use > it. I also think it's probably a bad idea for example to define a > format where the whitespace conveys additional information. The case > where I've seen whitespace as part of the syntax actually work cleanly > is in Python. > > -- 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: RFC: exposing controls in sysfs
On 04/06/10 15:32, Mauro Carvalho Chehab wrote: > Hans Verkuil wrote: >>> Hans Verkuil wrote: $ ls /sys/class/video4linux/video1/controls balance mpeg_insert_navigation_packets mpeg_video_aspect brightnessmpeg_median_chroma_filter_maximum mpeg_video_b_frames chroma_agcmpeg_median_chroma_filter_minimum mpeg_video_bitrate chroma_gain mpeg_median_filter_type mpeg_video_bitrate_mode contrast mpeg_median_luma_filter_maximum mpeg_video_encoding hue mpeg_median_luma_filter_minimum mpeg_video_gop_closure mpeg_audio_crcmpeg_spatial_chroma_filter_type mpeg_video_gop_size mpeg_audio_emphasis mpeg_spatial_filter mpeg_video_mute mpeg_audio_encoding mpeg_spatial_filter_mode mpeg_video_mute_yuv mpeg_audio_layer_ii_bitrate mpeg_spatial_luma_filter_type mpeg_video_peak_bitrate mpeg_audio_mute mpeg_stream_type mpeg_video_temporal_decimation mpeg_audio_sampling_frequency mpeg_stream_vbi_format mute mpeg_audio_stereo_modempeg_temporal_filter saturation mpeg_audio_stereo_mode_extension mpeg_temporal_filter_mode volume >>> >>> It would be more intuitive if you group the classes with a few subdirs: >>> >>> /video/balance >>> /video/brightness >>> ... >>> /mpeg_audio/crc >>> /mpeg_audio/mute >>> ... >>> /audio/volume >>> /audio/bass >>> /audio/treble >> >> 1) We don't have that information. >> 2) It would make a simple scheme suddenly a lot more complicated (see >> Andy's comments) >> 3) The main interface is always the application's GUI through ioctls, not >> sysfs. >> 4) Remember that ivtv has an unusually large number of controls. Most >> drivers will just have the usual audio and video controls, perhaps 10 at >> most. > > Ok. > >> I think we should just ditch this for the first implementation of the >> control framework. It can always be added later, but once added it is >> *much* harder to remove again. It's a nice proof-of-concept, though :-) > > I like the concept, especially if we can get rid of other similar sysfs > interfaces > that got added on a few drivers (pvrusb2 and some non-gspca drivers have > it, for sure). I think I saw some of the gspca patches also touching on sysfs. > Having this unified into a common interface is a bonus. Obviously it adds to the review burden, but perhaps we can state that the sysfs interface is only an additional option (and personally I think I'd find it pretty helpful for debugging if nothing else) and that all functionality there MUST be available through the normal routes? If any functionality only supported via sysfs is seen as a bug, then we can point it out in reviews etc. I agree with Mauro that it would be really handy to unify any interfaces that are going to turn up there anyway. Generally I'm personally in favor with the convenience of sysfs interfaces for quick and dirty debugging purposes but perhaps this isn't the time to do it here. -- 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: RFC: exposing controls in sysfs
On Tue, 6 Apr 2010, Laurent Pinchart wrote: > Hi Andy, > > On Tuesday 06 April 2010 13:06:18 Andy Walls wrote: > > On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote: > > [snip] > > > > Again, I still don't know whether we should do this. It is dangerously > > > seductive because it would be so trivial to implement. > > > > It's like watching ships run aground on a shallow sandbar that all the > > locals know about. The waters off of 'Point /sys' are full of usability > > shipwrecks. I don't know if it's some siren's song, the lack of a light > > house, or just strange currents that deceive even seasoned > > navigators > > > > Let the user run 'v4l2-ctl -d /dev/videoN -L' to learn about the control > > metatdata. It's not as easy as typing 'cat', but the user base using > > sysfs in an interactive shell or shell script should also know how to > > use v4l2-ctl. In embedded systems, the final system deployment should > > not need the control metadata available from sysfs in a command shell > > anyway. > > I fully agree with this. If we push the idea one step further, why do we need > to expose controls in sysfs at all ? I have found it useful to have the sysfs interface within the pvrusb2 driver. If it is going to take a lot of work to specifically craft a sysfs interface that exports the V4L API, then it will probably be a pain to maintain going forward. By "a lot of work" I mean that each V4L API function would have to be explicitly coded for in this interface, thus as the V4L API evolves over time then extra work must be expended each time to keep the sysfs interface in step. If that is to be the case then it may not be worth it. In the pvrusb2 driver this has not been the case because the code I wrote which implements the sysfs interface for the driver does this programmatically. That is, there is nothing in the pvrusb2-sysfs.c module which is specific to a particular function. Instead, when the module initializes it is able to enumerate the API on its own and generate the appropriate interface for each control it finds. Thus as the pvrusb2 driver's implementation has evolved over time, the sysfs implementation has simply continues to do its job, automatically reflecting internal changes without any extra work in that module's code. I don't know if that same strategy could be done in the V4L core. If it could, then this would probably alleviate a lot of concerns about testing / maintenance going forward. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: RFC: exposing controls in sysfs
On Tue, 6 Apr 2010, Markus Rechberger wrote: [...] > > how about security permissions? while you can easily change the > permission levels for nodes in /dev you can't do this so easily with > sysfs entries. > I don't really think this is needed at all some applications will > start to use ioctl some other apps might > go for sysfs.. this makes the API a little bit whacko This is an excellent point. I should have brought this up sooner. The driver has control over the modes of the nodes in sysfs. The driver does NOT have control over the owner / group of those nodes. It is possible to change the owner / group from userspace, and I *think* it's possible to create a udev rule to do this, but honestly I have not investigated this possibility so I don't fully know. This is one serious potential drawback to using sysfs as a driver API. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: RFC: exposing controls in sysfs
On Tue, 6 Apr 2010, Devin Heitmueller wrote: [...] > > I tend to agree with Hans. We've already got *too many* interfaces > that do the same thing. The testing matrix is already a nightmare - > V4L1 versus V4L2, mmap() versus read(), legacy controls versus > extended controls, and don't get even me started on VBI. > > We should be working to make drivers and interfaces simpler, with > *fewer* ways of doing the same thing. The flexibility of providing > yet another interface via sysfs compared to just calling v4l2-ctl just > isn't worth the extra testing overhead. We've already got too much > stuff that needs to be fixed and not enough good developers to warrant > making the code more complicated with little tangible benefit. If another API (e.g. sysfs) is defined and it is specifically NOT permitted to be a complete set, then one can ultimately end up with situations where in order to effectively use a driver then multiple APIs *must* be used by the application. That's even worse. This situation already exists in the pvrusb2 driver and it's not because of sysfs - it's because of V4L and DVB. When the pvrusb2 driver is used to handle a hybrid device (such as the HVR-1950) one has to use both the DVB and V4L APIs in order to effectively operate the device. This is because both APIs provide something not available in the other. And this really sucks if all the user wants to do is "stream mpeg, darn it! And I don't care if it is digital or analog". I think that situation is very wrong; given that the HVR-1950 can spit out mpeg in either mode the user shouldn't be forced to make his application choice based on which mode he wants. There's only ONE application out there that allows the user to operate an HVR-1950 without being forced to deal with this: MythTV, and that's because, well, MythTV implements both APIs: V4L and DVB. I really, really dislike situations that arise where multiple APIs are *required* to operate a device, when really there should just be one API. That said, if multiple APIs are to be exported by the driver interface, then such APIs really should be as complete as possible in order to avoid potential problems later where because of previous limiting choices of API design now multiple APIs become required. I agree that testing against multiple APIs can be a pain and a drain on effort. But that has not happened with the pvrusb2 driver. It should be possible to implement the API in a way that minimizes further thrashing due to driver changes. The pvrusb2 sysfs implementation there is programmatically created when the driver comes up. The code which implements that interface really doesn't have any logic specific to particular API functions; it is just a reflection of what is internally in the driver. If new "knobs" are added to the pvrusb2 driver, then the knob automatically appears in the sysfs interface. If you were to go through the change history of the pvrusb2-sysfs.c module, all you're really going to find are changes caused by the sysfs class environment itself (i.e. when struct class was morphed into struct device), not the driver or its functionality. > > And nobody I've talked to who writes applications that work with V4L > has been screaming "OMG, if only V4L had a sysfs interface to manage > controls!" The experience I've seen with users and the pvrusb2 interface is that once they discover the sysfs API, the response is in fact very positive. Most users of the driver had no concept that such a thing was even possible until they were exposed to it. Now that's not to say that we should all be screaming for this - but if people didn't really understand what was possible, then how could they ask for it? -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: [RFC] Serialization flag example
Hans Verkuil wrote: >> Hans Verkuil wrote: >> - performance is important only for the ioctl's that directly handles >> the streaming (dbuf/dqbuf & friends); > > What performance? These calls just block waiting for a frame. How the hell > am I suppose to test performance anyway on something like that? They are called on the main loop for receiving buffers. As the userspace may be doing some video processing, by introducing latency here, you may affect the applications. By using perf subsystem, you should be able to test how much time is spent by an ioctl. > >> - videobuf has its own lock implementation; >> >> - a trivial mutex-based approach won't protect the stream to have >> some parameters modified by a VIDIOC_S_* ioctl (such protection should be >> provided by a resource locking); > > Generally once streaming starts drivers should return -EBUSY for such > calls. Nothing to do with locking in general. Yes, that's exactly what I said. This is a resource locking: you cannot change several stream properties while streaming (yet, you can change a few ones, like bright, contrast, etc). >> then, maybe the better would be to not call the hooks for those ioctls. >> It may be useful to do some perf tests and measure the real penalty before >> adding >> any extra code to exclude the buffer ioctls from the hook logic. > > Yuck. We want something easy to understand. Like: 'the hook is called for > every ioctl'. Not: 'the hook is called for every ioctl except this one and > this one and this one'. Then the driver might have to do different things > for different ioctls just because some behind-the-scene logic dictated > that the hook isn't called in some situations. > > I have said it before and I'll say it again: the problem with V4L2 drivers > has never been performance since all the heavy lifting is done with DMA, > the problem is complexity. Remember: premature optimization is the root of > all evil. If a driver really needs the last drop of performance (for what, > I wonder?) then it can choose to just not implement those hooks and do > everything itself. I tend to agree with you. All I'm saying is that it is valuable to double check the impacts before committing 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
Re: RFC: exposing controls in sysfs
On Tue, 6 Apr 2010, Hans Verkuil wrote: [...] > > One thing that might be useful is to prefix the name with the control class > name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It would > groups them better. Or one could make a controls/user and controls/mpeg > directory. That might not be such a bad idea actually. I agree with grouping in concept, and using subdirectories is not a bad thing. Probably however you'd want to ensure that in the end all the controls end up logically at the same depth in the tree. [...] > > An in between solution would be to add _type files. So you would have > 'hue' and 'hue_type'. 'cat hue_type' would give something like: > > int 0 255 1 128 0x Hue > > In other words 'type min max step flags name'. There was I thought at some point in the past a kernel policy that sysfs controls were supposed to limit themselves to one value per node. > > And for menu controls like stream_type (hmm, that would become > stream_type_type...) you would get: > > menu 0 5 1 0 Stream Type > MPEG-2 Program Stream > > MPEG-1 System Stream > MPEG-2 DVD-compatible Stream > MPEG-1 VCD-compatible Stream > MPEG-2 SVCD-compatible Stream > > Note the empty line to denote the unsupported menu item (transport stream). > > This would give the same information with just a single extra file. Still not > sure whether it is worth it though. Just remember that the more complex / subtle you make the node contents, then the more parsing will be required for any program that tries to use it. I also think it's probably a bad idea for example to define a format where the whitespace conveys additional information. The case where I've seen whitespace as part of the syntax actually work cleanly is in Python. -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: RFC: exposing controls in sysfs
Comments below... On Mon, 5 Apr 2010, Hans Verkuil wrote: > Hi all, > > The new control framework makes it very easy to expose controls in sysfs. > The way it is implemented now in the framework is that each device node > will get a 'controls' subdirectory in sysfs. Below which are all the controls > associated with that device node. > > So different device nodes can have different controls if so desired. > > The name of each sysfs file is derived from the control name, basically making > it lowercase, replacing ' ', '-' and '_' with '_' and skipping any other non- > alphanumerical characters. Seems to work well. > > For numerical controls you can write numbers in decimal, octal or hexadecimal. > > When you write to a button control it will ignore what you wrote, but still > execute the action. > > It looks like this for ivtv: > > $ ls /sys/class/video4linux/video1 > controls dev device index name power subsystem uevent > > $ ls /sys/class/video4linux/video1/controls > audio_crcchroma_gain > spatial_chroma_filter_type video_bitrate_mode > audio_emphasis contrast spatial_filter > video_encoding > audio_encoding hue > spatial_filter_mode video_gop_closure > audio_layer_ii_bitrate insert_navigation_packets > spatial_luma_filter_typevideo_gop_size > audio_mute median_chroma_filter_maximum stream_type > video_mute > audio_sampling_frequency median_chroma_filter_minimum stream_vbi_format > video_mute_yuv > audio_stereo_modemedian_filter_typetemporal_filter > video_peak_bitrate > audio_stereo_mode_extension median_luma_filter_maximum > temporal_filter_modevideo_temporal_decimation > balance median_luma_filter_minimumvideo_aspect > volume > brightness mute video_b_frames > chroma_agc saturationvideo_bitrate > > > The question is, is this sufficient? > > One of the few drivers that exposes controls in sysfs is pvrusb2. As far as > I can tell from the source it will create subdirectories under the device > node for each control. Those subdirs have the name ctl_ (e.g. > ctl_volume), and below that are files exposing all the attributes of that > control: name, type, min_val, max_val, def_val, cur_val, custom_val, enum_val > and bit_val. Most are clear, but some are a bit more obscure. enum_val is > basically a QUERYMENU and returns all menu options. bit_val seems to be used > for some non-control values like the TV standard that pvrusb2 also exposes > and where bit_val is a bit mask of all the valid bits that can be used. > > Mike, if you have any additional information, just let us know. My pvrusb2 > is in another country at the moment so I can't do any testing. Hans: What you see in the pvrusb2 driver is the result of an idea I had back in 2005. The pvrusb2 driver has an internal "control" API; my original idea back then was to then reimplement other interfaces on top of that API, in a manner that is as orthogonal as possible. The reality today is still pretty close to that concept (except for DVB unfortunately since that framework's architecture effectively has to take over the RF tuner...); the V4L2 implementation in the driver certainly works this way. The sysfs interface you see here is the result of implementing the same API through sysfs. Right now with the pvrusb2 driver the only thing not exported through sysfs is the actual streaming of video itself. The entire sysfs implementation in the driver can be found in pvrusb2-sysfs.c. Notice that the file is generic; there is not anything in it that is specific to any particular control. Rather, pvrusb2-sysfs.c is able to iterate through the driver's controls, picking up the control's name, its type, and accessors. Based on what it finds, this module then synthesizes the interface that you see in /class/pvrusb2/* - it's actually possible to add new controls to the driver without changing anything in pvrusb2-sysfs.c. > > Personally I think that it is overkill to basically expose the whole > QUERYCTRL information to sysfs. I see it as an easy and quick way to read and > modify controls via a command line. Over time, I have ended up using pretty much every control in that interface. Obviously not every control always gets touched, but I have found it extremely valuable to have such direct access to every "knob" in the driver this way. Also, the original concept was that the interface was to be orthogonal; in theory any kind of control action in one interface should be just as valid in another. > > Mike, do you know of anyone actively using that additional information? Yes. The VDR project at one time implemented a plugin to directly
Re: RFC: exposing controls in sysfs
Hans Verkuil wrote: >> Hans Verkuil wrote: >>> $ ls /sys/class/video4linux/video1/controls >>> balance mpeg_insert_navigation_packets >>> mpeg_video_aspect >>> brightnessmpeg_median_chroma_filter_maximum >>> mpeg_video_b_frames >>> chroma_agcmpeg_median_chroma_filter_minimum >>> mpeg_video_bitrate >>> chroma_gain mpeg_median_filter_type >>> mpeg_video_bitrate_mode >>> contrast mpeg_median_luma_filter_maximum >>> mpeg_video_encoding >>> hue mpeg_median_luma_filter_minimum >>> mpeg_video_gop_closure >>> mpeg_audio_crcmpeg_spatial_chroma_filter_type >>> mpeg_video_gop_size >>> mpeg_audio_emphasis mpeg_spatial_filter >>> mpeg_video_mute >>> mpeg_audio_encoding mpeg_spatial_filter_mode >>> mpeg_video_mute_yuv >>> mpeg_audio_layer_ii_bitrate mpeg_spatial_luma_filter_type >>> mpeg_video_peak_bitrate >>> mpeg_audio_mute mpeg_stream_type >>> mpeg_video_temporal_decimation >>> mpeg_audio_sampling_frequency mpeg_stream_vbi_format >>> mute >>> mpeg_audio_stereo_modempeg_temporal_filter >>> saturation >>> mpeg_audio_stereo_mode_extension mpeg_temporal_filter_mode >>> volume >> >> It would be more intuitive if you group the classes with a few subdirs: >> >> /video/balance >> /video/brightness >> ... >> /mpeg_audio/crc >> /mpeg_audio/mute >> ... >> /audio/volume >> /audio/bass >> /audio/treble > > 1) We don't have that information. > 2) It would make a simple scheme suddenly a lot more complicated (see > Andy's comments) > 3) The main interface is always the application's GUI through ioctls, not > sysfs. > 4) Remember that ivtv has an unusually large number of controls. Most > drivers will just have the usual audio and video controls, perhaps 10 at > most. Ok. > I think we should just ditch this for the first implementation of the > control framework. It can always be added later, but once added it is > *much* harder to remove again. It's a nice proof-of-concept, though :-) I like the concept, especially if we can get rid of other similar sysfs interfaces that got added on a few drivers (pvrusb2 and some non-gspca drivers have it, for sure). I think I saw some of the gspca patches also touching on sysfs. Having this unified into a common interface is a bonus. -- 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: [RFC] Teach drivers/media/IR/ir-raw-event.c to use durations
Hi David,
Em Tue, 6 Apr 2010 12:48:11 +0200
David Härdeman escreveu:
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline; filename=use-pulse-space-timings-in-ir-raw
Thunderbird 2 really don't like this. It considers the entire body as a file,
and
refuses to quote it.
> drivers/media/IR/ir-raw-event.c is currently written with the assumption that
> all "raw" hardware will generate events only on state change (i.e. when
> a pulse or space starts).
>
> However, some hardware (like mceusb, probably the most popular IR receiver
> out there) only generates duration data (and that data is buffered so using
> any kind of timing on the data is futile).
Am I understanding right and this hardware is not capable of indicating if the
event is a pulse or a space? It seems hard to auto-detect what is pulse or
space,
but IMO such code should belong to mceusb driver and not to the decoders.
Based on the code changes you did, I suspect that one of the things the hardware
provides is a "machine reset" state, right? If you just need to add a code to
reset
the state machines, this could be done as easily as adding an event at kfifo
with
IR_STOP_EVENT. A three line addition at the decoders event handler would be
enough
to use it to reset the state machine:
if (ev->type & IR_STOP_EVENT) {
data->state = STATE_INACTIVE;
return;
}
This event were not added yet, since no hardware currently ported needs it.
Eventually,
we may rename it to IR_RESET_STATE, if you think it is clearer.
> This patch (which is not tested since I haven't yet converted a driver for
> any of my hardware to ir-core yet, will do soon) is a RFC on my proposed
> interface change...once I get the green light on the interface change itself
> I'll make sure that the decoders actually work :)
Yes, better to discuss before changing everything ;)
> The rc5 decoder has also gained rc5x support and the use of kfifo's for
> intermediate storage is gone (since there is no need for it).
The RC-5X addition is welcome, but the better is to add it as a separate patch.
I won't comment every single bits of the change, since we're more interested on
the conceptual
aspects.
> -int ir_raw_event_store(struct input_dev *input_dev, enum raw_event_type type)
Don't remove the raw_event_store. It is needed by the hardware that gets events
from
IRQ/polling. For sure another interface is needed, for the cases where the
hardware pass their
own time measure, like cx18
(http://linuxtv.org/hg/~awalls/cx23885-ir2/rev/2cfef53b95a2).
For those, we need something like:
int ir_raw_event_time_store(struct input_dev *input_dev, enum raw_event_type
type, u32 nsecs)
Where, instead of using ktime_get_ts(), it will use the timing provided by the
hardware.
>
> -int ir_raw_event_handle(struct input_dev *input_dev)
> +/**
> + * ir_raw_event_edge() - notify raw ir decoders of the start of a pulse/space
> + * @input_dev: the struct input_dev device descriptor
> + * @type:the type of the event that has occurred
> + *
> + * This routine is used to notify the raw ir decoders on the beginning of an
> + * ir pulse or space (or the start/end of ir reception). This is used by
> + * hardware which does not provide durations directly but only interrupts
> + * (or similar events) on state change.
> + */
> +void ir_raw_event_edge(struct input_dev *input_dev, enum raw_event_type type)
> {
> - struct ir_input_dev *ir = input_get_drvdata(input_dev);
> - int rc;
> - struct ir_raw_event ev;
> - int len, i;
> -
> - /*
> - * Store the events into a temporary buffer. This allows calling more
> than
> - * one decoder to deal with the received data
> - */
> - len = kfifo_len(&ir->raw->kfifo) / sizeof(ev);
> - if (!len)
> - return 0;
The removal of kfifo is not a good idea. On several drivers, the event is
generated during
IRQ time, or on a very expensive polling loop. So, buffering is needed to
release the
IRQ as soon as possible and not adding too much processing during polling.
> -
> - for (i = 0; i < len; i++) {
> - rc = kfifo_out(&ir->raw->kfifo, &ev, sizeof(ev));
> - if (rc != sizeof(ev)) {
> - IR_dprintk(1, "overflow error: received %d instead of
> %zd\n",
> -rc, sizeof(ev));
> - return -EINVAL;
> - }
> - IR_dprintk(2, "event type %d, time before event: %07luus\n",
> - ev.type, (ev.delta.tv_nsec + 500) / 1000);
> - rc = RUN_DECODER(decode, input_dev, &ev);
> - }
> + struct ir_input_dev *ir = input_get_drvdata(input_dev);
> + ktime_t now;
> + s64 delta; /* us */
> +
> + if (!ir->raw)
> + return;
>
> - /*
> - * Call all ir decoders. Thi
Re: RFC: exposing controls in sysfs
On Tue, Apr 6, 2010 at 9:44 AM, Hans Verkuil wrote: > 1) We don't have that information. > 2) It would make a simple scheme suddenly a lot more complicated (see > Andy's comments) > 3) The main interface is always the application's GUI through ioctls, not > sysfs. > 4) Remember that ivtv has an unusually large number of controls. Most > drivers will just have the usual audio and video controls, perhaps 10 at > most. > > Strife for simplicity. I'm not sure whether we want to have this in sysfs > at all. While nice there is a danger that people suddenly see it as the > main API. And Markus' comment regarding permissions was a good one, I > thought. > > I think we should just ditch this for the first implementation of the > control framework. It can always be added later, but once added it is > *much* harder to remove again. It's a nice proof-of-concept, though :-) I tend to agree with Hans. We've already got *too many* interfaces that do the same thing. The testing matrix is already a nightmare - V4L1 versus V4L2, mmap() versus read(), legacy controls versus extended controls, and don't get even me started on VBI. We should be working to make drivers and interfaces simpler, with *fewer* ways of doing the same thing. The flexibility of providing yet another interface via sysfs compared to just calling v4l2-ctl just isn't worth the extra testing overhead. We've already got too much stuff that needs to be fixed and not enough good developers to warrant making the code more complicated with little tangible benefit. And nobody I've talked to who writes applications that work with V4L has been screaming "OMG, if only V4L had a sysfs interface to manage controls!" Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Serialization flag example
> Hans Verkuil wrote: >> On Tuesday 06 April 2010 00:58:54 Hans Verkuil wrote: >>> On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote: On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote: > After looking at the proposed solution, I personally find the > suggestion for a serialization flag to be quite ridiculous. As others > have mentioned, the mere presence of the flag means that driver > writers will gloss over any concurrency issues that might exist in > their driver on the mere assumption that specifying the serialization > flag will handle it all for them. I happen to agree with this. Proper locking is difficult, but that's not a reason to introduce such a workaround. I'd much rather see proper documentation for driver developers on how to implement locking properly. >>> I've taken a different approach in another tree: >>> >>> http://linuxtv.org/hg/~hverkuil/v4l-dvb-ser2/ >>> >>> It adds two callbacks to ioctl_ops: pre_hook and post_hook. You can use >>> these >>> to do things like prio checking and taking your own mutex to serialize >>> the >>> ioctl call. >>> >>> This might be a good compromise between convenience and not hiding >>> anything. >> >> I realized that something like this is needed anyway if we go ahead with >> the >> new control framework. That exposes controls in sysfs, but if you set a >> control >> from sysfs, then that bypasses the ioctl completely. So you need a way >> to hook >> into whatever serialization scheme you have (if any). >> >> It is trivial to get to the video_device struct in the control handler >> and >> from there you can access ioctl_ops. So calling the pre/post hooks for >> the >> sysfs actions is very simple. >> >> The prototype for the hooks needs to change, though, since accesses from >> sysfs do not provide you with a struct file pointer. >> >> Something like this should work: >> >> int pre_hook(struct video_device *vdev, enum v4l2_priority prio, int >> cmd); >> void post_hook(struct video_device *vdev, int cmd); >> >> The prio is there to make priority checking possible. It will be >> initially >> unused, but as soon as the events API with the new v4l2_fh struct is >> merged >> we can add centralized support for this. > > I like this strategy. > > My only concern is about performance. Especially in the cases where we > need to > handle the command at the hooks, those methods will introduce two extra > jumps > to the driver and two extra switches. As the jump will go to a code > outside > V4L core, I suspect that they'll likely flush the L1 cache. > > If we consider that: > > - performance is important only for the ioctl's that directly handles > the streaming (dbuf/dqbuf & friends); What performance? These calls just block waiting for a frame. How the hell am I suppose to test performance anyway on something like that? > > - videobuf has its own lock implementation; > > - a trivial mutex-based approach won't protect the stream to have > some parameters modified by a VIDIOC_S_* ioctl (such protection should be > provided by a resource locking); Generally once streaming starts drivers should return -EBUSY for such calls. Nothing to do with locking in general. > then, maybe the better would be to not call the hooks for those ioctls. > It may be useful to do some perf tests and measure the real penalty before > adding > any extra code to exclude the buffer ioctls from the hook logic. Yuck. We want something easy to understand. Like: 'the hook is called for every ioctl'. Not: 'the hook is called for every ioctl except this one and this one and this one'. Then the driver might have to do different things for different ioctls just because some behind-the-scene logic dictated that the hook isn't called in some situations. I have said it before and I'll say it again: the problem with V4L2 drivers has never been performance since all the heavy lifting is done with DMA, the problem is complexity. Remember: premature optimization is the root of all evil. If a driver really needs the last drop of performance (for what, I wonder?) then it can choose to just not implement those hooks and do everything itself. Regards, Hans > > -- > > Cheers, > Mauro > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: exposing controls in sysfs
> Hans Verkuil wrote: >> $ ls /sys/class/video4linux/video1/controls >> balance mpeg_insert_navigation_packets >> mpeg_video_aspect >> brightnessmpeg_median_chroma_filter_maximum >> mpeg_video_b_frames >> chroma_agcmpeg_median_chroma_filter_minimum >> mpeg_video_bitrate >> chroma_gain mpeg_median_filter_type >> mpeg_video_bitrate_mode >> contrast mpeg_median_luma_filter_maximum >> mpeg_video_encoding >> hue mpeg_median_luma_filter_minimum >> mpeg_video_gop_closure >> mpeg_audio_crcmpeg_spatial_chroma_filter_type >> mpeg_video_gop_size >> mpeg_audio_emphasis mpeg_spatial_filter >> mpeg_video_mute >> mpeg_audio_encoding mpeg_spatial_filter_mode >> mpeg_video_mute_yuv >> mpeg_audio_layer_ii_bitrate mpeg_spatial_luma_filter_type >> mpeg_video_peak_bitrate >> mpeg_audio_mute mpeg_stream_type >> mpeg_video_temporal_decimation >> mpeg_audio_sampling_frequency mpeg_stream_vbi_format >> mute >> mpeg_audio_stereo_modempeg_temporal_filter >> saturation >> mpeg_audio_stereo_mode_extension mpeg_temporal_filter_mode >> volume > > > It would be more intuitive if you group the classes with a few subdirs: > > /video/balance > /video/brightness > ... > /mpeg_audio/crc > /mpeg_audio/mute > ... > /audio/volume > /audio/bass > /audio/treble 1) We don't have that information. 2) It would make a simple scheme suddenly a lot more complicated (see Andy's comments) 3) The main interface is always the application's GUI through ioctls, not sysfs. 4) Remember that ivtv has an unusually large number of controls. Most drivers will just have the usual audio and video controls, perhaps 10 at most. Strife for simplicity. I'm not sure whether we want to have this in sysfs at all. While nice there is a danger that people suddenly see it as the main API. And Markus' comment regarding permissions was a good one, I thought. I think we should just ditch this for the first implementation of the control framework. It can always be added later, but once added it is *much* harder to remove again. It's a nice proof-of-concept, though :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: webcam problem after suspend/hibernate
On Tue 2010-04-06 11:32:46, Mohamed Ikbel Boulabiar wrote: > Hi ! > > > Ok, that puts the problem firmly into uvcvideo area. > > > > Try changing its _resume routine to whatever is done on device > > unplug... it should be rather easy, and is quite close to "correct" > > solution. > > I am waiting to try that. > > If I always need to rmmod/modprobe everytime, that is meaning that > something is kept messed somewhere in memory and should be cleaned by > restart (reinitialize ?) the device. Yes. And it also means that problem is within the stuff being rmmoded/insmoded. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: RFC: exposing controls in sysfs
Hans Verkuil wrote: > On Tuesday 06 April 2010 00:12:48 Hans Verkuil wrote: >> On Monday 05 April 2010 23:47:10 Hans Verkuil wrote: >>> Hi all, >>> >>> The new control framework makes it very easy to expose controls in sysfs. >>> The way it is implemented now in the framework is that each device node >>> will get a 'controls' subdirectory in sysfs. Below which are all the >>> controls >>> associated with that device node. >>> >>> So different device nodes can have different controls if so desired. >>> >>> The name of each sysfs file is derived from the control name, basically >>> making >>> it lowercase, replacing ' ', '-' and '_' with '_' and skipping any other >>> non- >>> alphanumerical characters. Seems to work well. >>> >>> For numerical controls you can write numbers in decimal, octal or >>> hexadecimal. >>> >>> When you write to a button control it will ignore what you wrote, but still >>> execute the action. >>> >>> It looks like this for ivtv: >>> >>> $ ls /sys/class/video4linux/video1 >>> controls dev device index name power subsystem uevent >>> >>> $ ls /sys/class/video4linux/video1/controls >>> audio_crcchroma_gain >>> spatial_chroma_filter_type video_bitrate_mode >>> audio_emphasis contrast spatial_filter >>>video_encoding >>> audio_encoding hue >>> spatial_filter_mode video_gop_closure >>> audio_layer_ii_bitrate insert_navigation_packets >>> spatial_luma_filter_typevideo_gop_size >>> audio_mute median_chroma_filter_maximum stream_type >>>video_mute >>> audio_sampling_frequency median_chroma_filter_minimum >>> stream_vbi_format video_mute_yuv >>> audio_stereo_modemedian_filter_typetemporal_filter >>>video_peak_bitrate >>> audio_stereo_mode_extension median_luma_filter_maximum >>> temporal_filter_modevideo_temporal_decimation >>> balance median_luma_filter_minimumvideo_aspect >>>volume >>> brightness mute video_b_frames >>> chroma_agc saturationvideo_bitrate >>> >>> >>> The question is, is this sufficient? >> One thing that might be useful is to prefix the name with the control class >> name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It >> would >> groups them better. Or one could make a controls/user and controls/mpeg >> directory. That might not be such a bad idea actually. > > Replying to your own mails is probably a bad sign, but I can't help myself :-) > > I've changed the code to add a control class prefix for all but the user > controls. > It looks much better now: > > $ ls /sys/class/video4linux/video1/controls > balance mpeg_insert_navigation_packets > mpeg_video_aspect > brightnessmpeg_median_chroma_filter_maximum > mpeg_video_b_frames > chroma_agcmpeg_median_chroma_filter_minimum > mpeg_video_bitrate > chroma_gain mpeg_median_filter_type > mpeg_video_bitrate_mode > contrast mpeg_median_luma_filter_maximum > mpeg_video_encoding > hue mpeg_median_luma_filter_minimum > mpeg_video_gop_closure > mpeg_audio_crcmpeg_spatial_chroma_filter_type > mpeg_video_gop_size > mpeg_audio_emphasis mpeg_spatial_filter > mpeg_video_mute > mpeg_audio_encoding mpeg_spatial_filter_mode > mpeg_video_mute_yuv > mpeg_audio_layer_ii_bitrate mpeg_spatial_luma_filter_type > mpeg_video_peak_bitrate > mpeg_audio_mute mpeg_stream_type > mpeg_video_temporal_decimation > mpeg_audio_sampling_frequency mpeg_stream_vbi_format mute > mpeg_audio_stereo_modempeg_temporal_filter > saturation > mpeg_audio_stereo_mode_extension mpeg_temporal_filter_mode volume It would be more intuitive if you group the classes with a few subdirs: /video/balance /video/brightness ... /mpeg_audio/crc /mpeg_audio/mute ... /audio/volume /audio/bass /audio/treble .. -- 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: [RFC] Serialization flag example
Hans Verkuil wrote: > On Tuesday 06 April 2010 00:58:54 Hans Verkuil wrote: >> On Tuesday 06 April 2010 00:46:11 Laurent Pinchart wrote: >>> On Sunday 04 April 2010 05:14:17 David Ellingsworth wrote: After looking at the proposed solution, I personally find the suggestion for a serialization flag to be quite ridiculous. As others have mentioned, the mere presence of the flag means that driver writers will gloss over any concurrency issues that might exist in their driver on the mere assumption that specifying the serialization flag will handle it all for them. >>> I happen to agree with this. Proper locking is difficult, but that's not a >>> reason to introduce such a workaround. I'd much rather see proper >>> documentation for driver developers on how to implement locking properly. >> I've taken a different approach in another tree: >> >> http://linuxtv.org/hg/~hverkuil/v4l-dvb-ser2/ >> >> It adds two callbacks to ioctl_ops: pre_hook and post_hook. You can use these >> to do things like prio checking and taking your own mutex to serialize the >> ioctl call. >> >> This might be a good compromise between convenience and not hiding anything. > > I realized that something like this is needed anyway if we go ahead with the > new control framework. That exposes controls in sysfs, but if you set a > control > from sysfs, then that bypasses the ioctl completely. So you need a way to hook > into whatever serialization scheme you have (if any). > > It is trivial to get to the video_device struct in the control handler and > from there you can access ioctl_ops. So calling the pre/post hooks for the > sysfs actions is very simple. > > The prototype for the hooks needs to change, though, since accesses from > sysfs do not provide you with a struct file pointer. > > Something like this should work: > > int pre_hook(struct video_device *vdev, enum v4l2_priority prio, int cmd); > void post_hook(struct video_device *vdev, int cmd); > > The prio is there to make priority checking possible. It will be initially > unused, but as soon as the events API with the new v4l2_fh struct is merged > we can add centralized support for this. I like this strategy. My only concern is about performance. Especially in the cases where we need to handle the command at the hooks, those methods will introduce two extra jumps to the driver and two extra switches. As the jump will go to a code outside V4L core, I suspect that they'll likely flush the L1 cache. If we consider that: - performance is important only for the ioctl's that directly handles the streaming (dbuf/dqbuf & friends); - videobuf has its own lock implementation; - a trivial mutex-based approach won't protect the stream to have some parameters modified by a VIDIOC_S_* ioctl (such protection should be provided by a resource locking); then, maybe the better would be to not call the hooks for those ioctls. It may be useful to do some perf tests and measure the real penalty before adding any extra code to exclude the buffer ioctls from the hook logic. -- 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] V4L/DVB: saa7146: Making IRQF_DISABLED or IRQF_SHARED optional
Oliver Endriss writes: > Bjørn Mork wrote: >> As discussed many times, e.g. in http://lkml.org/lkml/2007/7/26/401 >> mixing IRQF_DISABLED with IRQF_SHARED may cause unpredictable and >> unexpected results. >> >> Add a module parameter to allow fine tuning the request_irq >> flags based on local system requirements. Some may need to turn >> off IRQF_DISABLED to be able to share interrupt with drivers >> needing interrupts enabled, while others may want to turn off >> IRQF_SHARED to ensure that IRQF_DISABLED has an effect. > > NAK. We should not add module parameters for this kind of crap. OK. You are perfectly right. This is something that Should Just Work(tm) without any user intervention. Sorry for adding confusion. > Let's check whether IRQF_DISABLED is really required. > Afaics it can be removed. Thanks for reviewing. > @all: > Please check whether the first patch causes any problems. Anyone? FWIW, I do have real stabilitity problems with IRQF_DISABLED. Removing it seem to have resolved these, and I have not noticed any regressions. If it matters, this is tested on a quad core system with two DVB-C cards (one budget-av and one mantis): bj...@canardo:~$ lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] (rev 02) 00:01.0 PCI bridge [0604]: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port [8086:29c1] (rev 02) 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 02) 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 02) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 02) 00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 [8086:2948] (rev 02) 00:1c.5 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 [8086:294a] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 02) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 02) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 02) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 92) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9) LPC Interface Controller [8086:2918] (rev 02) 00:1f.2 SATA controller [0106]: Intel Corporation 82801IB (ICH9) 4 port SATA AHCI Controller [8086:2923] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02) 01:00.0 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit Ethernet Controller [8086:105e] (rev 06) 01:00.1 Ethernet controller [0200]: Intel Corporation 82571EB Gigabit Ethernet Controller [8086:105e] (rev 06) 02:00.0 Ethernet controller [0200]: Atheros Communications L1 Gigabit Ethernet Adapter [1969:1048] (rev b0) 03:00.0 SATA controller [0106]: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller [197b:2363] (rev 03) 03:00.1 IDE interface [0101]: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller [197b:2363] (rev 03) 04:00.0 RAID bus controller [0104]: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller [1095:3132] (rev 01) 05:00.0 Multimedia controller [0480]: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] [1822:4e35] (rev 01) 05:01.0 Multimedia controller [0480]: Philips Semiconductors SAA7146 [1131:7146] (rev 01) 05:02.0 PCI bridge [0604]: Intel Corporation 80960RP (i960RP) Microprocessor/Bridge [8086:0960] (rev 05) 05:02.1 Memory controller [0580]: Intel Corporation 80960RP (i960RP) Microprocessor [8086:1960] (rev 05) 05:03.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev c0) 06:00.0 VGA compatible controller [0300]: ATI Technologies Inc 3D Rage IIC 215IIC [Mach64 GT IIC] [1002:4756] (rev 7a) canardo:/tmp# lspci -vvnns 5:0 05:00.0 Multimedia controller [0480]: Twinhan Technology Co. Ltd Mantis DTV PCI Bridge Controller [Ver 1.0] [1822:4e35] (rev 01) Subsystem: TERRATEC Electronic GmbH Device [153b:1178] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- http://vger.kernel.org/majordomo-info.html
Re: RFC: exposing controls in sysfs
On Tue, Apr 6, 2010 at 1:27 PM, Laurent Pinchart wrote: > Hi Andy, > > On Tuesday 06 April 2010 13:06:18 Andy Walls wrote: >> On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote: > > [snip] > >> > Again, I still don't know whether we should do this. It is dangerously >> > seductive because it would be so trivial to implement. >> >> It's like watching ships run aground on a shallow sandbar that all the >> locals know about. The waters off of 'Point /sys' are full of usability >> shipwrecks. I don't know if it's some siren's song, the lack of a light >> house, or just strange currents that deceive even seasoned >> navigators >> >> Let the user run 'v4l2-ctl -d /dev/videoN -L' to learn about the control >> metatdata. It's not as easy as typing 'cat', but the user base using >> sysfs in an interactive shell or shell script should also know how to >> use v4l2-ctl. In embedded systems, the final system deployment should >> not need the control metadata available from sysfs in a command shell >> anyway. > > I fully agree with this. If we push the idea one step further, why do we need > to expose controls in sysfs at all ? > how about security permissions? while you can easily change the permission levels for nodes in /dev you can't do this so easily with sysfs entries. I don't really think this is needed at all some applications will start to use ioctl some other apps might go for sysfs.. this makes the API a little bit whacko Markus -- 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: RFC: exposing controls in sysfs
Hi Andy, On Tuesday 06 April 2010 13:06:18 Andy Walls wrote: > On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote: [snip] > > Again, I still don't know whether we should do this. It is dangerously > > seductive because it would be so trivial to implement. > > It's like watching ships run aground on a shallow sandbar that all the > locals know about. The waters off of 'Point /sys' are full of usability > shipwrecks. I don't know if it's some siren's song, the lack of a light > house, or just strange currents that deceive even seasoned > navigators > > Let the user run 'v4l2-ctl -d /dev/videoN -L' to learn about the control > metatdata. It's not as easy as typing 'cat', but the user base using > sysfs in an interactive shell or shell script should also know how to > use v4l2-ctl. In embedded systems, the final system deployment should > not need the control metadata available from sysfs in a command shell > anyway. I fully agree with this. If we push the idea one step further, why do we need to expose controls in sysfs at all ? -- 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: RFC: exposing controls in sysfs
On Tue, 2010-04-06 at 08:37 +0200, Hans Verkuil wrote: > On Tuesday 06 April 2010 00:12:48 Hans Verkuil wrote: > > On Monday 05 April 2010 23:47:10 Hans Verkuil wrote: > > One thing that might be useful is to prefix the name with the control class > > name. E.g. hue becomes user_hue and audio_crc becomes mpeg_audio_crc. It > > would > > groups them better. Or one could make a controls/user and controls/mpeg > > directory. That might not be such a bad idea actually. > > Replying to your own mails is probably a bad sign, but I can't help myself :-) I had an old InfoCom text adventure game that would respond to querying oneself with: "Talking to oneself is a sign of impending mental collapse." :D > I've changed the code to add a control class prefix for all but the user > controls. > It looks much better now: > > $ ls /sys/class/video4linux/video1/controls > balance mpeg_insert_navigation_packets > mpeg_video_aspect > brightnessmpeg_median_chroma_filter_maximum > mpeg_video_b_frames > chroma_agcmpeg_median_chroma_filter_minimum > mpeg_video_bitrate > chroma_gain mpeg_median_filter_type > mpeg_video_bitrate_mode > contrast mpeg_median_luma_filter_maximum > mpeg_video_encoding > hue mpeg_median_luma_filter_minimum > mpeg_video_gop_closure > mpeg_audio_crcmpeg_spatial_chroma_filter_type > mpeg_video_gop_size > mpeg_audio_emphasis mpeg_spatial_filter > mpeg_video_mute > mpeg_audio_encoding mpeg_spatial_filter_mode > mpeg_video_mute_yuv > mpeg_audio_layer_ii_bitrate mpeg_spatial_luma_filter_type > mpeg_video_peak_bitrate > mpeg_audio_mute mpeg_stream_type > mpeg_video_temporal_decimation > mpeg_audio_sampling_frequency mpeg_stream_vbi_format mute > mpeg_audio_stereo_modempeg_temporal_filter > saturation > mpeg_audio_stereo_mode_extension mpeg_temporal_filter_mode volume So this is beginning to look OK. You'll have longer names when a class name is longer than 4 characters (e.g. "technician_" ). However, I suppose it is better than another directory which creates a deeper hierarchy while still not avoiding the longer pathname. > > > One of the few drivers that exposes controls in sysfs is pvrusb2. As far > > > as > > > I can tell from the source it will create subdirectories under the device > > > node for each control. Those subdirs have the name ctl_ > > > (e.g. > > > ctl_volume), and below that are files exposing all the attributes of that > > > control: name, type, min_val, max_val, def_val, cur_val, custom_val, > > > enum_val > > > and bit_val. Most are clear, but some are a bit more obscure. enum_val is > > > basically a QUERYMENU and returns all menu options. bit_val seems to be > > > used > > > for some non-control values like the TV standard that pvrusb2 also exposes > > > and where bit_val is a bit mask of all the valid bits that can be used. > > > > > > Mike, if you have any additional information, just let us know. My pvrusb2 > > > is in another country at the moment so I can't do any testing. > > > > > > Personally I think that it is overkill to basically expose the whole > > > QUERYCTRL information to sysfs. I see it as an easy and quick way to read > > > and > > > modify controls via a command line. > > An in between solution would be to add _type files. So you would have 'hue' > > and > > 'hue_type'. 'cat hue_type' would give something like: > > If we go for something like this, then I think it would be better to make a > new subdirectory. So 'controls' just has the controls, and 'ctrl_info' or > something similar would have read-only files containing this information. sysfs' major usability problem for humans is the insane directory depths it can reach and the cross-links to everywhere. Humans attempt to keep a mental model of "where" they are in a logical "space", and sysfs is like "maze of twisty little passages, all alike". In the true sysfs spirit you should create a 'ctrl_info' directory full of nodes with metadata *and* also create "foo_type" symlinks to all of those metadata nodes. Bonus points for having the 'ctrl_info' directory and 'foo_type' symlinks in a different part of the sysfs tree but with a similar directory name. > Again, I still don't know whether we should do this. It is dangerously > seductive because it would be so trivial to implement. It's like watching ships run aground on a shallow sandbar that all the locals know about. The waters off of 'Point /sys' are full of usability shipwrecks. I don't know if it's some siren's song, the lack of a light house, or just strange currents that deceive even seasoned navigators Let the user run 'v4l2-ctl -d /dev/videoN -L' to learn about th
[RFC] Teach drivers/media/IR/ir-raw-event.c to use durations
drivers/media/IR/ir-raw-event.c is currently written with the assumption that
all "raw" hardware will generate events only on state change (i.e. when
a pulse or space starts).
However, some hardware (like mceusb, probably the most popular IR receiver
out there) only generates duration data (and that data is buffered so using
any kind of timing on the data is futile).
This patch (which is not tested since I haven't yet converted a driver for
any of my hardware to ir-core yet, will do soon) is a RFC on my proposed
interface change...once I get the green light on the interface change itself
I'll make sure that the decoders actually work :)
The rc5 decoder has also gained rc5x support and the use of kfifo's for
intermediate storage is gone (since there is no need for it).
diffstat:
drivers/media/IR/ir-nec-decoder.c | 229 +++-
drivers/media/IR/ir-raw-event.c | 143 -
drivers/media/IR/ir-rc5-decoder.c | 204 +++-
drivers/media/video/saa7134/saa7134-input.c |4
include/media/ir-core.h | 18 --
5 files changed, 291 insertions(+), 307 deletions(-)
Index: ir/drivers/media/IR/ir-raw-event.c
===
--- ir.orig/drivers/media/IR/ir-raw-event.c 2010-04-06 12:16:27.0
+0200
+++ ir/drivers/media/IR/ir-raw-event.c 2010-04-06 12:17:08.856877124 +0200
@@ -15,13 +15,11 @@
#include
#include
#include
-
-/* Define the max number of bit transitions per IR keycode */
-#define MAX_IR_EVENT_SIZE 256
+#include
/* Used to handle IR raw handler extensions */
static LIST_HEAD(ir_raw_handler_list);
-static spinlock_t ir_raw_handler_lock;
+static DEFINE_SPINLOCK(ir_raw_handler_lock);
/**
* RUN_DECODER() - runs an operation on all IR decoders
@@ -56,25 +54,14 @@
int ir_raw_event_register(struct input_dev *input_dev)
{
struct ir_input_dev *ir = input_get_drvdata(input_dev);
- int rc, size;
+ int rc;
ir->raw = kzalloc(sizeof(*ir->raw), GFP_KERNEL);
if (!ir->raw)
return -ENOMEM;
- size = sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE * 2;
- size = roundup_pow_of_two(size);
-
- rc = kfifo_alloc(&ir->raw->kfifo, size, GFP_KERNEL);
- if (rc < 0) {
- kfree(ir->raw);
- ir->raw = NULL;
- return rc;
- }
-
rc = RUN_DECODER(raw_register, input_dev);
if (rc < 0) {
- kfifo_free(&ir->raw->kfifo);
kfree(ir->raw);
ir->raw = NULL;
return rc;
@@ -93,82 +80,84 @@
RUN_DECODER(raw_unregister, input_dev);
- kfifo_free(&ir->raw->kfifo);
kfree(ir->raw);
ir->raw = NULL;
}
EXPORT_SYMBOL_GPL(ir_raw_event_unregister);
-int ir_raw_event_store(struct input_dev *input_dev, enum raw_event_type type)
+/**
+ * ir_raw_event_reset() - resets the raw decoding state machines
+ * @input_dev: the struct input_dev device descriptor
+ *
+ * This routine resets the raw ir decoding state machines, useful e.g. when
+ * a timeout occurs or when resetting the hardware.
+ */
+void ir_raw_event_reset(struct input_dev *input_dev)
{
- struct ir_input_dev *ir = input_get_drvdata(input_dev);
- struct timespec ts;
- struct ir_raw_event event;
- int rc;
-
- if (!ir->raw)
- return -EINVAL;
-
- event.type = type;
- event.delta.tv_sec = 0;
- event.delta.tv_nsec = 0;
-
- ktime_get_ts(&ts);
-
- if (timespec_equal(&ir->raw->last_event, &event.delta))
- event.type |= IR_START_EVENT;
- else
- event.delta = timespec_sub(ts, ir->raw->last_event);
-
- memcpy(&ir->raw->last_event, &ts, sizeof(ts));
+ RUN_DECODER(reset, input_dev);
+}
+EXPORT_SYMBOL_GPL(ir_raw_event_reset);
- if (event.delta.tv_sec) {
- event.type |= IR_START_EVENT;
- event.delta.tv_sec = 0;
- event.delta.tv_nsec = 0;
- }
+/**
+ * ir_raw_event_duration() - pass a pulse/space duration to the raw ir decoders
+ * @input_dev: the struct input_dev device descriptor
+ * @duration: duration of the pulse or space
+ *
+ * This routine passes a pulse/space duration to the raw ir decoding state
+ * machines. Pulses are signalled as positive values and spaces as negative
+ * values.
+ */
+void ir_raw_event_duration(struct input_dev *input_dev, int duration)
+{
+ struct ir_input_dev *ir = input_get_drvdata(input_dev);
- kfifo_in(&ir->raw->kfifo, &event, sizeof(event));
+ if (!ir->raw || duration == 0)
+ return;
- return rc;
+ RUN_DECODER(decode, input_dev, duration);
}
-EXPORT_SYMBOL_GPL(ir_raw_event_store);
+EXPORT_SYMBOL_GPL(ir_raw_event_duration);
-int ir_raw_event_handle(struct input_dev *input_dev)
+/**
+ * ir_raw_event
Re: webcam problem after suspend/hibernate
Hi ! > Ok, that puts the problem firmly into uvcvideo area. > > Try changing its _resume routine to whatever is done on device > unplug... it should be rather easy, and is quite close to "correct" > solution. I am waiting to try that. If I always need to rmmod/modprobe everytime, that is meaning that something is kept messed somewhere in memory and should be cleaned by restart (reinitialize ?) the device. Mohamed-Ikbel -- 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
Scan not getting Channel names after DSO
Hi on one (and only one I think) multiplex after digital switchover I am getting the following [6440]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:101:102:25664 [6480]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:201:202:25728 [64c0]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:301:302:25792 [6500]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:25856 [6540]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:501:502:25920 [6b00]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:2101:2102:27392 [6b40]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27456 [6b80]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27520 [6bc0]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27584 [6c00]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27648 [6c40]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27712 [6c80]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27776 [6cc0]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:2311:2312:27840 [6d00]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27904 [6d80]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:601:602:28032 [6980]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GDone. UARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:27008 [6840]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1901:26688 [6800]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1809:26624 [67c0]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1701:26560 [66c0]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1301:26304 [6680]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1201:26240 [6640]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1101:26176 [6700]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:1401:26368 [6a00]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:701:702:27136 As you can see instead of the Channel name I am getting what looks to be hex - any idea why, this is on 530167000 frequency (channel 28+) example being this item [6d80]:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:601:602:28032 should be ITV4:530167000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:601:602:28032 any ideas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
