On Mon, Nov 23, 2009 at 02:05:55PM +0200, Onkalo Samu wrote: > twl4030 keypad is more or less connected to omap based systems and this > kind of disabling and enabling feature is clearly targetted to embedded There's rather a lot of embedded systems and off the shelf application stacks for them so having an interface that isn't driver-specific is also useful for them. > systems. One more generic way could be to add ioctl to evdev driver > which calls chip-specific driver for disabling / enabling the keypad. > It is then up to chip specific driver to setup necessary callback > functions which makes actual job. Does this sound bad? Something along these lines which makes the user space interface part of the common code, enabled if driver provides functions to implement the behaviour does seem like a good approach. sysfs might be easier to use than an ioctl(), though. -- 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
