I have a similar problem.  lirc_imon is used to drive the LCD display on my HTPC case, and that has stopped working with both 2.6.32 updates so far.

lirc_imon has always required the display_type=1 parameter to work with the LCD display in my case.

From insmod lirc_imon display_type=1 (kernel 2.6.32-9.70):

insmod /lib/modules/2.6.32.9-70.fc12.x86_64/kernel/drivers/input/lirc/lirc_imon.ko display_type=1
insmod: error inserting '/lib/modules/2.6.32.9-70.fc12.x86_64/kernel/drivers/input/lirc/lirc_imon.ko': -1 Unknown symbol in module

From insmod lirc_imon (kernel 2.6.32-9.70):

Returns OK, but LCD display doesn't work as needed display_type parameter can't be set.

Checking the LIRC website, it does not appear as this parameter has been deprecated.

Final thing - the lirc_imon module seems significantly smaller in the 2.6.32 updates:

From ls -l /lib/modules/2.6.32.9-70.fc12.x86_64/kernel/drivers/input/lirc/lirc_imon.ko:

-rwxr--r-- 1 root root 27424 2010-03-03 04:59 /lib/modules/2.6.32.9-70.fc12.x86_64/kernel/drivers/input/lirc/lirc_imon.ko

From ls -l /lib/modules/2.6.31.12-174.2.22.fc12.x86_64/kernel/drivers/input/lirc/lirc_imon.ko:

-rwxr--r-- 1 root root 58576 2010-02-19 19:12 /lib/modules/2.6.31.12-174.2.22.fc12.x86_64/kernel/drivers/input/lirc/lirc_imon.ko

2.6.31 module is over twice the size.

My HW does not work either - Hauppauge

If I use the updated lirc package (0.8.6-4), besides not working it will consume 1 core at full speed!

Below is with lirc-0.8.6-1

With 2.6.31 (working):
Mar 10 19:09:15 jukebox kernel: Linux version 2.6.31.12-174.2.22.fc12.i686 (mockbuild.fedoraproject.org) (gcc version
 4.4.3 20100127 (Red Hat 4.4.3-4) (GCC) ) #1 SMP Fri Feb 19 19:26:06 UTC 2010
Mar 10 19:09:45 jukebox kernel: lirc_dev: IR Remote Control driver registered, major 249 
Mar 10 19:09:45 jukebox kernel: lirc_i2c: chip 0x10020 found @ 0x18 (Hauppauge IR)
Mar 10 19:09:45 jukebox kernel: i2c ir driver 3-0018: lirc_dev: driver lirc_i2c registered at minor = 0
Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: accepted new client on /var/run/lirc/lircd
Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: could not get hardware features
Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: this device driver does not support the LIRC ioctl interface
Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: major number of /dev/lirc0 is 249
Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: LIRC major number is 61
Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: check if /dev/lirc0 is a LIRC device
Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: Failed to initialize hardware
Mar 10 19:16:59 jukebox lircd-0.8.6[1188]: caught signal
Mar 10 19:16:59 jukebox lircd-0.8.6[3984]: lircd(default) ready, using /var/run/lirc/lircd
Mar 10 19:17:01 jukebox lircd-0.8.6[3984]: accepted new client on /var/run/lirc/lircd

with 2.6.32.9-70 (Not working):
Linux version 2.6.32.9-70.fc12.i686 (mockbuild.fedoraproject.org) (gcc version 4.4.3 
20100127 (Red Hat 4.4.3-4) (GCC) ) #1 SMP Wed Mar 3 05:14:32 UTC 2010
Mar 13 13:45:30 jukebox lircd-0.8.6[1305]: lircd(default) ready, using /var/run/lirc/lircd
Mar 13 13:46:02 jukebox kernel: lirc_dev: IR Remote Control driver registered, major 249 
Mar 13 13:46:02 jukebox kernel: lirc_i2c: chip 0x0 found @ 0x18 (Leadtek IR)
Mar 13 13:46:02 jukebox kernel: i2c ir driver 3-0018: lirc_dev: driver lirc_i2c registered at minor = 0
Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: accepted new client on /var/run/lirc/lircd
Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: could not get hardware features
Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: this device driver does not support the LIRC ioctl interface
Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: major number of /dev/lirc0 is 249
Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: LIRC major number is 61
Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: check if /dev/lirc0 is a LIRC device
Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: Failed to initialize hardware

Looks like imon went upstream with a different name than we had in our 2.6.31 kernel. Maybe the userspace code needs to be updated?

Newer imon devices are being serviced by !lirc_imon now, they're being handled using the imon driver, which is a pure input layer driver. Unfortunately, its not yet 100% complete (doesn't work as well for 0xffdc devices in the current Fedora kernel, update coming soon to hopefully remedy that), and the transition from one to the other isn't exactly smooth or 100% obvious.

