Ticket #112 (assigned defect)

Opened 6 years ago

Last modified 5 years ago

How to deliver kernel-level alarm to destination app

Reported by: mickey@… Owned by: openmoko-devel
Priority: high Milestone:
Component: alarm handling Version: unspecified
Severity: normal Keywords:
Cc: buglog@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

Lot of PDAs usually are doing this with a dedicated script in /etc/apm.d/

Change History

comment:1 Changed 6 years ago by mickey@…

  • Summary changed from How to deliver kernel-level alam to destination app to How to deliver kernel-level alarm to destination app

comment:2 Changed 6 years ago by laforge@…

  • rep_platform changed from PC to GTA01
  • dependson set to 80, 81

comment:3 Changed 5 years ago by willie_chen@…

  • Owner changed from buglog@… to willie_chen@…

We need to plan this.

comment:4 Changed 5 years ago by willie_chen@…

  • Status changed from new to closed
  • Resolution set to wontfix

SIGALRM can do this.

comment:5 Changed 5 years ago by mickey@…

  • Status changed from closed to reopened
  • Resolution wontfix deleted

Which applications get SIGALRM on resume? When the system wakes up from resume,
there may be one or more applications interested in being notified about the
reason. Part of this should be done by neod via dbus, but how does neod get
informed about a resume? (Note that it not necessarily was triggering the suspend)

comment:6 Changed 5 years ago by laforge@…

yes, the PMU knows the reason for the resume (RTC alarm in this case). However,
the PMU driver doesn't really have an idea on how to signal this to userspace yet.

So this is very much a valid bug, and we need to define an interface by which
the wakeup reason can be obtained (query) as well as some kind of
event/notification interface in the resume path, sending an event if the resume
was based on RTC alarm.

comment:7 Changed 5 years ago by andy@…

It seems we misunderstood what this bug is about from the title.

How does this lack of awareness of why we woke up affect the userspace apps,
ie, is this something we must attack before shipping anything?

If I understood #80, grepping /proc/cmdline can get the reason information if
not the notification part.

comment:8 Changed 5 years ago by roh

  • Owner changed from willie_chen@… to willie_chen

comment:9 Changed 5 years ago by john_lee

  • Status changed from reopened to assigned
  • Owner changed from willie_chen to openmoko-devel
  • HasPatchForReview unset
Note: See TracTickets for help on using tickets.