Saturday, 23 March 2013

Eliminate LED screen flicker with Intel i915

Step-by-step solution

Disclaimer
Actions described here may cause damage to your hardware. Do at your own risk.
  1. Install Intel GPU tools
  2. Read reference clock value with command
    # intel_reg_read 0xC6204
    and put the value in the box below
  3. Type desired PWM frequency in the box below
    Hz
  4. Click
  5. In your terminal execute
    # intel_reg_write 0xC8254 0x7a107a1
Finally, to make things permanent, run this command on system startup. I use systemd so here is what I have
pwmfrequency@.service
[Unit]
Description=LED PWM frequency 

[Service]
Type=oneshot
ExecStart=/usr/bin/intel_reg_write 0xc8254 %I

[Install]
WantedBy=graphical.target
Enable service on startup
# systemctl enable pwmfrequency@0x7a107a1

Background

PWM modulation frequency of LED backlight in laptops with Intel i915 GPU may be controlled by GPU itself (sometimes it is not the case though). So adjustment of PWM modulation frequency becomes possible by write to special HW register.

In i915 (at least, in Sandy Bridge) PWM modulation frequency is controlled by value of the 4 upper bytes of the register 0xC8254. According to the Intel HD Graphics programmer's reference manual the value of these 4 bytes
represents the period of the PWM stream in PCH display raw clocks multiplied by 128.
PCH display raw clock frequency is held in another register 0xC6204 and by default it equals to 125 MHz (0x7D).
Resulting PWM modulation frequency can be calculated by formula
fPWM = regC6204 / 128 / regC8254{7:4}
For example, for reference clock frequency equal to 125 MHz and value of the regC8254 equal to 0x12281228 (default on my Thinkpad X220) PWM modulation frequency will be equal to approximately 200 Hz.

See also

