Re: Antec Veris Multimedia Station Basic not functioning

[Jarod W. <ja...@wi...>]

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...