Jarod Wilson wrote: >> I guess the question is what is the interface we want the regular >> userspace (i.e. not lircd) to use. Right now programs has to use 2 >> intercfaces - one lirc for dealing with remotes that are not using >> the standard event interface and evdev for remotes using it as well >> as the rest of the input devices. > > From the mythtv perspective, using the input layer could yield a better > out-of-the-box experience -- users don't have to set up an lircrc mapping > that converts key names as specified in lircd.conf into commands > (key strokes, actually) that mythtv understands. For example, a button > labeled "Play" > in lircd.conf has to be mapped to 'p' in ~/.lircrc for mythtv to do the right > thing with it. If everything came through the input layer, be that natively > or via lircd's uinput reinjection, there would be no need to do that extra > mapping step, mythtv would simply handle a KEY_PLAY event. So at worst, > one manual mapping to do -- IR signal to standard button name in lircd.conf > -- > instead of two. But the lircrc approach does also allow more flexibility, > in that you can only have a certain app respond to a certain key, if so > desired, > and remap a key to a different function (KEY_RED, KEY_GREEN, KEY_BLUE, > KEY_YELLOW > -- what should their default functionality be? I know some users map a pair > of those to mythtv's "skip to next commflag point" and "skip to prior > commflag point"). > > Unfortunately, mythtv currently doesn't handle KEY_PLAY, KEY_VOLUMEUP, etc., > etc. at > all right now, it operates purely on keys commonly found on a standard > keyboard. > Remedying that is on my TODO list for the next release, if I can carve out > the time.
This discussion is a little OT from the API discussions, since it affects both out-of-the box IR reception via input layer and lirc. All media applications should be capable of handling the corresponding KEY_PLAY, KEY_VOLUMEUP ... keys without needing to do anything else than just handling the corresponding keycode. You shouldn't need to start a daemon or doing anything else for this to work out-of-the-box. They currently don't do it due to historic reasons (it is easier to let something else remap KEY_PLAY into 'p' than to add the proper code there). When using non-hot-pluggable devices where you're building a dedicated MCE hardware (this is the common case of MythTV setups), things are not that bad, since, once you set your hardware, it is done. However, by looking on the number of different new devices, it seems that the most common type of devices are the TV USB sticks. As they are hot pluggable, eventually users may have more than one hardware and they expect that the IR layer will work equally on all your devices. The proper way for supporting it is to have a common application-agnostic keycode to indicate the received events. For example, all IR's should produce KEY_CHANNELUP/KEY_CHANNELDOWN events for changing the channels. Also, on a perfect world, lirc should send this event to the multimedia application that handles TV when such key is pressed, instead of converting into some other keycode. This prevents future problems if, for some reason, the application needs to do something else with that key, or if the key has a different meaning on some different contexts. For example, on some applications, KEY_UP/KEY_DOWN can mean to change a channel, but those keys are also used for menu navigation. However, KEY_CHANNELUP has a clear unique meaning: to change a channel. The expected behavior, from users perspective, is to mimic a TV box, where if you press channel UP any open menu will be closed and the channel will be changed, but pressing UP key will navigate at the menu. Well, if you map KEY_CHANNELUP as KEY_UP, you'll produce a different behavior. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
