On Wed, 2010-10-06 at 10:56 +0200, ext Sundar R IYER wrote: > Hi, > > >-----Original Message----- > >From: Trilok Soni [mailto:tsoni@xxxxxxxxxxxxxx] > >Sent: Wednesday, October 06, 2010 2:02 PM > > > >I agree with Dmitry. Meego people or you should explain the real end-to-end > >usecase first. Why it can't fit anywhere else? > > I don't know the full details; but what I can think of (or did I read it somewhere?) > is events like phones with slider keypad; you can power save keypad controller > when the keypad is not active. And these events are probably issued from the user > space to the kernel and that's why the requirement probably. And I do remember > Samu mentioning about unwanted wakeup events which were avoided via these switches. > > Adding Samu who can explain more on this. This is how I see this issue I tried to push enable / disable entries to generic input layer to avoid driver specific controls. That was not accepted. The need for keypad locking is not following any global PM transition. In phones (like N900), global suspend / resume is not used at all. Phone is running all the time. For example phone must be able to handle incoming calls all the time. Instead suspend / resume, system is in deep idle state as much as possible. Wake up from that takes couple of milliseconds and everything is running again. Powers, clocks and any extra activity must be turned off when ever possile depending on the overall system state. For input devices this means that keypad, touch controller etc. are turned off or partially disabled for example when the screen is blanked. Meanwhile system may still have other activity ongoing like mp3 playback. When the screen is off, there must be some way to tell to touch controller that please turn off and save some power. This not following pm transitions. On the other hand, disable entry may trig pm_runtime suspend transifion for that device. For mobile devices it is not acceptable to filter events away at some upper SW layer depending on the system state. The HW which generates those events may not generate events at all to allow longer CPU sleep periods. In ideal world it would be nice to control device states based on for example user count. However, there are several listeners for input devices and it is hard or impossible to have them all to follow overall state transition (screen blanked etc.). Instead, there is some system state controller in the userspace who is responsible to get all the HW in the correct state. Separate disable / enable entries makes life much easier. Hopefully this clears out our point of view. Regards, Samu > > >We should not fill in features very specific to userspace frameworks. I see lately > >lot of Android and Meego specific bits into TS and Keypad drivers from many > >folks. > > > > Yeah. IMO it is because people want to mainline and push out all drivers more and more; > And as of today most of these drivers and HW are tested and delivered on such frameworks :) > > Regards, > Sundar > > -- 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
