Discrete on/off IR commands

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 08:01

I would like to discuss this topic to follow on from the discrete code discussion here which references my discrete on/off instructions here.

The discrete on/off functionality that I posted only applied to the T4, as it had received a driver update to enable the new KEY_POWER2 (0xfc) command.

The drawback to the modification is that it is forced to re-use the power toggle key from the native remote (KEY_POWER) and use it as the discrete-on command.

What is needed for a cleaner solution is an IR command that can be recognised by both the front panel and the running firmware as a wakeup-only command. The existing 0xC0FFEE discrete on command is not suitable, as it will wake all T series boxes within the IR broadcast area, and it is only functional from deep-standby, not from regular standby.

There was an additional command added to the driver that could be of use.
Command KEY_WAKEUP (0xfb) could be used to wake the T series from standby, but not from deep standby.

My first query is, can the KEY_WAKEUP (0xfb) code be added to the front panel firmware as a second power-on code in addition to the existing KEY_POWER (0x0a) code.

This way, users who wish to use either power toggle or discrete power commands may do so without interference.

This will of course not be possible on the T2 as it lacks upgradable front panel firmware.

If the second wake command cannot be added to the T3/T4 front panel, then we would need to look at adapting my previous solution into something a little cleaner.

dRdoS7 · Post by **dRdoS7** » Sun Dec 27, 2015 09:23

MrQuade wrote:The existing 0xC0FFEE

Could we have a 1xBEER command?

IanSav · Post by **IanSav** » Sun Dec 27, 2015 10:16

Hi,

MrQuade has nicely summarised the situation. I definitely support a change that will allow users to have discrete ON and OFF codes without compromising the POWER toggle code. I would also ask that any new codes follow the same device and sub device coding as selected for the remote control with the function code alone used to select the desired new functions.

An ON code should bring the unit to running state without regard to its previous state. That is, if the unit is in standby or shutdown / deep standby the ON code should bring the unit fully on.

The OFF code should be configurable in the button settings screen to allow the user to choose if OFF means standby or shutdown / deep standby. Different users will have different requirements. Alternatively there could be two OFF codes, one for standby and one for shutdown / deep standby. The latter is probably more flexible.

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 10:38

IanSav wrote:I would also ask that any new codes follow the same device and sub device coding as selected for the remote control with the function code alone used to select the desired new functions.

I don't think it is possible to craft an IR code that does not include the device prefix, so they would naturally be included.

IanSav wrote: An ON code should bring the unit to running state without regard to its previous state. That is, if the unit is in standby or shutdown / deep standby the ON code should bring the unit fully on.

As long as the front panel is configured with the new code, the same discrete on can simply be added to the keymap.xml file as part of the accompanying firmware update (and as I have already done in my other mod), so it will work exactly as described.

IanSav wrote: The OFF code should be configurable in the button settings screen to allow the user to choose if OFF means standby or shutdown / deep standby. Different users will have different requirements. Alternatively there could be two OFF codes, one for standby and one for shutdown / deep standby. The latter is probably more flexible.

The way I configured my previous mod, the discrete-off function simply used the existing setting for the power-toggle button, so it allowed you to select if you wanted standby or deep standby from the GUI. Are you proposing that power-toggle and discrete-off should be able to be configured with different behaviours?

peteru · Post by **peteru** » Sun Dec 27, 2015 11:22

MrQuade wrote:an IR command that can be recognised by both the front panel and the running firmware as a wakeup-only command.

That is already the case for the front panel. All front panels across all models support only one IR command. The response to that one command is to power on the main board if it is off and do nothing otherwise. All IR commands are also routed to the main board and the drivers and application decide how to react to those.

MrQuade wrote:The existing 0xC0FFEE discrete on command is not suitable

Don't think of the 0xC0FFEE code as a user level code. This is effectively a service mode IR command that can be used to power on a system regardless of what remote the user has selected. It's not even available on all hardware models.

MrQuade wrote:can the KEY_WAKEUP (0xfb) code be added to the front panel firmware as a second power-on code in addition to the existing KEY_POWER (0x0a) code.

No.

As detailed above the front panel only understands one IR code. The front panel reacts to this single IR code only when the main board is powered off and the only thing that the front panel does is to power on the main board. Everything else is handled by drivers and application. The driver actually has a minimal role. The driver code listens to the IR codes for a particular device id and then translates known IR keycodes into Linux input event codes. These events are then delivered to the application and it is up to the application to choose how to respond.

