tilman at baumann.name
Wed Sep 17 18:24:30 CEST 2008
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
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
Getting and setting stuff to the clock does not sound to me like
something that needs to be exposed as a interface.
Sorry if my sarcasm sounded too harsh. It isn't all that bad. ;)
Drucken Sie diese Mail bitte nur auf Recyclingpapier aus.
Please print this mail only on recycled paper.
More information about the community