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 <jarod@...> 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
>>> 220.127.116.11 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:
>>> 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.
> [root@... 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
>> 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...