On Thu, Dec 03, 2009 at 04:20:23PM +0100, Ferenc Wagner wrote: > Joonyoung Shim <jy0922.shim@xxxxxxxxxxx> writes: > > > On 12/3/2009 8:08 PM, Mark Brown wrote: > > > >> On Thu, Dec 03, 2009 at 12:58:19PM +0200, Samu Onkalo wrote: > >> > >>> Add optional enable and disable methods to input system. > >>> Add sysfs entry for enabling and disabling input device. > >>> > >>> When registering a device to input system, device can provide > >>> optional enable and disable methods. State is set to enabled by default. > >>> Opening / closing the input device doesn't change the state. > >>> If the callback functions are not provided, sysfs entry returns > >>> ENOSYS error code. > >> > >> I'm wondering if it might be nice to provide a default implementation > >> which causes the input core to ignore the events generated by the device > >> if the driver doesn't support being enabled or disabled? Obviously this > >> wouldn't be of any benefit in preventing resume or providing power > >> saving but it would give userspace the same effect which might be useful > >> to it for UI purposes. > > > > I think a default implementation of the input core for this is useful > > ex. at gpio-keys driver. > > Mika Westerberg is proposing an actual device specific implementation > for gpio-keys right now. The implementation details are not decided > yet, but unifying the interface would be preferable, so Cc-ing him. Unifying these would be nice. However, in the gpio-keys patch the idea is that we could disable separate GPIO lines from the device, not the whole device. Maybe something like generic sysfs entry for the input device to disable the whole device /and/ also possibility to disable single events or something like that? > Do you work at different departments? :) Well we work at different locations :) Thanks, MW -- 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
