On Wed, Mar 16, 2011 at 04:12:35PM +0900, Joonyoung Shim wrote: > On 2011-03-16 ìí 1:55, Dmitry Torokhov wrote: > >On Tue, Mar 15, 2011 at 06:06:26PM +0900, Joonyoung Shim wrote: > >>Hi, all. > >> > >>The many smartphones and embedded devices have LCD panel with > >>touchscreen. The LCD panel is turned off for power saving and > >>touchscreen also is disabled if there isn't user input for a while or if > >>user presses power key briefly. This state is such idle, not suspend. > >> > >>The framebuffer device driver of kernel supplies sysfs interface to > >>control blanking level of framebuffer and we can turn off LCD panel > >>using this sysfs at the above case. > >> > >>Currently i know there isn't the generic way for disabling input device > >>via user interface, so i am looking for the way for disabling > >>input device on kernel side for above case. > >> > >>The above case has a condition which the touchscreen is disabled if LCD > >>panel is turned off. The framebuffer framework of kernel has notifier > >>block to callback on events like hardware display blank change occured, > >>so the callback function disabling and enabling input device can be > >>called using notifier block of framebuffer. The callback function is > >>implemented in each touchscreen driver or can be implemented though > >>input core if this can be generic way for input device. > >> > >>Actually i wonder whether this approach makes sense. I know this is a > >>specific case but certainly necessary function in the smartphone and > >>embedded devices. > > > >I do not believe that we should tie the 2 together. I can come up with > >scenarios where you woudl want to put the keeboard/touchcsreen to sleep > >before turning off the display and vice versa. > > Right, as you say, various scenarios can come up, so i think generic > way for disabling input device needs more and more. Not only input, other devices need this facility as well. -- 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