fso bug/oddity

[Didier Raboud]

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...

Hi, 

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
time)
* 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.

Regards, 

OdyX

--
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org