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

Mark Greenwood fatgerman at gmail.com
Wed Nov 28 19:16:27 UTC 2012


On Wednesday 28 Nov 2012 13:39:09 Michael T. Dean wrote:
> 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.

Yeah that's daft, I agree. I'd log that as a kernel bug if it were me. I think I said a few posts back thought that there is a small, simple set of keys which you'd imagine the majority of remotes would have. On my remote these all generate keys that work in X, they all have names that reflect what's on the key, but only a small number of them work by default in myth. You, as someone who knows the workings of the GUI intimately, can get use out of KEY_COFFEE no doubt, but my view is that the fewer butons you have to use the better and a minimal set is all most people will ever use.

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

Yeah absolutely, but like I say, sensible support for a minimal button set will keep most people happy.

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

It said 'Volume Down'.

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

Well like I say, that's where I fundamentally disagree. If I can install the software and basically use it with minimal effort that'll keep me happy. Then if I decide I want to make it work "better", that's when I put the effort in. Seriously and without offense meant, making mythtv frontend work is a *lot* of effort - and the competition beats it hands down on that score. That's where I started from in this discussion - I was more or less happy with myth until I tried something else and found that it doesn't need to be that difficult.

Mark

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