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

Mark Greenwood fatgerman at gmail.com
Wed Nov 28 18:20:22 UTC 2012

On Wednesday 28 Nov 2012 12:32:09 Michael T. Dean wrote:
> On 11/28/2012 11:18 AM, Mark Greenwood wrote:
> > On Wednesday 28 Nov 2012 09:52:01 Michael T. Dean wrote:
> >> On 11/28/2012 02:59 AM, Simon Hobson wrote:
> >>> I wrote:
> >>>>> Summary:  There's a systemic issue (any key with code>  256 is
> >>>>> filtered by X),
> >>>> BINGO !
> >>>> ir-keytable tells me that all the keys I can't get to work have codes
> >>>> greater than 0xff.
> >>>>
> >>>> So I'm off to make a copy of the rc6_mce keymap and fix some of these.
> >>> Well I now have Back, Pause, Info, Commercial skip forwards/back, and
> >>> Menu working, plus the numeric digits. Along with the keys that
> >>> already worked, that covers almost all my usage :)
> >>>
> >>>
> >>> Gary Buhrmaster wrote:
> >>>
> >>>> There was some work being discussed (Jarod may have been part of it?)
> >>>> to allow
> >>>> the linux kernel ir codes>255 to be able to be used via X, but it
> >>>> was stated
> >>>> to be major work, and unlikely to be seen any time soon.  You can
> >>>> probably find
> >>>> the list archives regarding this if you search the various X11 lists,
> >>>> and maybe
> >>>> find the status of any work and/or possible schedules for work.
> >>> To me that seems the logical place to fix the problem - it doesn't
> >>> seem to make sense to me capturing IR buttons and then sending
> >>> keycodes through into a system that's going to filter most of them !
> >>> Presumably (other than using LIRC) there's no way for Myth to access
> >>> the codes before they get filtered ?
> >>>
> >>> In the meantime, I guess the easiest thing to do is find the header
> >>> file where all the keycodes are defined, pick a bunch of codes
> >>> (probably all those>=128) and modify my IR code table to use those.
> >>> Then back to figuring out what is what in the very long list of Myth
> >>> keybindings.
> >>>
> >> I still don't get why people think doing this (and repeating it with
> >> each upgrade--and on each system) is easier than creating (or, likely,
> >> downloading) a single LIRC configuration file for the remote
> >> (lircd.conf) and a LIRC configuration for MythTV (~/.lircrc) and any
> >> other application you want to use with the remote, which can then be
> >> backed up with your other configuration files and just dropped in place
> >> whenever you upgrade your distro or set up a new system or...
> >>
> >> Sure, getting LIRC working once took some learning, but once I finished,
> >> I forgot /everything/ I ever knew about configuring LIRC and haven't
> >> worried about it since I first set it up in 2004.  All I remember at
> >> this point is just how sensible LIRC's abstraction is--allowing me to
> >> configure applications individually independent of the specific remote
> >> I'm using and without having to remap remote buttons for a specific
> >> application (and make them crazy mappings for other apps) or without
> >> having to remap application buttons (and mess up keyboard mappings at
> >> the same time).
> > Because, with the in-kernel drivers now producing sensible keypress names for our remote buttons *without* doing *any* configuration *at all*, all it needs is for mythtv to support those keypress names and we'd have a system that worked out of the box. (Like my xbmc setup did when I installed it. I was very impressed by that.)
> No, for the case I questioned--Simon's case--it's sending keys that are 
> eaten by X and, therefore, unusable in any X-based application.  So, 
> Simon *reconfigured* his kernel's keymap for the remote.  This is *not* 
> "without doing any configuration at all."

Yeah that's fair enough. But see my comment at the end.

> > As it is I have to use a file that maps 'KEY_VOLUMEDOWN' to '[', KEY_UP' to 'Up', 'KEY_PLAY' to 'P'. This is ridiculous. All because mythtv refuses to recognise 'KEY_PLAY' as meaning 'I have pressed the PLAY button' or 'KEY_VOLUMEDOWN' as meaning 'Please reduce the volume'. And apparently this is because doing this would be confusing. Yes, definitely less confusing than the current method a newcomer is presented with, which is to ignore all the buttons on his remote. That's baffling.
> 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. 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.

> 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?

> >> And since modern distros that are a good choice for MythTV (i.e. *buntu
> >> and Fedora and possibly others with excellent repo/configuration support
> >> for MythTV) actually allow you to just select a remote so it can set it
> >> up for you, things should be a lot easier now than they were in 2004.
> > Yeah it would be nice if it worked. It's good for you that you have no trouble with LIRC. You must have a different remote than I do. Mine's apparently supported by the mythbuntu control centre but it has never created a functional hardware.conf for me, nor does it choose anything like a sensible mapping.
> >
> >> But, hey, at least you can say, "I finally set up my system and I don't
> >> /have/ to use Linux Infrared Remote Control to, support my, er, ...
> >> infrared remote control in ... Linux."
> > Yes, I can also say 'Hey, I just installed a new media centre and it basically just worked without me having to spend hours fiddling with it. Let's go to the pub'. I like it when technology doesn't fight with me.
> Again, you're not talking about the same thing I was.  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 eg KEY_PLAY, KEY_WHATEVER 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.


> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users

More information about the mythtv-users mailing list