On Wed, Jul 20, 2011 at 08:05:43AM +1000, Chris W wrote: > On 20/07/11 02:12, Jarod Wilson wrote: > > The imon devices have either 1 or 2 usb interfaces on them, each wired > > up to its own urb callback. The interface 0 urb callback is wired up > > before the imon context's rc_dev pointer is filled in, which is > > necessary for imon 0xffdc device auto-detection to work properly, but > > we need to make sure we don't actually run the callback routines until > > we've entirely filled in the necessary bits for each given interface, > > lest we wind up oopsing. Technically, any imon device could have hit > > this, but the issue is exacerbated on the 0xffdc devices, which send a > > constant stream of interrupts, even when they have no valid key data. > > > > OK. The patch applies and everything continues to work. There is no > obvious difference in the dmesg output on module load, with my device > remaining unidentified. I don't know if that is indicative of anything.
Did you apply this patch on top of the earlier patch, or instead of it? > input: iMON Panel, Knob and Mouse(15c2:ffdc) as > /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input9 > imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00) The 'id 0x00' part should read 'id 0x24', as the ongoing spew below has in index 6, which makes me think you still have the earlier patch applied. You actually want only the newer patch applied. If you only have the newer one applied, then I'll have to take another look to see what's up. > intf0 decoded packet: 00 00 00 00 00 00 24 01 > intf0 decoded packet: 00 00 00 00 00 00 24 01 > intf0 decoded packet: 00 00 00 00 00 00 24 01 One other amusing tidbit: you get continuous spew like the above, because to date, I thought all the ffdc devices had "nothing to report" spew that started with 0xffffff, which we filter out. Sigh. I hate imon hardware... -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
