[mythtv-users] mceusb as an input device

[Jarod Wilson]

On Mar 6, 2011, at 11:01 PM, Harry Orenstein wrote:

> On Saturday, March 05, 2011 10:53:48 pm Jarod Wilson wrote:
> 
>> So does that thing actually come with a TiVo remote? The in-kernel driver
>> is only set up to handle the MCE remotes, its likely the TiVo remote uses
>> different signaling. Judging from TiVo lircd.conf's out there, that's the
>> case. Not sure exactly what it uses, and/or if the protocol is known by
>> the in-kernel decoders. Worst-case, you should be able to use it the same
>> old /dev/lirc0 way though.
>> 
> The remote seems to really be a TiVo remote.  It even has the key with the 
> little TiVo guy and the thumb keys.

Okay, good to know. Where did you get that kit from? I might be
interested in picking one up myself (or just getting a TiVo
remote somewhere) so we can have that bundle Just Work(tm) out of
the box too.


> It turns out that the transceiver also 
> recognizes RC-5 codes,

They'll work with pretty much any IR signal, provided there's a decoder
for the signal. That's one area where lircd still has it over the
in-kernel bits -- much wider protocol support.


> so my recent work getting ir-kbd-i2c working with my 
> PVR-250 is applicable.  I just replaced the default keymap for rc_rc6_mce in 
> the /etc/rc_maps.cfg with one I created and set the protocol for the device to 
> RC-5 using ir-keytable.

Cool.


>> Nope, I think its just a case of this being the one and only mceusb device
>> I know of that comes with a non-RC6 MCE remote.
> 
> Using the TiVo remote would be nice, but I can get by with my JP-1 OFA 
> universal (guess the effort we spent 7 years ago was worth it).  I may spend 
> some time playing around with the TiVo remote to see if any remote with a 
> supported kernel module responds to it, but it would be impolite for me to ask 
> if anyone is working on a kernel module specifically to handle TiVo codes when 
> I am not able to do the coding myself.        This is me not asking ;)

Yeah, but I'm still interested in doing it anyway. :)


> I hate to ask more questions after all your good help, but now that I'm more 
> "mainstream" with my MCE transceiver I'm curious about the best approach to 
> using it.  The standard keymap for MCE remotes maps scancodes to non-ASCII 
> keys (e.g.: Play to KEY_PLAY, Menu to KEY_MENU, etc.).  Is the best way to 
> handle this to set up the key mappings in Myth to use these defaults?  If so, 
> how do I know what the key codes should be in Myth (KEY_UP = Up?  KEY_VOLUMEUP 
> = VolumeUp?  Just drop "KEY_" and case doesn't matter?) and what about keys 
> that get picked up by the OS (like volume up/down, mute, power, etc.), which 
> get acted on outside of Myth?

Unfortunately, X sucks. It won't pass any keycodes > 255 for hysterical
raisins. Its being worked on, but in the mean time, it means a fair
number of keys can't get directly to mythtv. The recommended approach at
the moment is to keep using lircd. That can be done with either the
lirc interface or the input layer interface, at your discretion.


> One more question.  When I set up my custom keymap I have to use ir-keytable 
> to set the protocol to RC-5 to use it.  What is the best way to automate that 
> on boot up?  Should I put 'echo RC-5 > /sys/class/rc/rc0/protocols' in 
> rc.local?  Should I use ir-keytable instead?  Is there a way to do this in a 
> modprobe conf file (executing the command after the module loads)?

Its possible to set things up to have ir-keytable automatically run via
a udev trigger. There's a rules file in the v4l-utils source, but its
not installed/enabled by default yet.


> Sorry to be such a pain.  It's the first time I'm doing a major upgrade on my 
> Myth system since I originally set it up.  Getting everything to work just 
> right is taking more effort than I would have guessed.

Yep! The X issue is the biggest wrench in the works, it has made things
a lot more complicated than we all first though they would be, but there
is a bit of progress on that upstream...


-- 
Jarod Wilson
jarod at wilsonet.com