The T4 driver (and only T4 for now) currently generates the usual KEY_POWER as well as three additional new events: KEY_SUSPEND, KEY_WAKEUP and KEY_POWER2. Currently there is no assigned functionality for these three new events, but they can be used in the keymap or enigma2 code to do whatever is required.

One option would be to change enigma2 to not use KEY_POWER to shutdown and use KEY_POWER2 instead, thus giving discrete on and off commands. This can't be the default setting because the supplied remote does not have the capability of sending KEY_POWER2, but it could be a user setting that users with a programmable remote could enable.

The additional KEY_SUSPEND and KEY_WAKEUP events could be used for other purposes, such as to go directly to standby or wake up only if the T4 is in standby, or they could be repurposed for other functions, such as to emulate a separate pause button, aspect ratio switch button, setup button, etc...

Either way, the T4 front panel and driver now have enough mechanisms to achieve discrete on/off. People wishing to customise can do so now with a fairly simple change to they keymap. The next step would be to standardise such a change by making it a user selectable option in the user interface, such as "Only use discrete POWER OFF" (This will ignore normal power commands and will only standby/shutdown when the discrete power off code is received.)

IanSav · Post by **IanSav** » Sun Dec 27, 2015 11:26

Hi MrQuade,

MrQuade wrote:I don't think it is possible to craft an IR code that does not include the device prefix, so they would naturally be included.

You are correct but I was more intending that the device and sub device codes used for the new functions be the same as for the other functions on the remote. 0xC0FFEE is an example where the device and sub device codes differed from all the other codes.

MrQuade wrote:The way I configured my previous mod, the discrete-off function simply used the existing setting for the power-toggle button, so it allowed you to select if you wanted standby or deep standby from the GUI. Are you proposing that power-toggle and discrete-off should be able to be configured with different behaviours?

Yes.

If the user is using the factory remote control then the POWER button should always work as it has been configured. Menu, no menu, whatever is chosen in "MENU > Setup > System > Button settings". A user with a programmable remote control may wish to have a different behaviour when the discrete OFF function codes are used.

Assume the following function names:

POWER - Function code 0x0A (Current POWER button)
STANDBY - New function code to nominate standby mode
SHUTDOWN - New function code to nominate shutdown / deep standby mode
ON - New function code to nominate full on mode

For example POWER could be configured to pop up the power menu but STANDBY would immediately send the unit to standby mode while SHUTDOWN would immediately send the unit to shutdown / deep standby mode. (ON as previously discussed would bring the unit fully on.) This would allow users with activity based remote controls to accurately determine the state the unit is in. (Assuming the functions are not interrupted by other activities like active recordings!

)

An interesting thought: Should the STANDBY function also bring the unit to standby mode if the unit is currently in shutdown / deep standby? In this case it would be considered an ON code as well. I suspect that this could be an attractive feature.

Regards,
Ian.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 11:32

Hi PeterU,

Do you have the IR function codes for those new KEY codes? I would like to add them to my IR code generator program.

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 11:44

IanSav wrote: Do you have the IR function codes for those new KEY codes? I would like to add them to my IR code generator program.

You can convert those yourself to some common formats with the following website:
http://irdb.tk/

They would be 0x02fb and 0x02fc for the T4's remote in its default configuration.

ie.
Protocol NEC1, device 2, subdevice 251, OBC 252
and
Protocol NEC1, device 2, subdevice 252, OBC 252

Gully · Post by **Gully** » Sun Dec 27, 2015 11:45

peteru wrote:The T4 driver (and only T4 for now) currently generates the usual KEY_POWER as well as three additional new events: KEY_SUSPEND, KEY_WAKEUP and KEY_POWER2. Currently there is no assigned functionality for these three new events, but they can be used in the keymap or enigma2 code to do whatever is required.

One option would be to change enigma2 to not use KEY_POWER to shutdown and use KEY_POWER2 instead, thus giving discrete on and off commands. This can't be the default setting because the supplied remote does not have the capability of sending KEY_POWER2, but it could be a user setting that users with a programmable remote could enable.

The additional KEY_SUSPEND and KEY_WAKEUP events could be used for other purposes, such as to go directly to standby or wake up only if the T4 is in standby, or they could be repurposed for other functions, such as to emulate a separate pause button, aspect ratio switch button, setup button, etc...

Either way, the T4 front panel and driver now have enough mechanisms to achieve discrete on/off. People wishing to customise can do so now with a fairly simple change to they keymap. The next step would be to standardise such a change by making it a user selectable option in the user interface, such as "Only use discrete POWER OFF" (This will ignore normal power commands and will only standby/shutdown when the discrete power off code is received.)

