On Mon, Nov 17, 2014 at 10:21:53PM -0500, Frank Praznik wrote: > Hi Brian, > > On 11/17/2014 19:00, bri wrote: > > > >>Yeah, the device ID in the driver is only for tracking devices internally > >>and setting sane default LED values. It has no meaning outside of the > >>module. Like Antonio said, if you want the system number for a controller > >>you are better off just getting it from the joystick device. > >Would you be amenable to a patch that removes the IDA entirely and just sets > >the LEDs to all solid-on? Since the LEDs are available through sysfs, > >udev rule could probably be made to set the LEDs in the absence of bluez > >or a higher level controller manager, and then it becomes the distro's > >responsibility. > > > > What would be the benefit of doing this? Nothing is stopping higher level > services from setting the LEDs right now. The driver just sets sane > defaults for systems that don't have anything else to set the 'real' values. > Other controllers like Wiimotes and Xbox gamepads do the same thing. It > doesn't get in the way of services like BlueZ setting them once > initialization is complete. > > Leaving it completely up to the distro just means that there will be > situations where there is nothing to set the default values which makes for > a bad user experience. It would eliminate 50 to 100 lines of code just for that tiny purpose, which userspace can and probably should take care of, given the disparity with the eventual values. I'm honestly a bit confused of the criteria in use here, as I thought it was mostly deciding between the usefulness of features versus maintainability. In my mind if I weight a master_bdaddr sysfs file and the code to support it versus this feature, I don't see where this one wins out. But whatever. I made this for my own use, and offered it up, and if the community does not want it I am free to keep using what I made, so I'm happy either way. -- 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