Re: imon - debug shows keys, but not irw

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

On May 27, 2011, at 4:30 PM, Andreas Dick wrote:

> dear Lirc List 
> 
> in short:
> starting imon driver with the debug=1 option, I can see all my imon buttons in 
> the syslog, like:
> May 27 21:47:35 localhost kernel: [  298.328024] intf0 decoded packet: 00 00 
> 00 17 ff ff 46 ee 
> 
> but using inputlirc (or even devinput) I get with irw just two of the events 
> (VolUp and VolDown), but none of the other buttons... what can go wrong here?
> Is this a keytable topic or is imon not yet supporting my hardware?

Looks like a bit of both. That code looks like nothing I've ever seen reported
before, and we haven't had an 0x46 ffdc device reported before either, so some
code updates are required as well.


> Let me become more precise now:
> I am using a "Noblesse AV" as HTPC. It contains a imon driven LCD, a Volume-
> wheel+button and 7 seperate buttons. An IR remote would be supported as well, 
> I do not use it since my homebrew IR reciver (lirc_serial) has a much better 
> sensitivity (ca. 5m instead of 1m)

Ah, ok, so you're only trying to make use of the buttons on the panel, if I'm
understanding you correctly.


> It was well supported with the Hardy kernel (lirc_imon) but since I read 
> Jarods blog at http://wilsonet.com/?page_id=95 I know that this is the past 
> and I have to find a new way now :-)
> (BTW: great decission to redesign lir, unfortuenately a lot people out in the 
> net do not agree with me since they do not understand the way of progress :-(

I'm glad to hear *some* people at least get it. :) Moving the drivers into
the kernel has been no small undertaking, and while there has been some
breakage here and there, we're fixing things as quickly as we can, and having
everything actually in the kernel will provide a much better experience in
the long run... The end goal is that your stuff will Just Work right out of
the box without having to do any config work at all.


> Now, my today distro (Ubuntu Natty) gives me:
> 
> $ lsusb | grep iMON
> Bus 003 Device 002: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller
> 
> $ modprobe imon display_type=1 nomouse=1 debug=1
> $ dmesg | grep imon
> [    9.664092] imon 3-4:1.0: Unknown 0xffdc device, defaulting to VFD and iMON 
> IR (id 0x46)
> [    9.664099] imon 3-4:1.0: imon_set_display_type: overriding display type to 
> 1 via modparam

So right here, its already defaulting to VFD, but you're overriding it to
VFD. I take it this is a VFD? Will need to add its ID to the driver... And
do you know if the remote for it was an imon one or an RC6/media center one?
The ffdc devices only support one or the other, hard-coded in the device's
firmware, so I'd like to make sure the right default keytable gets loaded.


> [    9.688025] Registered IR keymap rc-imon-pad
> [    9.704143] imon 3-4:1.0: iMON device (15c2:ffdc, intf0) on usb<3:2> 
> initialized
> [    9.704168] usbcore: registered new interface driver imon
> 
> Now, if I press any imon button, I can see just the same bytes in the syslog 
> (like above) as I used in the old lircd.conf, thus I think that I am not far 
> away.
> 
> 
> The strange thing is that I get now with irw verry different codes!
> E.g. when I turn the iMON-wheel CW I get in syslog:
> 	... intf0 decoded packet: 00 01 00 00 ff ff 46 ee
> in the old lircd.conf I used 
> 	imoncw          0x00010000          (I used just the first 32 bits)

That's still the scancode the driver gets from the hardware, but its getting
mapped to the linux input layer key KEY_VOLUMEUP.


> but now I get (using irrecord):
> 	imoncw    0x01007300000001 0x00000000000000
> and irw/inputlic shows me:
> 	73 0 KEY_VOLUMEUP event5

In kernel-source/include/linux/input.h, KEY_VOLUMEUP is defined to 115,
which is 0x73 in hex. The 0x01 prefix you see from irrecord is the marker
for EV_KEY.


> Well, I suppose, my hardware is kind of unusual, since I do not find any 
> similar codes somewhere in /usr/share/lirc/remotes/imon/*

You won't now. The scancodes get remapped to their appropriate linux input
layer keycodes in drivers/media/rc/imon.c. Take a look at the panel keytable
embedded in the driver. It probably just needs some minor extension to make
the variants of the scancodes your hardware generates work.

Side note: soungraph is notoriously BAD about making nearly identical hardware
function subtly different ways -- slight differences in scancode passed along
for the exact same IR signal, slight differences in scancodes passed along for
identically labeled panel buttons between different hardware revisions, and
the 0xffdc devices are the worst of all, since there are at least eight totally
different hardware devices that all share that usb device ID... And to top it
all off, SoundGraph can't be bothered to even reply to an email if you're not
running Windows. I truly despise them *and* their hardware. Despite that, lets
still see if we can get this thing working all the way. ;)

-- 
Jarod Wilson
ja...@wi...