JP1 Remotes

After having gone through making a Kameleon extender and the work with the RDFs and RM I have a couple of suggestions on how to improve the tools to deal specifically with KAmeleon remotes.

(this is about RM and IR, I'm not a KM user anymore but it could also benefit from this)


1: Find a way to deal with the "lit" keys in the tools. In the RDF we could define the keys that are lit for each device type. Then in the tools not offer as options the keys that are not lit for a given device. It turns out that the remote does check to see if these keys are lit before processing the key so even if you know where it is, the remote won't process it if you press.

This should be relatively straightforward in that a list of keys is put into the RDF for each mode. (I'd have to go check to see if the lit keys corresponds one-to-one to the keys in the list of valid keys) But I don't think that this will require any UI work


1a: as a corrolary to 1 above, some method of informing or showing the user that some keys are not lit for all screens in a device (the audio screens are the best example of this) Either doing the key maps on a screen by screen basis or something else. This is more involved and would probably require a good bit of UI work.


2: Deal with keys that get remapped based on different modes. In the 9960B01 (and 6960B00) buttons can mean different things with different screens active. For example, when you are in the first screen for a CBL device the menu button will send $14. When you scroll to the second screen (either with a scroll press or a PVR-VOD press) the menu button will send $54. This is very useful for a PVR for example in that menu can mean "setup menu" when you're in the first screen and "PVR menu" or "recordings list" on the second. (which is exactly what UEI does on the built-in CBL/1170 for Dish PVR devices)

where this starts to get odd is in extenders that try to shove in a bunch of non-key keycodes. The 9960B01 extender, for example puts in all of the pseudo-device selection stuff (56 keys) and all of the Xshift keys (64 keys). The only way to make all of this fit is to overlap the Xshift keys and the remapped keys. (all in the $40-$7F range since Shift takes all of the $80-$BF and Xshift takes all of the $C0-$FF keys)

It would be helpful if the tools would have a way to know that these are potentiall overlapped and depending on which device is active that is either an Xshift or a remap.

BTW, what RM does now is if I define a key that is a remap, it puts that key in three places (remap, Xshift-remap, and Xshift-original) I have to take the keymoves out when going into IR although I don't think that it'd hurt the extender, it just saves space.


This is a bit more complicated in that it would require some kind of bind command in the RDF that is device specific or maybe just loading the table of remap keys (it's about 20 keys all told) into the RDF so that it could check and make the right decision. Again, no UI really necessary here, maybe shading out Xshift on a per-device basis for those remap keys.


3: it would be really cool if we could make the extenders and the tools allow you to select which screeen comes first when selecting a device. The remote is capable of it, it probably wouldn't take too much space in the extender. But this requires a lot of thought on the IR and RM side. (maybe an Screenset command in a macro would do the trick. hmmmm.....)


I'm not a Java programmer and would cause probably more damage than help here so can't even think about doing a prototype or first implementation of this. So this has to be considered a wishlist more than anything else.



thoughts?

I think 1. is already implemented in RM. For instance the different screens of the 8206 can be specified as follows in the RDF file :
Each screen gets its own map and image and RM automatically displays the first screen corresponding to the selected device type. If a device type has several screens, the "<"Scroll">" buttons can be used to move from one to the other.

You can check how it works by yourself with these RDF and maps.

Here's a link to some discussion we had almost a year ago to improve RM's support for Kameleon remotes: http://www.hifi-remote.com/forums/viewtopic.php?t=6306

I think one of the basic questions about the Kameleon remotes is whether the "lit" buttons match the ButtonMap for each device type?

Lit does not always equal keys in the button map.

A couple of examples:


First, the device keys, power, setup, etc are lit in all of the device screens (they are not in some of the setup screens but who cares about those)

Second, there are a couple of others that are in the lit list but not on the button list. Why I don't know, but hey they are. I've manually done the matching from the lit table in the 6960 to the button maps and there are a few diff's. I can send the EXCEL sheet with this data to whomever wants to look at it (it aslo has the 9960B01 lit table in it but the button maps aren't in there yet)

Third, and probably most troubling, is that the remotes do their "remapping" of keys differently, and thus the button lists may or may not have the remapped keys in them. For example, the 6960B00 verifies that a key is lit THEN remaps the keys, so the remapped keys don't have to be in the lit list but they do have to be in the button list. The 9960B01 remaps first then verifies the key is lit, so the keys have to be in both lists. I don't think we can count on any one remote doing it consistently given that these two remotes are VERY similar in every other way but this is one big difference (that caused me some grief in a single-ASM extender by the way)

my guess is that we're going to have to have figure out how to deal with the lit keys AND the remap keys at once if we choose to tackle this problem.


I can send the gory details on lit, remap, and button maps to anyone who wants it.


(and thanks for the tip on the maps/images, I think when I find some time I'll give that a try for the 6960 and 9960B01 extenders)


-bill

If I understand everything correctly, RM should already be able to get very close to the desired behavior, at least on the Layout panel.

Using the DeviceTypeImageMaps, it is possible to create unique images maps for each screen of each device type. This includes using a unique image that shows (as part of the image, not generated by RM) which keys are lit on each screen.

In each map file, any button shapes associated with remapped keys should be assigned to the key with the keycode that is used after remapping. In your example above

the first screen for a CBL device the menu button will send $14. When you scroll to the second screen (either with a scroll press or a PVR-VOD press) the menu button will send $54.

The image map for the first screen must assign the shape to the Menu key, but the image map for the second screen must assign the shape to the PVR-Menu key.

Changing the behavior of RM's Buttons and Layout panel to prevent assigning functions to keys that are not lit on any of the screens for a particular device type would require enhancements to the RDF and code changes to parse and process them. Those same enhancements would have to be supported by IR to prevent assigning keymoves, macros, or special functions to those keys.