|
From: Jarod W. <ja...@wi...> - 2011-04-26 22:00:16
|
Please keep the list cc'd. On Apr 25, 2011, at 6:41 PM, Stephen E. Baker wrote: > On Mon, Apr 25, 2011 at 10:55 AM, Jarod Wilson <ja...@wi...> wrote: >> On Apr 24, 2011, at 8:55 AM, Stephen E. Baker wrote: >> >>> My Antec Veris Multimedia Station Basic (15c2:0043) was functioning in >>> the past. At some upgrade (I'm not sure if it was kernel or lirc or >>> which version) the buttons stopped responding. I am now on linux >>> 2.6.38.3 and lirc 0.9 (Arch Linux) >>> >>> I read that the drivers are built into the kernel now and that I >>> should be using devinput, and setting the device explicitely, which >>> I've done, setting the device to: >>> /dev/input/by-id/usb-15c2_0043-event-if00. >>> >>> After this setting the protocol to 'lirc' in ir-keytable allows some >>> of the buttons to work: >> >> Setting protocol to 'lirc' makes no sense at all on this hardware. >> The valid options are RC-6 and Other. The 'lirc' protocol is only >> for raw IR hardware, and it passes along raw IR samples via a >> /dev/lircX device node. >> >>> Up/Down/Left/Right, Volume Up/Down/Mute, and Channel Up register in >>> irw, none of the others seem to respond. >>> >>> I tried writting the keycodes for the RM100 from the lirc keymap file >>> to an rc_keymap file and loading it with ir-keytable -w, with no >>> improvement. No buttons register in ir-keytable -t in rc-6 mode. >> >> The RM-100 remote is protocol "Other", not RC-6. You should probably >> not be using ir-keytable for anything at all with this hardware, it >> should actually get the protocol and keymap correct right out of the >> box by default. >> > Tried: > [root@mediacenter family]# echo Other > /sys/class/rc/rc0/protocols > bash: echo: write error: Invalid argument > > Same with "other" Yeah, other is not valid right now, that's a kernel bug. I have a patch that should fix it. You shouldn't need to echo anything though. > I saw "Unknown" elsewhere which works and seems to be the default > state. Using Unknown no button presses are registered in irw or > ir-keytable -t. > > "Driver imon, table rc-imon-pad" does not indicate a problem then? I > was suspicous of the rc-imon-pad line. No. The signals for the RM-100 are the same as the signals for the iMON Pad remote (aka RM-200), its all one keytable. I suppose the keytable could stand to be renamed, but eh. >>> Possibly unrelated but the following shows up in messages: >>> Apr 19 16:33:20 localhost kernel: WARNING: at kernel/mutex-debug.c:78 >>> debug_mutex_unlock+0xdb/0xe0() >> >> Hm. Just a warning from the lock debugger, and one which I can't >> yet make heads or tails of. On the bright side, this shouldn't >> happen if you don't unnecessarily run ir-keytable. :) >> > Still seeing: > Apr 25 18:28:41 localhost kernel: [ 9.726307] Pid: 2499, comm: > ir-keytable Not tainted 2.6.38-ARCH #1 > > I'm not sure how that is coming up, ir-keytable is not part of init; > so unless it's being pulled in by a kernel hook? Its a udev hook, see /etc/udev/rules.d/70-infrared.rules (at least, that's where the rule file winds up on Fedora). Just comment it out. I still need to try to reproduce the problem here... -- Jarod Wilson ja...@wi... |