Any reason not to add this to the T3, Peter?

Using a Harmony remote, a discrete on and off code would be really great.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 11:55

peteru wrote: All front panels across all models support only one IR command.

So you are saying that the front panel firmware cannot be changed to add a second command, or simply that it currently doesn't have support for it?

peteru wrote: Either way, the T4 front panel and driver now have enough mechanisms to achieve discrete on/off. People wishing to customise can do so now with a fairly simple change to they keymap. The next step would be to standardise such a change by making it a user selectable option in the user interface, such as "Only use discrete POWER OFF" (This will ignore normal power commands and will only standby/shutdown when the discrete power off code is received.)

The problem is as I said earlier, there is no single command other than the KEY_POWER command that can bring the unit out of deep standby.
That means, that you have two options if you want a discrete on command.
1) configure a second command for the front panel to listen to to power on from deep standby. If you confirm that it is impossible, then this option is out.
2) re-use KEY_POWER as discrete on as-per my previous mod.

The issues with my mod are twofold.
1) The default remote can still turn the T4 on from standby and deep standby, but can only turn off the T4 with a long-press action.
2) The front panel power button will still turn the T4 on, but cannot be used to turn the T4 off.

Now I would be happy enough with those limitations, because, as you say, you can have a selectable option to "enable discrete power buttons". That way, anyone with a universal remote can take advantage of the functionality (albeit without the ability to turn off the T2/T3/T4 with the front panel power button), and those with the default remote can retain all of their current capabilities.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 12:13

Hi MrQuade,

MrQuade wrote:You can convert those yourself to some common formats with the following website:
http://irdb.tk/

They would be 0x02fb and 0x02fc for the T4's remote in its default configuration.

ie.
Protocol NEC1, device 2, subdevice 251, OBC 252
and
Protocol NEC1, device 2, subdevice 252, OBC 252

I don't understand what you are saying.

PeterU just provided us with three new function code mappings on top of the existing KEY_POWER. I am looking for the IR function codes to access KEY_SUSPEND, KEY_WAKEUP and KEY_POWER2. In your post there are only two codes listed and both feature different sub device codes using the same function code. That doesn't make any sense.

Regards,
Ian.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 12:21

Hi PeterU,

If I understand what your are saying correctly there is only one code that will bring the Beyonwiz out of shutdown / deep standby. That is KEY_POWER (function code 0x0A). All other codes are ignored until the unit is powered on.

Once the unit is in standby (or on) all IR codes are fed to the drivers / software for processing. It is up to the software to decide what to do with any and all IR / KEY_ codes. That includes what to do with KEY_POWER.

Have I understood you correctly so far?

Is it possible to add one more function code to power on the Beyonwiz and allow the driver to know which code was used?

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 12:31

Sorry, I buggered that up completely. Wasn't thinking straight and changed entirely the wrong field

The missing code for sleep was 0xfa. However, last time I was testing that, it was being converted to KEY_SLEEP, which is already used by the keymap file, so something was not quite right with that. Not sure if PeterU has done anything about that yet.

Anyway the codes:
[ 0xFA ] = KEY_SUSPEND (NOT KEY_SLEEP)
Protocol NEC1, device 2, subdevice 242, OBC 250
[ 0xFB ] = KEY_WAKEUP
Protocol NEC1, device 2, subdevice 242, OBC 251
[ 0xFC ] = KEY_POWER2,
Protocol NEC1, device 2, subdevice 242, OBC 252

Edited: KEY_SLEEP to correctly show KEY_SUSPEND (oops)

IanSav · Post by **IanSav** » Sun Dec 27, 2015 12:34

Hi MrQuade,

What about KEY_SUSPEND?

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 12:35

IanSav wrote: What about KEY_SUSPEND?

That would be the KEY_SLEEP that I listed. Sorry, PeterU has changed that then. Comprehension skills fail on my part, I was pulling information from another thread.

Fixed that.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 12:38

Hi,

Now that I know that these codes are only on the T4 I will point my IR Analyser at the T4 rather than the development T3 and see what my debugging UI generates on the serial port.

As Gully asked, I hope these new codes are also added to the T3. It is a shame that the T2 can't partake in all the IR code fun.

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 12:41

IanSav wrote: As Gully asked, I hope these new codes are also added to the T3. It is a shame that the T2 can't partake in all the IR code fun.

The T3 would just need the same driver update that the T4 got. The only reason the T4 had it was because it was experimental. If this becomes a proper feature then it should be a simple thing to enable on the T3.

