Control LinuxMCE using an Infrared remote - Revision history

Jamo at 20:05, 21 January 2013

2013-01-21T20:05:15Z

←Older revision		Revision as of 20:05, 21 January 2013
Line 59:		Line 59:
	Therefore, if you have a new remote control with some new buttons that we have not yet mapped, it is recommended that you e-mail us or post us a message in the forum, with the button name and the message and then we can add it to our master database and then your system can remain in sync with other users enhancements. If you want to do some mapping that is just for you, you can change the table and know your changes will not be overwritten.		Therefore, if you have a new remote control with some new buttons that we have not yet mapped, it is recommended that you e-mail us or post us a message in the forum, with the button name and the message and then we can add it to our master database and then your system can remain in sync with other users enhancements. If you want to do some mapping that is just for you, you can change the table and know your changes will not be overwritten.

	Note that the RemoteMapping table has 2 optional fields: ScreenType and RemoteLayout. When the IRReceiverBase base class is deciding which message to send in response to abutton press, it first looks for a more specific entry where the screen type matches the type of screen currently visible on the orbiter, and the remote layout matches the layout. The on-screen Orbiters regularly send messages to the infrared receiver telling them what type of screen is currently visible, using the following codes: M=Main Menu, m=other menu, R=LinuxMCE Remote, r=Non-LinuxMCE remote, F=File Listing. This allows for buttons to behave differently depending upon what type of screen is visible.		Note that the [[Remote_Mapping_Table\|RemoteMapping]] table has 2 optional fields: ScreenType and RemoteLayout. When the IRReceiverBase base class is deciding which message to send in response to abutton press, it first looks for a more specific entry where the screen type matches the type of screen currently visible on the orbiter, and the remote layout matches the layout. The on-screen Orbiters regularly send messages to the infrared receiver telling them what type of screen is currently visible, using the following codes: M=Main Menu, m=other menu, R=LinuxMCE Remote, r=Non-LinuxMCE remote, F=File Listing. This allows for buttons to behave differently depending upon what type of screen is visible.

	For example, when the main menu is visible, the arrows on a remote control should send a message to the on-screen Orbiter to move the highlight pointer around on the screen. However, when the user is controlling an external piece of AV equipment, like a DVD player, the arrows should pass through to the DVD player so the user can control its own on-screen menu. Also the type of functionality can vary depending upon the layout of the remote.		For example, when the main menu is visible, the arrows on a remote control should send a message to the on-screen Orbiter to move the highlight pointer around on the screen. However, when the user is controlling an external piece of AV equipment, like a DVD player, the arrows should pass through to the DVD player so the user can control its own on-screen menu. Also the type of functionality can vary depending upon the layout of the remote.

Mcefan at 21:18, 19 October 2012

2012-10-19T21:18:12Z

