Remote Controllers - Revision history

Mauro Carvalho Chehab: /* Adding support for new IR's */

2010-05-12T18:57:36Z

Adding support for new IR's

← Older revision		Revision as of 18:57, 12 May 2010
Line 67:		Line 67:
	}		}
	};		};
		+
		+	Don't forget to add the new module at drivers/media/IR/keymaps/Makefile, otherwise, it won't be built.

	===IR Keycode map used by media devices===		===IR Keycode map used by media devices===

Mauro Carvalho Chehab: /* Adding support for new IR's */

2010-05-12T18:46:45Z

Adding support for new IR's

← Older revision		Revision as of 18:46, 12 May 2010
Line 5:		Line 5:
	In order to add support for a new keyboard, you need first to discover how the IR code is sent to the device. There are several possibilities:		In order to add support for a new keyboard, you need first to discover how the IR code is sent to the device. There are several possibilities:
	* IR sensor is directly connected with a GPIO pin of the PCI/USB bridge. This is a very common case nowadays.		* IR sensor is directly connected with a GPIO pin of the PCI/USB bridge. This is a very common case nowadays.
-	* This is probably the easiest way to add support, provided that the driver has already other similar devices. For an example, please see: [add IR support for saa7134].	+	* This is probably the easiest way to add support, provided that the driver has already other similar devices. For an example, please see: [[add IR support for saa7134]].
	* Bridge has an IR decoder inside. Some chipsets have already some internal decoder for IR, like dib0700 and em2884;		* Bridge has an IR decoder inside. Some chipsets have already some internal decoder for IR, like dib0700 and em2884;
	* There's a small chip that does serial to parallel conversion, outputting the IR code at several GPIO pins.		* There's a small chip that does serial to parallel conversion, outputting the IR code at several GPIO pins.