(In reply to comment #2)
> My HW does not work either - Hauppauge
> 
> If I use the updated lirc package (0.8.6-4), besides not working it will
> consume 1 core at full speed!
> 
> Below is with lirc-0.8.6-1
> 
> With 2.6.31 (working):
> Mar 10 19:09:15 jukebox kernel: Linux version 2.6.31.12-174.2.22.fc12.i686
> (mockbuild.fedoraproject.org) (gcc version
>  4.4.3 20100127 (Red Hat 4.4.3-4) (GCC) ) #1 SMP Fri Feb 19 19:26:06 UTC 2010
> Mar 10 19:09:45 jukebox kernel: lirc_dev: IR Remote Control driver registered,
> major 249 
> Mar 10 19:09:45 jukebox kernel: lirc_i2c: chip 0x10020 found @ 0x18 (Hauppauge
> IR)
> Mar 10 19:09:45 jukebox kernel: i2c ir driver 3-0018: lirc_dev: driver lirc_i2c
> registered at minor = 0
> Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: accepted new client on
> /var/run/lirc/lircd
> Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: could not get hardware features
> Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: this device driver does not support
> the LIRC ioctl interface
> Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: major number of /dev/lirc0 is 249
> Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: LIRC major number is 61
> Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: check if /dev/lirc0 is a LIRC device
> Mar 10 19:11:07 jukebox lircd-0.8.6[1188]: Failed to initialize hardware
> Mar 10 19:16:59 jukebox lircd-0.8.6[1188]: caught signal
> Mar 10 19:16:59 jukebox lircd-0.8.6[3984]: lircd(default) ready, using
> /var/run/lirc/lircd
> Mar 10 19:17:01 jukebox lircd-0.8.6[3984]: accepted new client on
> /var/run/lirc/lircd
> 
> with 2.6.32.9-70 (Not working):
> Linux version 2.6.32.9-70.fc12.i686 (mockbuild.fedoraproject.org)
> (gcc version 4.4.3 
> 20100127 (Red Hat 4.4.3-4) (GCC) ) #1 SMP Wed Mar 3 05:14:32 UTC 2010
> Mar 13 13:45:30 jukebox lircd-0.8.6[1305]: lircd(default) ready, using
> /var/run/lirc/lircd
> Mar 13 13:46:02 jukebox kernel: lirc_dev: IR Remote Control driver registered,
> major 249 
> Mar 13 13:46:02 jukebox kernel: lirc_i2c: chip 0x0 found @ 0x18 (Leadtek IR)
> Mar 13 13:46:02 jukebox kernel: i2c ir driver 3-0018: lirc_dev: driver lirc_i2c
> registered at minor = 0
> Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: accepted new client on
> /var/run/lirc/lircd
> Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: could not get hardware features
> Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: this device driver does not support
> the LIRC ioctl interface
> Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: major number of /dev/lirc0 is 249
> Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: LIRC major number is 61
> Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: check if /dev/lirc0 is a LIRC device
> Mar 13 13:46:34 jukebox lircd-0.8.6[1305]: Failed to initialize hardware    

This is a completely different problem from the imon problem, needs to be tracked separately. I believe this one has to do with core i2c changes that lirc_i2c isn't yet equipped to handle, but I've not had a chance to investigate yet. Please open a new bug for this issue, and assign it to me.

Jarod,

Ok, found this (your?) blog on the imon transition here:

http://wilsonet.com/?p=45

So, to be clear on my bug report.  I've got an Antec Fusion with an IMON (0xffdc) VFD.  The 'imon' module is loaded (but lirc_imon is *not* with 2.6.32).  

I have a /dev/lcd0 device created when imon is inserted, and lcdproc 0.5.3-4 rpm installed.  This is all on an x86_64 machine.

However, I get no sign of life from the VFD display - screen is blank.

echo Hello > /dev/lcd0 returns a write error, and I get the following in dmesg:

imon 2-9:1.0: display port opened
imon: lcd_write: invalid payload size: 6 (expecting 8)
imon 2-9:1.0: display port closed

echo Hello12 > /dev/lcd0 returns OK.  Still nothing on the display.  Dmesg gives:

imon 2-9:1.0: display port opened
imon 2-9:1.0: display port closed

After running the LCD server, dmesg gives:

imon: lcd_write: invalid payload size: 32 (expecting 8)

repeated many times.  

I've tried setting Protocol=0 in LCDd.conf as per the blog, but with no effect. 

Hopefully your update to the imon driver will remedy all this!

Ah, scratch all the above. 

Hadn't changed my module options to include the display_type=1 parameter for the imon driver.  My Antec Fusion VFD is now working.

In summary, I've changed three things:

- I updated my modprobe.d/lirc.conf to include the line:

options imon display_type=1

- I added a Protocol=0 line to the [imon] section in LCDd.conf (not sure how much of a difference this has made - I haven't tried removing it again).

- I changed the device file in LCDd.conf to /dev/lcd0 (as my previous LCDd.conf was using, and I assume lirc_imon was creating, a /dev/lcd device).

Change all that and it's working fine.

Is there currently no way to grab IR input with the new imon module?

Use the devinput lircd userspace driver, pointing at the imon driver's event interface, and the matching lircd.conf.devinput file from lirc-remotes, and that should get you most of the way there. I need to add a few missing key mappings to the lircd.conf.devinput file still though... Will try to get to that shortly.

I am using the devinput driver and lircd.conf.devinput with lirc pointed to /dev/input/event5 (/dev/input/by-id/usb-15c2_ffdc-event-ir), but when I start lirc, run irw, and press keys on the remote, I get nothing.

Forgot to mention... 0xffdc device support isn't nearly as complete as I thought it was in the current latest Fedora 12 kernel (2.6.32.9-70.fc12). Its been significantly updated in the latest candidate build though. Please give this build a try, and see if it doesn't fare much better:

http://kojipkgs.fedoraproject.org/packages/kernel/2.6.32.10/78.fc12/

There are even a few more little fixups for mce mode and the mouse/keyboard toggle button that haven't been built yet, but that should be reasonably complete now for 0xffdc devices. I'll get an updated lircd.conf together momentarily too.

The lircd.conf I just checked into lirc cvs should be more complete. You can grab just that file here:

http://lirc.cvs.sourceforge.net/viewvc/lirc/lirc/remotes/devinput/

I'll patch it into an updated lirc package as well.

Just pushed an lirc-0.8.6-5.fc12 that carries the updated lircd.conf.devinput file.

I have updated to kernel 2.6.32.10-90. The remote still isn't working and I have the same message in the /var/log/messages file, i.e., 

Mar 29 20:55:21 bowmore lircd-0.8.6[1548]: accepted new client on /var/run/lirc/lircd
Mar 29 20:55:21 bowmore lircd-0.8.6[1548]: could not get file information for /dev/lirc0
Mar 29 20:55:21 bowmore lircd-0.8.6[1548]: default_init(): No such file or directory
Mar 29 20:55:21 bowmore lircd-0.8.6[1548]: Failed to initialize hardware

Is it something about this stuff that I have missed?

An additional comment maybe is at place. The funny little display does work and has done that with all of the here mentioned kernels.

(In reply to comment #14)
> I have updated to kernel 2.6.32.10-90. The remote still isn't working and I
> have the same message in the /var/log/messages file, i.e., 
> 
> Mar 29 20:55:21 bowmore lircd-0.8.6[1548]: accepted new client on
> /var/run/lirc/lircd
> Mar 29 20:55:21 bowmore lircd-0.8.6[1548]: could not get file information for
> /dev/lirc0
> Mar 29 20:55:21 bowmore lircd-0.8.6[1548]: default_init(): No such file or
> directory
> Mar 29 20:55:21 bowmore lircd-0.8.6[1548]: Failed to initialize hardware
> 
> Is it something about this stuff that I have missed?

Yes. From that output, lircd is trying to connect to /dev/lirc0. The new imon driver is pure input layer, not an lirc kernel driver. Instead of connecting to /dev/lirc0 (which doesn't exist now), you need to connect to /dev/input/eventX or the /dev/input/by-id/usb-15c2_xxxx-event-mouse alias (better to use the alias, as the event device number could change if you have different devices plugged in later on), you'll need to tell lircd to use the devinput driver instead of the default (lirc kernel device) driver, and you'll need the devinput lircd.conf.

For reference:

http://wilsonet.com/jarod/junk/imon-devinput-lirc/

The above sets up my own imon device for use via lirc, and it works quite well. The lircrc file might seem a bit quirky though, since its used primarily with a Logitech Harmony remote, rather than the stock iMON remote, but all the basics are there.

> An additional comment maybe is at place. The funny little display does work and
> has done that with all of the here mentioned kernels.    

Yes, the display device node portion remains unchanged between the old lirc_imon driver and the imon driver.

Nb: I now have an 0xffdc imon vfd in hand for testing, as well as the 0x0044 vfd and 0x0046 lcd. 2.6.32.10-90.fc12 *should* be completely functional for all of them, but I'll be double-checking everything when I get the chance.

I still am not getting any output with irw. However, I am getting syslog messages like this with every key press: 
Mar 31 13:50:50 localhost kernel: intf0 decoded packet: 80 0f 84 21 00 00 9e ae
Mar 31 13:50:51 localhost kernel: intf0 decoded packet: 80 0f 84 21 00 00 9e ae
Mar 31 13:50:51 localhost kernel: intf0 decoded packet: 80 0f 04 1e 00 00 9e ae
Mar 31 13:50:51 localhost kernel: intf0 decoded packet: 80 0f 04 1e 00 00 9e ae
Mar 31 13:50:51 localhost kernel: intf0 decoded packet: 80 0f 04 1e 00 00 9e ae
Mar 31 13:50:52 localhost kernel: intf0 decoded packet: 80 0f 84 22 00 00 9e ae
Mar 31 13:50:52 localhost kernel: intf0 decoded packet: 80 0f 84 22 00 00 9e ae
Mar 31 13:50:52 localhost kernel: intf0 decoded packet: 80 0f 84 22 00 00 9e ae
Mar 31 13:50:53 localhost kernel: intf0 decoded packet: 80 0f 04 22 00 00 9e ae
Mar 31 13:50:53 localhost kernel: intf0 decoded packet: 80 0f 04 22 00 00 9e ae
Mar 31 13:50:53 localhost kernel: intf0 decoded packet: 80 0f 04 22 00 00 9e ae
Mar 31 13:50:53 localhost kernel: intf0 decoded packet: 80 0f 84 22 00 00 9e ae
Mar 31 13:50:53 localhost kernel: intf0 decoded packet: 80 0f 84 22 00 00 9e ae
Mar 31 13:50:53 localhost kernel: intf0 decoded packet: 80 0f 84 22 00 00 9e ae
Mar 31 13:50:54 localhost kernel: intf0 decoded packet: 80 0f 04 22 00 00 9e ae
Mar 31 13:50:54 localhost kernel: intf0 decoded packet: 80 0f 04 22 00 00 9e ae
Mar 31 13:50:54 localhost kernel: intf0 decoded packet: 80 0f 04 22 00 00 9e ae

(In reply to comment #17)
> I still am not getting any output with irw. However, I am getting syslog
> messages like this with every key press: 
> Mar 31 13:50:51 localhost kernel: intf0 decoded packet: 80 0f 84 21 00 00 9e ae

KEY_RIGHT

> Mar 31 13:50:51 localhost kernel: intf0 decoded packet: 80 0f 04 1e 00 00 9e ae

KEY_UP

> Mar 31 13:50:54 localhost kernel: intf0 decoded packet: 80 0f 04 22 00 00 9e ae    

KEY_OK

These all match expected values in the driver, and the driver ought to be interpreting them appropriately, and sending the matching keycodes out via the input device. I suspect something lirc-side isn't configured correctly. Can you attach your /etc/lirc/lircd.conf and /etc/sysconfig/lirc files, and give me the output of 'ls -l /dev/input/by-id/'?

Also, I *presume* you're loading the driver w/the param 'ir_protocol=1' to set mce mode, since those are mce keycodes, but its possible maybe there exists a device that is in that mode by default, while the driver defaults to the imon key table.

The only parameters I have set for the imon module:
options imon debug=1 display_type=1

My lircd.conf and sysconfig/lirc:
http://www.attackus.net/lirc/

[root@HTPC ~]# ls -l /dev/input/by-id
total 0
lrwxrwxrwx 1 root root 9 2010-03-31 13:37 usb-15c2_ffdc-event-if00 -> ../event5
lrwxrwxrwx 1 root root 9 2010-03-31 13:18 usb-Logitech_Logitech_BT_Mini-Receiver_000761CD43F8-event-kbd -> ../event3
lrwxrwxrwx 1 root root 9 2010-03-31 13:18 usb-Logitech_Logitech_BT_Mini-Receiver_000761CD43F8-event-mouse -> ../event4
lrwxrwxrwx 1 root root 9 2010-03-31 13:18 usb-Logitech_Logitech_BT_Mini-Receiver_000761CD43F8-mouse -> ../mouse1

I have it working now with configs from Jarod above.

My info:
Bus 008 Device 002: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller

modprobe.d/imonlcd.conf:
options imon display_type=2 ir_protocol=1

/etc/lirc/lircd.conf from Jarod

Additionally, I had to have HAL ignore the IR receiver as mentioned in 

http://www.lirc.org/html/devinput.html

Without the HAL change, X would try to grab the devinput device and I was experiencing X server lockups.  Even when I added ServerFlags to turn off AutoAddDevice, most of my IR buttons were still unusable.

Only problem outstanding in my setup is I still can't control mplayer when run from mythtv frontend whereas it was working before the devinput conversion.  But there is probably something I missed in my configs.

Now, also my remote is up and running for kernel 2.6.32.10-90 using Jarods configuration files for lirc, i.e. those found at the website given in comment 15. In addition, I have included the following parameters for the imon module

options imon display_type=0 ir_protocol=1

in the file /etc/modepobe.d/imonlcd.conf

See, also the previous comment.

As yet, I have not seen any problems what concerns HAL and X.

(In reply to comment #21)
> Now, also my remote is up and running for kernel 2.6.32.10-90 using Jarods
> configuration files for lirc, i.e. those found at the website given in comment
> 15. In addition, I have included the following parameters for the imon module
> 
> options imon display_type=0 ir_protocol=1

Nb: display_type=0 is the default, its actually "auto-detect", and shouldn't be necessary. The ir_protocol=1 bit is definitely needed atm for enabling the mce keymap.

> in the file /etc/modepobe.d/imonlcd.conf

I'm actually working on some further enhancements to the imon driver, specific on 0xffdc devices, and could really use some additional data from your device... SoundGraph made some very bad design decisions when they put out umpteen completely different devices all with the same device ID (0xffdc), as well as having all of them constantly spew interrupts even when there's nothing that actually needs to be processed. Anyhow, I *think* we can properly config all 0xffdc devices out of the box based on byte 6 of the 'nothing is actually there' buffer spew from these devices, but I need to collect said bytes and device specifics. Currently, this requires a patch to the imon driver, as these buffers are at present, silently discarded.

Åke, how comfortable are you with building and/or loading an out-of-tree imon module for me? :) (I can actually make the process quite simple, and all I need is a few lines of dmesg output, then you could return to the stock imon module...)

> As yet, I have not seen any problems what concerns HAL and X.    

I've never hit any such issues either. Could be desktop environment specific.

Jarod,

I'm happy to build an out-of-tree imon for my 0xffdc device if it helps (I only use the VFD, not the remote, but it requires the display_type=1 to work).

Can you upload a tar-ball?

Jarod,

I can also make a try building the module for the device. Just direct me to what I should do.

Åke

I set ir_protocol=1 and now my remote works. However, when I hold a button down, only one event is registered. How can I make it so that holding a button down registers multiple events?

If all imon owners with 0xffdc devices would be so kind, please grab this:

http://wilsonet.com/jarod/junk/imon-test.tar.bz2

Unpack it, and run the build.sh script in it, which will compile a new imon.ko. Then do the following:

# modprobe -r imon
# insmod imon.ko debug=1 display_type=0
# dmesg | tail -n 20

Put the dmesg output here in the bug (or mail it to me, if you prefer), along with specifics on your devices -- i.e., with or without a display, whether the display is vfd or lcd, and which IR protocol you need to use with it.

Hopefully, a pattern emerges from this, or at least, no duplicate device IDs between different devices, and I can build up a table of IDs to get the things properly configured out of the box.

Ok, dmesg output is as follows:

input: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:02.0/usb2/2-9/2-9:1.0/input/input13
imon 2-9:1.0: Unknown 0xffdc device, defaulting to VFD (id 0x35)
imon 2-9:1.0: iMON device (15c2:ffdc, intf0) on usb<2:3> initialized
usbcore: registered new interface driver imon

The device is a VFD in an Antec Fusion HTPC Case.  Note, I only really got the above four lines of output with the debug flag set to 1.  Were you expecting 20?

With the module you posted, the VFD does work with display_type=0 - previously I've always had to set it to 1 for it to work.

(In reply to comment #27)
> Ok, dmesg output is as follows:
> 
> input: iMON Remote (15c2:ffdc) as
> /devices/pci0000:00/0000:00:02.0/usb2/2-9/2-9:1.0/input/input13
> imon 2-9:1.0: Unknown 0xffdc device, defaulting to VFD (id 0x35)
> imon 2-9:1.0: iMON device (15c2:ffdc, intf0) on usb<2:3> initialized
> usbcore: registered new interface driver imon
> 
> The device is a VFD in an Antec Fusion HTPC Case.  Note, I only really got the
> above four lines of output with the debug flag set to 1.  Were you expecting
> 20?

Nah, that looks about right, just arbitrarily went w/20 to make sure we got it all.

> With the module you posted, the VFD does work with display_type=0 - previously
> I've always had to set it to 1 for it to work.    

Yeah, part of the patch in there defaults to VFD for unknown 0xffdc devices, as they actually seem to be far more common than LCD 0xffdc devices. One last bit of clarification... Which remote do you use?

(In reply to comment #25)
> I set ir_protocol=1 and now my remote works.

Ah yes, I recently found some data from soundgraph's updated web site that says the 0xffdc devices have the ir protocol hard-coded into the device, so they only support imon *or* mce mode, the ir_protocol param is half-ignored (it does tell the driver which keymap to load though).

> However, when I hold a button
> down, only one event is registered. How can I make it so that holding a button
> down registers multiple events?    

Which button? The driver *does* relay repeats along to the input subsystem, but it consumes them somehow. Not quite sure yet how to get it to not do that for all keys to make repeats work as expected...

I have a separate USB MCE receiver.  

The 0xffdc device in my Antec Fusion case doesn't actually include an IR receiver - the imon device only drives the VFD and the Volume Knob (which lirc supports, but I don't use it so never set it up).  I believe the newer fusion cases did come with a built-in receiver as part of the imon device, but mine doesn't.

(In reply to comment #30)
> I have a separate USB MCE receiver.  
> 
> The 0xffdc device in my Antec Fusion case doesn't actually include an IR
> receiver - the imon device only drives the VFD and the Volume Knob (which lirc
> supports, but I don't use it so never set it up).  I believe the newer fusion
> cases did come with a built-in receiver as part of the imon device, but mine
> doesn't.    

Ah, one of those. Forgot about those. We *should* be setting up the knob in the driver to work via the input layer now. Does it do anything at the moment? If not, there's probably some spew from it in dmesg that details the hex codes it outputs when the knob is twiddled.

dmesg:

input: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/input/input6
imon 8-1:1.0: Unknown 0xffdc device, defaulting to VFD (id 0x9f)
imon 8-1:1.0: iMON device (15c2:ffdc, intf0) on usb<8:2> initialized
usbcore: registered new interface driver imon

I have an Antec Fusion Black 430, LCD presumably (display_type=2 works for me), ir_protocol=2, using MCE RC6 remote.  It didn't come with a remote.  Looks like it's not detecting the correct display type?

I should clarify that my device has a IR receiver and it works with MCE RC6 codes, but the retail package when I purchased the enclosure did not include a remote controller.

Okay, I just uploaded a replacement tarball to http://wilsonet.com/jarod/junk/imon-test.tar.bz2 which *should* properly identify and auto-configure all the devices everyone's reported ids for so far. Confirmation that I got it right would be appreciated, as would any additional device IDs.

dmesg:

input: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/input/input6
imon 8-1:1.0: 0xffdc iMON LCD, MCE IR (id 0x9f)
imon 8-1:1.0: iMON device (15c2:ffdc, intf0) on usb<8:2> initialized
usbcore: registered new interface driver imon

Works for me :)

Thanks, Jarod.

Yes, the device driver works perfectly also in my case.

I have one of the newer iMon devices 15c2:0038. AFter the kernel upgrade the LCD was working jsut fine but the IR was broken. I believe I have got it working except for one outstanding issue. Here's the steps I took to fix it with a Veris RM200 remote included with a Antec Fusion Max HTPC case.

Created /etc/modprobe.d/imonlcd.conf with the line
options imon ir_protocol=2

Changed lircd to use devinput and read the correct device
/usr/sbin/lircd -r -H devinput -d /dev/input/by-id/usb-15c2_0038-event-mouse

Rewrote my entire lircd.conf file based on a hexdump of the above device to get the new codes the driver puts out (there's probably a better way to have done that, but I don't know what the relationship was between the old codes and the new ones). Here's a snippet of that file:

begin remote

  name  RM200
  bits           16
  eps            30
  aeps          100

  one             0     0
  zero            0     0
  pre_data_bits   16
  pre_data       0x1
  gap          132799
  toggle_bit_mask 0x0

      begin codes
        KEY_UP          0x0067
        KEY_DOWN        0x006C
        KEY_LEFT        0x0069
        KEY_RIGHT       0x006A
	<snip>
	end codes
end remote

But I have a new problem, the repeat rate on the pad (up/down/left/right) is insanely fast. I've played with the repeat value in .lircrc, the gap, and the min_repeat, nothing seems to have any effect.

The output of irw when pressing those buttons shows as:

000000000001006a 00 KEY_RIGHT RM200
000000000001006a 00 KEY_RIGHT_UP RM200
0000000000010067 00 KEY_UP RM200
0000000000010067 00 KEY_UP_UP RM200
0000000000010069 00 KEY_LEFT RM200
0000000000010069 00 KEY_LEFT_UP RM200
0000000000010069 00 KEY_LEFT RM200
0000000000010069 00 KEY_LEFT_UP RM200
000000000001006c 00 KEY_DOWN RM200
000000000001006c 00 KEY_DOWN_UP RM200

Even a half second press causes a repeat of the up/down event 4 times or more, even if the button is not released?

(In reply to comment #37)
> I have one of the newer iMon devices 15c2:0038. AFter the kernel upgrade the
> LCD was working jsut fine but the IR was broken. I believe I have got it
> working except for one outstanding issue. Here's the steps I took to fix it
> with a Veris RM200 remote included with a Antec Fusion Max HTPC case.
> 
> Created /etc/modprobe.d/imonlcd.conf with the line
> options imon ir_protocol=2

Should not necessary, that's the default ir protocol for that device.

> Changed lircd to use devinput and read the correct device
> /usr/sbin/lircd -r -H devinput -d /dev/input/by-id/usb-15c2_0038-event-mouse

$ lircd -h
...
	 -r --release[=suffix]		auto-generate release events
...

I'd remove that -r.


> Rewrote my entire lircd.conf file based on a hexdump of the above device to get
> the new codes the driver puts out (there's probably a better way to have done
> that, but I don't know what the relationship was between the old codes and the
> new ones).

Yes, there's a much better way. Its a devinput device, just use the devinput lircd.conf file in the lirc package. :)

If you install lirc-remotes, /usr/share/lirc-remotes/devinput/lircd.conf.devinput. (lirc-remotes-0.8.6-5.fc12 for the most up-to-date and complete version).

> But I have a new problem, the repeat rate on the pad (up/down/left/right) is
> insanely fast. I've played with the repeat value in .lircrc, the gap, and the
> min_repeat, nothing seems to have any effect.
> 
> The output of irw when pressing those buttons shows as:
> 
> 000000000001006a 00 KEY_RIGHT RM200
> 000000000001006a 00 KEY_RIGHT_UP RM200
> 0000000000010067 00 KEY_UP RM200
> 0000000000010067 00 KEY_UP_UP RM200
> 0000000000010069 00 KEY_LEFT RM200
> 0000000000010069 00 KEY_LEFT_UP RM200
> 0000000000010069 00 KEY_LEFT RM200
> 0000000000010069 00 KEY_LEFT_UP RM200
> 000000000001006c 00 KEY_DOWN RM200
> 000000000001006c 00 KEY_DOWN_UP RM200
> 
> Even a half second press causes a repeat of the up/down event 4 times or more,
> even if the button is not released?    

Because you have the -r param enabled. Remove it. :)

You might also try tweaking the pad_thresh parameter upwards from its default of 28. The pad really does send a steady stream of a ton of ir signals for mouse mode, which we down-sample for arrow key mode. When we have 28 samples in a consistent direction, we report an arrow key event.

> > Created /etc/modprobe.d/imonlcd.conf with the line
> > options imon ir_protocol=2
> 
> Should not necessary, that's the default ir protocol for that device.
> 

Looks like it has to be in there, if I remove it, no more remote. Don't even see the kernel events with debug=1 if its not in there.

> Yes, there's a much better way. Its a devinput device, just use the devinput
> lircd.conf file in the lirc package. :)
> 
> If you install lirc-remotes,
> /usr/share/lirc-remotes/devinput/lircd.conf.devinput.
> (lirc-remotes-0.8.6-5.fc12 for the most up-to-date and complete version).

Thanks for the advice!

> 
> > But I have a new problem, the repeat rate on the pad (up/down/left/right) is
> > insanely fast. I've played with the repeat value in .lircrc, the gap, and the
> > min_repeat, nothing seems to have any effect.

Removing the -r got rid of those release events (that was silly of me), but it didn't seem to have much if any impact on the repeat rate.

> 
> You might also try tweaking the pad_thresh parameter upwards from its default
> of 28. The pad really does send a steady stream of a ton of ir signals for
> mouse mode, which we down-sample for arrow key mode. When we have 28 samples in
> a consistent direction, we report an arrow key event.    

I now have options imon pad_thresh=128 ir_protocol=2 (I also tried a value of 42)

Assuming I've got pad_thresh in the right place here, even as high as 128, I have seen no effect on the repeat rate. Its usable for sure as it is, you just need a quick thumb :)

(In reply to comment #39)
> > > Created /etc/modprobe.d/imonlcd.conf with the line
> > > options imon ir_protocol=2
> > 
> > Should not necessary, that's the default ir protocol for that device.
> > 
> 
> Looks like it has to be in there, if I remove it, no more remote. Don't even
> see the kernel events with debug=1 if its not in there.

Hrm? Which imon driver are you running, the stock one or the one built from the tarball I posted links to?

From the stock imon driver in the Fedora kernels:

parm:           ir_protocol:Which IR protocol to use. 0=native iMON, 1=Windows Media Center Ed. (RC-6), 2=iMON w/o PAD stabilize (default: native iMON) (int)

Native iMON is the default protocol, 2 is iMON w/o the pad stabilization formula enabled -- which explains why pad_thresh isn't making any difference. Buttons should all behave the same under both the default and 2 protos, the only difference is the stabilization of the pad presses in keyboard mode.

> I now have options imon pad_thresh=128 ir_protocol=2 (I also tried a value of
> 42)
> 
> Assuming I've got pad_thresh in the right place here, even as high as 128, I
> have seen no effect on the repeat rate. Its usable for sure as it is, you just
> need a quick thumb :)    

See above. :)

Something else funky and unexpected is going on if the default ir protocol isn't working.

> Hrm? Which imon driver are you running, the stock one or the one built from the
> tarball I posted links to?

Running the stock one

> 
> From the stock imon driver in the Fedora kernels:
> 
> parm:           ir_protocol:Which IR protocol to use. 0=native iMON, 1=Windows
> Media Center Ed. (RC-6), 2=iMON w/o PAD stabilize (default: native iMON) (int)
> 
> Native iMON is the default protocol, 2 is iMON w/o the pad stabilization
> formula enabled -- which explains why pad_thresh isn't making any difference.
> Buttons should all behave the same under both the default and 2 protos, the
> only difference is the stabilization of the pad presses in keyboard mode.
> 
> > I now have options imon pad_thresh=128 ir_protocol=2 (I also tried a value of
> > 42)
> > 
> > Assuming I've got pad_thresh in the right place here, even as high as 128, I
> > have seen no effect on the repeat rate. Its usable for sure as it is, you just
> > need a quick thumb :)    
> 
> See above. :)
> 
> Something else funky and unexpected is going on if the default ir protocol
> isn't working.

I replaced my custom lircd.conf with the one from the lirc-remotes package as you suggested and removed the config file from modprobe.d.

Interestingly, I had always "assumed" the remote wasn't working unless ir_protocol=2 was there, but as it turns out its just the PAD is not working without ir_protocol=2. All the other buttons work with the exception of channel up/down which is probably easily fixable with a change to lircd.conf, but I don't know what to do about the pad. I was looking at the hex dump of the device again with the driver in this mode and the data is a lot different then I was seeing before, I can't really see a pattern from the data coming from the pad buttons when I press them that I can associate with something for lircd.

Interestingly enough the PAD does work as a mouse device in X, its just lirc that doesn't pick anything up. Any ideas on how to work out the correct mappings for the pad in lircd.conf?

(In reply to comment #41)
> > Hrm? Which imon driver are you running, the stock one or the one built from the
> > tarball I posted links to?
> 
> Running the stock one
> 
> > 
> > From the stock imon driver in the Fedora kernels:
> > 
> > parm:           ir_protocol:Which IR protocol to use. 0=native iMON, 1=Windows
> > Media Center Ed. (RC-6), 2=iMON w/o PAD stabilize (default: native iMON) (int)
> > 
> > Native iMON is the default protocol, 2 is iMON w/o the pad stabilization
> > formula enabled -- which explains why pad_thresh isn't making any difference.
> > Buttons should all behave the same under both the default and 2 protos, the
> > only difference is the stabilization of the pad presses in keyboard mode.
> > 
> > > I now have options imon pad_thresh=128 ir_protocol=2 (I also tried a value of
> > > 42)
> > > 
> > > Assuming I've got pad_thresh in the right place here, even as high as 128, I
> > > have seen no effect on the repeat rate. Its usable for sure as it is, you just
> > > need a quick thumb :)    
> > 
> > See above. :)
> > 
> > Something else funky and unexpected is going on if the default ir protocol
> > isn't working.
> 
> I replaced my custom lircd.conf with the one from the lirc-remotes package as
> you suggested and removed the config file from modprobe.d.
> 
> Interestingly, I had always "assumed" the remote wasn't working unless
> ir_protocol=2 was there, but as it turns out its just the PAD is not working
> without ir_protocol=2. All the other buttons work with the exception of channel
> up/down which is probably easily fixable with a change to lircd.conf, but I
> don't know what to do about the pad. I was looking at the hex dump of the
> device again with the driver in this mode and the data is a lot different then
> I was seeing before, I can't really see a pattern from the data coming from the
> pad buttons when I press them that I can associate with something for lircd.
> 
> Interestingly enough the PAD does work as a mouse device in X, its just lirc
> that doesn't pick anything up. Any ideas on how to work out the correct
> mappings for the pad in lircd.conf?    

Thanks for your time on this Jarod, I got it all worked out now, everything is working.

(In reply to comment #42)
...
> > I replaced my custom lircd.conf with the one from the lirc-remotes package as
> > you suggested and removed the config file from modprobe.d.
> > 
> > Interestingly, I had always "assumed" the remote wasn't working unless
> > ir_protocol=2 was there, but as it turns out its just the PAD is not working
> > without ir_protocol=2. All the other buttons work with the exception of channel
> > up/down which is probably easily fixable with a change to lircd.conf, but I
> > don't know what to do about the pad. I was looking at the hex dump of the
> > device again with the driver in this mode and the data is a lot different then
> > I was seeing before, I can't really see a pattern from the data coming from the
> > pad buttons when I press them that I can associate with something for lircd.
> > 
> > Interestingly enough the PAD does work as a mouse device in X, its just lirc
> > that doesn't pick anything up. Any ideas on how to work out the correct
> > mappings for the pad in lircd.conf?    
> 
> Thanks for your time on this Jarod, I got it all worked out now, everything is
> working.    

I take it that means you've discovered what the mouse/keyboard toggle button does? :)

The driver operates as both a keypad and a mouse device, defaulting to mouse mode at startup, as that's the more useful function in most cases, until an application is started up (possibly by using the remote's mouse functionality to launch it). The pad behaves as the control for the mouse cursor in mouse mode, and the channel +/- keys operate as a mouse scroll wheel. Hit the mouse/keyboard button (at the top edge of the pad), and it toggles to keyboard mode, where the pad becomes up/down/left/right arrow keys, and the channel +/- keys become, well, channel +/- keys.

If you don't ever need/want mouse mode (i.e., a dedicated media center box, where the media app doesn't support using a mouse in its default setup -- such as mythtv), you can load the imon driver with 'nomouse=1', and the mouse mode functionality will be disabled.

(In reply to comment #43)
> 
> I take it that means you've discovered what the mouse/keyboard toggle button
> does? :)
> 
> The driver operates as both a keypad and a mouse device, defaulting to mouse
> mode at startup, as that's the more useful function in most cases, until an
> application is started up (possibly by using the remote's mouse functionality
> to launch it). The pad behaves as the control for the mouse cursor in mouse
> mode, and the channel +/- keys operate as a mouse scroll wheel. Hit the
> mouse/keyboard button (at the top edge of the pad), and it toggles to keyboard
> mode, where the pad becomes up/down/left/right arrow keys, and the channel +/-
> keys become, well, channel +/- keys.
> 
> If you don't ever need/want mouse mode (i.e., a dedicated media center box,
> where the media app doesn't support using a mouse in its default setup -- such
> as mythtv), you can load the imon driver with 'nomouse=1', and the mouse mode
> functionality will be disabled.    

