2010/6/9 <david@xxxxxxx>: > On Wed, 9 Jun 2010, Arve Hj?nnev?g wrote: > >> >> The power may not see the event, the process that reads the event will >> always see it. If the power manager is not in the poll call when the >> event happens, the process that reads the event can read the event >> before the power manager calls poll. >> > >> >> All input events that can wake the system are handled by one >> user-space suspend blocker. Input devices come and go so we would need >> to add and remove the fds dynamically. > > >> >> For that to work the wakeup events would have to be reported to the >> power manager in a reliable way in the first place. Passing the file >> descriptor that the app uses to the power manager does not work for >> this, since the app could read the event while the power manager was >> not in the poll call and the power manager would never see it. Also, >> existing apps don't pass their file descriptors to the power manager, >> so it has the get the event from somewhere else. >> > > why could the suspend blocker process see all events, but the power manager > process not see the events? > Because in this proposal the power manager only looks for the events (on the same queue) when no user space suspend blockers are active. > have the userspace talk to the power manager the way it does to the suspend > blocker now and what's the difference? > > effectivly think s/suspend blocker/power manager/ (with the power manager > doing all the other things that are proposed instead of grabbing the > wakelock), the difference should be hidden to the rest of userspace. > > what am I missing here? > The current user space interface does not require that clients register the file descriptors that they get wakeup events from with another process. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm