Saturday, 23 March 2013

Eliminate LED screen flicker with Intel i915





This post contained factual mistakes. It has been revised and published at https://127001.me/post/eliminate-backlight-flicker-with-i915/



Posted by at
Labels: , , , ,

48 comments:

  1. Unknown22 January 2014 at 17:40

    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. edio2 February 2014 at 07:19

      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. Unknown16 March 2014 at 14:53

    This comment has been removed by the author.

    ReplyDelete
  3. Unknown16 March 2014 at 14:54

    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. Unknown20 March 2014 at 19:34

      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. Unknown7 April 2014 at 23:04

      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. Unknown7 April 2014 at 23:44

      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. Unknown11 September 2014 at 19:22

      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. powerslave18 December 2015 at 09:07

      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. Alexandr19 June 2016 at 00:52

      This comment has been removed by the author.

      Delete
    7. Alexandr19 June 2016 at 00:55

      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. Kenny30 July 2014 at 16:20

    Happen to know the registers for Haswell?

    ReplyDelete
    Replies
    1. edio3 August 2014 at 05:20

      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. Paweł7 September 2014 at 02:41

    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. Anonymous3 May 2015 at 08:14

    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. powerslave16 December 2015 at 19:19

    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. edio16 December 2015 at 23:32

      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. powerslave18 December 2015 at 08:39

      This comment has been removed by the author.

      Delete
    3. powerslave18 December 2015 at 08:46

      This comment has been removed by the author.

      Delete
  8. powerslave18 December 2015 at 08:56

    This comment has been removed by the author.

    ReplyDelete
    Replies
    1. edio18 December 2015 at 09:08

      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. powerslave21 December 2015 at 11:57

      This comment has been removed by the author.

      Delete
  9. Unknown29 May 2016 at 03:55

    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. Unknown29 May 2016 at 14:22

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

      Delete
    2. edio1 June 2016 at 00:44

      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. Unknown1 June 2016 at 05:44

      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. edio1 June 2016 at 08:08

      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. Unknown1 June 2016 at 13:04

      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. edio1 June 2016 at 13:41

      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. Unknown1 June 2016 at 17:29

      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. Teesid Gaw24 November 2016 at 01:36

      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. Unknown16 December 2016 at 11:24

      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. edio16 December 2016 at 15:45

      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. Unknown16 December 2016 at 16:01

      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. Unknown31 December 2016 at 06:55

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

      Delete
  10. Alexandr4 October 2016 at 14:35

    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. Unknown30 November 2016 at 17:40

      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. JHM7 November 2017 at 00:26

    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. Mr.B20 February 2018 at 20:08

    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. edio22 February 2018 at 21:19

      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. Unknown6 April 2018 at 05:11

      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. Unknown30 April 2018 at 18:32

    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. edio30 April 2018 at 21:10

      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. Unknown1 July 2018 at 22:34

    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. Bamelive16 August 2018 at 23:14

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

    ReplyDelete
  16. nina.didenko16 December 2018 at 03:27

    Its better to disable this calculator.

    The calculation method varies from chipset to chipset as you can see reading linux intel driver source code.

    So people in most cases write wrong values into register.

    ReplyDelete
  17. Unknown30 March 2019 at 18:29

    kabylake processors use 16 to divide instead of 28,and their base clock frequency is 24, if we use a base clock frequency with your current default of dividing by 128 it gives a terrible result.. you need to add an option to change 128 to 16

    ReplyDelete
  18. Marck Andrew7 May 2019 at 15:08

    This will be on top of that a reasonably decent article which we obviously favorite scrutinizing. Far from day after day which inturn like the opportunities to pinpoint a products. www.gecey.com

    ReplyDelete

Subscribe to: Post Comments (Atom)