Yes, that was the issue there, I clued in while I was looking at the code for the driver, I noticed the nomouse option in there and use that as well. Thank You!

I still can't get the PAD support working (even when pressing the toggle button).  I am using the kernel 2.6.32 on F-11 from updates-testing:

https://admin.fedoraproject.org/updates/kernel-2.6.32.10-44.fc11

and the following lirc-0.8.6 also from updates-testing:

https://admin.fedoraproject.org/updates/lirc-0.8.6-1.fc11

I get the following on driver load:

Apr 24 04:08:59 htpc kernel: imon: Driver for SoundGraph iMON MultiMedia IR/Display, v0.8
Apr 24 04:08:59 htpc kernel: input: iMON IR Remote (15c2:0038) as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/input/input7
Apr 24 04:08:59 htpc kernel: imon 8-2:1.0: iMON device (15c2:0038, intf0) on usb<8:2> initialized
Apr 24 04:08:59 htpc kernel: imon 8-2:1.1: iMON device (15c2:0038, intf1) on usb<8:2> initialized

However I noticed that with the old kernel-2.6.30.10-105.2.23.fc11(for which the Pad *did* work) I got:

Apr 23 06:16:59 htpc kernel: lirc_imon: Driver for SoundGraph iMON MultiMedia IR/Display, v0.6
Apr 23 06:16:59 htpc kernel: lirc_dev: lirc_register_driver: sample_rate: 0
Apr 23 06:16:59 htpc kernel: lirc_imon: Registered iMON driver (lirc minor: 0)
Apr 23 06:16:59 htpc kernel: input: iMON PAD IR Mouse (15c2:0038) as /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2:1.0/input/input8
Apr 23 06:16:59 htpc kernel: lirc_imon: iMON device (15c2:0038, intf0) on usb<8:2> initialized
Apr 23 06:16:59 htpc kernel: lirc_imon: iMON device (15c2:0038, intf1) on usb<8:2> initialized

