gnome-shell-extension-gsconnect

gnome-shell-extension-gsconnect copied to clipboard

Is your feature request related to a problem? Please describe. Battery usage

Describe the solution you'd like Respond to power-profiles-daemon to adjust settings to fit the power profile. Such as decreasing checks on network

Describe alternatives you've considered Manual settings to adjust checking the network etc

System Details (please complete the following information):

• Fedora 35

One can react to this https://docs.gtk.org/gio/iface.PowerProfileMonitor.html to properly implement such functitonality

Interesting idea! What did you have in mind for this; just changing the keepalive on sockets or something?

Interesting idea! What did you have in mind for this; just changing the keepalive on sockets or something?

I do not have full understanding of the code base. But you seem to be the active developer.

Changing the sockets is a bare minimum. Do you think there is other things that can be changed?

One thing I think can be done is change the network calls to the mobile device itself during power saving mode.

But you seem to be the active developer.

I don't really maintain GSConnect anymore, unfortunately, I just poke my head in sometimes or triage bugs :slightly_smiling_face:

One thing I think can be done is change the network calls to the mobile device itself during power saving mode.

Well, the keepalive on the sockets is probably the most major hardware wakeup done, although that probably affects the remote device more than the local device I would guess.

I think it would take a fair amount of thinking to decide what packets could be safely delayed or batch-sent though. You probably don't want notifications or other time-sensitive communication to be delayed, so a blanket throttling is probably a no-go.

If someone were to do a thorough overview of the opportunities where power-saving could be applied, I might be interested enough to write something :slightly_smiling_face:

Do we have a list of what packets are sent / received?

So we can create a chart of what to throttle and what not to throttle

There is no official documentation of the protocol yet, but you could reference this as a starting point.

Then I suppose a higher abstraction of what to limit is which plugins to limit

which might come down to personal preference.

a good idea upon that is to create an option for users to decide if a plugin is power limited or not.