Improving Linux battery life, enabling PSR by default, testers wanted

Hi All,

Update: Thank you everyone for all the test-reports I've received. The response has been quite overwhelming, with 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 power-consumption. 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).

As you've probably read already I'm working on improving Linux laptop battery live, previously I've talked about enabling SATA link powermanagement by default. This is now enabled in rawhide / Fedora 28 since January 1st and so far no issues have been reported. This is really good news as this leads to significantly better idle power consumption (1 - 1.5W lower) on laptops with sata disks. Fedora 28 will also enable HDA codec autosuspend and autosuspend for USB Bluetooth controllers, for another (aprox) 0.8W gain.

But we're not done yet, testing on a Lenovo T440s and X240 has shown that enabling Panel Self Refresh (PSR) by setting i915.enable_psr=1 saves another 0.5W. Enabling this on all machines has been tried in the past and it causes problems on some machines. So we will likely need either a blacklist or whitelist for this. I'm leaning towards a whitelist to avoid regressions, but if there are say only 10-20 models which don't work with it a blacklist makes more sense. So the most important thing to do right now is gather more data, hence this blog post.

So I would like to ask everyone who runs Linux on their laptop (with a recent-ish kernel) to test this and gather some data for me:

  1. Check if your laptop uses an eDP panel, do: "ls /sys/class/drm" there should be a card?-eDP-1 there, if not your laptop is using LVDS or DSI for the panel, and this does not apply to your laptop.

  2. Check that your machine supports PSR, do: "cat /sys/kernel/debug/dri/0/i915_edp_psr_status", if this says: "PSR not supported", then this does not apply to your laptop.

  3. Get a baseline powerconsumption measurement, install powertop ("sudo dnf install powertop" on Fedora), then close all your apps except for 1 terminal, maximimze that terminal and run "sudo powertop". Unplug your laptop if plugged in and wait 5 minutes, on some laptops the power measurement is a moving average so this is necessary to get a reliable reading. Now look at the power consumption shown (e.g. 7.95W), watch it for a couple of refreshes as it sometimes spikes when something wakes up to do some work, write down the lowest value you see, this is our base value for your laptops power consumption, write this down.                        Note beware of "dim screen when idle" messing with your brightness, either make sure you do no touch the laptop for a couple of minutes before taking the reading, or turn this feature of in your power-settings.

  4. Add "i915.enable_psr=1" to your kernel cmdline and reboot, check that the LCD panel still works, try suspend/resume and blanking the screen (by e.g. locking it under GNOME3) still work.

  5. Check that psr actually is enabled now (you're panel might not support it), do: "cat /sys/kernel/debug/dri/0/i915_edp_psr_status" and check that it says both: "Enabled: yes" and  "Active: yes"

  6. Measure idle powerconsumption again as described under 1. Make sure you use the same LCD brightness setting as before, write down the new value

  7. Dump your LCD panels edid, run "cat /sys/class/drm/card0-eDP-1/edid > panel-edid"

  8. Send me a mail at with the following in there:

  • Report of success or bad side effects

  • The idle powerconsumption before and after the changes

  • The brand and model of your laptop

  • The "panel-edid" file attached

  • The output of the following commands:

  • cat /proc/cpuinfo | grep "model name" | uniq

  • cat /sys/class/dmi/id/modalias

Once I've info from enough models hopefully I can come up with some way for us to enable PSR be default, or at least build a whitelist with popular laptop models and enable it there.

Thanks & Regards,


Improving Linux laptop battery life: Testers Wanted

Edit: linrunner (TLP author) has been so kind as to make prebuilt Ubuntu kernel packages with the patch available.

My next project for Red Hat is to work on improving Linux laptop battery life. Part of the (hopefully) low hanging fruit here is using kernel tunables to enable more runtime powermanagement. My first target here is SATA Link Power Management (LPM) which, as Matthew Garrett blogged about 2 years ago, can lead to a significant improvement in battery life.

There is only one small problem, there have been some reports that some disks/SSDs don't play well with Linux' min_power LPM policy and that this may lead to system crashes and even data corruption.

Let me repeat this: Enabling SATA LPM may lead to DATA CORRUPTION. So if you want to help with testing this please make sure you have recent backups! Note this happens only in rare cases (likely only with a coupe of specific SSD models with buggy firmware. But still DATA CORRUPTION may happen make sure you have BACKUPS.

As part of his efforts 2 years ago Matthew found this document which describes the LPM policy the Windows Intel Rapid Storage Technology (IRST) drivers use by default and most laptops ship with these drivers installed.

So based on an old patch from Matthew I've written a patch adding support for a new LPM policy called "med_power_with_dipm" to Linux. This saves
(almost) as much power as the min_power setting and since it matches Windows defaults I hope that it won't trip over any SSD/HDD firmware bugs.

So this is where my call for testers comes in, for Fedora 28 we would like to switch to this new SATA LPM policy by default (on laptops at least), but
we need to know that this is safe to do. So we are looking for people to help test this, if you have a laptop with a SATA drive (not NVME) and would like to help please make BACKUPS and then continue reading :)

First of all on a clean Fedora (no powertop --auto-tune, no TLP) do "sudo dnf install powertop", then close all your apps except for 1 terminal, maximimze that terminal and run "sudo powertop".

Now wait 5 minutes, on some laptops the power measurement is a moving average so this is necessary to get a reliable reading. Now look at the
power consumption shown (e.g. 7.95W), watch it for a couple of refreshes as it sometimes spikes when something wakes up to do some work, write down the lowest value you see, this is our base value for your laptops power consumption.

Next install the new kernel and try the new SATA LPM policy. I've done a scratch-build of the Fedora kernel with this patch added, which
you can download here. Linrunner (TLP author) has been so kind as to make prebuilt Ubuntu kernel packages with the patch available.

After downloading all the .x86_64.rpm files there into a dir, do from this dir:
sudo rpm -ivh kernel*.x86_64.rpm

Next download a rc.local script applying the new settings from here, copy it to /etc/rc.d/rc.local, and make it executable: "sudo chmod +x /etc/rc.d/rc.local".

Now reboot and do: "cat /sys/class/scsi_host/host0/link_power_management_policy" this should return med_power_with_dipm, if not something is wrong.

Then close all your apps except for 1 terminal, maximimze that terminal and run "sudo powertop" again. Wait 5 minutes as last time, then get a couple of readings and write down the lowest value you see.

After this continue using your laptop as normal, please make sure that you keep running the special kernel with the patch adding the "med_power_with_dipm" policy. If after 2 weeks you've not noticed any bad side effects (or if you do notice bad side effects earlier) send me a mail at with:

  • Report of success or bad side effects

  • The idle powerconsumption before and after the changes

  • The brand and model of your laptop

  • The output of the following commands:

  • cat /proc/cpuinfo | grep "model name"

  • cat /sys/class/scsi_device/*/device/model

I will gather the results in a table which will be part of the to-be-created Fedora 28 Changes page for this.

Did I mention already that although the chance is small something will go wrong, it is non zero and you should create backups ?

Thank you for your time.

Bay and Cherry Trail kernel improvements in 4.12

For the last couple of months I've been working on improving Linux support for Intel Bay and Cherry Trail based tablets and laptops as a spare-time project.

I'm happy to report that quite a bit of work on this has landed for 4.12, specifically the following fixes / improvements have landed:

  • LCD panel not working with the i915 driver on some devices

  • Battery monitoring not working on most Bay and Cherry devices (battery monitoring did not work on any device using the very popular AXP288 PMIC)

  • Backlight control not working on many devices (you need to builtin the pwm-lpss drivers, or add them to your initrd for this fix to work)

  • Volume and power buttons not working on Cherry Trail devices shipping with Win10

  • The microsd slot on the Asus Transformer T100TA not working

  • Preliminary (incomplete) support Cherry Trail devices with a Whiskey Cove PMIC, some bits to get e.g. battery monitoring working are still missing

  • Added the rtl8723bs driver to staging, enabling ootb support for wifi on many devices

I've also prepared a patch for the Fedora kernel config to enable the necessary new drivers so this should all also work with the upcoming 4.12
kernel for Fedora.

Improving the Fedora VirtualBox guest experience and upstreaming the VirtualBox linux guest drivers

For Fedora 27 I'm working on making Fedora 27 a fully integrated VirtualBox guest, the plan is to have Fedora 27 Workstation ship with the VirtualBox Guest Additions installed out of the box, so that cut and paste, file sharing, etc. all will work out of the box for users running Fedora 27 in a VirtualBox vm.

As a first step towards this I'm working on getting the VirtualBox guest kernel drivers merged into the mainline Linux kernel. Up until now this has never been done because of userspace ABI stability concerns surrounding the guest drivers.

I've been talking to VirtualBox upstream about mainlining the guest drivers and VirtualBox upstream has agreed to consider the userspace ABI stable and only extend it in a backwards compatible manner.

I'm about to finish cleaning up the vboxvideo drm/kms driver, when I started working on this the files under /usr/src/vboxguest/vboxvideo as installed by VirtualBox 5.1.18 Guest Additions had a total linecount of 52681 lines. I've been submitting cleanups to VirtualBox upstream and the current VirtualBox upstream svn code is now under 8000 lines.

Update: I've submitted the vboxvideo driver for inclusion into drivers/staging, see this mailinglist thread.

Getting Linux to run properly on the GPDwin

About 10 weeks ago I bought a GPDwin. I was working on improving Fedora on Cherry Trail based as a side project and I found out about this cute little machine via a blogpost from Adrien Plazas.

So now 10 weeks later I'm happy to report that after spending a lot of my spare time on kernel fixes I've it mostly working, specifically I've fixed the following things:

1) Brightness control
2) Wifi no longer working with recent kernels
3) Suspend/resume not working
4) Power and volume up/down buttons not working
5) System not waking up when opening the lid
6) Not charging when the power cable gets plugged in after boot
7) Only drawing max 0.5A from the charger, charging slowly if at all
8) Battery monitoring

And Takashi Iwai and Adrian Plazas have fixed:

9) Headphone jack detection

I've done my best to fix all of these properly and I've been submitting patches for all of this upstream. About half of the patches have already been accepted and will be merged into the kernel for the 4.12 release.

If you want to give it a try here are some step-by-step instructions:

1) First of all if you still have Windows on there and you've the 20161118 BIOS you may want to consider downgrading the BIOS to the 20161025 version before wiping Windows. The 20161118 BIOS is locked in a sort of novice mode and removes all options from the BIOS. Since Windows does not support USB gadget mode the dwc3 gadget controller is disabled and cannot be re-enabled in the 20161118 BIOS. So if you want to be able to use the USB-C connector in gadget/device mode and not just as a charging or host port in the future you are going to need the 20161025 BIOS and BIOS-flashing is only supported under Windows (flashrom may work but I was not brave enough to try it).

2) Install your favorite distro, either use an external hdmi monitor or add "i915.modeset=0 fbcon=rotate:1" to the kernel cmdline

3) To get wifi to work copy this file to /lib/firmware/brcm and then reboot.

If you kernel is new enough it will trip over a BIOS bug which causes the wifi chip to get disabled, you can "fix" the BIOS bug (if you do not have
the 20161118 BIOS) by changing the following BIOS setting: "Chipset" -> "South Bridge" -> "LPSS & SCC Configuration" -> "SCC SDIO Support"
to "Disabled". My patches include a workaround for the BIOS bug which works with the 20161118 BIOS, so if you've that you will need to install my kernel through other means (e.g. an USB network adapter).

4) clone my personal linux kernel repo:

git clone

This comes with a kernel .config file based on the standard Fedora kernel config (so highly modular). Follow the usual instructions for your distro to build a kernel from source (minus getting the .config). Make sure an initrd gets generated, this kernel-config will not work without an initrd.

Before rebooting into the new kernel add the following to the kernel cmdline in your grub configuration: "fbcon=rotate:1 dmi_product_name=GPD-WINI55".

For brightness control to work your initrd must include the pwm-lpss and pwm-lpss-platform modules. Under Fedora you can do this by booting into the new kernel and then running:

dracut -f --add-drivers "pwm-lpss pwm-lpss-platform" /boot/initramfs-$(uname -r).img $(uname -r)

5) To get sound to work you need to do some userspace config tweaks:

Edit /etc/pulse/daemon.conf and set: "realtime-scheduling = no" to work around a pulse issue with the hdmi-audio support for Cherry Trail.

Create an /usr/share/alsa/ucm/chtrt5645 directory and copy the 2 .conf files from here into that dir.

6) Edit /lib/udev/hwdb.d/99-local.hwdb, add:

 ACCEL_MOUNT_MATRIX=-1, 0, 0; 0, -1, 0; 0, 0, 1

Copy this file to /lib/udev/rules.d/

Then run "sudo udevadm hwdb --update" and reboot, together with a new enough iio-sensor-proxy, this will fix the screen orientation under gdm / gnome (note you need to tilt the device a bit toward you after booting to get it to recognize the screen orientation for now).

7) All done enjoy your (almost) fully functional GPDwin under Linux

Note these instructions are for somewhat advanced Linux users, if you hit problems please take a look at your distro's documentation or ask for help on your distro's forums.

Linux BIOS tweaks, if you have the 20161025 BIOS, there are 2 BIOS tweaks you can do:

1) Enable USB gadget support, goto: "Chipset" -> "South Bridge" -> "USB Configuration" And change the following 2 options:
"USB OTG Support" : "PCI"
"DRD Access Method" : "Mmio"
This will allow you to load gadget drivers (e.g. "modprobe g_serial") and then connect the GPD-win to a PC and have it show up as an usb device

2) Enable the "S5-Charging Driver" some howtos actually advice disabling this, but it is useful to make sure the GPDwin fast charges when plugged into a charger without being turned on (and even allows for faster charging once the OS is booted). The reason some people advice to turn it off is because it causes problems turning the device on when plugged in and fully charged, when plugged in and fully charged it will simply show a "Battery 100%" screen when you turn it on and then turn off again. You can workaround this by pressing ctrl-alt-del while at the "Battery 100%" screen, or not enable the "S5-Charging Driver" and live with the slower charging.

To enable this goto: "Advanced" -> "System Component" and set "S5-Charging Driver" to "Enabled"


1) Recently I found out that the GPDwin has a FUSB300C USB Type-C controller and a PI3USB30532 USB switch which together should allow full USB-C functionality at USB 3.0 speeds (currently the gadget mode runs at 2.0 speed and host mode does not work at all). I plan to write and upstream drivers for this to make this all work.

2) Get all of the required kernel changes upstream.

3) Make things more simple overall ideally new distros released in 2018 will just work without requiring any changes at all.
me nvidia packages should now work out of the box on optimus setups

In this blog post I promised I would get back to people who want to use the nvidia driver on an optimus laptop.

The set of xserver patches I blogged about last time have landed upstream and in Fedora 25 (in xorg-x11-server 1.19.0-3 and newer), allowing the nvidia driver packages to drop a xorg.conf snippet which will make the driver atuomatically work on optimus setups.

The nvidia packages now are using this, so if you install these, then the nvidia driver should just work on your laptop.

Note that you should only install these drivers if you actually have a supported (new enough) nvidia GPU. These drivers replace the libGL implementation, so installing them on a system without a nvidia GPU will cause things to break. This will be fixed soon by switching to libglvnd as the official libGL provider and having both mesa and the nvidia driver provide "plugins" for libglvnd. I've actually just completed building a new enough libglvnd + libglvnd enabled mesa for rawhide, so rawhide users will have libglvnd starting tomorrow.

Xorg in Fedora-26 will use xorg-x11-drv-modesetting instead of -intel for all recent Intel GPUs

A while back Debian has switched to using the modesetting Xorg driver rather then the intel Xorg driver for Intel GPUs.

There are several good reasons for this, rather then repeating them I'm just going to point to the Debian announcement.

This blog post is to let all Fedora users know that starting with Fedora-26 / rawhide as of today, we are making the same change.

Note that the xorg-x11-drv-intel package has already been carrying a Fedora patch to not bind to the GPU on Skylake or newer, even before Debian announced this, this just makes the same change for older Intel GPUs.

For people who are using the now default GNOME3 on Wayland session, nothing changes, since Xwayland always uses glamor for X acceleration, just like the modesetting driver.

If you encounter any issues causes by this change, please file a bug in bugzilla.

The "for all recent Intel GPUs" in the subject of this blog post in practice means that we're making this change for gen4 and newer Intel GPUs.

Hybrid graphics and NVidia binary driver support in Fedora 25

As blogged about already by Christian for Fedora 25 we've been working on improving hybrid gfx support, as well as on making it easier for users who want to, to install the NVidia binary driver.

The improved hybrid gfx support using the default opensource drivers was ready in time for and is part of the Fedora 25 release. Unfortunately the NVidia driver work was not ready in time. This has lead to some confusion.

Let me start with a FAQ to try and clarify things:

1)  I want to use Fedora 25 on a laptop with hybrid graphics, will this work?

Yes Fedora 25 supports hybrid graphics out of the box using the opensource drivers included with Fedora. A lot of work has been done to make this as smooth as possible. If you encounter any problems with hybrid graphics under Fedora 25 using the default opensource drivers, please file a bug in bugzilla and put me in the Cc.

2) I want to use the NVidia driver with Fedora 25, I heard it would be available in gnome-software?

It is our intend to make the NVidia driver available in gnome-software (for users who have 3th party sources enabled), but this is not ready yet, I hope to announce some progress on this on this blog soon. see below for a progress report on this.

3) I've an NVidia GPU which driver is better for me?

If you want maximum performance for e.g. gaming, you will likely want the NVidia driver. But be aware that on Optimus laptops using the NVidia driver will result in much higher power consumption / shorter battery life, as all rendering then is done on the NVidia GPU, which means that it cannot be powered down while your doing light work.

If your workload does not need maximum 3D rendering performance your likely better of with the default opensource drivers. On Optimus laptops these offer much better batery life and the opensource drivers do not have the risk of breaking when upgrading your kernel, or upgrading to the next Fedora release.

4) I want to have good battery life, but I also want to play the occasional game with good performance?

As part of the work on making it easy to use the NVidia driver with Fedora, I'm also planning to add a utility which will allow you to easily switch between nouveau and the NVidia driver. Note this will require a reboot each time you switch.

5) What is the status of making the NVidia driver available for easy installation in Fedora 25?

This biggest issue with the Nvidia driver is that it will not work out of the box on optimus enabled laptops, installing it on such a laptop will typically result in the laptop booting to a black screen, which is NOT the user experience we want to offer.

I've just finished a set of patches for the xserver, which will allow the NVidia driver rpm to install a xorg.conf snippet which will make the xorg autoconfigure code automatically set things up the right way for the nvidia driver on optimus enabled laptops.

Depending on the upstream review of these patches I will prepare an updated xserver package with these patches for Fedora 25 soon. Once that is in place, the rpms can be updated with the xorg.conf snippet.

When that is done, there still are some other issues to tackle:

  • Mesa in F25 is not yet glvnd dispatch enabled, which means that the rpms need to play ldconfig path tricks, which means that if the rpms get installed on a system with an unsupported GPU, and Xorg falls back to the open-source driver things go boom because apps end up loading the wrong

  • We want to have some mechanism in place to automatically load the nouveau kernel-module before starting gdm if the nvidia kernel module did not load for some reason (e.g. it failed to compile against a new kernel)

  • The rpms currently use dkms or akmod, building the nvidia kernel module from source on your system, we want to switch things over to having pre-built kmods available

Note not all of these are necessarily blockers for adding the Nvidia driver
to gnome-software.

6) I want to try out the nvidia driver now, is that possible ?

First of all, if you've an optimus enabled laptop, please do not do this (yet), we should have a solution ready for you in a couple of weeks.

If you have a system which is only using a *single* nvidia GPU, then you can install the nvidia driver using the following commands:

  sudo dnf update 'kernel*'
  sudo dnf config-manager --add-repo=
  sudo dnf install nvidia-settings kernel-devel dkms-nvidia vulkan.i686 nvidia-driver-libs.i686

Then reboot and you should be running the nvidia driver, to get back to the opensource driver do:

  sudo dnf remove nvidia-driver

Switchable / Hybrid Graphics support in Fedora 25

Recently I've been working on improving hybrid graphics support for the upcoming Fedora 25 release. Although Fedora 25 Workstation will use Wayland by default for its GNOME 3 desktop, my work has been on hybrid gfx support under X11 (Xorg) as GNOME 3 on Wayland does not yet support hybrid gfx,

So no Wayland, still there are a lot of noticable hybrid gfx support and users of laptops with hybrid gfx using the open-source drivers should have a much smoother userexperience then before. Here is an (incomplete) list of generic improvements:

  • Fix the discrete GPU not suspending after using an external monitor, halving laptop battery life

  • xrandr --listproviders no longer shows 3 devices instead of 2 on laptops with 2 GPUs

  • Hardware cursor support when both GPUs have active video outputs, previously X would fallback to software cursor rendering in this case which would typically lead to a flickering, or entirely invisible cursor at the top of the screen

Besides this a lot of work has been done on fixing hybrid gfx issues in the modesetting driver, this is important since with Fedora we use the modesetting driver on Skylake and newer Intel integrated gfx as well as on Maxwell and newer Nvidia discrete GPUs, the following issues have been fixed in the modesetting driver (and thus on laptops with a Skylake CPU and/or a Maxwell or newer GPU):

  • Hide HW cursor on init, this fixes 2 cursors showing on some setups

  • Make the modesetting driver support DRI_PRIME=1 render offloading when the secondary GPU is using the modesetting driver

  • Fix misrendering (tiled vs linear) when using DRI_PRIME=1 render offloading and the primary GPU is using the modesetting driver

  • Fix GL apps running at 1 fps when shown on a video-output of the secondary GPU and the primary GPU is using the modesetting driver

  • Fix secondary GPU video output partial screen updates (part of the screen showing a previous frame) when the discrete GPU is the secondary GPU and the primary GPU is using the modesetting driver

  • Fix secondary GPU video output updates lagging (or sometimes the last frame simply not being shown at all because no further rendering is happening) when the discrete GPU is the secondary GPU and the primary GPU is using the modesetting driver

Note coming Thursday (November 3th) we're having a Fedora Better Switchable Graphics Test Day, if you have a laptop with hybrid gfx please join us to help further improving hybrid gfx support.

Fixing accelerometer calibration on some rockchip tablets

So I've a RK3188 tablet which accelerometer calibration was completely off. I've spend quite some time figuring out how to fix this so I wanted to share the fix. Note this will only work on some tablets. First lets see if this fix will work for your tablet, from an adb shell do:

cat /proc/acc_info

If that file exists it will contain something like this:

root@rk31board:/ # cat /proc/acc_info                                        
offset:8 0 -4

If it does not exist, the this fix will not work for you. If the numbers after offset are all close to 0 like above, then likely you do not need this fix, but you can still try it.

So rockchip tablets with this particular file store accelerometer calibration data in something which rockchip calls the "sys sector" of nand, if you look in dmesg you will see "rknand_sys_storage_ioctl" messages there. The problem with this approach is that the "sys sector" data survives a factory reset so once the calibration data is off, it stays off, unless we manually force a recalibrate.

Note the next steps need root, make sure that the tablet is flat on a level service, and that it is not sleeping
(otherwise it will not calibrate until you wake it up, registering the powerbutton press during the calibrate)
then do:

echo 1 > /proc/acc_cal

Now run "dmesg | grep acc", you should see something like this:

<4>[ 1497.846716] acc calibrating 1
<4>[ 1497.875330] acc new offset 8 0 0

If you do congrats, you've successfully recalibrated your tablet.