If we can't get a second wakeup code added to the T3/T4 front panel, then they are simply in the same boat as the T2. The T2 is completely capable of the modifications I described in my post.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 12:48

Hi,

While I am editing my T4 remote control profile I am reminded to add that discrete PLAY and PAUSE function codes should be added independently of these new power related functions.

It will be impossible to have the new power functionality and separate PLAY and PAUSE functions with only three new codes.

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 12:51

I am pretty sure that KEY_PLAY and KEY_PAUSE are already defined commands in addition to the KEY_PLAYPAUSE.
https://bitbucket.org/beyonwiz/easy-ui- ... ew-default

I have no idea what the corresponding IR codes for those are though.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 13:30

Hi MrQuade,

MrQuade wrote:I am pretty sure that KEY_PLAY and KEY_PAUSE are already defined commands in addition to the KEY_PLAYPAUSE.
https://bitbucket.org/beyonwiz/easy-ui- ... ew-default

I have no idea what the corresponding IR codes for those are though.

That is the BIG question. I hope there is are appropriate IR code mappings.

Regards,
Ian.

peteru · Post by **peteru** » Sun Dec 27, 2015 15:04

The discrete power key codes are the same for every device prefix:

Code: Select all

	// Discrete power codes
	[ 0xFA ] = KEY_SUSPEND,
	[ 0xFB ] = KEY_WAKEUP,
	[ 0xFC ] = KEY_POWER2,

The front panels can not support more than one IR code for wakeup. There are multiple reasons for it, including hardware limitations, communication protocol limitations and backwards/forwards compatibility considerations.

T4 is the platform where this functionality will be developed first. Once the T4 implementation is deemed adequate and goes through some real world testing, it will be back ported to the T3 and T2.

However, given some of the requests I have been seeing, I am not sure that continuing on the same trajectory is a good idea at all. I think a better approach may be to define a completely new "programmable IR device", which does not correspond to any existing remote control. This would be a "virtual" remote that has somewhere around 200 or so IR codes mapped to various Linux event codes. This would allow a custom installer the maximum flexibility in designing a remote for whatever task, given that it would be the equivalent of having a remote with 200+ buttons. For maximum flexibility, this programmable IR device map could be available on 4 separate device codes, so you can have up to 4 devices in the same physical location and not have them interfere with each other.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 15:09

Hi PeterU,

I very much like that approach. It would, for example, allow me to use and define functions for the very many buttons available on my Blutooth Sony PS3 Bluray Remote Control. I gather that this more open approach would also allow for mapping and remapping of standard keyboards keys.

The existing Beyonwiz remote controls with their 5 device number code set possibilities would then simply become an instance of this wider scheme.

Regards,
Ian.

peteru · Post by **peteru** » Sun Dec 27, 2015 15:15

IanSav wrote:allow me to use and define functions for the very many buttons available on my Blutooth Sony PS3 Bluray Remote Control.
...
The existing Beyonwiz remote controls with their 5 device number code set possibilities would then simply become an instance of this wider scheme.

You have it back to front. It's not a case of the T4 accepting arbitrary IR codes. Instead the T4 will define a set of 4*200 IR codes and their mapping to Linux event codes and it is the responsibility of the person programming the remote control to send the correct IR codes.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 15:35

Hi,

While a rework of the remote control code would be welcome there are probably people waiting for a faster solution.

An idea I am working up at the moment would be to define KEY_SUSPEND as a IR command that immediately sets the Beyonwiz to standby. No prompts or other interactions with the user. This should then facilitate the following options that should be activity based remote control friendly. This proposal also keeps the current manufacturer remote control and front panel functionality.

(For simplicity in the following narrative I will only use the term shutdown but it also means deep standby for those who prefer that term.)

Send KEY_POWER to always wake the unit from either shutdown or standby.
Send KEY_POWER when the unit is on to trigger the currently implemented power menu / power control options.
Send KEY_SUSPEND when the unit is on to always send the unit to standby mode. No user interaction should be required.
Send KEY_SUSPEND when the unit is in standby is always ignored.
Send KEY_SUSPEND followed by KEY_POWER to always send the unit to the full on state. This sequence would be used by people with activity based remote controls.
- If the unit is in shutdown mode then KEY_SUSPEND will be ignored and KEY_POWER will turn the unit on.
- If the unit is in standby mode then KEY_SUSPEND will do nothing and KEY_POWER will turn the unit on.

