On Wed, 28 Apr 2010, Arve Hjønnevåg wrote: > >> > suspend blockers can be used to allow > >> > +user-space to decide whether a keystroke received while the system is suspended > >> > +should cause the screen to be turned back on or allow the system to go back into > >> > +suspend. > >> > >> That's not right. Handling the screen doesn't need suspend blockers: > >> The program decides what to do and then either turns on the screen or > >> else writes "mem" to /sys/power/state. > > That does not work though. Unless every key turns the screen on you > will have a race every time the user presses a key you want to ignore. Of course. You are confirming what I wrote immediately below: Suspend blockers help resolve races. Note that this race has nothing to do with the _screen_ in particular -- exactly the same race occurs if you decide to turn on the audio speaker or some other piece of hardware. > >> What suspend blockers add is > >> the ability to resolve races and satisfy multiple constraints when > >> going into suspend -- which has nothing to do with operating the > >> screen. > > I'm not sure I agree with this. You cannot reliably turn the screen on > from user space when the user presses a wakeup-key without suspend > blockers. Let's say that it has nothing to do _specifically_ with the screen. _Any_ action you want to take in userspace is difficult to coordinate with system suspends if you don't have suspend blockers. > >> > >> I _think_ what you're trying to get at can be expressed this way: > >> > >> Here's an example showing how a cell phone or other embedded > >> system can handle keystrokes (or other input events) in the > >> presence of suspend blockers. Use set_irq_wake... > > OK, but the last version was what you (Alan) suggested last year. So at least my mental processes have remained consistent over the span of a year. Nice to know I haven't undergone a complete personality change... :-) > >> ... > >> > >> - The user-space input-event thread returns from read. It > >> carries out whatever activities are appropriate (for example, > >> powering up the display screen, running other programs, and so > >> on). When it is finished, it calls suspend_unblock on the > >> process_input_events suspend_blocker and then calls select or > >> poll. The system will automatically suspend again when it is > >> idle and no suspend blockers remain active. > > > > Yeah, that sounds better. Arve, what do you think? > > > > Idle is irrelevant and needs to be removed. This new last step is also > no longer a concrete example, but if you really think is it better I > can change it. Perhaps you would prefer to change this completely. Write up a description of what can go wrong when suspend blockers _aren't_ used, and show how suspend blockers can prevent the problem from occurring. But whatever you do, don't make it appear that suspend blockers allow user programs to make decisions (which is what you wrote before). They don't -- programs can make whatever decisions they want. Suspend blockers merely help them carry out the actions they have decided upon in a safe manner. And don't make it appear that suspend blockers can only be used for solving screen-related problems. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
