On Jan 29, 2011, at 9:41 AM, Cory Coager wrote:
> On 01/29/2011 01:05 AM, Brendan Hughes wrote:
>> I had a similar problem where the lirc-imon module wasn't loading
>> although lirc-dev was. I then tried to manually load lirc-imon by
>> running -
>> modprobe lirc-imon
>> Then by looking at dmesg it implied that I had a bad option. It turned
>> out that I had two copies of the lirc-dev module. One was in
>> /lib/modules/(kernel version)/misc and the other in
>> /lib/modules/(kernel version)/kernel/drivers/media/IR. By removing both
>> of them and then re-installing the lirc drivers from source the problem
>> was fixed. I'm not sure if the latter was installed as part of the
>> openSUSE package or when I recompiled the kernel and erroneously had the
>> lirc modules compiled too. (Bound to be one of them).
> I've been using the userspace drivers for ~6 years now. From what I
> understand they won't work anymore on the 2.6.36+ kernels. The
> userspace driver gets compiled in the 'misc' directory. When I loaded
> the userspace driver I got a kernel oops and nothing worked.
I think you're a bit confused. The "userspace" drivers you're referring to
are *kernel*-space drivers. Userspace drivers are ones for which a kernel
module is NOT required.
> Another confusing thing is, the kernel has a 'imon' driver and a
> 'lirc_imon' driver. The imon driver is listed under Device Drivers >
> Multimedia support > Infrared remote controller adapters > SoundGraph
> iMON Receiver and Display (CONFIG_IR_IMON). The other driver is under
> Device Drivers > Staging Drivers > Linux Infrared Remote Control IR
> receiver/transmitter drivers > Legacy SoundGraph iMON receiver and
> Display (CONFIG_LIRC_IMON). No idea why there is two. I didn't have
> any luck with the lirc_imon driver as it never even created a device in
> /dev. I've been working with the imon driver instead.
If you read the Kconfig help text, its pretty self-explanatory.
Driver for the original SoundGraph iMON IR Receiver and Display
Current generation iMON devices use the input layer imon driver.
lirc_imon is only for some very VERY early imon devices that actually pass
raw IR, opposed to the hardware decode style ones that have been the norm
for at least 5 years now.
>> Until the lirc-imon driver is loaded you won't see it listed under
>> and the directory may not exist at all.
> Does it really need to be loaded in /dev/input/by-id ?
No, but if its not showing up at all there, and other things are, it suggests
to me that something isn't right.
> I can see a
> device created in /dev/input called event5. Besides, the devices in
> /dev/input/by-id are just symlinks.
Yes, I know. But do you know if /dev/input/event5 is the *mouse* device or the
*remote* device? The imon driver, when properly initialized, creates *two* event
devices, one for mouse operations, one for other operations.
[96649.372169] usb 4-1: new low speed USB device using uhci_hcd and address 3
[96649.517196] usb 4-1: New USB device found, idVendor=15c2, idProduct=ffdc
[96649.517207] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
--> [96649.580577] input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/input/input17
[96649.596133] imon 4-1:1.0: 0xffdc iMON Knob, iMON IR (id 0x21)
[96649.642104] Registered IR keymap rc-imon-pad
--> [96649.643037] input: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/rc/rc5/input18
[96649.643162] rc5: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/rc/rc5
[96649.652318] rc_register_device: Registered rc5 (driver: imon, remote: rc-imon-pad, mode cooked)
[96649.652330] imon 4-1:1.0: iMON device (15c2:ffdc, intf0) on usb<4:3> initialized
[96649.652387] usbcore: registered new interface driver imon
$ ls -l /dev/input/by-id/
lrwxrwxrwx 1 root root 9 Jan 30 12:10 usb-15c2_ffdc-event-if00 -> ../event7
lrwxrwxrwx 1 root root 9 Jan 30 12:10 usb-15c2_ffdc-event-mouse -> ../event6
lrwxrwxrwx 1 root root 9 Jan 30 12:10 usb-15c2_ffdc-mouse -> ../mouse1