If required, KEY_POWER2 can be programmed used to always send the unit to shutdown mode (from both on and standby modes). This *MAY* trigger user interactions if the unit is currently busy! Because of the possibility of user interaction being required I don't think this command would be particularly useful. On the other hand the command could be special and assume that the user *REALLY* wants the unit shut down and automatically stop all activities (without user interaction) and go directly to shutdown mode.

Have I covered all the required bases?

What do people think?

Regards,
Ian.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 15:39

Hi PeterU,

peteru wrote:You have it back to front. It's not a case of the T4 accepting arbitrary IR codes. Instead the T4 will define a set of 4*200 IR codes and their mapping to Linux event codes and it is the responsibility of the person programming the remote control to send the correct IR codes.

Are these four sets all new? What would happen to the existing remote controls and the five different device codes that they support?

How could I use my Sony remote control which has fixed function codes assigned to each button. Would some sort of mapping or translation layer be possible?

Regards,
Ian.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 16:06

Hi MrQuade,

If there is a chance that KEY_STANDBY can be missed then use a few in a row - it won't hurt. It may also be necessary to introduce some delay between the individual transmissions. I don't have an activity based remote control so my comments are based on a conversation with a user who does.

Did you find any problems with the logic of my proposal? For those who don't have IR line of sight problems this proposal should work fine.

If you are losing remote control sequences due to physical issues then all bets are off. Without an ability to change the front panel in a way that I don't think PeterU is willing to do then no matter what you try and program nothing can get around such a loss of physical signal.

In my case I recently purchased some cheap IR repeaters. They are working far better than I could ever have expected. I can use a Beyonwiz remote control or my remote control tablet in an adjacent room with poor or even no line of sight and the repeater receiver is sensitive enough to pick up the signal and relay it accurately to the Beyonwiz units.

EDIT: Hmmm, I appear to be replying to a post that no longer exists.

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 16:10

IanSav wrote:EDIT: Hmmm, I appear to be replying to a post that no longer exists.

Yes, I realised my example was a bad one and went to repost.

What I am trying to say is that if you use that standby-power combination while the PVR is running, then you will either glitch into standby and out again, or if a command is missed, end up in standby or in the power menu when you didn't need to be.

You *have* to cater for when a command is missed if you are going to be invoking sequences to do a job.

Personally, I use the Harmony Ultimate that has blasters so do not suffer from this, but others are not so fortunate.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 16:16

Ahh, and the other part that was in my deleted post.

A question for PeterU. Can the front panel firmware be changed such that it sends something other than KEY_POWER when the power button on the front panel is pressed while the T4 is running? Or rather, if I have that backwards, can the T4 interpret the button as something other than KEY_POWER.

If that was possible, then you could use my previous solution, and regain the functionality of the front panel power button for its intended use.

The only limitation then is that the IR command for KEY_POWER would no longer toggle power, but can still be long-pressed and that long-press action can be configured to do whatever you want it to do as-per existing functionality.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 16:25

Hi MrQuade,

MrQuade wrote:You *have* to cater for when a command is missed if you are going to be invoking sequences to do a job.

*I* don't have the problem so I don't *have* to do anything.

I am simply trying to identify a solution for those users who have activity based remote controls and want to gain some extra functionality / improved reliability.

Regards,
Ian.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 16:27

Hi MrQuade,

MrQuade wrote:The only limitation then is that the IR command for KEY_POWER would no longer toggle power, but can still be long-pressed and that long-press action can be configured to do whatever you want it to do as-per existing functionality.

Any changes that break any existing functionality should not be considered.

Regards,
Ian.

peteru · Post by **peteru** » Sun Dec 27, 2015 16:31

IanSav wrote:Have I covered all the required bases? What do people think?

It looks a bit like a subset of the full finite-state machine that I put up for some closed discussions back in August. I have since revised it and here's my current take on it:

back in August 2015, peteru wrote:The idea is that there are three power states, OFF, ON and STANDBY and four keys that can affect those states.
KEY_SUSPEND
ON -> STANDBY
OFF -> OFF
STANDBY -> STANDBY

KEY_WAKEUP
ON -> ON
OFF -> OFF
STANDBY -> ON

KEY_POWER2 (aka power off key)
ON -> OFF
OFF -> OFF
STANDBY -> OFF

KEY_POWER (existing key, which may need reassignment when operating in "discrete" mode)
ON -> ON
OFF -> ON
STANDBY -> ON
All the transitions from OFF mode are fixed because of hardware limitations.

Feedback welcome at this stage.

