v4l-05 add infrared remote support

Hi,

This patch adds a module with some helper functions to handle infrared remotes using the linux input layer. It doesn't do any useful stuff alone, but the saa7134 and bttv drivers will use that to support the remotes shipped with some TV cards.

Gerd

diff -u linux-2.6.1/drivers/media/Kconfig linux/drivers/media/Kconfig
@@ -49,5 +49,11 @@
 	default VIDEO_BT848
 	depends on VIDEO_DEV
 
+config VIDEO_IR
+	tristate
+	default y if VIDEO_BT848=y || VIDEO_SAA7134=y
+	default m if VIDEO_BT848=m || VIDEO_SAA7134=m
+	depends on VIDEO_DEV
+
 endmenu
 

diff -u linux-2.6.1/drivers/media/common/Makefile linux/drivers/media/common/Makefile
@@ -3,4 +3,4 @@
 
 obj-$(CONFIG_VIDEO_SAA7146) += saa7146.o
 obj-$(CONFIG_VIDEO_SAA7146_VV) += saa7146_vv.o
-
+obj-$(CONFIG_VIDEO_IR) += ir-common.o

You have a new virus in /var/mail/kraxel

Hi,

	def_tristate VIDEO_BT848 || VIDEO_SAA7134

# selected as needed
config VIDEO_IR
	tristate

	...
	select VIDEO_IR

I like that one more, but last time I tried it didn't work. Is support select in Linus tree now?

Gerd

You have a new virus in /var/mail/kraxel

Hi,

Yes, it should work, it was merged quite some time ago.

bye, Roman

In message <[email protected]> you write:

	module_param(repeat, bool, 0644);
	module_param(debug, int, 0644);

No. The code in question must also build on 2.4 kernels which don't have module_param(). And I don't want to clutter up the code with #ifdefs unless I absolutely have to.

I'll do for the bttv ir support, that is 2.6 only anyway due to the usage of tasklets.

Gerd

"... und auch das ganze Wochenende oll" -- Wetterbericht auf RadioEins

Here we go.

Gerd

==============================[ cut here ]==============================

diff -u linux-2.6.1-mm5/drivers/media/video/ir-kbd-i2c.c linux/drivers/media/video/ir-kbd-i2c.c
@@ -25,6 +25,7 @@
  */
 
 #include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/sched.h>

@@ -55,8 +56,7 @@
 /* ----------------------------------------------------------------------- */
 /* insmod parameters                                                       */
 
-static int debug = 0;    /* debug level (0,1,2) */
-MODULE_PARM(debug,"i");
+module_param(debug, int, 0644);    /* debug level (0,1,2) */
 
 #define DEVNAME "ir-kbd-i2c"
 #define dprintk(level, fmt, arg...)	if (debug >= level) \

diff -u linux-2.6.1-mm5/drivers/media/video/ir-kbd-gpio.c linux/drivers/media/video/ir-kbd-gpio.c
@@ -18,6 +18,7 @@
  */
 
 #include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/input.h>
 #include <linux/delay.h>

@@ -170,8 +171,7 @@
 	struct timer_list       timer;
 };
 
-static int debug = 0;    /* debug level (0,1,2) */
-MODULE_PARM(debug,"i");
+module_param(debug, int, 0644);    /* debug level (0,1,2) */
 
 #define DEVNAME "ir-kbd-gpio"
 #define dprintk(fmt, arg...)	if (debug) \

In message <[email protected]> you write:

Marcelo, please read and apply.

This provides simple forwards compat for 2.4. It doesn't do arrays or strings, but they can be added if required (this will cover the easy 90%).

Tested on 2.5.24-pre6.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Name: 2.4 module_param Forward Compatibility Macros
Author: Rusty Russell
Status: Tested on 2.5.24-pre6
Version: 2.4

D: Simple uses of module_param() (implemented in 2.6) can be mapped
D: onto the old MODULE_PARM macros.
D:
D: New code should use module_param() because:
D: 1) Types are checked,
D: 2) Existence of parameters are checked,
D: 3) Customized types are possible [1]
D: 4) Customized set/get routines are possible [1]
D: 5) Parameters appear as boot params with prefix "<modname>." [1]
D: 6) Optional viewing and control through sysfs [2]
D:
D: [1] Not for 2.4 compatibility macros
D: [2] Not in 2.6.1 or 2.4, and only if third arg non-zero.

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .25425-linux-2.4.25-pre6/include/linux/moduleparam.h .25425-linux-2.4.25-pre6.updated/include/linux/moduleparam.h
@@ -0,0 +1,25 @@
+#ifndef _LINUX_MODULE_PARAMS_H
+#define _LINUX_MODULE_PARAMS_H
+/* Macros for (very simple) module parameter compatibility with 2.6. */
+#include <linux/module.h>
+
+/* type is byte, short, ushort, int, uint, long, ulong, bool. (2.6
+   has more, but they are not supported).  perm is permissions when
+   it appears in sysfs: 0 means doens't appear, 0444 means read-only
+   by everyone, 0644 means changable dynamically by root, etc.  name
+   must be in scope (unlike MODULE_PARM).
+*/
+#define module_param(name, type, perm)					     \
+	static inline void *__check_existence_##name(void) { return &name; } \
+	MODULE_PARM(name, _MODULE_PARM_STRING_ ## type)
+
+#define _MODULE_PARM_STRING_byte "b"
+#define _MODULE_PARM_STRING_short "h"
+#define _MODULE_PARM_STRING_ushort "h"
+#define _MODULE_PARM_STRING_int "i"
+#define _MODULE_PARM_STRING_uint "i"
+#define _MODULE_PARM_STRING_long "l"
+#define _MODULE_PARM_STRING_ulong "l"
+#define _MODULE_PARM_STRING_bool "i"
+
+#endif /* _LINUX_MODULE_PARAM_TYPES_H */

In message <[email protected]> you write:

Sure! I'll write and test the forward compat macros for 2.4, submit them to Marcelo, and then bother you again 8)

Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

At least the array stuff I'm using in my drivers, to handle the "multiple tv cards in one box" case, like this:

  static unsigned int card[] = {[0 ... (SAA7134_MAXBOARDS - 1)] = UNSET };
  MODULE_PARM(card,"1-" __stringify(SAA7134_MAXBOARDS) "i");
  MODULE_PARM_DESC(card,"card type");

So having that in 2.4 too would be nice.

I have also two more questions: How can I specify default values != 0 for insmod options using the new macros? How specify help/description texts? Using the MODULE_PARM_DESC() macro or is there something new too?

Gerd

In message <[email protected]> you write:

Unfortunately the module_param_array() macro is not really fungible into the old MODULE_PARM() macro: in particular the array size is now implicit.

I could introduce another macro which could be #defined to both, but for the moment I thought I'd see we get without one.

Not sure I understand? You'd presumably do it like so:

int foo = 7;
MODULE_PARM(foo, "i"); / module_param(foo, int, 0600)

I didn't change it. I thought about it, but I think that would just be neatening for the sake of neatening, which I dislike.

Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.