On Fri, Nov 30, 2012 at 08:13:29PM -0800, Chris Moeller wrote: > On Fri, 30 Nov 2012 14:30:23 -0800 > Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > > Hi Chris, > > > > On Friday, November 30, 2012 01:54:06 PM Chris Moeller wrote: > > > I've submitted versions of this with prior patch sets, and this part > > > was never accepted, possibly because it depended on other patches to > > > work, or possibly because it wasn't so cleanly organized. This time, > > > I've split the LED setting command off into its own static function, > > > then call that on controller connect and optionally on LED setting > > > commands. The static function does not include any locking, because > > > locking inside the function which receives the incoming packets > > > deadlocks the driver, and does not appear to be necessary anyway. > > > > > > It also removes all traces of the original bulk out function which > > > was designed for the purpose of setting the LED status on connect, > > > as I found that it actually does not work at all. It appears to try > > > to send the data, but nothing actually happens to the controller > > > LEDs. > > > > Attached is a reply I sent to on 7/4/11 to which you unfortunately > > never responded. The issue is that of force feedback (rumble) and LED > > share the same URB then access to that URB should be arbitrated. The > > attached message contains a patch that attempts to implement that > > arbitration, could you please try it out and see what changes are > > needed to make it work? > > > > Thanks. > > > > So sorry I missed your reply. That's what I get for filtering the > mailing list messages past my inbox, then never following up on my > filter/folder set for replies to my own messages. I recall you > mentioned that potential race condition when I first submitted, but I > forgot to do anything about it. I'm glad at least one of us has our > stuff together. It seems to work just fine, but there may be a force > feedback issue with the following test program, where it leaves the > effect playing indefinitely after the program terminates, and then the > controller itself ceases to respond until the module is removed and > reloaded. Just to confirm, you see this problem only with the patch being discussed and do not see it without it, right? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