Once you draw the finite-state machine diagram on a bit of paper, the transitions from any state to any other state become fairly obvious and more importantly you will see that you can get from any state to any other state with a single and consistent code. The only exception to that is the transition from OFF to STANDBY, which is both tricky and not very interesting. That transition would require two codes and their timing would play a role.

My proposal was designed to provide maximum flexibility to cater for all sorts of scenarios. MrQuade's feedback was along the lines that for most practical purposes, half of the discrete power control keys were not required. I'm not sure whether that view is coloured by him being a Logitech user and looking at the problem through Logitech Harmony coloured glasses or whether that is generally the case for most systems. However, given that the vast majority of people who would look for this feature are very likely to be Logitech users, it's probably not a bad idea to make the Logitech way the primary use case scenario.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 16:33

IanSav wrote:Hi MrQuade,
MrQuade wrote:The only limitation then is that the IR command for KEY_POWER would no longer toggle power, but can still be long-pressed and that long-press action can be configured to do whatever you want it to do as-per existing functionality.
Any changes that break any existing functionality should not be considered.

What's broken though? If you switch on discrete codes, then you no longer require the toggle code.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 16:37

peteru wrote: It looks a bit like a subset of the full finite-state machine that I put up for some closed discussions back in August. I have since revised it and here's my current take on it:

Looks fine to me. It's the same as what I had, but with the added WAKEUP and SUSPEND codes for additional functions.

You have the same KEY_POWER issue that IanSav has an issue with though. (loss of toggle function and front panel issue).

peteru · Post by **peteru** » Sun Dec 27, 2015 16:38

What's broken though?

Two users in the same room. One user prefers Harmony, the other the T3 remote. However, that is solvable too, just configure long press of POWER to bring up the POWER menu. The T3 remote user would just have to get into the habit of long pressing POWER to go to standby or shut down.

peteru · Post by **peteru** » Sun Dec 27, 2015 16:40

I'm not quite sure if front panel is an issue. If I recall correctly, the keymap file has the facility to differentiate keys from different devices. Have a closer look...

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 16:47

peteru wrote:
What's broken though?
Two users in the same room. One user prefers Harmony, the other the T3 remote. However, that is solvable too, just configure long press of POWER to bring up the POWER menu. The T3 remote user would just have to get into the habit of long pressing POWER to go to standby or shut down.

That's exactly what I proposed (and how the T4 discrete codes are currently operating on my T4), and what IanSav doesn't like.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 16:49

peteru wrote:I'm not quite sure if front panel is an issue. If I recall correctly, the keymap file has the facility to differentiate keys from different devices. Have a closer look...

Hmm ok. Just that when I removed KEY_POWER from the keymap.xml file to prevent the T4 from responding to it when in the ON state, the front panel power button stopped working. I just presumed that it also sent a KEY_POWER. I'll see if there is an alternative.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 16:54

Hi PeterU,

peteru wrote:I'm not quite sure if front panel is an issue. If I recall correctly, the keymap file has the facility to differentiate keys from different devices. Have a closer look...

Are you talking about the "device=" tags in the keymap.xml file?

For example:

Code: Select all

		<device name="dreambox front panel">
			<key id="KEY_POWER" mapto="deepstandby" flags="l"/>
		</device>

I know there is also a device called "keyboard" that I assume relates to a standard 101 key beyboard. Is this available in the Beyonwiz firmware? What are the other device names that can be used on the Beyonwiz? I suspect that the various "dreambox" definitions, like the one in the example above, are left overs from the upstream builds.

Regards,
Ian.

Gully · Post by **Gully** » Sun Dec 27, 2015 16:59

peteru wrote:It looks a bit like a subset of the full finite-state machine that I put up for some closed discussions back in August. I have since revised it and here's my current take on it:

back in August 2015, peteru wrote:The idea is that there are three power states, OFF, ON and STANDBY and four keys that can affect those states.
KEY_SUSPEND
ON -> STANDBY
OFF -> OFF
STANDBY -> STANDBY

KEY_WAKEUP
ON -> ON
OFF -> OFF
STANDBY -> ON

KEY_POWER2 (aka power off key)
ON -> OFF
OFF -> OFF
STANDBY -> OFF

KEY_POWER (existing key, which may need reassignment when operating in "discrete" mode)
ON -> ON
OFF -> ON
STANDBY -> ON
All the transitions from OFF mode are fixed because of hardware limitations.

Feedback welcome at this stage.

That looks perfect for a Harmony Remote user.

In my case adding KEY_WAKEUP to the end my Watch PVR start up would ensure the T3 was on regardless of being ON or in STANDBY.