←Older revision		Revision as of 21:18, 19 October 2012
Line 5:		Line 5:
	[[Category:Infrared]]		[[Category:Infrared]]
	[[Category: Programmer's Guide]]		[[Category: Programmer's Guide]]
	~~[[Category: Tutorials]]~~

	==How to set it up==		==How to set it up==
	*In [[LinuxMCE Admin Website]]-->Wizard-->Devices-->Media Directors, choose the type of Infrared Receiver you have from the pull-down. The list of choices includes [http://lirc.org/ LIRC drivers]. Most users can use the "default" driver.		*In [[LinuxMCE Admin Website]]-->Wizard-->Devices-->Media Directors, choose the type of Infrared Receiver you have from the pull-down. The list of choices includes [http://lirc.org/ LIRC drivers]. Most users can use the "default" driver.

Wierdbeard65 at 10:34, 2 May 2010

2010-05-02T10:34:07Z

←Older revision		Revision as of 10:34, 2 May 2010
Line 1:		Line 1:
			{{versioninfo}}
	{\| align="right"		{\| align="right"
	\| __TOC__		\| __TOC__

Adamantivm: /* Programmer's Guide */

2008-08-24T13:59:02Z

Programmer's Guide

←Older revision		Revision as of 13:59, 24 August 2008
Line 39:		Line 39:
	The DCE Devices (i.e. the LinuxMCE binary that handles I/R reception) are specified in the category Peripherals-->Infrared Receivers.		The DCE Devices (i.e. the LinuxMCE binary that handles I/R reception) are specified in the category Peripherals-->Infrared Receivers.

	In [[LinuxMCE Admin Website]]-->Advanced--> Device Templates, you can see the categories and devices in them. There is a separate folder for the LIRC drivers. In addition to a device for the I/R receiver, there is also a device for the I/T remote. The remote controls are of the type Peripherals --> Remote Controls. Since the definition of the infrared codes for a remote control is stored within the remote control device, and that definition varies depending upon the type of receiver, you will see that there is a separate subcategory for each type of receiver.		In [[LinuxMCE Admin Website]]-->Advanced-->Configuration--> Device Templates, you can see the categories and devices in them. There is a separate folder for the LIRC drivers. In addition to a device for the I/R receiver, there is also a device for the I/T remote. The remote controls are of the type Peripherals --> Remote Controls. Since the definition of the infrared codes for a remote control is stored within the remote control device, and that definition varies depending upon the type of receiver, you will see that there is a separate subcategory for each type of receiver.

	For example there is a folder "LIRC Remote Controls" that has all of the remote controls and definition files for the LIRC project. We also created our own DCE devices for other infrared receivers, such as IRTrans and Tira. Although these are supported within the LIRC project, we found that we had better control and greater accuracy when we used the native SDKs for these receivers. So, for example, if you have an IRTrans receiver, and an XPMC remote, you have two possibilities. First you could add the LIRC receiver device, and the XPMC remote device that is within the LIRC remote category. In this case the remote control will be using an LIRC config file. Secondly you could add LinuxMCE's native IRTrans receiver device, and then pick the XMPC remote device that is within the IRTrans remotes category, which stores the button codes in a different format, that is in IRTrans' native format. When you are adding your infrared receiver and remote control using the LinuxMCE Admin Wizard/Devices/Media Directors page, the wizard automatically ensures that when you add a remote control it is the correct category.		For example there is a folder "LIRC Remote Controls" that has all of the remote controls and definition files for the LIRC project. We also created our own DCE devices for other infrared receivers, such as IRTrans and Tira. Although these are supported within the LIRC project, we found that we had better control and greater accuracy when we used the native SDKs for these receivers. So, for example, if you have an IRTrans receiver, and an XPMC remote, you have two possibilities. First you could add the LIRC receiver device, and the XPMC remote device that is within the LIRC remote category. In this case the remote control will be using an LIRC config file. Secondly you could add LinuxMCE's native IRTrans receiver device, and then pick the XMPC remote device that is within the IRTrans remotes category, which stores the button codes in a different format, that is in IRTrans' native format. When you are adding your infrared receiver and remote control using the LinuxMCE Admin Wizard/Devices/Media Directors page, the wizard automatically ensures that when you add a remote control it is the correct category.

Perspectoff: /* Programmer's Guide */

2008-05-25T16:19:46Z

Programmer's Guide

Perspectoff: /* Programmer's Guide */

2008-05-25T16:11:01Z

Programmer's Guide

←Older revision		Revision as of 16:11, 25 May 2008
Line 53:		Line 53:
	Whenever any infrared receiver reports any of those button presses, the message "0 -106 1 65 5 +1" gets fired. The format of the message is the same as if you typed it with the MessageSend utility: ie from device, to device message type, message id, followed by parameters.		Whenever any infrared receiver reports any of those button presses, the message "0 -106 1 65 5 +1" gets fired. The format of the message is the same as if you typed it with the MessageSend utility: ie from device, to device message type, message id, followed by parameters.

	~~<p>~~So if the user presses a button called ChanUp, a message will be sent to device -106 (media plugin) of type 1 (command) id 65 (Jump Position In Playlist) with parameter 5 (Value To Assign) set to "+1". This table is shared amongst all LinuxMCE users, and is updated every time your system upgrades versions. If you make your own manual changes to this table then the next time your core upgrades it will not upgrade the rows in that table that you modified, because SQL CVS does not, by default, overwrite your local changes with global ones. Therefore, if you have a new remote control with some new buttons that we have not yet mapped, it is recommended that you e-mail us or post us a message in the forum, with the button name and the message and then we can add it to our master database and then your system can remain in sync with other users enhancements. If you want to do some mapping that is just for you, you can change the table and know your changes will not be overwritten.~~</p>~~		So if the user presses a button called ChanUp, a message will be sent to device -106 (media plugin) of type 1 (command) id 65 (Jump Position In Playlist) with parameter 5 (Value To Assign) set to "+1". This table is shared amongst all LinuxMCE users, and is updated every time your system upgrades versions. If you make your own manual changes to this table then the next time your core upgrades it will not upgrade the rows in that table that you modified, because SQL CVS does not, by default, overwrite your local changes with global ones. Therefore, if you have a new remote control with some new buttons that we have not yet mapped, it is recommended that you e-mail us or post us a message in the forum, with the button name and the message and then we can add it to our master database and then your system can remain in sync with other users enhancements. If you want to do some mapping that is just for you, you can change the table and know your changes will not be overwritten.

	~~<p>~~You'll note that the RemoteMapping table has 2 optional fields: ScreenType and RemoteLayout. When the IRReceiverBase base class is deciding what message to send in response to button press, it first looks for a more specific entry where the screen type matches the type of screen currently visible on the orbiter, and the remote layout matches the layout. The on-screen orbiters regularly send messages to the infrared receiver telling them what type of screen is currently visible, using the following codes: M=Main Menu, m=other menu, R=LinuxMCE Remote, r=Non-LinuxMCE remote, F=File Listing. This allows for buttons to behave differently depending upon what type of screen is visible. For example when the main menu is visible, the arrows on a remote control should send a message to the on-screen orbiter to move the highlight pointer around on the screen. However when the user is controlling an external piece of AV equipment, like a DVD player, the arrows should pass through to the DVD player so the user can control its own on-screen menu. Also the type of functionality can vary depending upon the layout of the remote. For example, Bang & Olufsen remotes are quite simple, there is only a single up/down/left/right buttons which are used both to navigate on-screen menus as well as to handle rewind fast-forward and skip. Other remotes have dedicated arrows and media navigation buttons. So one remote layout can be created for Bang & Olufsen-style remote, where the arrows control the menu when there is a menu on screen, and adjust the media when there is not. The remote layout is a device data "#110 Remote Layout" stored with the remote control~~</p>~~		You'll note that the RemoteMapping table has 2 optional fields: ScreenType and RemoteLayout. When the IRReceiverBase base class is deciding what message to send in response to button press, it first looks for a more specific entry where the screen type matches the type of screen currently visible on the orbiter, and the remote layout matches the layout. The on-screen orbiters regularly send messages to the infrared receiver telling them what type of screen is currently visible, using the following codes: M=Main Menu, m=other menu, R=LinuxMCE Remote, r=Non-LinuxMCE remote, F=File Listing. This allows for buttons to behave differently depending upon what type of screen is visible. For example when the main menu is visible, the arrows on a remote control should send a message to the on-screen orbiter to move the highlight pointer around on the screen. However when the user is controlling an external piece of AV equipment, like a DVD player, the arrows should pass through to the DVD player so the user can control its own on-screen menu. Also the type of functionality can vary depending upon the layout of the remote. For example, Bang & Olufsen remotes are quite simple, there is only a single up/down/left/right buttons which are used both to navigate on-screen menus as well as to handle rewind fast-forward and skip. Other remotes have dedicated arrows and media navigation buttons. So one remote layout can be created for Bang & Olufsen-style remote, where the arrows control the menu when there is a menu on screen, and adjust the media when there is not. The remote layout is a device data "#110 Remote Layout" stored with the remote control

	~~<p>~~When IRReceiverBase looks for a mapping it first looks for records that match the current screen type and remote layout, and then revert to standard records (ie ScreenType and RemoteLayout are null) only if there are no matching results.~~</p>~~		When IRReceiverBase looks for a mapping it first looks for records that match the current screen type and remote layout, and then revert to standard records (ie ScreenType and RemoteLayout are null) only if there are no matching results.

	See also: [[Add support for new remote controls]]		See also: [[Add support for new remote controls]]

Perspectoff at 16:10, 25 May 2008

2008-05-25T16:10:04Z

←Older revision		Revision as of 16:10, 25 May 2008
Line 1:		Line 1:
			{\| align="right"
			\| __TOC__
			\|}
			[[Category:Infrared]]
			[[Category: Programmer's Guide]]
			[[Category: Tutorials]]
	==How to set it up==		==How to set it up==
	*In [[LinuxMCE Admin Website]]-->Wizard-->Devices-->Media Directors, choose the type of Infrared Receiver you have from the pull-down. The list of choices includes [http://lirc.org/ LIRC drivers]. Most users can use the "default" driver.		*In [[LinuxMCE Admin Website]]-->Wizard-->Devices-->Media Directors, choose the type of Infrared Receiver you have from the pull-down. The list of choices includes [http://lirc.org/ LIRC drivers]. Most users can use the "default" driver.
Line 25:		Line 31:
	To use the 10-key pad, choose the type of scenario you want. The categories are numbered: 1=Lighting, 2=Media, 3=Climate, 4=Telecom, 5=Security, 6=Misc. Thus, 22 on the remote will start TV (2=Media category and TV is the 2nd option in the category).		To use the 10-key pad, choose the type of scenario you want. The categories are numbered: 1=Lighting, 2=Media, 3=Climate, 4=Telecom, 5=Security, 6=Misc. Thus, 22 on the remote will start TV (2=Media category and TV is the 2nd option in the category).

	~~[[Category:Infrared]]~~
	~~[[Category: Programmer's Guide]]~~
	~~[[Category: Tutorials]]~~
	== Programmer's Guide ==		== Programmer's Guide ==

Perspectoff: /* Programmer's Guide */

2008-05-25T16:09:04Z

Programmer's Guide

←Older revision		Revision as of 16:09, 25 May 2008
Line 25:		Line 25:
	To use the 10-key pad, choose the type of scenario you want. The categories are numbered: 1=Lighting, 2=Media, 3=Climate, 4=Telecom, 5=Security, 6=Misc. Thus, 22 on the remote will start TV (2=Media category and TV is the 2nd option in the category).		To use the 10-key pad, choose the type of scenario you want. The categories are numbered: 1=Lighting, 2=Media, 3=Climate, 4=Telecom, 5=Security, 6=Misc. Thus, 22 on the remote will start TV (2=Media category and TV is the 2nd option in the category).

			[[Category:Infrared]]
			[[Category: Programmer's Guide]]
			[[Category: Tutorials]]
	== Programmer's Guide ==		== Programmer's Guide ==

	~~<p>Be sure to read~~ the How To Use It section above first.		*Read the How To Use It section (above) first.

	As you can see, LinuxMCE provides a highly intelligent interpretation of infrared remote buttons, that automatically change their function based on what the user is doing, what type of remote control layout exists, and where the infrared codes are going. If you have ever worked with infrared remote controls, such as LIRC, you know that there is no standard, and all the remote controls have different buttons with different names. Therefore we had to create a database structure that allows for interpreting the different button names into commands which can change depending upon the context and the layout of the remote.</p>		As you can see, LinuxMCE provides a highly intelligent interpretation of infrared remote buttons, that automatically change their function based on what the user is doing, what type of remote control layout exists, and where the infrared codes are going. If you have ever worked with infrared remote controls, such as LIRC, you know that there is no standard, and all the remote controls have different buttons with different names. Therefore we had to create a database structure that allows for interpreting the different button names into commands which can change depending upon the context and the layout of the remote.</p>

			The DCE Devices (i.e. the LinuxMCE binary that is run to handle i/r reception) are all of the category Peripherals, Infrared Receivers.

	<p>~~The DCE Devices (i~~.e. the ~~LinuxMCE binary that~~ is ~~run to handle~~ i/r ~~reception)~~ are ~~all~~ of the ~~category~~ Peripherals, ~~Infrared Receivers~~.		In [[LinuxMCE Admin Website]]-->Advanced--> Device Templates, you can see the categories and devices in them. There is a separate folder for the LIRC drivers. In addition to a device for the i/r receiver, there is also a device for the i/r remote. The remote controls are of the type Peripherals > Remote Controls. Since the definition of the infrared codes for a remote control is stored within the remote control device, and that definition varies depending upon the type of receiver, you will see there is a separate subcategory for each type of receiver.


	~~In LinuxMCE Admin choose Advanced > Device Templates, and you can see the categories and devices in them. There~~ is a ~~separate~~ folder for the LIRC ~~drivers~~. ~~In addition to a device~~ for the ~~i/r receiver~~, ~~there is also a device~~ for ~~the i/r remote~~. ~~The~~ remote ~~controls are of the type Peripherals > Remote Controls~~. ~~Since~~ the ~~definition of~~ the ~~infrared codes for a~~ remote ~~control~~ is ~~stored~~ within the remote control device, and that ~~definition varies depending upon~~ the ~~type of~~ receiver, you ~~will see there~~ is ~~a separate subcategory for each type of receiver~~.		For example there is a folder "LIRC Remote Controls" that has all of the remote controls and definition files for the LIRC project. We also created our own DCE devices for other infrared receivers, such as IRTrans and Tira. Although these are supported within the lirc project, we found that we had better control and greater accuracy when we used the native SDKs for these receivers. So, for example, if you have an IRTrans receiver, and an XPMC remote, you have two possibilities. First you could add the LIRC receiver device, and the XPMC remote device that is within the LIRC remote category. In this case the remote control will be using an LIRC config file. Secondly you could add LinuxMCE's native IRTrans receiver device, and then pick the XMPC remote device that is within the IRTrans remotes category, which stores the button codes in a different format, that is in IRTrans' native format. When you are adding your infrared receiver and remote control using the LinuxMCE Admin Wizard/Devices/Media Directors page, the wizard automatically ensures that when you add a remote control it is the correct category.

			For each remote control there is a device data "#59 Configuration" which has the remote controls configuration file, which defined all the infrared codes at each button will send and gives each code, or button, a name. So the XPMC remote within the LIRC category has a device data #59 that is the LIRC config file. The XPMC remote within the IRTrans category has a device data #59 that is the same buttons/codes, but in IRTrans format.

	~~For example there is a folder "LIRC Remote Controls" that has all of~~ the ~~remote controls and definition files~~ for ~~the LIRC project. We also created our own DCE~~ devices ~~for other infrared receivers, such as IRTrans and Tira. Although these are supported~~ within the ~~lirc project~~, ~~we found that we had better control~~ and ~~greater accuracy when we used the native SDKs for these receivers~~. So, for example, ~~if you have an IRTrans receiver, and an XPMC~~ remote, ~~you have two possibilities. First you could add~~ the ~~LIRC receiver~~ device, and ~~the XPMC remote device~~ that ~~is within the LIRC remote category~~. ~~In this case the remote control will be using an LIRC config~~ file~~. Secondly you could add LinuxMCE's native IRTrans receiver device~~, and then pick the XMPC remote device that is within the IRTrans remotes category, which stores the button codes in a different format, that is in IRTrans' native format. When you are adding your infrared receiver and remote control using the LinuxMCE Admin Wizard/Devices/Media Directors page, the wizard automatically ensures that when you add a remote control it is the correct category.~~</p>~~		When the framework starts an IR receiver device, iIn general this device will first scan for all sister devices within the category remote control, and write out a configuration file. So, for example, when LIRC_DCE runs it finds all LIRC remote controls on that machine, grabs the device data "#59 Configuration" for every one of them and writes that out to a lirc.conf file, and then starts LIRC.

	~~<p>For~~ each ~~remote control there~~ is ~~a device data "#59 Configuration" which has~~ the ~~remote controls~~ configuration file, ~~which defined all the infrared codes at each button will send~~ and ~~gives each code, or button, a name. So~~ the ~~XPMC remote~~ within ~~the LIRC category has~~ a ~~device data #59 that~~ is ~~the LIRC config file~~. ~~The XPMC remote within~~ the ~~IRTrans category has~~ a ~~device data #59 that is the same buttons/codes~~, ~~but in IRTrans format~~.~~</p>~~		All the logic is in a base class called IRReceiverBase. All of LinuxMCE's infrared receiver devices use this same base class. So the actual code that is specific to each type of receiver is very small, usually around 20 lines. It only needs to write out the configuration file at start up, and then call the member function ReceivedCode within IRReceiverBase when a button is pushed. This function takes the name of the button as a parameter, and converts this into a message.

	~~<p>When~~ the ~~framework starts an IR receiver device~~, ~~iIn general this device will first scan for~~ all ~~sister devices within~~ the ~~category remote control,~~ and ~~write out~~ a ~~configuration file~~. So, for ~~example~~, ~~when LIRC_DCE runs it finds all LIRC remote controls on that machine~~, ~~grabs the device data~~ "~~#59 Configuration~~" ~~for every one of them and writes that out to~~ a ~~lirc.conf file~~, ~~and then starts LIRC~~.~~</p>~~		Since all of the receivers use a common base class to handle the logic, that also means that all of the translation between buttons and actions is also in a shared database. It does not matter whether you are using LIRC or some other infrared receiver, the translation is the same. There is no unified standard for what the buttons are called. The button "SkipFwd" may be called "Fwd", "Skip+", "Jump->", etc. The table RemoteMapping in the main mysql database, pluto_main, has a field Mapping which lists all the button aliases, followed by the command to be executed when any of those buttons is pushed. For example: chup;skipfwd;ChanUp;SkipNext;\|0 -106 1 65 5 +1

	<p>All the logic is in a base class called IRReceiverBase. All of LinuxMCE's infrared receiver devices use this same base class. So the actual code that is specific to each type of receiver is very small, usually around 20 lines. It only needs to write out the configuration file at start up, and then call the member function ReceivedCode within IRReceiverBase when a button is pushed. This function takes the name of the button as a parameter, and converts this into a message.</p>		Whenever any infrared receiver reports any of those button presses, the message "0 -106 1 65 5 +1" gets fired. The format of the message is the same as if you typed it with the MessageSend utility: ie from device, to device message type, message id, followed by parameters.

	<p>Since all of the receivers use a common base class to handle the logic, that also means that all of the translation between buttons and actions is also in a shared database. It does not matter whether you are using LIRC or some other infrared receiver, the translation is the same. There is no unified standard for what the buttons are called. The button "SkipFwd" may be called "Fwd", "Skip+", "Jump->", etc. The table RemoteMapping in the main mysql database, pluto_main, has a field Mapping which lists all the button aliases, followed by the command to be executed when any of those buttons is pushed. For example: chup;skipfwd;ChanUp;SkipNext;\|0 -106 1 65 5 +1</p>

	~~<p>~~Whenever any infrared receiver reports any of those button presses, the message "0 -106 1 65 5 +1" gets fired. The format of the message is the same as if you typed it with the MessageSend utility: ie from device, to device message type, message id, followed by parameters.~~</p>~~

	<p>So if the user presses a button called ChanUp, a message will be sent to device -106 (media plugin) of type 1 (command) id 65 (Jump Position In Playlist) with parameter 5 (Value To Assign) set to "+1". This table is shared amongst all LinuxMCE users, and is updated every time your system upgrades versions. If you make your own manual changes to this table then the next time your core upgrades it will not upgrade the rows in that table that you modified, because SQL CVS does not, by default, overwrite your local changes with global ones. Therefore, if you have a new remote control with some new buttons that we have not yet mapped, it is recommended that you e-mail us or post us a message in the forum, with the button name and the message and then we can add it to our master database and then your system can remain in sync with other users enhancements. If you want to do some mapping that is just for you, you can change the table and know your changes will not be overwritten.</p>		<p>So if the user presses a button called ChanUp, a message will be sent to device -106 (media plugin) of type 1 (command) id 65 (Jump Position In Playlist) with parameter 5 (Value To Assign) set to "+1". This table is shared amongst all LinuxMCE users, and is updated every time your system upgrades versions. If you make your own manual changes to this table then the next time your core upgrades it will not upgrade the rows in that table that you modified, because SQL CVS does not, by default, overwrite your local changes with global ones. Therefore, if you have a new remote control with some new buttons that we have not yet mapped, it is recommended that you e-mail us or post us a message in the forum, with the button name and the message and then we can add it to our master database and then your system can remain in sync with other users enhancements. If you want to do some mapping that is just for you, you can change the table and know your changes will not be overwritten.</p>
Line 56:		Line 56:
	<p>When IRReceiverBase looks for a mapping it first looks for records that match the current screen type and remote layout, and then revert to standard records (ie ScreenType and RemoteLayout are null) only if there are no matching results.</p>		<p>When IRReceiverBase looks for a mapping it first looks for records that match the current screen type and remote layout, and then revert to standard records (ie ScreenType and RemoteLayout are null) only if there are no matching results.</p>

	~~<p>~~See also [[Add support for new remote controls~~]]</p>~~		See also: [[Add support for new remote controls]]


	~~[[Category:Infrared]]~~
	~~[[Category: Programmer's Guide]]~~
	~~[[Category: Tutorials~~]]

Perspectoff: /* How to use it */

2008-05-25T16:06:26Z

How to use it

←Older revision		Revision as of 16:06, 25 May 2008
Line 7:		Line 7:
	A Media Director displays an on-screen Orbiter User Interface with a menu of buttons (which appears similar to the interface seen on webpads and PDAs). The button functions on the infrared remote control are context-sensitive. Sometimes the buttons control the Media Director's on-screen Orbiter, and sometimes the buttons control the media device you're using.		A Media Director displays an on-screen Orbiter User Interface with a menu of buttons (which appears similar to the interface seen on webpads and PDAs). The button functions on the infrared remote control are context-sensitive. Sometimes the buttons control the Media Director's on-screen Orbiter, and sometimes the buttons control the media device you're using.

	Here's an example. Let's say your Media Director controls your satellite TV box as well as a regular DVD player. The satellite TV control, the DVD player, and the Media Director all have infrared sensors. You have a universal remote control which you added to LinuxMCE as described above. The On-screen Orbiter is visible on the TV. As you hit the up/down/left/right/enter buttons on the remote you will see that you can select the menu options on the Orbiter. You select the button to watch "Satellite TV", and the TV appears. Now when you hit up/down/left/right/enter LinuxMCE knows you obviously want to control the satellite tv box. So, when you press those buttons LinuxMCE translates the infrared codes into ones that your satellite tv box understands, and you will see the same arrows on the same remote control are now controlling the satellite TV. You hit 'Power Off', and the satellite box shuts off, and the Orbiter's menu is again visible. Now the arrows are again controlling the Orbiter. You choose the button to watch a DVD in your DVD Player. Now the same arrows are controlling the DVD player. And when you hit 'pause' the DVD player will pause, even though you're holding the LinuxMCE remote--not the DVD remote. LinuxMCE is translating everything for you so you don't have to juggle remote controls. Again you hit 'power' and the DVD turns off. Hit 'power' again and the orbiter shuts the TV off. Hit 'power' a third time and the media director itself turns off. This is even better than a universal remote control since you don't need to tell it what device you want to control--LinuxMCE figures it out on its own.</p>		Here's an example. Let's say your Media Director controls your satellite TV box as well as a regular DVD player. The satellite TV control, the DVD player, and the Media Director all have infrared sensors. You have a universal remote control which you added to LinuxMCE as described above.

	~~<p>Although you can use all sorts of remote controls, and all have different buttons, they will all control LinuxMCE in a consistent manner.~~ The ~~media~~-~~specific buttons, like rewind/fastforward, play/pause, etc., will always control whatever media device you are currently listening to no matter what~~ screen is visible on the ~~on-screen Orbiter~~. ~~Navigation buttons, like~~ up/down/left/right/enter ~~and~~ the ~~10-key number pad,~~ will ~~control the currently active media device if the On-screen Orbiter is showing the remote control for~~ that ~~device. Otherwise it controls the On-screen Orbiter. When~~ the ~~main~~ menu ~~is visible~~ on the Orbiter ~~you can select scenarios with the up/down/left/right/enter buttons, or the 10-key pad~~. ~~To use~~ the ~~10-key pad~~, ~~hit~~ the ~~type of scenario you want: the categories are always numbered as follows: 1=Lighting, 2=Media, 3=Climate, 4=Telecom, 5=Security, 6=Misc Then when the list of those scenarios~~ appears~~, hit the scenario you want, such as 2 for the 2nd scenario. Thus 22 on the remote will start TV (2=Media, TV is always the 2nd option)~~.~~</p>~~		The on-screen Orbiter is visible on the TV. As you hit the ''up/down/left/right/enter'' buttons on the remote you will see that you can select the menu options on the Orbiter. You select the button to watch "Satellite TV", and the TV appears.

	~~<p>You can use different remote controls that have completely different layouts, but they will still control LinuxMCE in a consistent manner. For example~~ you ~~can use a Bang & Olufsen remote which only has a single set of~~ up/down/left/right ~~buttons, and~~ LinuxMCE knows ~~that~~ when ~~there is a menu on screen~~ those buttons ~~should move~~ the ~~highlighter around on the screen~~, and ~~when there is not a menu~~ on ~~screen, those buttons are used for rewind fast-forward and skip up/down. The logic is all handled automatically so for~~ the ~~user it is a very intuitive experience, allowing all sorts of different devices to be controlled with all sorts of different~~ remote ~~controls without having to do any setup~~.~~</p>~~		Now when you hit ''up/down/left/right/enter'' LinuxMCE knows you obviously want to control the satellite TV box. So, when you press those buttons LinuxMCE translates the infrared codes into ones that your satellite TV box understands, and the same arrows on the remote control will now control the satellite TV.

			You hit 'Power Off', and the satellite box shuts off. Now the Orbiter's menu is again visible. The arrows will again control the Orbiter.

			You choose the button to watch a DVD in your DVD Player. Now the same arrows will control the DVD player. When you hit ''pause'' the DVD player will pause (even though using the LinuxMCE remote instead of the DVD remote.

			LinuxMCE translates everything for you so you don't have to juggle remote controls. If you again hit ''power'', the DVD turns off. Hit ''power'' again and the the TV shuts off. Hit ''power'' a third time and the Media Director turns off.

			This is even better than a universal remote control since you don't need to tell it what device you want to control -- LinuxMCE figures it out on its own.

			Although you can use all sorts of remote controls (all with different buttons), they will control LinuxMCE in a consistent manner. The media-specific buttons, like ''rewind/fastforward/ play/pause'', will always control whichever media device you are currently using (no matter what screen is visible on the on-screen Orbiter). Navigation buttons, like ''up/down/left/right/enter'' and the 10-key number pad, will control the currently active media device (as long as the on-screen Orbiter is showing the remote control menu for that device). Otherwise it controls the on-screen Orbiter. When the main menu is visible on the Orbiter, you can select scenarios with the ''up/down/left/right/enter'' buttons (or the 10-key pad).

			To use the 10-key pad, choose the type of scenario you want. The categories are numbered: 1=Lighting, 2=Media, 3=Climate, 4=Telecom, 5=Security, 6=Misc. Thus, 22 on the remote will start TV (2=Media category and TV is the 2nd option in the category).

	== Programmer's Guide ==		== Programmer's Guide ==

Perspectoff at 15:57, 25 May 2008

2008-05-25T15:57:30Z

←Older revision		Revision as of 15:57, 25 May 2008
Line 1:		Line 1:
	~~{{cleanup}}~~

	==How to set it up==		==How to set it up==
	*In [[LinuxMCE Admin Website]]-->Wizard-->Devices-->Media Directors, choose the type of Infrared Receiver you have from the pull-down. The list of choices includes [http://lirc.org/ LIRC drivers]. Most users can use the "default" driver.		*In [[LinuxMCE Admin Website]]-->Wizard-->Devices-->Media Directors, choose the type of Infrared Receiver you have from the pull-down. The list of choices includes [http://lirc.org/ LIRC drivers]. Most users can use the "default" driver.

←Older revision		Revision as of 16:19, 25 May 2008
Line 35:		Line 35:
	*Read the How To Use It section (above) first.		*Read the How To Use It section (above) first.

	As you can see, LinuxMCE provides a highly intelligent interpretation of infrared remote buttons, that automatically change their function based on what the user is doing, what type of remote control layout exists, and where the infrared codes are going. If you have ever worked with infrared remote controls, such as LIRC, you know that there is no standard, and all the remote controls have different buttons with different names. Therefore we had to create a database structure that allows for interpreting the different button names into commands which can change depending upon the context and the layout of the remote.~~</p>~~		As you can see, LinuxMCE provides a highly intelligent interpretation of infrared remote buttons, that automatically change their function based on what the user is doing, what type of remote control layout exists, and where the infrared codes are going. If you have ever worked with infrared remote controls, such as LIRC, you know that there is no standard, and all the remote controls have different buttons with different names. Therefore we had to create a database structure that allows for interpreting the different button names into commands which can change depending upon the context and the layout of the remote.

	The DCE Devices (i.e. the LinuxMCE binary that ~~is run to handle i~~/r reception) are ~~all of~~ the category Peripherals, Infrared Receivers.		The DCE Devices (i.e. the LinuxMCE binary that handles I/R reception) are specified in the category Peripherals-->Infrared Receivers.

	In [[LinuxMCE Admin Website]]-->Advanced--> Device Templates, you can see the categories and devices in them. There is a separate folder for the LIRC drivers. In addition to a device for the i/r receiver, there is also a device for the i/r remote. The remote controls are of the type Peripherals > Remote Controls. Since the definition of the infrared codes for a remote control is stored within the remote control device, and that definition varies depending upon the type of receiver, you will see there is a separate subcategory for each type of receiver.		In [[LinuxMCE Admin Website]]-->Advanced--> Device Templates, you can see the categories and devices in them. There is a separate folder for the LIRC drivers. In addition to a device for the I/R receiver, there is also a device for the I/T remote. The remote controls are of the type Peripherals --> Remote Controls. Since the definition of the infrared codes for a remote control is stored within the remote control device, and that definition varies depending upon the type of receiver, you will see that there is a separate subcategory for each type of receiver.

	For example there is a folder "LIRC Remote Controls" that has all of the remote controls and definition files for the LIRC project. We also created our own DCE devices for other infrared receivers, such as IRTrans and Tira. Although these are supported within the ~~lirc~~ project, we found that we had better control and greater accuracy when we used the native SDKs for these receivers. So, for example, if you have an IRTrans receiver, and an XPMC remote, you have two possibilities. First you could add the LIRC receiver device, and the XPMC remote device that is within the LIRC remote category. In this case the remote control will be using an LIRC config file. Secondly you could add LinuxMCE's native IRTrans receiver device, and then pick the XMPC remote device that is within the IRTrans remotes category, which stores the button codes in a different format, that is in IRTrans' native format. When you are adding your infrared receiver and remote control using the LinuxMCE Admin Wizard/Devices/Media Directors page, the wizard automatically ensures that when you add a remote control it is the correct category.		For example there is a folder "LIRC Remote Controls" that has all of the remote controls and definition files for the LIRC project. We also created our own DCE devices for other infrared receivers, such as IRTrans and Tira. Although these are supported within the LIRC project, we found that we had better control and greater accuracy when we used the native SDKs for these receivers. So, for example, if you have an IRTrans receiver, and an XPMC remote, you have two possibilities. First you could add the LIRC receiver device, and the XPMC remote device that is within the LIRC remote category. In this case the remote control will be using an LIRC config file. Secondly you could add LinuxMCE's native IRTrans receiver device, and then pick the XMPC remote device that is within the IRTrans remotes category, which stores the button codes in a different format, that is in IRTrans' native format. When you are adding your infrared receiver and remote control using the LinuxMCE Admin Wizard/Devices/Media Directors page, the wizard automatically ensures that when you add a remote control it is the correct category.

	For each remote control there is a device data "#59 Configuration" which has the remote controls configuration file, which ~~defined all~~ the infrared codes at each button will send and gives each code, or button, a name. ~~So the~~ XPMC remote within the LIRC category has a device data #59 that is the LIRC config file. The XPMC remote within the IRTrans category has a device data #59 that is the same ~~buttons/~~codes, but in IRTrans format.		For each remote control there is a device data "#59 Configuration" which has the remote controls configuration file (which defines the infrared codes each button will send, and gives each code, or button, a name). The XPMC remote within the LIRC category has a device data #59 that is the LIRC config file. The XPMC remote within the IRTrans category has a device data #59 that has the same button codes, but in IRTrans format.

	When the framework starts an IR receiver device, ~~iIn~~ general this device will first scan for ~~all~~ sister devices within the category remote control, and write out a configuration file. ~~So, for~~ example, when LIRC_DCE runs it finds all LIRC remote controls on that machine, grabs the device data "#59 Configuration" for every one of them and writes that out to a lirc.conf file~~, and~~ then starts LIRC.		When the framework starts an IR receiver device, in general this device will first scan for sister devices within the category remote control (and will then write out a configuration file). For example, when LIRC_DCE runs it finds all LIRC remote controls on that machine, grabs the device data "#59 Configuration" for every one of them and writes that out to a lirc.conf file. It then starts LIRC.

	~~All the~~ logic is in a base class called IRReceiverBase. ~~All of~~ LinuxMCE's infrared receiver devices use this same base class. So the actual code that is specific to each type of receiver is very small, usually around 20 lines. It only needs to write out the configuration file at start up, and then call the member function ReceivedCode within IRReceiverBase when a button is pushed. This function takes the name of the button as a parameter, and converts this into a message.		The logic is in a base class called IRReceiverBase. LinuxMCE's infrared receiver devices all use this same base class. So the actual code that is specific to each type of receiver is very small, usually around 20 lines. It only needs to write out the configuration file at start up, and then call the member function ReceivedCode within IRReceiverBase when a button is pushed. This function takes the name of the button as a parameter, and converts this into a message.

	Since all ~~of the~~ receivers use a common base class to handle the logic, that ~~also~~ means that ~~all of~~ the translation between buttons and actions is also in a shared database. It does not matter whether you are using LIRC or some other infrared receiver, the translation is the same. There is no unified standard for what the buttons are called. The button "SkipFwd" may be called "Fwd", "Skip+", "Jump->", etc. The table RemoteMapping in the main mysql database, pluto_main, has a field Mapping which lists all the button aliases, followed by the command to be executed when any of those buttons is pushed. For example: chup;skipfwd;ChanUp;SkipNext;\|0 -106 1 65 5 +1		Since all receivers use a common base class to handle the logic, that means that the translation between buttons and actions is also in a shared database. It does not matter whether you are using LIRC or some other infrared receiver, the translation is the same. There is no unified standard for what the buttons are called. The button "SkipFwd" may be called "Fwd", "Skip+", "Jump->", etc. The table RemoteMapping in the main mysql database, pluto_main, has a field Mapping which lists all the button aliases, followed by the command to be executed when any of those buttons is pushed. For example: chup;skipfwd;ChanUp;SkipNext;\|0 -106 1 65 5 +1

	Whenever any infrared receiver reports any of those button presses, the message "0 -106 1 65 5 +1" gets ~~fired~~. The format of the message is the same as if you typed it with the MessageSend utility: ie from device, to device message type, message id, followed by parameters.		Whenever any infrared receiver reports any of those button presses, the message "0 -106 1 65 5 +1" gets triggered. The format of the message is the same as if you typed it with the MessageSend utility: i.e. from device, to device message type, message id, followed by parameters.

	~~So if~~ the user presses a button called ChanUp, a message will be sent to device -106 (media plugin) of type 1 (command) id 65 (Jump Position In Playlist) with parameter 5 (Value To Assign) set to "+1". This table is shared ~~amongst~~ all LinuxMCE users, and is updated every time your system upgrades versions. If you make your own manual changes to this table then the next time your core upgrades it will not upgrade the rows in that table that you modified~~, because~~ SQL CVS does not, by default, overwrite your local changes with global ones. Therefore, if you have a new remote control with some new buttons that we have not yet mapped, it is recommended that you e-mail us or post us a message in the forum, with the button name and the message and then we can add it to our master database and then your system can remain in sync with other users enhancements. If you want to do some mapping that is just for you, you can change the table and know your changes will not be overwritten.		If the user presses a button called ChanUp, a message will be sent to device -106 (media plugin) of type 1 (command) id 65 (Jump Position In Playlist) with parameter 5 (Value To Assign) set to "+1". This table is shared betweem all LinuxMCE users, and is updated every time your system upgrades versions. If you make your own manual changes to this table, then the next time your core upgrades it will not upgrade the rows in that table that you modified. SQL CVS does not, by default, overwrite your local changes with global ones.

	~~You'll note~~ that ~~the RemoteMapping table has 2 optional fields: ScreenType and RemoteLayout. When the IRReceiverBase base class is deciding what message to send in response to button press~~, it first looks for a more specific entry where the screen type matches the type of screen currently visible on the orbiter, and the remote layout matches the layout. The on-screen orbiters regularly send messages to the infrared receiver telling them what type of screen is ~~currently visible, using the following codes: M=Main Menu, m=other menu, R=LinuxMCE Remote, r=Non~~-LinuxMCE remote, F=File Listing. This allows for buttons to behave differently depending upon what type of screen is visible. For example when the main menu is visible, the arrows on a remote control should send a message ~~to the on-screen orbiter to move the highlight pointer around on the screen. However when~~ the ~~user is controlling an external piece of AV equipment, like a DVD player~~, the ~~arrows should pass through to~~ the ~~DVD player so the user~~ can ~~control its own on-screen menu. Also the type of functionality~~ can ~~vary depending upon the layout of the remote~~. ~~For example, Bang & Olufsen remotes are quite simple, there~~ is only a single up/down/left/right buttons which are used both to navigate on-screen menus as well as to handle rewind fast-forward and skip. Other remotes have dedicated arrows and media navigation buttons. So one remote layout can be created for ~~Bang & Olufsen-style remote~~, ~~where~~ the ~~arrows control the menu when there is a menu on screen,~~ and ~~adjust the media when there is~~ not. ~~The remote layout is a device data "#110 Remote Layout" stored with the remote control~~		Therefore, if you have a new remote control with some new buttons that we have not yet mapped, it is recommended that you e-mail us or post us a message in the forum, with the button name and the message and then we can add it to our master database and then your system can remain in sync with other users enhancements. If you want to do some mapping that is just for you, you can change the table and know your changes will not be overwritten.

	When IRReceiverBase looks for a mapping it first looks for records that match the current screen type and remote layout, and then revert to standard records (ie ScreenType and RemoteLayout are null) only if there are no matching results.		Note that the RemoteMapping table has 2 optional fields: ScreenType and RemoteLayout. When the IRReceiverBase base class is deciding which message to send in response to abutton press, it first looks for a more specific entry where the screen type matches the type of screen currently visible on the orbiter, and the remote layout matches the layout. The on-screen Orbiters regularly send messages to the infrared receiver telling them what type of screen is currently visible, using the following codes: M=Main Menu, m=other menu, R=LinuxMCE Remote, r=Non-LinuxMCE remote, F=File Listing. This allows for buttons to behave differently depending upon what type of screen is visible.

			For example, when the main menu is visible, the arrows on a remote control should send a message to the on-screen Orbiter to move the highlight pointer around on the screen. However, when the user is controlling an external piece of AV equipment, like a DVD player, the arrows should pass through to the DVD player so the user can control its own on-screen menu. Also the type of functionality can vary depending upon the layout of the remote.

			For example, Bang & Olufsen remotes are quite simple: there is only a single ''up/down/left/right'' button which is used both to navigate on-screen menus as well as to handle ''rewind fast-forward'' and ''skip''. Other remotes have dedicated arrows and media navigation buttons. So, one remote layout can be created for Bang & Olufsen-style remote, where the arrows control the menu when there is a menu on screen, and adjust the media when there is not. The remote layout is a device data "#110 Remote Layout" stored with the remote control

			When IRReceiverBase looks for a mapping it first looks for records that match the current screen type and remote layout, and then revert to standard records (i.e. ScreenType and RemoteLayout are null) only if there are no matching results.

	See also: [[Add support for new remote controls]]		See also: [[Add support for new remote controls]]