Michael 'Mickey' Lauer
mickey at openmoko.org
Wed Sep 17 18:33:44 CEST 2008
Am Wednesday 17 September 2008 18:24:30 schrieb Tilman Baumann:
> Michael 'Mickey' Lauer wrote:
> > Am Wednesday 17 September 2008 17:54:54 schrieb Tilman Baumann:
> >> Michael 'Mickey' Lauer wrote:
> >>> Am Wednesday 17 September 2008 16:16:43 schrieb Tilman Baumann:
> >>>> Tilman Baumann wrote:
> >>>>> dbus is getting flodded by org.freedesktop.Gypsy.Time.TimeChanged,
> >>>>> org.freedesktop.Gypsy.Satellite.SatellitesChanged and
> >>>>> org.freedesktop.Gypsy.Time.TimeChanged signals.
> >>>>> But GPS is off.
> >>>>> I think neither of the events makes sense in this case and wastes
> >>>>> cycles. Probably not good for battery life.
> >>>> I just had a look at the fso apis again. And i almost fell of my
> >>>> chair. I just found org.freesmartphone.Device.RealtimeClock
> >>>> What is wrong with gettimeofday anc co with all it's beauty?
> >>> Last time I checked gettimeofday reads from system time.
> >>> org.freesmartphone.Device.RealtimeClock is a dbus interface to program
> >>> the RealtimeClock (sic!).
> >> My mistake. But what about /dev/rtc and the hwclock command?
> > programming /dev/rtc works fine from C and asm, much less so for higher
> > level languages.
> But they will however probably never be in a position where they need to.
> Keeping the rtc in sync sounds to me like a framework job.
> I don't know, the system clock should probably be stored in rtc before
> going to sleep and saved back afterwards.
> And the usual stuff, shutdown and booting.
> > I felt a dbus interface for that would be nice. It's not in use
> > yet, but we need something like that anyways when we want to support
> > waking up arbitrary dbus clients for PIM events.
> What about a interface where a process can register a timer event for a
> callback/dbus signal?
> Getting and setting stuff to the clock does not sound to me like
> something that needs to be exposed as a interface.
Ok, how would you design it then? Lets say we have a couple of clients who
know about certain appointments and every time you go into suspend, you need
to find out which client knows about the soonest appointment and have the RTC
How do these programs know each other? Are all supposed to concurrently
program the RTC? => Boom.
> Sorry if my sarcasm sounded too harsh. It isn't all that bad. ;)
Don't worry, I'm sarcasm-resistent by now. It's important though that people
understand why we need all these abstractions. It's not because we love high
level interfaces, it's because we need to prepare for application
More information about the community