And adding KEY_SUSPEND to the exit string would always ensure the T3 was in STANDBY.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 17:00

Hi MrQuade,

MrQuade wrote:
peteru wrote: It looks a bit like a subset of the full finite-state machine that I put up for some closed discussions back in August. I have since revised it and here's my current take on it:
Looks fine to me. It's the same as what I had, but with the added WAKEUP and SUSPEND codes for additional functions.

You have the same KEY_POWER issue that IanSav has an issue with though. (loss of toggle function and front panel issue).

If the modification away from the default operation of KEY_POWER is made optional via a UI selection option such that I can have ALL the buttons work as they do now and users who want the discrete options for activity based remote controls can opt for the modified behaviour then I would be okay with the proposal.

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 17:15

IanSav wrote: If the modification away from the default operation of KEY_POWER is made optional via a UI selection option such that I can have ALL the buttons work as they do now and users who want the discrete options for activity based remote controls can opt for the modified behaviour then I would be okay with the propose.

You realise of course this is what I have been saying the whole time?
When you enable "discrete mode", then you disable the KEY_POWER from functioning when the T4 is on.

All of your proposed changes with key sequences can already be achieved by editing the keymap.xml file and will not interfere with the current operation of the T4 and T4 native remote. Your solution would not require "discrete mode" to be enabled.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 17:33

Hi MrQuade,

The quoting in your last post is a little broken but I believe you are confirming that all the proposals work without issue now except the change to KEY_POWER which could be made switch-able in the UI so that users can select current operation or new discrete mode.

So when will the changes be coded and made available for the activity based remote control owners?

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 17:52

IanSav wrote:I know there is also a device called "keyboard" that I assume relates to a standard 101 key beyboard. Is this available in the Beyonwiz firmware? What are the other device names that can be used on the Beyonwiz? I suspect that the various "dreambox" definitions, like the one in the example above, are left overs from the upstream builds.

Ahh thanks for the tips. I have modified my keymap thusly:

Code: Select all

	<map context="GlobalActions">
		<key id="KEY_VOLUMEUP" mapto="volumeUp" flags="mr"/>
		<key id="KEY_VOLUMEDOWN" mapto="volumeDown" flags="mr"/>
		<key id="KEY_MUTE" mapto="volumeMute" flags="mr"/>
		<key id="KEY_POWER" mapto="power_long" flags="l"/>
<!--+
		<key id="KEY_POWER" mapto="power_down" flags="m"/>
		<key id="KEY_POWER" mapto="power_up" flags="b"/> +-->
		<key id="KEY_POWER2" mapto="power_down" flags="m"/>
		<key id="KEY_POWER2" mapto="power_up" flags="b"/>
		<key id="KEY_KP0" mapto="discrete_off" flags="m"/>
		<device name="dreambox front panel">
			<key id="KEY_POWER" mapto="power_down" flags="m"/>
			<key id="KEY_POWER" mapto="power_up" flags="b"/>
		</device>
	</map>

The front power button works just as it did before.

Very nice.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 17:54

IanSav wrote: The quoting in your last post is a little broken but I believe you are confirming that all the proposals work without issue now except the change to KEY_POWER which could be made switch-able in the UI so that users can select current operation or new discrete mode.

So when will the changes be coded and made available for the activity based remote control owners?

Sorry fixed.

As for the changes, that's what I am throwing out there to an experienced developer. I am a long way away from making any python mods to the code.

I'll post the other sections of my keymap file once I have implemented the additional WAKEUP and STANDBY keys (I don't have a purpose for those, so didn't do anything with them yet).

IanSav · Post by **IanSav** » Sun Dec 27, 2015 17:58

Hi MrQuade,

Are you finding that the "dreambox" definitions are working on the Beyonwiz? I am searching the source and can not fix the source code or mapping file for the Beyonwiz remote controls. The closest I came was in "lib/driver/rcdreambox2.cpp" where the following table defines the DreamBox remote control mappings:

Code: Select all