Line 55:		Line 55:

	static struct ir_scancode name_of_my_new_keyboard[] = {		static struct ir_scancode name_of_my_new_keyboard[] = {
-	{ ~~0x300~~, KEY_POWER2 },	+	{ 0x0300, KEY_POWER2 },
-	{ ~~0x30c~~, KEY_CHANNELUP },	+	{ 0x030c, KEY_CHANNELUP },
-	{ ~~0x310~~, KEY_CHANNELDOWN },	+	{ 0x0310, KEY_CHANNELDOWN },
	};		};
	static struct rc_keymap name_of_my_new_keyboard_map = {		static struct rc_keymap name_of_my_new_keyboard_map = {

Mauro Carvalho Chehab: /* Adding support for new IR's */

2010-05-12T18:45:00Z

Adding support for new IR's

← Older revision		Revision as of 18:45, 12 May 2010
Line 51:		Line 51:
	ir_getkeycode: unknown key for scancode 0x0310		ir_getkeycode: unknown key for scancode 0x0310

-	All you need to do is to make sure that those codes are properly mapped at the keycode table:	+	All you need to do is to make sure that those codes are properly mapped at the keycode table, and to specify
		+	the ir_type (in this case, IR_TYPE_NEC). So, to support the above, the main content of the new rc map will be:

-	static struct ir_scancode ~~rc_name_of_my_new_keyboard_map~~[] = {	+	static struct ir_scancode name_of_my_new_keyboard[] = {
	{ 0x300, KEY_POWER2 },		{ 0x300, KEY_POWER2 },
-	{ 0x30c, ~~KEY_CHANNEL_UP~~ },	+	{ 0x30c, KEY_CHANNELUP },
-	{ 0x310, ~~KEY_CHANNEL_DOWN~~ },	+	{ 0x310, KEY_CHANNELDOWN },
		+	};
		+	static struct rc_keymap name_of_my_new_keyboard_map = {
		+	.map = {
		+	.scan = name_of_my_new_keyboard,
		+	.size = ARRAY_SIZE(name_of_my_new_keyboard),
		+	.ir_type = IR_TYPE_NEC,
		+	.name = RC_MAP_EMPTY,
		+	}
	};		};

Mauro Carvalho Chehab: /* Adding support for new IR's */

2010-05-12T18:41:24Z

Adding support for new IR's

← Older revision		Revision as of 18:41, 12 May 2010
Line 33:		Line 33:

	Remove all keys at static struct ir_scancode, and add your new keycodes.		Remove all keys at static struct ir_scancode, and add your new keycodes.
		+
		+	For example, assuming that you have a driver with raw decode. By loading ir_core with debug=1, with:
		+	modprobe ir_core debug=1
		+	(be sure that ir_core weren't loaded before)
		+	you'll start to generate lots of logs at the syslog. Use the dmesg command to get those codes:
		+	dmesg \|grep scancode
		+
		+	Let's assume that this get you the following results:
		+	for power key:
		+	ir_nec_decode: NEC scancode 0x0300
		+	ir_getkeycode: unknown key for scancode 0x0300
		+	for channel up key:
		+	ir_nec_decode: NEC scancode 0x030c
		+	ir_getkeycode: unknown key for scancode 0x030c
		+	for channel down key:
		+	ir_nec_decode: NEC scancode 0x0310
		+	ir_getkeycode: unknown key for scancode 0x0310
		+
		+	All you need to do is to make sure that those codes are properly mapped at the keycode table:
		+
		+	static struct ir_scancode rc_name_of_my_new_keyboard_map[] = {
		+	{ 0x300, KEY_POWER2 },
		+	{ 0x30c, KEY_CHANNEL_UP },
		+	{ 0x310, KEY_CHANNEL_DOWN },
		+	};

	===IR Keycode map used by media devices===		===IR Keycode map used by media devices===

Mauro Carvalho Chehab: /* Adding support for new IR's */

2010-05-12T18:34:48Z

Adding support for new IR's

← Older revision		Revision as of 18:34, 12 May 2010
Line 3:		Line 3:
	===Adding support for new IR's===		===Adding support for new IR's===

-	To do.	+	In order to add support for a new keyboard, you need first to discover how the IR code is sent to the device. There are several possibilities:
		+	* IR sensor is directly connected with a GPIO pin of the PCI/USB bridge. This is a very common case nowadays.
		+	* This is probably the easiest way to add support, provided that the driver has already other similar devices. For an example, please see: [add IR support for saa7134].
		+	* Bridge has an IR decoder inside. Some chipsets have already some internal decoder for IR, like dib0700 and em2884;
		+	* There's a small chip that does serial to parallel conversion, outputting the IR code at several GPIO pins.
		+
		+	The way to get the data is hardware specific. Once the driver is able to get an IR scancode, it is generally required to create a new table for it.
		+	NOTE: before adding a new table, please check if the existing ones have already the proper mapping.
		+
		+	The first step to add a new map is to create an alias for it atinclude/media/rc-map.h:
		+
		+	/* Names of the several keytables defined in-kernel */
		+
		+	#define RC_MAP_ADSTECH_DVB_T_PCI "rc-adstech-dvb-t-pci"
		+	...
		+	#define RC_MAP_VIDEOMATE_TV_PVR "rc-videomate-tv-pvr"
		+	#define RC_MAP_WINFAST "rc-winfast"
		+	#define RC_MAP_WINFAST_USBII_DELUXE "rc-winfast-usbii-deluxe"
		+	/*
		+	* Please, do not just append newer Remote Controller names at the end.
		+	* The names should be ordered in alphabetical order
		+	*/
		+
		+	Just add a new line there with the IR name, on alphabetical order:
		+	#define RC_MAP_NAME_OF_MY_NEW_BOARD_MAP "rc-name-of-my-new-board-map"
		+
		+	Then copy one of the existing keymaps, for example, drivers/media/IR/keymaps/rc-empty.c,
		+	replacing the names for the name of your new IR.
		+
		+	Remove all keys at static struct ir_scancode, and add your new keycodes.

	===IR Keycode map used by media devices===		===IR Keycode map used by media devices===

Mauro Carvalho Chehab at 18:20, 12 May 2010

2010-05-12T18:20:45Z

← Older revision		Revision as of 18:20, 12 May 2010
Line 1:		Line 1:
	Currently, most analog and digital devices have an Infrared input for a remote control. Each manufacturer has their own type of control. It is not uncommon for the same manufacturer to ship different types of remote controls, depending on the device.		Currently, most analog and digital devices have an Infrared input for a remote control. Each manufacturer has their own type of control. It is not uncommon for the same manufacturer to ship different types of remote controls, depending on the device.
		+
		+	===Adding support for new IR's===
		+
		+	To do.
		+
		+	===IR Keycode map used by media devices===

	While there has been effort over the years to keep track of the varying IR layouts (documenting them within ir-common.c), unfortunately, there was never any effort to uniform the actual IR keycodes used by the different devices. This lack of uniformity resulted in cases where the same IR keyname was mapped completely different on different IR's. The overall state of confusion that existed is perhaps best demonstrated by viewing what [[ir-common.c]] IR summary looked like as of Aug, 26 2009.		While there has been effort over the years to keep track of the varying IR layouts (documenting them within ir-common.c), unfortunately, there was never any effort to uniform the actual IR keycodes used by the different devices. This lack of uniformity resulted in cases where the same IR keyname was mapped completely different on different IR's. The overall state of confusion that existed is perhaps best demonstrated by viewing what [[ir-common.c]] IR summary looked like as of Aug, 26 2009.
Line 5:		Line 11:
	On Aug, 27 2009, having a common mapping for supported IR's became the subject of a [[Development: A proposal for a common IR keycode definition map\|proposal]] which would allow userspace applications to make use of common keycode definitions. The table bellow reflects the expected keycode mappings for IR keys.		On Aug, 27 2009, having a common mapping for supported IR's became the subject of a [[Development: A proposal for a common IR keycode definition map\|proposal]] which would allow userspace applications to make use of common keycode definitions. The table bellow reflects the expected keycode mappings for IR keys.

-	~~===IR Keycode map used by media devices===~~	+
	{\| border="1" cellpadding="2"		{\| border="1" cellpadding="2"
	!Key code		!Key code

CityK: minor changes; wording, spelling etc

2010-04-11T17:59:23Z

minor changes; wording, spelling etc

← Older revision		Revision as of 17:59, 11 April 2010
Line 1:		Line 1:
-	~~===Remote Controllers===~~	+	Currently, most analog and digital devices have an Infrared input for a remote control. Each manufacturer has their own type of control. It is not uncommon for the same manufacturer to ship different types of remote controls, depending on the device.
-	Currently, most analog and digital devices have a Infrared input for remote ~~controllers~~. Each manufacturer has their own type of control. It is not ~~rare that~~ the same manufacturer to ship different types of controls, depending on the device. Unfortunately, during several years, there weren't any effort to uniform the IR keycodes under different boards. This resulted that the same IR keyname to be mapped completely different on differnt IR's.	+
-	~~There were, however, an effort to keep those IR layouts at the same file (ir-common.c)~~.	+

-	~~See~~ [[ir-common.c]] IR summary by Aug, 26 2009 ~~for a sample of the confusion~~.	+	While there has been effort over the years to keep track of the varying IR layouts (documenting them within ir-common.c), unfortunately, there was never any effort to uniform the actual IR keycodes used by the different devices. This lack of uniformity resulted in cases where the same IR keyname was mapped completely different on different IR's. The overall state of confusion that existed is perhaps best demonstrated by viewing what [[ir-common.c]] IR summary looked like as of Aug, 26 2009.

	On Aug, 27 2009, having a common mapping for supported IR's became the subject of a [[Development: A proposal for a common IR keycode definition map\|proposal]] which would allow userspace applications to make use of common keycode definitions. The table bellow reflects the expected keycode mappings for IR keys.		On Aug, 27 2009, having a common mapping for supported IR's became the subject of a [[Development: A proposal for a common IR keycode definition map\|proposal]] which would allow userspace applications to make use of common keycode definitions. The table bellow reflects the expected keycode mappings for IR keys.

CityK: fixed link, minor rephrasing

2009-08-29T23:07:06Z

fixed link, minor rephrasing

← Older revision		Revision as of 23:07, 29 August 2009
Line 5:		Line 5:
	See [[ir-common.c]] IR summary by Aug, 26 2009 for a sample of the confusion.		See [[ir-common.c]] IR summary by Aug, 26 2009 for a sample of the confusion.

-	On Aug, 27 2009, a common mapping ~~were object~~ of a [[proposal]] for ~~using~~ a common keycode definition ~~at the supported IR's to be used also by~~ userspace applications. The table bellow reflects the expected keycode mappings for IR keys.	+	On Aug, 27 2009, having a common mapping for supported IR's became the subject of a [[Development: A proposal for a common IR keycode definition map\|proposal]] which would allow userspace applications to make use of common keycode definitions. The table bellow reflects the expected keycode mappings for IR keys.

	===IR Keycode map used by media devices===		===IR Keycode map used by media devices===

Mauro Carvalho Chehab: /* IR Keycode map used by media devices */

2009-08-29T12:28:10Z

IR Keycode map used by media devices

← Older revision		Revision as of 12:28, 29 August 2009
Line 200:		Line 200:
	\|KEY_LEFT \|\| Left key \|\| LEFT \|\| On simpler IR's, without separate volume keys, you need to map LEFT as KEY_VOLUMEDOWN		\|KEY_LEFT \|\| Left key \|\| LEFT \|\| On simpler IR's, without separate volume keys, you need to map LEFT as KEY_VOLUMEDOWN
	\|-		\|-
-	\|KEY_RIGHT \|\| Right key \|\| RIGHT \|\| On simpler IR's, without separate ~~channel~~ keys, you need to map RIGHT as KEY_VOLUMEUP	+	\|KEY_RIGHT \|\| Right key \|\| RIGHT \|\| On simpler IR's, without separate volume keys, you need to map RIGHT as KEY_VOLUMEUP
	\|-		\|-
	\|- style= "font-weight: bolder; color: blue"		\|- style= "font-weight: bolder; color: blue"

Mauro Carvalho Chehab: /* IR Keycode map used by media devices */

2009-08-29T12:24:03Z

IR Keycode map used by media devices

← Older revision		Revision as of 12:24, 29 August 2009
Line 12:		Line 12:
	!Meaning		!Meaning
	!Key examples on IR		!Key examples on IR
		+	!Notes
	\|- style= "font-weight: bolder; color: blue"		\|- style= "font-weight: bolder; color: blue"
	\| Numeric keys		\| Numeric keys
Line 192:		Line 193:
	\|-		\|-
	\|KEY_WWW \|\| Open the default browser \|\| WEB		\|KEY_WWW \|\| Open the default browser \|\| WEB
		+	\|-
		+	\|KEY_UP \|\| Up key \|\| UP \|\| On simpler IR's, without separate channel keys, you need to map UP as KEY_CHANNELUP
		+	\|-
		+	\|KEY_DOWN \|\| Down key \|\| DOWN \|\| On simpler IR's, without separate channel keys, you need to map DOWN as KEY_CHANNELDOWN
		+	\|-
		+	\|KEY_LEFT \|\| Left key \|\| LEFT \|\| On simpler IR's, without separate volume keys, you need to map LEFT as KEY_VOLUMEDOWN
		+	\|-
		+	\|KEY_RIGHT \|\| Right key \|\| RIGHT \|\| On simpler IR's, without separate channel keys, you need to map RIGHT as KEY_VOLUMEUP
	\|-		\|-
	\|- style= "font-weight: bolder; color: blue"		\|- style= "font-weight: bolder; color: blue"