Re: Custom keymap for mceusb on 2.6.36+
|
From: Jarod Wilson <jarod@wi...> - 2010-12-20 20:30:22
|
On Dec 20, 2010, at 3:01 PM, Daniel Klaffenbach wrote: > Hi, > > On Monday 15 November 2010 05:03:50 Jarod Wilson wrote: >> Patch got sent upstream on Friday: >> >> https://patchwork.kernel.org/patch/321592/ >> >> Works perfectly here now w/that change (testing with both an mceusb >> transceiver and my nuvoton-cir receiver. > any chance that this will be included in Linux 2.6.38? At the moment I do not > see this patch in the v4l/dvb linux-next tree. There's still some debate about how best to implement support for "non-standard" NEC remotes, but it just came up again over the weekend. I'm still hopeful we'll get something in place for 2.6.38. -- Jarod Wilson jarod@... |
Thread view
|
From: Daniel Klaffenbach <danielklaffenbach@gm...> - 2010-11-08 23:44:18
|
Hi, I am using a current kernel 2.6 git tree (2.6.37-rc1+ at the moment) with the in-kernel mceusb module. I would like to create a custom keymap for an Apple Remote that can be loaded with "ir-keytable". A while ago I did use irrecord to create an lircd.conf file for the Apple Remote. Since I want to use the kernel input layer directly I want to somehow convert the old lircd.conf into a keytable which can be loaded using ir-keytable from v4l-utils. Where can I find documentation on how to accomplish this? Is this even supported? I am aware of the fact that this might not be very LIRC-related, but for now I could not find any other place to ask for this. If anybody knows a better place for this question please tell me. Notes: * The original remote works fine (using the rc6_mce keymap) * mceusb.debug=1 shows lots of codes (also from the Apple Remote) - but I currently do not know how to make use of them Regards, Daniel |
|
From: Jarod Wilson <jarod@wi...> - 2010-11-09 01:28:32
|
On Nov 8, 2010, at 6:43 PM, Daniel Klaffenbach wrote: > Hi, > > I am using a current kernel 2.6 git tree (2.6.37-rc1+ at the moment) > with the in-kernel mceusb module. I would like to create a custom > keymap for an Apple Remote that can be loaded with "ir-keytable". > > A while ago I did use irrecord to create an lircd.conf file for the > Apple Remote. Since I want to use the kernel input layer directly I > want to somehow convert the old lircd.conf into a keytable which can > be loaded using ir-keytable from v4l-utils. Where can I find > documentation on how to accomplish this? Is this even supported? Supported... almost. Documentation is currently a bit lacking. Enabling ir-core debugging and/or using evtest will get you the scancodes, once Apple's NEC variant is supported in-kernel, then you just map them to keycodes. v4l-utils contains example keymaps. > I am aware of the fact that this might not be very LIRC-related, but > for now I could not find any other place to ask for this. If anybody > knows a better place for this question please tell me. linux-media@... would work too, but I think this is fine. (I'm on both lists, and would answer on either one of them, though linux-media has a few more people on it that aren't on this list who might have input on some topics). > Notes: > * The original remote works fine (using the rc6_mce keymap) > * mceusb.debug=1 shows lots of codes (also from the Apple Remote) - > but I currently do not know how to make use of them Right this very second, you actually *can't* do in-kernel decode for Apple remotes. They use NEC protocol for the data link layer, but the actual bits have different meanings when compared with standard NEC, which the in-kernel decoder currently strictly follows. I've got patches headed upstream Real Soon Now(tm) to make it functional though. -- Jarod Wilson jarod@... |
|
From: Daniel Klaffenbach <danielklaffenbach@gm...> - 2010-11-09 20:25:08
Attachments:
application/pgp-signature
|
On Tuesday 09 November 2010 02:28:23 you wrote: > Right this very second, you actually *can't* do in-kernel decode for Apple > remotes. They use NEC protocol for the data link layer, but the actual > bits have different meanings when compared with standard NEC, which the > in-kernel decoder currently strictly follows. I've got patches headed > upstream Real Soon Now(tm) to make it functional though. Thanks a lot for your efforts and this information. I am definitely looking forward to in-kernel Apple Remote support. Regards, Daniel |
|
From: Jarod Wilson <jarod@wi...> - 2010-11-15 04:04:00
|
On Tue, Nov 9, 2010 at 3:24 PM, Daniel Klaffenbach <danielklaffenbach@...> wrote: > On Tuesday 09 November 2010 02:28:23 you wrote: >> Right this very second, you actually *can't* do in-kernel decode for Apple >> remotes. They use NEC protocol for the data link layer, but the actual >> bits have different meanings when compared with standard NEC, which the >> in-kernel decoder currently strictly follows. I've got patches headed >> upstream Real Soon Now(tm) to make it functional though. > Thanks a lot for your efforts and this information. I am definitely looking > forward to in-kernel Apple Remote support. Patch got sent upstream on Friday: https://patchwork.kernel.org/patch/321592/ Works perfectly here now w/that change (testing with both an mceusb transceiver and my nuvoton-cir receiver. -- Jarod Wilson jarod@... |
|
From: Daniel Klaffenbach <danielklaffenbach@gm...> - 2010-12-20 20:04:46
Attachments:
application/pgp-signature
|
Hi, On Monday 15 November 2010 05:03:50 Jarod Wilson wrote: > Patch got sent upstream on Friday: > > https://patchwork.kernel.org/patch/321592/ > > Works perfectly here now w/that change (testing with both an mceusb > transceiver and my nuvoton-cir receiver. any chance that this will be included in Linux 2.6.38? At the moment I do not see this patch in the v4l/dvb linux-next tree. I can confirm that the patch works fine (after fixing the keycodes). Regards, Daniel |
|
From: Jarod Wilson <jarod@wi...> - 2010-12-20 20:30:22
|
On Dec 20, 2010, at 3:01 PM, Daniel Klaffenbach wrote: > Hi, > > On Monday 15 November 2010 05:03:50 Jarod Wilson wrote: >> Patch got sent upstream on Friday: >> >> https://patchwork.kernel.org/patch/321592/ >> >> Works perfectly here now w/that change (testing with both an mceusb >> transceiver and my nuvoton-cir receiver. > any chance that this will be included in Linux 2.6.38? At the moment I do not > see this patch in the v4l/dvb linux-next tree. There's still some debate about how best to implement support for "non-standard" NEC remotes, but it just came up again over the weekend. I'm still hopeful we'll get something in place for 2.6.38. -- Jarod Wilson jarod@... |
|
From: Daniel Klaffenbach <danielklaffenbach@gm...> - 2010-11-15 21:16:45
|
2010/11/15 Jarod Wilson <jarod@...>: > Patch got sent upstream on Friday: > > https://patchwork.kernel.org/patch/321592/ Thanks a lot, this works great. To apply the patch to the current git kernel I needed to replace "drivers/media/rc/" with "drivers/media/IR". However my Apple remote seems to use different scancodes: ir_nec_decode: Apple remote detected, pair ID 0xea ir_nec_decode: NEC (Ext, no csum) scancode 0xee8705ea ir_nec_decode: NEC decode failed at state 0 (31750us space) ir_nec_decode: NEC decode failed at state 0 (31750us space) ir_nec_decode: NEC decode failed at state 0 (31750us space) ir_nec_decode: NEC decode failed at state 0 (11100us space) ir_nec_decode: Apple remote detected, pair ID 0xea ir_nec_decode: NEC (Ext, no csum) scancode 0xee8705ea ir_nec_decode: NEC decode failed at state 0 (12400us space) ir_nec_decode: Repeat last key ir_nec_decode: Apple remote detected, pair ID 0xea ir_nec_decode: NEC (Ext, no csum) scancode 0xee8705ea ir_nec_decode: NEC decode failed at state 0 (31750us space) ir_nec_decode: NEC decode failed at state 0 (31750us space) ir_nec_decode: NEC decode failed at state 0 (31750us space) ir_nec_decode: NEC decode failed at state 0 (11100us space) These are the scancodes that my Apple remote produces: UP: 0xee870aea DOWN: 0xee870cea LEFT: 0xee8709ea RIGHT: 0xee8706ea PLAY: 0xee8705ea MENU: 0xee8703ea - Daniel |
|
From: Jarod Wilson <jarod@wi...> - 2010-11-15 21:31:26
|
On Nov 15, 2010, at 4:16 PM, Daniel Klaffenbach wrote: > 2010/11/15 Jarod Wilson <jarod@...>: >> Patch got sent upstream on Friday: >> >> https://patchwork.kernel.org/patch/321592/ > Thanks a lot, this works great. To apply the patch to the current git > kernel I needed to replace "drivers/media/rc/" with > "drivers/media/IR". The patch is against: http://git.linuxtv.org/media_tree.git?a=shortlog;h=refs/heads/staging/for_v2.6.38 IR will be moved to rc in 2.6.38, as we start branching out into things other than just infrared. > However my Apple remote seems to use different scancodes: > > ir_nec_decode: Apple remote detected, pair ID 0xea > ir_nec_decode: NEC (Ext, no csum) scancode 0xee8705ea > ir_nec_decode: NEC decode failed at state 0 (31750us space) > ir_nec_decode: NEC decode failed at state 0 (31750us space) > ir_nec_decode: NEC decode failed at state 0 (31750us space) > ir_nec_decode: NEC decode failed at state 0 (11100us space) > ir_nec_decode: Apple remote detected, pair ID 0xea > ir_nec_decode: NEC (Ext, no csum) scancode 0xee8705ea > ir_nec_decode: NEC decode failed at state 0 (12400us space) > ir_nec_decode: Repeat last key > ir_nec_decode: Apple remote detected, pair ID 0xea > ir_nec_decode: NEC (Ext, no csum) scancode 0xee8705ea > ir_nec_decode: NEC decode failed at state 0 (31750us space) > ir_nec_decode: NEC decode failed at state 0 (31750us space) > ir_nec_decode: NEC decode failed at state 0 (31750us space) > ir_nec_decode: NEC decode failed at state 0 (11100us space) > > These are the scancodes that my Apple remote produces: > > UP: 0xee870aea > DOWN: 0xee870cea > LEFT: 0xee8709ea > RIGHT: 0xee8706ea > PLAY: 0xee8705ea > MENU: 0xee8703ea Those are fully expected. You've set pair=1, I take it? The included default keytable only works with pair=0, which replaces the pairing byte with 0x00. To use pairing, you'll have to upload your own table with the pair byte set to what your remote has there. -- Jarod Wilson jarod@... |
|
From: Daniel Klaffenbach <danielklaffenbach@gm...> - 2010-11-15 21:45:01
|
2010/11/15 Jarod Wilson <jarod@...>: > Those are fully expected. You've set pair=1, I take it? The included > default keytable only works with pair=0, which replaces the pairing > byte with 0x00. To use pairing, you'll have to upload your own table > with the pair byte set to what your remote has there. Yes and No. The keycodes I've send are indeed from pair=1. With pair=0 I still get different keycodes: UP: 0xee870a00 DOWN: 0xee870c00 LEFT: 0xee870900 RIGHT: 0xee870600 PLAY: 0xee870500 MENU: 0xee870300 - Daniel |
|
From: Jarod Wilson <jarod@wi...> - 2010-11-15 21:51:44
|
On Nov 15, 2010, at 4:44 PM, Daniel Klaffenbach wrote: > 2010/11/15 Jarod Wilson <jarod@...>: >> Those are fully expected. You've set pair=1, I take it? The included >> default keytable only works with pair=0, which replaces the pairing >> byte with 0x00. To use pairing, you'll have to upload your own table >> with the pair byte set to what your remote has there. > Yes and No. The keycodes I've send are indeed from pair=1. With pair=0 > I still get different keycodes: > > UP: 0xee870a00 > DOWN: 0xee870c00 > LEFT: 0xee870900 > RIGHT: 0xee870600 > PLAY: 0xee870500 > MENU: 0xee870300 Ugh. Crap. My mistake there, the keycodes in the default keymap have the command and pairing bytes reversed. I fixed this on my laptop, but neglected to do so in the tree on my workstation, where I spit out the patches. D'oh. -- Jarod Wilson jarod@... |