didier at raboud.com
Wed Sep 17 17:27:03 CEST 2008
Tilman Baumann wrote:
> Tilman Baumann wrote:
>> 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? Who wants
>> time via dbus?
>> I hope this is just some over enthusiastic proof of concept. *g*
> I just realized the difference between system time and realtime clock.
> But there is still a well established interface for that too. It's
> called hwclock and /dev/rtc.
> And for the wakeup stuff. Well besides at there is not much of a stable
> interface i guess, besides some acpi and nvram cruft.
> I guess a dbus interface suits well for that. But needs to be more
> abstract (register timer for callback/signal, remove timer). :)
> But somehow i can't get the at command out of my head...
just to add with my limited knowledge...
There are at least five different times in our system :
* The time given in the GSM carrier (I remember old phones getting their
* The time given in by the GPS sattelites
* The time effectively held in the internal clock
* Some realtime clock (effective time, but with higher accuracy)
* And the "real time", not held anywhere (reference time).
So we need access to the four first times. We need access on a "one-time"
basis, to update the 3rd or the 4th, wich we can then access.
Anyway, I don't know if this is useful or not, but I hope it helps.
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
More information about the community