[mythtv-users] Programming remote button bindings (WAS: What major features are planned for 0.27?)

Michael T. Dean mtdean at thirdcontact.com
Wed Nov 28 18:39:09 UTC 2012


On 11/28/2012 01:20 PM, Mark Greenwood wrote:
> On Wednesday 28 Nov 2012 12:32:09 Michael T. Dean wrote:
>> FWIW, the defaults for volume in MythTV are:
>>
>> |TV Frontend/VOLUMEDOWN:||[,{,F10,Volume Down
>> ||TV Frontend/VOLUMEUP:||],},F11,Volume Up|
>> |TV Frontend/MUTE:|||,\\,F9,Volume Mute|
>>
>> where the last are keys someone added to allow the multimedia
>> volume/mute keys to work out of the box (
>> https://github.com/MythTV/mythtv/commit/26893b2ab0 ).
> Well, I'll admit, I haven't even looked at the keybindings for some time. When I first used mythtv (0.22) and eventually got LIRC to work I saved the lircrc I created and guarded it with my life. But you are right - there is now a default mapping for Volume Down, and Volume Up as you describe, but it doesn't work with my remote.
>
>> And, FWI(also)W, you don't need to use a file to map 'KEY_VOLUMEDOWN' to
>> '['--you just need to go to Edit Keys and set up your remote using
>> whatever random key bindings the kernel developers decided to send for
>> each of your remote buttons.
> This never worked for me in 0.22 or 0.24. Perhaps because I had LIRC running? I don't know. It would never respond to *any* of the 'un-LIRCed' buttons from my remote, even when I had LIRC sending KEY_PLAY for example - I had to remap LIRC to send P. So on 0.26 I went in and tried to map my remote's Play button to the 'Play' function and this time it worked (no LIRC). I also tried remapping the volume keys - it recognised the buttons and mapped them, but still won't adjust the volume when I press them during playback. Play and Pause, however, worked.
>
> But then I tried to map my Stop button (KEY_STOP) but myth says 'Add Key 'Meta+Ctrl+Alt+Shift+[][]'? Close, but no cigar.
>
> I repeat that all these keys work out of the box with xbmc and can be mapped in VLC.
>
> And you keep calling them 'Random bindings' but the point I've been failing to make is that they're not random.

They are for non-standard buttons.  I.e. what in the world is 
KEY_COFFEE?  Since there's absolutely no button on my remote with 
anything even resembling coffee, but yet it's one of the buttons mapped 
by the kernel's key map, they're assigning some random button 
name--probably because some other remote had a button with a cup of 
coffee picture on it and they didn't want to add a whole new button name 
for the button on my remote--to some button on my remote.

>   If the kernel guys have any sense at all (and let's not get into that) then the 'Play' button on a remote will always send KEY_PLAY etc etc etc. This is about as non-random as you can get. Certainly less random than using '[' for Volume Down. I still don't get why myth doesn't have a default binding for PLAY or PAUSE, as the functions of these are obvious. I know there's a question of play/pause over just play or pause, but a default that does *something* is better than a default which does nothing.

Which helps with just a few "normal" multimedia keys (i.e. those that 
are also likely to exist on a multimedia keyboard).  It doesn't help at 
all for all the other remote buttons, as above.

>> And, I've been asking if the multimedia keys should actually be
>> VolumeDown/VolumeUp/VolumeMute (no spaces) since it went in--based
>> purely on the Qt key names--but no one has ever cared to test in 5
>> years, which made me assume it must actually work, so I haven't changed
>> it.  I haven't actually tested it, either (probably because a. I don't
>> care since I'm not affected by it/don't care to use multimedia keys in
>> MythTV, and b. I'm too busy repeating myself on the list when people
>> just don't get that any valid key that's sent through X can be used in
>> MythTV simply by using Edit Keys to map it appropriately).  But now that
>> you're saying it doesn't work out of the box, if you were to actually
>> test mapping your volume keys and report back what key is actually
>> mapped for your remote buttons and keyboard multimedia volume, I'd be
>> happy to fix it if I am, indeed, correct that it was improperly mapped
>> years ago.
> Given what I found above, perhaps you're right about the spaces?

What key was mapped when you remapped your volume keys above?  Was it 
VolumeDown, etc.?

>> Remapping kernel
>> keymaps is not, "It Just Works, so let's have a beer."  Since the kernel
>> must--by necessity--use key codes>  255 for new "remote-only" "keys"
>> (neigh, buttons) because key codes<= 255 are already used, those keys
>> aren't usable in X or X applications, so if you have a remote with those
>> buttons you /must/ remap those key codes to repeat already-used codes.
> This is what I find odd. I didn't have to change any kernel keymaps at all. One must therefore assume that all the multimedia keys

Yes.

>   eg KEY_PLAY,

Yes.

>   KEY_WHATEVER

No--but possibly your remote doesn't have some of the WHATEVER keys that 
are > 255 key codes.

>   are<  255. Therefore if a remote is sending a keycode of>  255 when the PLAY key is pushed, this would sound like a kernel bug since the Play button should always send KEY_PLAY, just as the P button on my keyboard should always send KEY_P. Or maybe I've misunderstood.
>

Again, I'm talking about all the rest of the buttons--the "not normal" 
buttons that exist on remotes; the ones we /can't/ make work without 
some reconfiguration of the underlying system (kernel keymaps) or major 
rearchitecting of X or some program, such as LIRC, designed to make 
remotes usable in X.  This is why, IMHO, it's better for a remote to be 
completely unusable and require complete configuration (i.e. let the 
user know exactly what needs to be done) rather than make the number and 
VCR buttons work and leave the rest useless--and completely unusable 
with the approach that the user thought was "close, so I just have a few 
changes to make for these last few buttons".  At that point, when the 
user tries to make those "few changes", they'll find they have to 
completely change the approach their using.

Mike


More information about the mythtv-users mailing list