I notice that "PAD" is dropped from the description of the driver in the newer kernel version, does this matter?

I wanted to mention that Jarod's devel modules make my (somewhat uncommon) 15c2:0039 work nicely.

Thanks much.

(In reply to comment #45)
> I still can't get the PAD support working (even when pressing the toggle
> button).  I am using the kernel 2.6.32 on F-11 from updates-testing:
> 
> https://admin.fedoraproject.org/updates/kernel-2.6.32.10-44.fc11
> 
> and the following lirc-0.8.6 also from updates-testing:
> 
> https://admin.fedoraproject.org/updates/lirc-0.8.6-1.fc11

Pad (in arrow key mode) seems to be working again now, must have been some transient issue.

Glenn (and others):
I'm in a situation similar to the one Glenn describes in comments 1 and 6: 

+ my lirc_imon won't take the display_type parameter
+ modinfo lirc_imon shows only one parameter for the module, and that's debug
+ I'm getting the 1,289,753 wrong-sized-payload log entries in /var/log/messages

However, it would  seem that somehow or other Glenn managed to change/replace/update his lirc_imon, because as of comment 7 he's able to set a display_type parameter again.

Obviously, he got a new lirc_imon someplace, but from where, and how?  I've been  unsuccessful at this, and am feeling remarkably clueless.

