How do you know how the system has just woken up from memories?

Question

I have a Qt application that runs on Linux.

The user can switch the system to mem sleep using this application.

Switching to mem sleep is trivial, but catching an awakening event in user space is not.

My current solution is to use an infinite loop to catch the mem dream, so when the system wakes up, my application always continues from a predictable point.

Here is my code:

void MainWindow::memSleep() { int fd; fd = ::open("/sys/power/state", O_RDWR);// see update 1) QTime start=QTime::currentTime(); write(fd,"mem",3); // command that triggers mem sleep while(1){ usleep(5000); // delay 5ms const QTime &end=QTime::currentTime();// check system clock if(start.msecsTo(end)>5*2){// if time gap is more than 10ms break; // it means this thread was frozen for more } // than 5ms, indicating a wake up after a sleep start=end; } :: close(fd); // the end of this function marks a wake up event } 

I described this method as a comment on this question , and it was pointed out that this is not a good solution, which I agree on.

Question: Is there a C API that I can use to catch the wake up event?

Update:

1) What is a sleep dream?

https://www.kernel.org/doc/Documentation/power/states.txt

The kernel supports up to four system sleep states in general, although three of them depend on the platform support code to implement low-level details for each state.

States are represented by lines that can be read or written to / sys / power / state . These lines can be "mem" , "standby", "freeze" and "disk", where the latter always represents sleep mode (Suspend-To-Disk) and the meaning of the rest depends on the relative_sleep_states line command.

2) Why do I want to catch an awakening event?

Because some hardware must be reset after waking up. The hardware input device generates erroneous input events after the system wakes up, so it must be turned off before bedtime (easy) and turned on after waking up (this question).

This should / could be handled by the driver in the kernel, to which I have access or fixed on the equipment that my team can do, but does not have time for this. (why I, the application developer, need to fix it in user space)

3) restrictions

This is the built-in linux, kernel 2.6.37, arch: arm, march: omap2, distro: arago . This is not as convenient as computer distributions for adding packages, rather than ACPI. Mem sleep support in 2.6.37 kernel is not mature at all.

Answer 1

Linux device drivers for PCI devices can possibly handle suspend and resume, which are presumably kernel calls, respectively, just before the system pauses and immediately after the pause resumes. PCI input points are in struct pci_driver .

You can write and install a trivial device driver that no more than perceives renewal operations and provides instructions for any interested processes. The simplest may be support for the read () file, which returns one byte whenever a resume is detected. A program only needs to open the device and leave the thread stuck by reading one character. Whenever a read is successful, the system simply resumes.

---

Moreover, if the devices that your application runs on have device drivers, the drivers must be updated to respond appropriately to the resume.

Answer 2

Check out pm-utils , which you can put in /etc/pm/sleep.d In the hook, you can deliver a signal to your application, for example. by destruction or any IPC.

You can also let pm-utils pause your computer, which IMO is much more compatible with various configurations.

EDIT:

I am not familiar with arago , but pm-utils comes with arch and ubuntu. Also note that on a new system using systemd , pm-utils is deprecated, and you should instead hook the systemd .

REF: systemd power events

Answer 3

When the system wakes up from sleep, it should generate an ACPI event, so acpid should allow you to detect and process this: through the /etc/acpi/events script, connecting to /var/run/acpid.socket or using acpi_listen . ( acpi_listen should be an easy way to check if this will work.)