On 01-02-18 13:31, Hans de Goede wrote:
As you may have heard I've recently been working on improving
Linux laptop battery life, specifically the OOTB experience
without tweaking any options such as e.g. powertop --auto-tune
would do, see:
So far this is going quite nicely, it looks like Fedora 28
will have SATA ALPM (big win), autosuspend of USB Bluetooth HCIs
and snd_intel_hda powersaving all enabled OOTB.
Looking for more savings I've run some quick tests with
i915.enable_psr=1, this seems to be another nice win (for an idle
system) of aprox. 0.5W.
So as with the other 3 items I just mentioned I'm now looking into
somehow enabling this be default, at least one some models.
Currently I'm thinking doing a whitelist or blacklist (*) for this,
but first I think we need some more data about on how much models
this just works and where it is causing issues, as such I've done
a blog post to gather this data:
So I will revisit this eventually, once people have had some time
to respond to this blog-post.
In the mean time I wonder if anyone can explain why this options
is currently disabled by default. E.g. are there any known specific
models laptops / panels which are causing issues, are the bugzillas
for this? Etc. ?
Also does anyone know if any problems are mainly panel or laptop
model specific ? I would expect this to mostly be panel specific
and not depend on the model laptop (given then certain models
ship with different panels over their production lifetime).
If anyone on this list can make 10 minutes to run the tests
described in my blogpost and gather the data mentioned there, then
that would be great.
*) I know that maintaining such a white/blacklist in the kernel
is going to be a pain, so my current thinking on this is to make
this runtime configurable through a sysfs attribute and then
use a udev rule + udev hwdb entries for this.
So a quick update on this. The response has been quite overwhelming,
with well over 50 test-reports received sofar. The results are all
over the place, some people see no changes, some people report the
aprox. 0.5W saving my own test show and many people also report
display problems, sometimes combined with a significant increase in
I need to take a closer look at all the results, but right now I
believe that the best way forward with this is (unfortunately) a
whitelist matching on a combination of panel-id (from edid) and
dmi data, so that we can at least enable this on popular models
(any model with atleast one user willing to contribute).
So intel-gfx-team folks any input from your side, any feedback
on the plan to use a udev rule + udev hwdb entries to build a
whitelist for this?
dri-devel mailing list