Currently uname -a shows:
Linux batvideo.tombruce.info 2.6.32.11-99.fc12.i686 #1 SMP Mon Apr 5 16:32:08 EDT 2010 i686 athlon i386 GNU/Linux

and modinfo lirc_imon gives:
filename:       /lib/modules/2.6.32.11-99.fc12.i686/kernel/drivers/input/lirc/lirc_imon.ko
license:        GPL
version:        0.8
description:    Driver for SoundGraph iMON MultiMedia IR/Display
author:         Venky Raju <dev>
srcversion:     B7B13E49D2C2D0FF015C037
alias:          usb:v15C2pFFDAd*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0AA8pFFDAd*dc*dsc*dp*ic*isc*ip*
alias:          usb:v04E8pFF30d*dc*dsc*dp*ic*isc*ip*
alias:          usb:v0AA8p8001d*dc*dsc*dp*ic*isc*ip*
depends:        lirc_dev
vermagic:       2.6.32.11-99.fc12.i686 SMP mod_unload 686 
parm:           debug:Debug messages: 0=no, 1=yes(default: no) (int)

(In reply to comment #48)
> Glenn (and others):
> I'm in a situation similar to the one Glenn describes in comments 1 and 6: 
> 
> + my lirc_imon won't take the display_type parameter

Wrong driver. You're after the imon driver, not the lirc_imon driver.

(In reply to comment #49)
> (In reply to comment #48)
> > Glenn (and others):
> > I'm in a situation similar to the one Glenn describes in comments 1 and 6: 
> > 
> > + my lirc_imon won't take the display_type parameter
> 
> Wrong driver. You're after the imon driver, not the lirc_imon driver.    

Well, duh.  Thanks.

t.

Hi Jarod, my remote doesn't work either with kernel 2.6.32 (I'm running 2.6.32.11-99.fc12.i686.PAE). It worked fine on F11. I've tried both imon and lirc_imon, neither one works, and I'm getting the same message as other people:


May  6 13:55:45 localhost lircd-0.8.6[2427]: accepted new client on /var/run/lirc/lircd
May  6 13:55:45 localhost lircd-0.8.6[2427]: could not get file information for /dev/lirc0
May  6 13:55:45 localhost lircd-0.8.6[2427]: default_init(): No such file or directory
May  6 13:55:45 localhost lircd-0.8.6[2427]: Failed to initialize hardware
May  6 13:56:14 localhost lircd-0.8.6[2427]: removed client
May  6 13:57:02 localhost lircd-0.8.6[2427]: caught signal


However I have a different remote, the iMon 2.4G, which uses a USB radio transmitter, not IR. And guess what device ID it uses:


[root@quad giulio]# lsusb | grep iMON
Bus 005 Device 002: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller


I tried your script but it doesn't work for me:


[root@quad imon-test]# insmod imon.ko debug=1 display_type=0
insmod: error inserting 'imon.ko': -1 Unknown symbol in module


I'd love to be able to help you in your effort, please let me know if there's anything I can do!

(In reply to comment #51)
...
> However I have a different remote, the iMon 2.4G, which uses a USB radio
> transmitter, not IR. And guess what device ID it uses:
> 
> [root@quad giulio]# lsusb | grep iMON
> Bus 005 Device 002: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller

I knew they existed, but you're the first person I've run across that actually has one. :)

Definitely interested to get some info from that device and get it working.

> I tried your script but it doesn't work for me:
> 
> [root@quad imon-test]# insmod imon.ko debug=1 display_type=0
> insmod: error inserting 'imon.ko': -1 Unknown symbol in module
> 
> I'd love to be able to help you in your effort, please let me know if there's
> anything I can do!    

if you 'modprobe sparse-keymap', then retry the insmod of imon.ko, you should be in better shape.

It worked! The output of dmesg is about a million of these lines:

intf0 decoded packet: ff ff ff ff ff ff 4e af

Hi Jarod,
I also had my iMON VFD stop working normally from kernel 2.6.32. My device ID is 15c2:0036 ("current stuff" I think). CPU is AMD Phenom X3 8750. Current kernel is 2.6.32.12-115.fc12.x86_64. My problems are two-fold:-

1) When I start LCDd I get slightly corrupt characters on the display & syslog fills up with entries like 

Apr  3 00:19:06 localhost kernel: imon: send_packet: packet tx failed (-32)
Apr  3 00:19:06 localhost kernel: imon: vfd_write: send packet failed for packet #3
Apr  3 00:19:07 localhost kernel: imon: send_packet: packet tx failed (-32)
Apr  3 00:19:07 localhost kernel: imon: vfd_write: send packet failed for packet #5

I had this problem previously with lirc_imon. It appears it is a timing issue with fast CPUs (http://codeka.com/forums/viewtopic.php?f=3&t=35&start=10#p863l). The fix was to add 

   set_current_state(TASK_INTERRUPTIBLE);
   schedule_timeout(50);
  
at the end of the send_packet function in lirc_imon.c. I did this with source from CSV source for LIRC, looks like the same is needed for imon but I can't find source separate from the whole kernel.

2) The remote Pad moves th mouse cursor & some of the keys work, without lircd running or device /dev/lirc existing. But how can I map all the keys on the remote, using irremote to build lircd.conf? The main use is with MythTV, and with that I prefer to use the Pad to emulate arrow keys.

I have uninstalled my hacked version of lirc_imon and blacklisted the stock kernel version, but still makes no difference. Grateful for any advice, & happy to do any testing.

Andrew

(In reply to comment #53)
> It worked! The output of dmesg is about a million of these lines:
> 
> intf0 decoded packet: ff ff ff ff ff ff 4e af    

Okay, I still need to add some special handling for this device to the imon driver. For one, that string differs slightly from all other imon devices I've seen, in that the last byte isn't 0xff, and we suppress that gunk based on 0xff being present in both the first and last byte of the buffer.

In any case, you and Andrew both need to alter your lirc setups to use the lirc devinput userspace driver instead of the default kernel driver. Config examples for this can be found here:

http://wilsonet.com/jarod/imon_stuff/imon-devinput-lirc/

Alter LIRC_DEVICE for your particular device, that example is for my own iMON VFD, which I use just about daily with MythTV. :)

(In reply to comment #54)
> 
>    set_current_state(TASK_INTERRUPTIBLE);
>    schedule_timeout(50);

I've already committed a fix for this in my git tree, but it hasn't been patched into a Fedora kernel yet.

http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git;a=commitdiff;h=3151b86b2906ffc94a20c09d96860f09a735ca3b

I first rewrote the imon driver to be a pure input layer driver, which I maintained in my lirc kernel git tree on git.kernel.org, but it has since been ported to the new ir-core (to be renamed rc-core) infrastructure landing in kernel 2.6.35, and has been merged into the v4l-dvb git tree, and should make its way into Linus' tree Real Soon Now too. So the latest version is here, but dependent on ir-core:

http://git.linuxtv.org/v4l-dvb.git?a=blob;f=drivers/media/IR/imon.c

Note specifically lines 447-528.

The interesting thing about this fix is that its not actually dependent on your cpu speed alone, the usb controller in use also matters. I've run my vfd in multiple systems, all without a problem, including the one its in now, but started hitting constant send_packet failures after swapping out nothing but the motherboard (I replaced an older nForce 630 board w/an AMD 785G board).

I have problem with Antec Fusion Remote 15c2:0038 in Fedora 12 and 13. Arrow and channel keys are not working in lirc-0.8.6-6.fc13.x86_64 and vdr-remote-plugin 0.4. Last working kernel was 2.6.32.9-70.fc12.x86_64. I am using this kernel in Fedora 13. I have copied /usr/share/lirc-remotes/devinput/lircd.conf.devinput to /etc/lirc/lircd.conf. I have tested imon nomouse option without success.

Evtest debug information: 

2.6.33.4-95.fc13.x86_64:

Event: time 1275142428.702386, type 1 (Key), code 513 (?), value 1
Event: time 1275142428.702389, -------------- Report Sync ------------
Event: time 1275142428.918236, type 1 (Key), code 513 (?), value 0
Event: time 1275142428.918238, -------------- Report Sync ------------
Event: time 1275142430.902387, type 2 (Relative), code 8 (Wheel), value 1
Event: time 1275142430.902390, -------------- Report Sync ------------
Event: time 1275142433.336666, type 2 (Relative), code 8 (Wheel), value -1
Event: time 1275142433.336670, -------------- Report Sync ------------
Event: time 1275142436.285850, type 2 (Relative), code 1 (Y), value -8
Event: time 1275142436.285854, -------------- Report Sync ------------
Event: time 1275142437.950624, type 2 (Relative), code 1 (Y), value 8
Event: time 1275142437.950627, -------------- Report Sync ------------
Event: time 1275142439.590139, type 2 (Relative), code 0 (X), value 8
Event: time 1275142439.590143, -------------- Report Sync ------------
Event: time 1275142441.133165, type 2 (Relative), code 0 (X), value -8
Event: time 1275142441.133169, -------------- Report Sync ------------

2.6.32.9-70.fc12.x86_64:

Event: time 1275142687.712535, type 1 (Key), code 402 (ChannelUp), value 1
Event: time 1275142687.712537, -------------- Report Sync ------------
Event: time 1275142687.816534, type 1 (Key), code 402 (ChannelUp), value 0
Event: time 1275142687.816536, -------------- Report Sync ------------
Event: time 1275142688.544534, type 1 (Key), code 403 (ChannelDown), value 1
Event: time 1275142688.544536, -------------- Report Sync ------------
Event: time 1275142688.760534, type 1 (Key), code 403 (ChannelDown), value 0
Event: time 1275142688.760536, -------------- Report Sync ------------
^[[AEvent: time 1275142692.015535, type 1 (Key), code 103 (Up), value 1
Event: time 1275142692.015538, -------------- Report Sync ------------
Event: time 1275142692.015539, type 1 (Key), code 103 (Up), value 0
Event: time 1275142692.015540, -------------- Report Sync ------------
^[[BEvent: time 1275142697.855536, type 1 (Key), code 108 (Down), value 1
Event: time 1275142697.855539, -------------- Report Sync ------------
Event: time 1275142697.855540, type 1 (Key), code 108 (Down), value 0
Event: time 1275142697.855541, -------------- Report Sync ------------
^[[CEvent: time 1275142700.359536, type 1 (Key), code 106 (Right), value 1
Event: time 1275142700.359538, -------------- Report Sync ------------
Event: time 1275142700.359539, type 1 (Key), code 106 (Right), value 0
Event: time 1275142700.359540, -------------- Report Sync ------------
^[[DEvent: time 1275142701.943535, type 1 (Key), code 105 (Left), value 1
Event: time 1275142701.943538, -------------- Report Sync ------------
Event: time 1275142701.943539, type 1 (Key), code 105 (Left), value 0
Event: time 1275142701.943540, -------------- Report Sync ------------

Hi i have the same problem as tomi.pahula. But i'm using Mythbuntu.

Here is my post:
http://ubuntuforums.org/showthread.php?t=1506214

Same issues are listed here:
http://ubuntuforums.org/showthread.php?p=9403905

Kind Regards
/Seppl

P.S: I'm using Kernel 2.26.32-22-generic

(In reply to comment #56)
> I have problem with Antec Fusion Remote 15c2:0038 in Fedora 12 and 13. Arrow
> and channel keys are not working in lirc-0.8.6-6.fc13.x86_64 and
> vdr-remote-plugin 0.4. Last working kernel was 2.6.32.9-70.fc12.x86_64. I am
> using this kernel in Fedora 13. I have copied
> /usr/share/lirc-remotes/devinput/lircd.conf.devinput to /etc/lirc/lircd.conf. I
> have tested imon nomouse option without success.
> 

I found solution to my original problem. Imon option ir_protocol=2 converted type 2 codes to type 1 codes. However repeat rate of arrow keys are quite high with newer kernels. I haven't found any solution to this problem.

Sorry for that stupid question but:
Is there now way to get the input working for Keys like 1, 2, 3?
Or Menu key?
Is there any way to disable that input feature and get back to the original version that does not emulate a keyboard?

(In reply to comment #56)
> I have problem with Antec Fusion Remote 15c2:0038 in Fedora 12 and 13. Arrow
> and channel keys are not working in lirc-0.8.6-6.fc13.x86_64 and
> vdr-remote-plugin 0.4. Last working kernel was 2.6.32.9-70.fc12.x86_64. I am
> using this kernel in Fedora 13. I have copied
> /usr/share/lirc-remotes/devinput/lircd.conf.devinput to /etc/lirc/lircd.conf. I
> have tested imon nomouse option without success.
> 
> Evtest debug information: 

The default state of the remote changed from keyboard mode to mouse mode. Just press the keyboard/mouse toggle button.

The high repeat rate is from using an ir_protocol parameter that disables the pad_stabilize function.

(In reply to comment #58)
> P.S: I'm using Kernel 2.26.32-22-generic    

That's likely lirc_imon, not the new imon driver, so your issues are slightly different, unless someone has gone and patched the imon driver into mythbuntu.

(In reply to comment #60)
> Sorry for that stupid question but:
> Is there now way to get the input working for Keys like 1, 2, 3?
> Or Menu key?

Sure. They work perfectly fine here. I don't know what code you're actually running in mythbuntu though.

> Is there any way to disable that input feature and get back to the original
> version that does not emulate a keyboard?    

Sounds like some version of the imon driver... You'd probably be better off working on this in your distribution's bug tracker than here, since I haven't a clue what you're actually running. Feel free to add a reference to a launchpad bug in here though, and I'll monitor it and provide any help I can over there, if someone can explain what code is actually being exercised.

Moving this bug to MODIFIED, as there's not currently any work needing to be done for this bug, but I don't want to close it yet, for the benefit of people who might be searching bugzilla for imon issues.

My remote works out of the box in Fedora 13 without lirc; however, not all of the keys work (e.g., OK, replay, skip, number keys). Is there a special way to get these keys to function without configuring lirc?

With the Fedora 13 vintage imon driver, I think the "special way" is via kernel patches. Later kernels, like the F14 one, should have more complete keytables to begin with, but you can also upload new mappings from userspace using ir-keytable in the v4l-utils package.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Jarod,

Just upgraded to F14 and now my IR isn't working.  Same info as before:

ffdc type but MCE remote type.  ffdc type detection is seeing id 0x00 but turning on debug for imon shows 0x9f as expected.  In short, driver is defaulting to incorrect VFD (should be LCD).  Setting display_type modparam does not work completely because the imon_set_display_type call isn't setting ir_type to RC6.

Let me know if you need more info.

Yun

(In reply to comment #61)

> The default state of the remote changed from keyboard mode to mouse mode. Just
> press the keyboard/mouse toggle button.

Hi Jarod, is there any way to change the default state back to keyboard mode?  It confuses people with my media center just after reboot because the buttons don't work.

(In reply to comment #67)
> Jarod,
> 
> Just upgraded to F14 and now my IR isn't working.  Same info as before:
> 
> ffdc type but MCE remote type.  ffdc type detection is seeing id 0x00 but
> turning on debug for imon shows 0x9f as expected.

Apologies for the delay, been insanely busy lately. Found some breakage that happened when the code was refactored a bit upstream. Should be all better in this build:

http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.10/75.fc14/

(In reply to comment #68)
> (In reply to comment #61)
> 
> > The default state of the remote changed from keyboard mode to mouse mode. Just
> > press the keyboard/mouse toggle button.
> 
> Hi Jarod, is there any way to change the default state back to keyboard mode? 
> It confuses people with my media center just after reboot because the buttons
> don't work.

I'm going to push a change upstream that switches the default back to keyboard mode, and will try to get that into the Fedora 14 kernels soon as well.

(In reply to comment #70)
> (In reply to comment #68)
> > (In reply to comment #61)
> > 
> > > The default state of the remote changed from keyboard mode to mouse mode. Just
> > > press the keyboard/mouse toggle button.
> > 
> > Hi Jarod, is there any way to change the default state back to keyboard mode? 
> > It confuses people with my media center just after reboot because the buttons
> > don't work.
> 
> I'm going to push a change upstream that switches the default back to keyboard
> mode, and will try to get that into the Fedora 14 kernels soon as well.

+1.  incidentally, is there a way to override lirc defaults to startup with either mouse or keyboard via the lirc config files?

(In reply to comment #71)
> incidentally, is there a way to override lirc defaults to startup with
> either mouse or keyboard via the lirc config files?

Nope, its entirely internal to the imon kernel driver.

Yun(In reply to comment #69)
> (In reply to comment #67)
> > Just upgraded to F14 and now my IR isn't working.  Same info as before:
> > 
> > ffdc type but MCE remote type.  ffdc type detection is seeing id 0x00 but
> > turning on debug for imon shows 0x9f as expected.
> 
> Apologies for the delay, been insanely busy lately. Found some breakage that
> happened when the code was refactored a bit upstream. Should be all better in
> this build:
> 
> http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.10/75.fc14/

This worked perfectly, Jarod.

It's correctly detecting 0x9f now.  Anything else I can help keep an eye out for w.r.t. integrating with the new RC core?

Yun

(In reply to comment #73)
> It's correctly detecting 0x9f now.  Anything else I can help keep an eye out
> for w.r.t. integrating with the new RC core?

Not a whole lot more change is expected with this driver, I think its pretty close to functionally complete now, and behaves as expected with respect to the new RC core code.

However, there are apparently some brand new imon touchscreen devices out there now, which may well require some driver changes at some point, but I don't have any of the new hardware myself (nor really the desire to further support a company like soundgraph that doesn't support any of the open-source efforts to support its hardware at _all_).

Hi there again.

With kernel 2.6.35.12-90 (and 88) my remote stopped working again. Now, we also have a new version of lirc, i.e. 0.9.0-1 if it matters (I am not sure what the previous version of lirc is).

This time I get this in dmesg when the lirc service is started:

[ 6458.559500] imon 8-1:1.0: Looks like you're trying to use an IR protocol this device does not support
[ 6458.559504] imon 8-1:1.0: Unsupported IR protocol specified, overriding to iMON IR protocol

and nothing happens when using the remote, e.g., running irw.

However, when starting lircd manually with:

lircd --driver=devinput --device=/dev/input/by-id/usb-15c2_ffdc-event-if00

using the standard lircd.conf.devinput as the config file it works just fine.

My /etc/sysconfig/lirc file is as follows:

# Note: in addition to these parameters, you need to have working    -*- sh -*-
# configuration file for lircd (and lircmd if enabled).

# Options to lircd(8).  Typically, this will be empty, as which driver to use
# should be specified using the LIRC_DRIVER variable below.
LIRCD_OPTIONS="-r"

# The infrared receiver (and/or transmitter) driver to be used by lircd(8),
# similar to passing "-H driver" to lircd(8).
# Run "/usr/sbin/lircd -H help" to get a listing of supported drivers.
LIRC_DRIVER="devinput"

# Which lirc device will be used by lircd(8).
# This is the same as passing "-d device" to lircd.
# An empty value will use the default /dev/lirc0 device.
LIRC_DEVICE="/dev/input/by-id/usb-15c2_ffdc-event-if00"

# If "yes", the init script will try to start lircmd(8) too.
ENABLE_LIRCMD="no"

# Options to lircmd(8).
LIRCMD_OPTIONS=""

What has happened between these versions of kernels and/or lirc that stopped my remote form working like it did before? 

Åke

(In reply to comment #75)
> Hi there again.
> 
> With kernel 2.6.35.12-90 (and 88) my remote stopped working again. Now, we also
> have a new version of lirc, i.e. 0.9.0-1 if it matters (I am not sure what the
> previous version of lirc is).
...
> What has happened between these versions of kernels and/or lirc that stopped my
> remote form working like it did before? 

I believe its the lirc 0.9.0-1 initscript, which is doing something it shouldn't be in the imon case. Please try lirc 0.9.0-2, which I've just built and submitted to be pushed as an update.

http://kojipkgs.fedoraproject.org/packages/lirc/0.9.0/2.fc14/

(In reply to comment #76)
> (In reply to comment #75)
> > Hi there again.
> > 
> > With kernel 2.6.35.12-90 (and 88) my remote stopped working again. Now, we also
> > have a new version of lirc, i.e. 0.9.0-1 if it matters (I am not sure what the
> > previous version of lirc is).
> ...
> > What has happened between these versions of kernels and/or lirc that stopped my
> > remote form working like it did before? 
> 
> I believe its the lirc 0.9.0-1 initscript, which is doing something it
> shouldn't be in the imon case. Please try lirc 0.9.0-2, which I've just built
> and submitted to be pushed as an update.
> 
> http://kojipkgs.fedoraproject.org/packages/lirc/0.9.0/2.fc14/

I have just installed lirc 0.9.0-2 and the remote works perfectly again. Thank you Jarod!

Åke

Hey gents, 

I get a fail error when i launch lirc: sudo /etc/init.d/lirc restart

this is my data: anyone any ideas? ( I am quite noob, just set up a whole ubuntu htpc, this is the only thing not working)

dmesg:

[ 3287.850350] imon:lcd_write: invalid payload size: 32 (expected 8)

ls -l /dev/input/by-id/
total 0
lrwxrwxrwx 1 root root 9 2011-11-20 15:15 usb-15c2_0038-event-if00 -> ../event4
lrwxrwxrwx 1 root root 9 2011-11-20 15:15 usb-15c2_0038-event-mouse -> ../event3
lrwxrwxrwx 1 root root 9 2011-11-20 15:15 usb-15c2_0038-mouse -> ../mouse0
lrwxrwxrwx 1 root root 9 2011-11-20 15:15 usb-DELL_DELL_USB_Keyboard-event-kbd -> ../event2

nano /etc/modprobe.d/lirc.conf
options lirc_imon debug=0 nomouse=1 display_type=0 ir_protocol=1 pad_thresh=5

nano /etc/lirc/lircd.conf
include "/usr/share/lirc/remotes/imon/lircd.conf.imon"

kernel version: 3.0.0-12-generic

(In reply to comment #78)

> this is my data: anyone any ideas? ( I am quite noob, just set up a whole
> ubuntu htpc, this is the only thing not working)

A closed fedora bug report is not an appropriate tech support forum for ubuntu users.

any ideas? this the best I found browsing around!