asked 2015-05-19 15:54:20 +0300
I read in the roadmap for sailfish that upower were dropped in favor of statefs. I know linux usally uses upower, what is the benefit of this change? I don't want to discuss this change (allthrough I don't like fregmentation). What is the benifit of this change?
answered 2015-05-20 08:55:37 +0300
Basically, upower was created for laptops and has some drawbacks for usage on mobile phones and tablets where battery power saving becomes even more important, also it has quite complex internal structure, so it requires disproportionate effort to maintain it for our purposes. Usage of upower D-Bus API is not so common, so there are no much software depending on it, on the other hand API design is questionable: there is a Changed signal but client should read all properties to understand what is changed. There were also issues with long upower daemon startup time etc. And final argument was that we do not want to keep one more daemon while context properties are used to get power information, so we just removed redundant link in the chain.
Asked: 2015-05-19 15:54:20 +0300
Seen: 495 times
Last updated: May 20 '15
iirc Jolla had to develop everything for upower implementation/integration themselves and statefs does not need that kind of upstream love from Jolla. What I understood is that they wasted 2 years coding time for upower they could have spent elsewhere.
chemist ( 2015-05-20 02:41:43 +0300 )editSo they tried to implement this but failed or what? why is this so hard?
Thaodan ( 2015-05-20 02:47:17 +0300 )editThey did not fail, what @dez describes below in short, upower is design wise not really made for mobilephones so a lot of effort was needed to make it fit a mobile OS that hibernates every 30seconds and needs to wakeup within a second. iirc some of the phone not waking in time on incoming call issues were upower taking too long. Why is this hard? Have you ever tried to fit a car's dashboard to a motorcycle?
chemist ( 2015-05-20 11:57:16 +0300 )edit