DS3: >> blinking sometimes got confused, setting trigger to none and back to >> timer resolved. > Could you elaborate on how the blinking became confused? When blink was enabled the led would turn off (from being statically on), but never turn on/blink... I'll try to do some more 'structured' testing over the weekend. Seen on the 3rd led, which might be a clue. DS4: > Yeah, if you set different LEDs to different triggers the light can get > stuck since the triggers will constantly override each other. I'm > thinking that an extra "blink" LED just to control the global blink rate > would be a better solution since the hardware blink setting isn't really > LED specific. Why not make the triggers/etc apply across the board, so it doesn't matter which led the command is sent to - it's just registered/copied to the first (red?) led data[]. IIRC the weirdness I saw was: -- cd red echo 80 > brightness # now red cd blue echo 80 > brightness # now purple cd red echo timer > trigger # now flashing blue.... -- >> 3rd Party Intec - Was unable to get any controlled blinking. > It sounds like this controller just doesn't implement all of the > behavior of the official controller. I'm not sure how to fix it if it's > not obeying the instructions in valid output reports and I don't have > one to test personally. Do the lights flash properly when the > controller is used with a PS3? I presume that they just reversed engineered what they thought to be correct, I don't have a Playstation so can't confirm for certain. In my testing from a year ago or so, I could make the blink work via sending data with python. The script can be found here: http://www.spinics.net/lists/linux-input/msg28271.html Note: "Which LED to enable(LED1..4 << 1, 0x20=none)" Cheers, Simon -- 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