int eRCDeviceDreambox2::getKeyCode(int key)
{
	switch (key)
	{
	case 0x00: return KEY_0;
	case 0x01: return KEY_1;
	case 0x02: return KEY_2;
	case 0x03: return KEY_3;
	case 0x04: return KEY_4;
	case 0x05: return KEY_5;
	case 0x06: return KEY_6;
	case 0x07: return KEY_7;
	case 0x08: return KEY_8;
	case 0x09: return KEY_9;
	case 0x0a: return KEY_VOLUMEUP;
	case 0x0b: return KEY_VOLUMEDOWN;
	case 0x0c: return KEY_TV;
	case 0x0d: return KEY_CHANNELUP;
	case 0x0e: return KEY_CHANNELDOWN;
	case 0x0f: return KEY_POWER;
	case 0x20: return KEY_MENU;
	case 0x21: return KEY_UP;
	case 0x22: return KEY_DOWN;
	case 0x23: return KEY_LEFT;
	case 0x24: return KEY_RIGHT;
	case 0x25: return KEY_OK;
	case 0x26: return KEY_AUDIO;
	case 0x27: return KEY_VIDEO;
	case 0x28: return KEY_INFO;
	case 0x40: return KEY_RED;
	case 0x41: return KEY_GREEN;
	case 0x42: return KEY_YELLOW;
	case 0x43: return KEY_BLUE;
	case 0x44: return KEY_MUTE;
	case 0x45: return KEY_TEXT;
	case 0x50: return KEY_RIGHT;
	case 0x51: return KEY_LEFT;
	case 0x52: return KEY_ESC;
	case 0x53: return KEY_RADIO;
	case 0x54: return KEY_HELP;
	}
	return -1;
}

Does anyone know where the equivalent definitions for the Beyonwiz lives?

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 18:04

IanSav wrote: Are you finding that the "dreambox" definitions are working on the Beyonwiz?

Yes, I just tested the section of the keymap.xml that I posted above and it works.

IanSav · Post by **IanSav** » Sun Dec 27, 2015 18:08

Hi,

MrQuade wrote:
IanSav wrote: Are you finding that the "dreambox" definitions are working on the Beyonwiz?
Yes, I just tested the section of the keymap.xml that I posted above and it works.

Hmmm, I wonder what Dream thinks about that.

I think it would be appropriate to create device names that better reflect the two different Beyonwiz remote controls.

Regards,
Ian.

MrQuade · Post by **MrQuade** » Sun Dec 27, 2015 18:24

Ok, so these modifications to keymap.xml will implement PeterU's state machine and retains the functionality of the front panel.

Code: Select all

	<map context="GlobalActions">
		<key id="KEY_VOLUMEUP" mapto="volumeUp" flags="mr"/>
		<key id="KEY_VOLUMEDOWN" mapto="volumeDown" flags="mr"/>
		<key id="KEY_MUTE" mapto="volumeMute" flags="mr"/>
		<key id="KEY_POWER" mapto="power_long" flags="l"/>
<!--+
		<key id="KEY_POWER" mapto="power_down" flags="m"/>
		<key id="KEY_POWER" mapto="power_up" flags="b"/> +-->
		<key id="KEY_POWER2" mapto="deepstandby" flags="m"/>
		<key id="KEY_SUSPEND" mapto="standby" flags="m"/>
		<key id="KEY_KP0" mapto="discrete_off" flags="m"/>
		<device name="dreambox front panel">
<!--+
			<key id="KEY_POWER" mapto="deepstandby" flags="l"/> +-->
			<key id="KEY_POWER" mapto="power_down" flags="m"/>
			<key id="KEY_POWER" mapto="power_up" flags="b"/>
		</device>
	</map>

Code: Select all

	<map context="StandbyActions">
		<key id="KEY_POWER" mapto="power" flags="m"/>
		<key id="KEY_KP1" mapto="discrete_on" flags="m"/>
		<key id="KEY_WAKEUP" mapto="power" flags="m"/>
	</map>

I left the original lines in there intact but commented out just to show what was modified.

This matches IanSav's suggestions as well.

The new "Enable discrete power buttons" setting would pretty much just enable or disable the KEY_POWER entry in the "Global Actions" section. Probably somewhere else in the code, clearly it would not be making dynamic modifications to the keymap.xml file.

This differs slightly from my original setting of having KEY_POWER2 emulate the function of the KEY_POWER button when the T4 is ON, but PeterU's suggestion is probably the correct one here since standby now has its own key.

My earlier issues with the front panel probably stemmed from the fact that the front panel appears to not be able to send a long-press action.

peteru · Post by **peteru** » Sun Dec 27, 2015 20:08

IanSav wrote:I know there is also a device called "keyboard" that I assume relates to a standard 101 key beyboard. Is this available in the Beyonwiz firmware? What are the other device names that can be used on the Beyonwiz? I suspect that the various "dreambox" definitions, like the one in the example above, are left overs from the upstream builds.

To answer that, I would have to read the enigma2 code, which right now I don't have time for. Good news is, that you can read the code too and should be able to arrive at the answer yourself.

About the Forum

Join us