On Wed, Nov 11, 2009 at 11:57:36AM +0200, Onkalo Samu wrote: > On Tue, 2009-11-10 at 18:26 +0100, ext Dmitry Torokhov wrote: > > It seems that Samu's patch is a bit different - it completely disables > > the keypad. But I wonder if it needs the special attribute or the same > > can be simply achieved by simply closing event device when it is not > > needed. Or maybe unbinding driver through sysfs. > Yes, purpose is to provide keylock feature which totally disables the > keymatrix. This way system is not even aware that some key was pressed. > It also helps to save power since unnecessary interrupts are not > received. OK, that's not what your patch description sounded like - it was talking specifically about preventing resume so I thought it was focused on suspend and resume. > It seems that several userspace programs are reading the device. I have > no idea how to get all the users to close the device when keylock is > needed. Could be quite big number of changes to here and there in > userspace side. This sounds like something that should have a generic API for - keylock functionality is a very common feature. > > Overall it seems that every input device used in embedded has it's own > > way of disabling itself, we need a generic solution... Maybe > > userspace-controlled PM is the answer). > That is something which should be somehow handled. Depending on what is > happening at the userspace, there can be different needs for input > devices. Current way will be a mess since every driver has its own > tricks to save power. But power saving is really needed for embedded > devices. It doesn't look that bad to me, to be honest - mostly it seems to be a case of shutting down the device as much as possible when it's closed plus other things that the particular device can get away with without impacting actual operation. -- 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