45 comments:

  1. This is great. I find I have to push the frequency all the way up to 2000Hz on my Thinkpad X1 Carbon in order to not notice any flicker (using the 'pencil test'). The default frequency is around 220Hz.

    Does anyone have a view on whether this might be dangerous for the screen, reducing it's lifespan?

    What frequencies have people managed to achieve for extended periods of time without any adverse effects?

    ReplyDelete
    Replies
    1. Hi.
      I believe, this may be dangerous for the screen. Don't know for sure of course.
      I tried 1200 Hz for my X220 — worked well, but there was a constant high-pitch zoom noise.
      Decided to go with 700 Hz. It is still perfectly noticeable with pencil test, though already doesn't cause any strain to my eyes.

      Delete
  2. This comment has been removed by the author.

    ReplyDelete
  3. Does anybody know what is the limit? I went with 1500 Hz, and it seems really fine. Can I damage my panel with such a high frequency?

    ReplyDelete
    Replies
    1. No idea. But it would great if you could check back in after a couple of months and let us know if you have any problems!

      Delete
    2. I did find this comment that BackLight Control values for intel driver should generally be between 200hz and 1000hz. This is on a website for a company that seems to make/work with boards for embedded devices, so it's not a hard and fast rule for a lapttop PC, but I guess it's an indication:
      http://developer.toradex.com/knowledge-base/backlight-control-%28woodpecker-robin%29

      I also found this link, referring to ATOM CPUs, that describes that an intel processor pin must be router to the display's "PWM-based backlight inverter module". Essentially this is telling me that it's the PWM inverter module that has to be able to cope with the frequency that's being set via the intel driver, and this I'm guessing is likely to be specific to your particular laptop. In an example screenshot here, they set the PWM frequency to 20300! But I don't want to read too much into this, as the document also says the frequency has to be within tolerance for your specific panel.
      http://www.intel.com.au/content/dam/www/public/us/en/documents/white-papers/lvds-dynamic-backlight-brightness-paper.pdf

      Delete
    3. My laptop is the HP EliteBook 9470m, and I have been using it with the PWM freq at 6000Hz for the last week without problems (yet).

      Delete
    4. In the comments on this page: http://xiphmont.livejournal.com/64114.html xiphmont seems to believe raising the frequency is generally safe, and his main conecern was potential noise that could be made by the inverter switching at rates above 500hz (which was mentioned by edio in the comment above).

      Xiphmont seems to enjoy replacing the backlight for his own thinkpad monitors, so he presumably has some expertise in this area :)

      Delete
    5. The way to find this information would perhaps be to find which panel your laptop has, then lookup the datasheet for that panel.

      There is mention of PWM min/typical/max frequencies in the datasheet.

      For the W520 FHD panel (B156HW01 V4), it's 100Hz/200Hz/20kHz. (I could be wrong, check it for yourself)

      Delete
    6. This comment has been removed by the author.

      Delete
    7. I have ASUS n551jm, working with 2000Hz for a month already. Tried to ask ASUS support about the max PWM frequency, but received just a stupid reply irrelevant to the question.

      Delete
  4. Happen to know the registers for Haswell?

    ReplyDelete
    Replies
    1. It should be the same according to https://01.org/linuxgraphics/sites/default/files/documentation/intel-gfx-prm-osrc-hsw-commandreference-registers_0.pdf (see SBMC_PWM_CTL2 on page 809)

      Delete
  5. And what if I use init.d? Could someone enter a startup script for debian please? My eyes get hurt from LED display and I'm not very advanced in this stuff. Beside I'm unable to spend much time with my PC due to obvious reasons. Thanks.

    ReplyDelete
  6. If you're using Wheezy, you need to setup a sid chroot first (it doesn't take as long as it sounds): http://linux.koolsolutions.com/2009/05/15/howto-bootstrapping-debian-linux-system-using-debootstrap/

    The relevant command is:
    debootstrap sid [your-chroot]

    Once you have that, do this:

    for i in /dev /sys /proc; do mount -R $i [your-chroot]$i; done

    and

    chroot [your-chroot]

    then
    apt-get install intel-gpu-tools


    Here's an init.d script (remember to exit the chroot before you install this):

    #!/bin/bash

    mount -o bind /sys/ [your-chroot]/sys/
    chroot [your-chroot] /usr/bin/intel_reg_write 0xC8254 [hex-value]

    ReplyDelete
  7. Does anyone know what effect increasing the frequency has on the battery life?

    I'll check powertop and see if I can figure something out.

    ReplyDelete
    Replies
    1. I haven't noticed any difference in real-case scenarios on my X220. If there's any impact on battery life, it is negligible for me.

      Delete
    2. This comment has been removed by the author.

      Delete
    3. This comment has been removed by the author.

      Delete
  8. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. I'd assume, there is a slight possibility to make some damage to hardware.
      I hear audible noise too which made me worre, so I picked the lowest comfortable frequency.

      Delete
    2. This comment has been removed by the author.

      Delete
  9. Hi. In Fedora 22 when my laptop goes in low battery, it changes the frequency and the screen return to flicker, there is something to prevent this behavior? any ideas where I can change the frequency setted from the system when the battery percentace is low? thanks

    ReplyDelete
    Replies
    1. Update: I noticed that even after I lock the screen the system restore the register value to default

      Delete
    2. I had this issue too.
      To fix it I created udev rule to reapply settings whenever something with display happens

      ````
      KERNEL!="intel_backlight", SUBSYSTEM!="backlight", ACTION!="change", GOTO="backlight_pwm_rules_end"

      TEST=="/tmp/intelpwm.lock", ATTR{brightness}!="0", RUN="/usr/bin/intelpwm", GOTO="backlight_pwm_rules_end"
      ATTR{brightness}=="0", RUN="/usr/bin/touch /tmp/intelpwm.lock"

      LABEL="backlight_pwm_rules_end"
      ````

      See AUR Archlinux package for more details
      https://aur.archlinux.org/packages/intelpwm-udev/

      Delete
    3. I'm sorry, maybe I'm not so practical to udev rule. I checked your AUR package, but I'm not sure I can use it in Fedora (I've found this https://github.com/FZUG/repo/wiki/use-yaourt but it could be not necessary maybe?).
      How can I use your work on my PC? I need to install AUR package or maybe I can use some parts of your code? How can I proceed?

      Is enough if I create the intelpwm command like you did in your package (in /usr/bin/ folder) and after that I copy the 99-intelpwn.rules in /usr/lib/udev/rules.d/ ?

      Usually I directly try, but in this case it could be not so safe, I think. Thanks

      Delete
    4. Gabriele, no need to install AUR on Fedora.

      I'd copy the 99-intelpwm.rule to /etc/udev/rules.d/ (my aur package uses /usr/lib, however by convention /etc should be used if you provide custom configuration manually, it is then easier to locate changes that are not tracked by package manager).

      intelpwm executable can be copied to a location you prefer. Just do not forget to update udev rule correspondingly then.

      When you're done with copying, you'd need to reload udev rules. Simply reboot or in terminal do

      ````
      sudo udevadm control --reload-rules
      ````

      Hope it helps.

      Delete
    5. It seems to work fine. Thank you very much!
      There's only another little problem I forgot before and (re)noticed now:
      when I execute the intel_reg_write command the brightness goes to the max value. And if I press only once the + o - button it returns to the level it was before. There's a reason for this? Do you know? Thanks again.

      Delete
    6. I can't give a technically precise answer, because I haven't investigated, how duty factor is stored. I guess, some of the registers holds some value, which is dependent on frequency, that's why the brightness changes.

      For me, whenever I set a higher frequency, brightness increases.

      If I have free time, I'll check, if it's possible to fix.

      Delete
    7. I actually don't check if I have that problem too. I will.
      Anyway if you find something interesting that could fix these problems I will very thankful if you could share it here (so maybe I will receive an email notification).

      Thank you very much for your time. Have a nice day

      Delete
    8. Kudos to edio for digging this and sharing it to us all.

      Based on my observation the brightness depends on the 4 least significant hex digits.
      For example if you have an X220 like edio's you can try
      # intel_reg write 0xC8254 0x07a107a1
      # intel_reg write 0xC8254 0x07a1061a
      # intel_reg write 0xC8254 0x07a10493
      # intel_reg write 0xC8254 0x07a1030d
      # intel_reg write 0xC8254 0x07a10186
      and you'll see the screen going from full brightness to about 20% brightness at 500Hz PWM frequency.

      Note that when you set the 4 last hex to something greater than the first 4 hex it just gives you the full brightness. You can try
      # intel_reg write 0xC8254 0x07a10800
      .

      The + o - buttons on the laptop just change the last 4 hex but somehow they are not aware of the new PWM frequency being used and just assumes the last 4 hex should still go up to 0x1157 go give full brightness (for X220 at the default 220MHZ PWM freq).

      Delete
    9. Hey! I'm having trouble to make this change permanent (for example after screen lock) on my x230 running Linux Mint Cinnamon.
      I tried to apply the suggestions given by edio on 1 June 2016 (at 8:08) with adding a udev rule.
      I've copied "99-intelpwm.rules" into "/etc/udev/rules.d/"
      then copied "intelpwm.conf" into "/etc/"
      then copied "intelpwm" into "/usr/bin/"

      and my udev rule 99-intepwm.rules looks like this:

      ''''
      KERNEL!="intel_backlight", SUBSYSTEM!="backlight", ACTION!="change", GOTO="backlight_pwm_rules_end"

      TEST=="/tmp/intelpwm.lock", ATTR{brightness}!="0", RUN="/usr/bin/intelpwm", GOTO="backlight_pwm_rules_end"
      ATTR{brightness}=="0", RUN="/usr/bin/touch /tmp/intelpwm.lock"

      LABEL="backlight_pwm_rules_end"

      ''''

      Does anyone have an idea what I'm missing or doing wrong?
      Or is there something very different when doing this in Linux Mint compared to Arch or Fedora?

      Delete
    10. If that does not work at all:
      1. be sure, you reloaded udev rules (reboot or udevadm control --reload-rules)
      2. do udevadm monitor -p and check if udev events are generated

      If that works just sometimes (as it actually should, because it appeared, that udev events are generated for brightness changes, so the script will work 50% of time), then try the following rule

      ```
      KERNEL!="intel_backlight", SUBSYSTEM!="backlight", ACTION!="change", GOTO="backlight_pwm_rules_end"
      RUN="/usr/bin/intelpwm"
      LABEL="backlight_pwm_rules_end"
      ```

      And modify /usr/bin/intelpwm to

      ```
      #!/usr/bin/env sh
      source /etc/intelpwm.conf
      intel_reg write $REGISTER $PERIOD
      ```

      It will update pwm frequency on any events from the video adapter backlight (brightness changes for example). Not sure if it plays well with dpms though. But I'd start with that, just to be sure, that it works.

      Delete
    11. If it helps: I tested in Fedora 24 the udev rule defined above. Although in Fedora 22 it worked well, here it doesn't work. I used udevadm monitor to check backlight event, but I think the problem is that the file intelpwm.lock is never created (because of the test fails always). I modified the udev rule like you suggested here and it works, but I can see some strange behaviors sometimes. I didn't have time to test it deeply, but if I will find time I will write it here.

      An interesting thing that I noticed based on Teesid Gaw observation is how changing backlight automatically change the register value. So i changed the /usr/bin/intelpwm to manage the problem of backlight going to the max value every time the register is updated with desired pwm frequency value.

      Delete
    12. Thank's a lot edio! This script works perfectly.

      Delete
  10. just a note from my personal experience

    on Windows 10 64bit I'm using this tool to set PWM frequency (2kHz):
    https://github.com/BALEHOK/PWM/blob/master/PWM%20tool.zip

    on Ubuntu I used Redshift tool (http://jonls.dk/redshift) to dim display which saves the screen from flickering (LEDs stay on 100% of the time, so no flickering at all)

    ReplyDelete
    Replies
    1. Hi, can I ask you your redshift configuration? I'm testing it on Fedora 24 but the screen is still flickering (while not applying registers edit). It's less noticeable but actually not solving the problem.

      Delete
  11. Hello. I faced the same problem: which frequency is safe for display? This is my method, dead simple yet very efficient.
    Go to dark room, set minimal brightness, open white picture on screen. This is very important!
    Then use tool and alter frequency in this way: 200-600-200-800-200-1000 and so on. At some level you will notice decrease of brightness. It means that you exceeded max working frequency. So, make step back and set maximum frequency without brightness drop.

    ReplyDelete
  12. Is this any different from changing brightness? I am under the impression that PWM is the ONLY way of modulating brightness, therefore this would be equivalent to raising, lowering brightness.
    Am I correct?
    If I select a high PWM frequency, then changing the brightness has no effect anymore.

    ReplyDelete
    Replies
    1. This post haven't been updated for a while. The issue with brightness is caused by incorrect write to the register described in this post.

      Period has to be written as higher 4-bytes of the register leaving 4-bytes intact. Here's how I do it on my computer

      ```
      #!/usr/bin/env sh
      CONFIG=/etc/intelpwm.conf
      if [ ! -f "$CONFIG" ]; then
      echo "$CONFIG not found"
      exit 1
      fi

      source $CONFIG

      RAW_DATA="$(intel_reg read ${REGISTER})"
      CYCLE="${RAW_DATA:56:4}"

      intel_reg write "${REGISTER}" "0x${PERIOD}${CYCLE}"
      ```

      ```
      REGISTER=0xc8254
      PERIOD=0470
      ```

      Delete
    2. Hi,
      Actually, Mr.B is right. I'm sure I have the same problem.
      Setting high frequency will lead to ...

      1) in case of leaving lower 4 bytes (brightness cycle) intact
      Display blinks and the only way is to reboot. It is because of period becoming lower than brightness cycle that is impossible

      2) in case of setting lower 4 bytes equal to higher bytes
      It works fine. But brightness level is changed to 100% and it is almost unchangeable (in very little range)

      3) in case of setting lower 4 bytes equal to value, calculated according to actual brightness: brightness cycle * {brightness level 0-1.0}
      It also works fine and brightness level is not changed.
      However, there is the same caveat as in 2) - almost unchangeable brightness level

      Why is that?
      There are /sys/class/backlight/intel_backlight/max_brightness parameter that equals to initial higher 4-bytes value. And changing brightness is performed by steps that are calculated based on that value. But after changing frequency to higher value our period drastically decreases.
      E.g.
      Old freq = 200Hz (period = 937, cycle 350, max bright = 937)
      New freq = 2000Hz (period = 94, cycle 35, actual max bright = 94)
      Step of brightness change is 1%. It is ~9 in period measure. It is not changed while intel_gpu write operation.
      In ideal case, I can change brightness under new frequency by step ~1.
      But in our real case, I still change it with step ~9

      I assume that mentioned issue could be resolved by changing /sys/class/backlight/intel_backlight/max_brightness. But I cannot change it even under root account.
      If someone can shed a light if it is changeable per se, it would be helpful

      Hope I explained understandably

      Thank you

      Delete
  13. Hi, after i run intel_reg_read 0xC6204, the output is 0x00000000, is anything wrong there? The cpu is n3060, which is a braswell processor

    ReplyDelete
    Replies
    1. Sorry, I don't have the answer, but I have 2 guesses
      * backlight of your display isn't managed by video adapter (some dedicated controller is used instead)
      * register has changed in braswell

      Documentation is usually freely available on intel's web site, so I'd suggesting looking there for an answer.

      Delete
  14. My new laptop (X1 Carbon 5th Gen) appears to have 2 PWM controllers. Does anyone know how to tune this?

    I still get headaches at 100% brightness, wheras on my old 1st Gen X1 Carbon 100% brightness fixed my headaches.

    I've tried setting the freq for BLC_PWM_PCH_CTL2 down to 16 and the cycle to 1 and I still can't perceive any flicker, so this screen doesn't follow the same rules...


    $ sudo intel_reg dump | grep -i pwm
    BLC_PWM_CPU_CTL2 (0x00048250): 0x80000000 (enable 1, pipe A, blinking 0, granularity 128)
    BLC_PWM_CPU_CTL (0x00048254): 0x04240161 (cycle 353, freq 1060)
    BLC_PWM2_CPU_CTL2 (0x00048350): 0x00000000 (enable 0, pipe A, blinking 0, granularity 128)
    BLC_PWM2_CPU_CTL (0x00048354): 0x00000000 (cycle 0, freq 0)
    BLC_MISC_CTL (0x00048360): 0x00000000 (PWM1-PCH PWM2-CPU)
    BLC_PWM_PCH_CTL1 (0x000c8250): 0x80000000 (enable 1, override 0, inverted polarity 0)
    BLC_PWM_PCH_CTL2 (0x000c8254): 0x04240161 (freq 1060, cycle 353)

    ReplyDelete
  15. Can somebody make a PWM Controller for AMD Graphics? My GPU is Radeon HD 7570M. Please...

    ReplyDelete