# Cannot dim display on laptop anymore

## Lebkoungcity

Hello,

I have a trouble with adjusting the brightness of the display on my ThinkPad R40. Since updating the kernel last August (I think it was from 3.18.12 to 4.0.5 - both being gentoo-sources) I cannot dim the backlight anymore. Before that (almost) everything worked just fine. There is this threat: https://forums.gentoo.org/viewtopic-t-1020052-highlight-brightness+adjustment+longer+kernel+upgrade.html?sid=1236c343d3a6f8dc71cfd6308b50c11a but that covers not exactly my problem and furthermore there never was a real solution in the sense that anyone knew what was the root-cause of the problem.

It's kind of weird because one can switch the brightness to it's full level but one can't dim it back again. The only way to achieve this is to give the command that it should be dimmed and then reboot the machine or switch it to hibernation and recover it from there. (Suspend to RAM results in a blank/black display - but this isn't a problem for me and it was always the case since I got the machine and installed gentoo.)

xbacklight never worked it always (since I have the machine) spit out:

```
No outputs have backlight property
```

Changing the settings in the files in "/sys/class/backlight/thinkpad_screen/" e.g. in "brightness" work(ed) - also the usage of the function keys on the ThinkPad's keyboard (pressing them changes the settings in "/sys/class/backlight/thinkpad_screen/brightness"). BUT: Only in the way mentioned before to get a brighter display instantly and a dimmer display only after reboot/hibernation.

I already searched the web but i didn't find something I found related (most of my search results were of the kind that one should just fiddle around with xbacklight or try to change the values in the files in "/sys/class/backlight/thinkpad_screen/" or something like that which I already tried and failed with...)

For me it is not that *big* issue but from time to time it annoys me  :Wink: 

Thanks in advance!

Andy

Some info on the system:

```
uname --all

Linux pulp-fiction 4.1.15-gentoo-r1 #4 SMP Sun Feb 28 18:37:49 CET 2016 i686 Intel(R) Pentium(R) M processor 1400MHz GenuineIntel GNU/Linux
```

```
lspci -v | grep VGA

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV200/M7 [Mobility Radeon 7500] (prog-if 00 [VGA controller])
```

```
cat /etc/portage/make.conf | grep VIDEO_CARDS

VIDEO_CARDS="radeon"
```

```
emerge -pv x11-drivers/xf86-video-ati

[...]

[ebuild   R    ] x11-drivers/xf86-video-ati-7.5.0::gentoo  USE="udev -glamor" 0 KiB
```

I've never set a xorg.conf, from the beginning it worked "out of the box".

----------

## khayyam

Lebkoungcity ...

have you tried passing 'video.use_native_backlight=1', and '=0', as a kernel parameter? What is enabled in the kernel WRT ACPI_VIDEO and BACKLIGHT, and what are you using to 'adjust brightness'? If acpid then what is defined for 'brightnessup' and 'brightnessdown'? The output of the following should answer those questions ...

```
# zgrep -E (ACPI_VIDEO|BACKLIGHT) /proc/config.gz

# acpi_listen # ... and hit 'brightnessup' and 'brightnessdown' a couple of times.

# [[ -f /etc/acpi/default.sh ]] && awk -v RS="esac" '/video/{print}' /etc/acpi/default.sh
```

HTH & best ... khay

----------

## Lebkoungcity

Hi khay,

thanks a lot for your advices!

 *Quote:*   

> have you tried passing 'video.use_native_backlight=1', and '=0', as a kernel parameter?

 

Right now I tried both ('=1' and '0=') but neither worked.

 *Quote:*   

> What is enabled in the kernel WRT ACPI_VIDEO and BACKLIGHT, and what are you using to 'adjust brightness'? If acpid then what is defined for 'brightnessup' and 'brightnessdown'? The output of the following should answer those questions ...

 

OK, had to rebuild my kernel to be able to answer the first one  :Wink: 

```
 ~ # zgrep -E (ACPI_VIDEO|BACKLIGHT) /proc/config.gz
```

but:

```
bash: Syntaxfehler beim unerwarteten Wort `('
```

so I did this instead:

```
 ~ # zgrep -E ACPI_VIDEO /proc/config.gz

CONFIG_ACPI_VIDEO=m

CONFIG_THINKPAD_ACPI_VIDEO=y
```

and:

```
 ~ # zgrep -E BACKLIGHT /proc/config.gz

# CONFIG_FB_BACKLIGHT is not set

CONFIG_BACKLIGHT_LCD_SUPPORT=y

CONFIG_BACKLIGHT_CLASS_DEVICE=m

CONFIG_BACKLIGHT_GENERIC=m

# CONFIG_BACKLIGHT_APPLE is not set

# CONFIG_BACKLIGHT_SAHARA is not set

CONFIG_BACKLIGHT_ADP8860=m

CONFIG_BACKLIGHT_ADP8870=m

CONFIG_BACKLIGHT_LM3639=m

# CONFIG_BACKLIGHT_LV5207LP is not set

# CONFIG_BACKLIGHT_BD6107 is not set

# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
```

The next one:

```
 ~ # acpi_listen

^C
```

(meaning: It just sits there while I hit the function keys - in my case they are 'Fn+Home' and 'Fn+End' - and nothing happens until I press 'Ctrl+C')

And the final one:

```
 ~ # [[ -f /etc/acpi/default.sh ]] && awk -v RS="esac" '/video/{print}' /etc/acpi/default.sh

 ~ # 

```

Does nothing.

So I put those two lines together in a shell-script but after executing it it also just sits there and does nothing until I stop it.

What am I doing wrong? What did you mean I should do? I'm really sorry for being such an ignorant.   :Sad: 

----------

## khayyam

 *Lebkoungcity wrote:*   

> 
> 
> ```
>  ~ # acpi_listen
> 
> ...

 

Lebkoungcity ... that means those keys are not sending 'brightness{up,down}'.

 *Lebkoungcity wrote:*   

> 
> 
> ```
>  ~ # [[ -f /etc/acpi/default.sh ]] && awk -v RS="esac" '/video/{print}' /etc/acpi/default.sh
> ```
> ...

 

Which means that either the file doesn't exist, or there is no 'video' defined ... it would be odd you have 'acpi_listen' but not /etc/acpi/default.sh as they are both part of sys-power/acpid.

 *Lebkoungcity wrote:*   

> What am I doing wrong? What did you mean I should do? I'm really sorry for being such an ignorant.  :(

 

the "[[ -f ]]" is a test condition, if true then the second part of the command (after '&&') is run.

The next thing you should do is make sure 'acpid' is running, if not start it and run 'acpi_listen' again. You should also provide the contents of 'default.sh' (if it exists) and a list of all the files under /sys/class/backlight/

```
# find /sys/class/backlight/thinkpad_screen/ -type f -print
```

best ... khay

----------

## Lebkoungcity

 *khayyam wrote:*   

> Lebkoungcity ... that means those keys are not sending 'brightness{up,down}'.

 

What puzzles me is that e.g. KDE notices it when I press one of these buttons, informs me about this and the display brightens up but never dims. But I would say that I don't understand the mechanics behind that good enough  :Wink: 

 *Quote:*   

> the "[[ -f ]]" is a test condition, if true then the second part of the command (after '&&') is run.

 

Ah, thanks a lot for explaining  :Smile: 

 *Quote:*   

> The next thing you should do is make sure 'acpid' is running, if not start it and run 'acpi_listen' again. You should also provide the contents of 'default.sh' (if it exists) and a list of all the files under /sys/class/backlight/

 

OK here it comes:

```
 ~ # /etc/init.d/acpid status

 * status: started 
```

So acpid is running - but 'acpi_listen' says nothing when I push the buttons...

```
 ~ # find /sys/class/backlight/thinkpad_screen/ -type f -print

/sys/class/backlight/thinkpad_screen/type

/sys/class/backlight/thinkpad_screen/brightness

/sys/class/backlight/thinkpad_screen/power/control

/sys/class/backlight/thinkpad_screen/power/runtime_active_time

/sys/class/backlight/thinkpad_screen/power/autosuspend_delay_ms

/sys/class/backlight/thinkpad_screen/power/runtime_status

/sys/class/backlight/thinkpad_screen/power/runtime_suspended_time

/sys/class/backlight/thinkpad_screen/bl_power

/sys/class/backlight/thinkpad_screen/max_brightness

/sys/class/backlight/thinkpad_screen/uevent

/sys/class/backlight/thinkpad_screen/actual_brightness

```

When I change the content of '/sys/class/backlight/thinkpad_screen/brightness' e.g. like this

```
 ~ # echo 5 > /sys/class/backlight/thinkpad_screen/brightness
```

everything is the same like when I press the buttons: The brightness goes up (if there is still room to go up) - but never down (when I 'echo' a lower number into the file) - and KDE informs me.

Here's the content of '/etc/acpi/default.sh':

```
 ~ # cat /etc/acpi/default.sh 

#!/bin/sh

# /etc/acpi/default.sh

# Default acpi script that takes an entry for all actions

set $*

group=${1%%/*}

action=${1#*/}

device=$2

id=$3

value=$4

log_unhandled() {

        logger "ACPI event unhandled: $*"

}

case "$group" in

        button)

                case "$action" in

                        power)

                                /etc/acpi/actions/powerbtn.sh

                                ;;

                        # if your laptop doesnt turn on/off the display via hardware

                        # switch and instead just generates an acpi event, you can force

                        # X to turn off the display via dpms.  note you will have to run

                        # 'xhost +local:0' so root can access the X DISPLAY.

                        #lid)

                        #       xset dpms force off

                        #       ;;

                        *)      log_unhandled $* ;;

                esac

                ;;

        ac_adapter)

                case "$value" in

                        # Add code here to handle when the system is unplugged

                        # (maybe change cpu scaling to powersave mode).  For

                        # multicore systems, make sure you set powersave mode

                        # for each core!

                        #*0)

                        #       cpufreq-set -g powersave

                        #       ;;

                        # Add code here to handle when the system is plugged in

                        # (maybe change cpu scaling to performance mode).  For

                        # multicore systems, make sure you set performance mode

                        # for each core!

                        #*1)

                        #       cpufreq-set -g performance

                        #       ;;

                        *)      log_unhandled $* ;;

                esac

                ;;

        *)      log_unhandled $* ;;

esac
```

I never touched it, which goes for the other files - until the function to dim the display stopped to work and I started to investigate and tried out some things...

----------

## khayyam

Lebkoungcity ... the fact that 'echo > */brightness' has no effect is a little strange, I'm not sure what the issue might be in that regard, nor why acpi_listen doesn't report anything on keypress. I suspect the following won't change anything but these are the changes/files needed for acpid:

```
#!/bin/sh

backlight_sys_dir="/sys/class/backlight/thinkpad_screen"

read -r max_brightness < "${backlight_sys_dir}/max_brightness"

read -r curr_brightness < "${backlight_sys_dir}/brightness"

case "$1" in

      up) increment="+ 10" ;;

    down) increment="- 10" ;;

       *) exit 1 ;;

esac 

new_brightness=$(($curr_brightness $increment))

if $((new_brightness < 1)) || $((new_brightness > $max_brightness)); then

    exit 1

else

    echo "$new_brightness" > ${backlight_sys_dir}/brightness 

fi
```

```
case "$group" in

   button)

[...]

   video)

      case "$action" in 

         brightnessup)

            /etc/acpi/actions/backlight.sh up

            ;;

         brightnessdown) 

            /etc/acpi/actions/backlight.sh down

            ;;

         *)

            log_unhandled $*

            ;;

      esac

      ;;
```

As for the problem, does disabling/blacklisting CONFIG_BACKLIGHT_GENERIC make any difference? Also, you're building all these as modules, what modules get loaded?

best ... khay

----------

## Lebkoungcity

Sorry for the delay but I needed some time to experiment a little but unfortunately you are right with:

 *Quote:*   

> I suspect the following won't change anything but these are the changes/files needed for acpid"

 

I didn't change anything...

 *Quote:*   

> As for the problem, does disabling/blacklisting CONFIG_BACKLIGHT_GENERIC make any difference? Also, you're building all these as modules, what modules get loaded?

 

To investigate the point with the modules I built several kernels with different settings and tried to find out how they depend on each other and which are being actually loaded. I ended on a setting in which I completely left all the modules in this section blank except for 'Lowlevel Backlight controls' because there's a dependency for it (e.g. 'THINKPAD_ACPI [=m]'):

```
--- Backlight & LCD device support                                           │ │  

  │ │      < >   Lowlevel LCD controls                                                  │ │  

  │ │      {M}   Lowlevel Backlight controls                                            │ │  

  │ │      < >     Generic (aka Sharp Corgi) Backlight Driver                           │ │  

  │ │      < >     Apple Backlight Driver                                               │ │  

  │ │      < >     Tabletkiosk Sahara Touch-iT Backlight Driver                         │ │  

  │ │      < >     Backlight Driver for ADP8860/ADP8861/ADP8863 using WLED              │ │  

  │ │      < >     Backlight Driver for ADP8870 using WLED                              │ │  

  │ │      < >     Backlight Driver for LM3639                                          │ │  

  │ │      < >     Sanyo LV5207LP Backlight                                             │ │  

  │ │      < >     Rohm BD6107 Backlight
```

That result's in:

```
 ~ # lsmod | grep backlight

backlight               4076  3 video,thinkpad_acpi,radeon
```

If there wouldn't have been a time when it worked it wouldn't be so annoying for me...

I think the next thing I might try is to boot some live-cd which provides a working backlight-dim-function on this machine and try to figure out how it's doing it.

Anyway, thanks a lot for all your time and work khay!

----------

## khayyam

 *Lebkoungcity wrote:*   

>  *khayyam wrote:*   I suspect the following won't change anything but these are the changes/files needed for acpid" 
> 
> I didn't change anything...

 

Lebkoungcity ... right, because the issue is elsewhere, when you run acpi_listen nothing is reported on keypress, so the contents of default.sh is never triggered. None the less, keep those changes/additions as at some point the actual issue may be resolved.  

 *Lebkoungcity wrote:*   

> If there wouldn't have been a time when it worked it wouldn't be so annoying for me... I think the next thing I might try is to boot some live-cd which provides a working backlight-dim-function on this machine and try to figure out how it's doing it.

 

You don't have that working kernel, or .config? If you do then perhaps /proc/config.gz or .config if diff'ed against the non-working kernel will provide some clue. Also, how did you create the current .config? If moving to a major release then running 'make oldconfig' is probably not a good idea. 

 *Lebkoungcity wrote:*   

> Anyway, thanks a lot for all your time and work khay!

 

You're welcome. If you need any further assistance just bump.

best ... khay

----------

## Roman_Gruber

Backlight support is broken since i ahve my laptop and i even supplied kenrel devs with a big list of data to bug wrangle it

output of my i3wm config which was written by myself and adapted.

```
grep xrandr .i3/config

bindsym $mod+l exec "xrandr --output LVDS-0 --set Backlight 1; xscreensaver-command --lock"

#xrandr --output LVDS-0 --set Backlight 75

bindsym $mod+F1 exec "xrandr --output LVDS-0 --set Backlight 1"

bindsym $mod+F2 exec "xrandr --output LVDS-0 --set Backlight 10"

bindsym $mod+F3 exec "xrandr --output LVDS-0 --set Backlight 20"

bindsym $mod+F4 exec "xrandr --output LVDS-0 --set Backlight 30"

bindsym $mod+F5 exec "xrandr --output LVDS-0 --set Backlight 40"

bindsym $mod+F6 exec "xrandr --output LVDS-0 --set Backlight 50"

bindsym $mod+F7 exec "xrandr --output LVDS-0 --set Backlight 60"

bindsym $mod+F8 exec "xrandr --output LVDS-0 --set Backlight 70"

bindsym $mod+F9 exec "xrandr --output LVDS-0 --set Backlight 80"

bindsym $mod+F10 exec "xrandr --output LVDS-0 --set Backlight 85"

bindsym $mod+F11 exec "xrandr --output LVDS-0 --set Backlight 90"

bindsym $mod+F12 exec "xrandr --output LVDS-0 --set Backlight 100"

```

This should work on any laptop afaik

xrandr --output LVDS-0 --set Backlight 100

you need to check which device your screen is connected to, mine is lvds-0, and the value is afaik 1 till 100. (see i as percentage)

I have searched kernel.org for many bugs and this is a common issue with linux and these days uefi ASUS bios. I assume other brands are the same maybe.

----------

## Lebkoungcity

khay, maybe I have some new input  :Wink: 

 *Quote:*   

> You don't have that working kernel, or .config? If you do then perhaps /proc/config.gz or .config if diff'ed against the non-working kernel will provide some clue. Also, how did you create the current .config? If moving to a major release then running 'make oldconfig' is probably not a good idea. 

 

Yes, I didn't have the working .config from last August anymore but I thought I couldn't loose anything if I'd tried something 'new'. I emerged gentoo-sources-3.18.25-r1 and took the .config from the running kernel (gentoo-sources-4.1.15-r1) and run 'make oldconfig' hoping that would create a valid .config for the 3.18.25-r1. Afterwards I built it, copied it to /boot, edited grub.conf (still using the legacy-branch) and rebooted.

And what should I say? Everything works, including dimming of the display - even without your changes/additions and the mentioned kernel parameters.

Then I took gentoo-sources-4.1.16 and tried it with the .config from 3.18.25-r1 ('make oldconfig'), But the resulting kernel behaves just like the gentoo-sources-4.1.15-r1 from the beginning of this thread...

I took the both .configs and diff'ed them but I can't see anything that was obvious to me. I put them here:

.config of gentoo-sources-3.18.25-r1:

https://bpaste.net/raw/d5402e300701

.config of gentoo-sources-4.1.16:

https://bpaste.net/raw/e6f02bb511cf

tw04l124, thank you for your reply!

On my machine it gives me:

```
 ~ # xrandr --output LVDS --set Backlight 100

X Error of failed request:  BadName (named color or font does not exist)

  Major opcode of failed request:  139 (RANDR)

  Minor opcode of failed request:  11 (RRQueryOutputProperty)

  Serial number of failed request:  29

  Current serial number in output stream:  29
```

My machine is an old IBM ThinkPad R40 (I think it's from 2004) with a Intel Pentium M processor 1400MHz, Mobility Radeon 7500 (RV200/M7) graphics and a old fashioned BIOS. So maybe my problem does not have the same root-cause as yours?

----------

## Hieronymus Bosch

Try x11-apps/xbacklight

----------

## Lebkoungcity

Hola Hieronymus Bosch,

 *Quote:*   

> Try x11-apps/xbacklight

 

It's already on my machine:

```
 ~ # emerge -pv x11-apps/xbacklight

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] x11-apps/xbacklight-1.2.1-r1::gentoo  0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB
```

 :Wink: 

----------

## Hieronymus Bosch

Ok, even with xbacklight you can't dim your screen?

----------

## Lebkoungcity

 *Hieronymus Bosch wrote:*   

> Ok, even with xbacklight you can't dim your screen?

 

No, it's always been like I've written in my initial post:

 *Quote:*   

> xbacklight never worked it always (since I have the machine) spit out:
> 
> ```
> No outputs have backlight property
> ```
> ...

 

----------

## khayyam

 *khayyam wrote:*   

> You don't have that working kernel, or .config? If you do then perhaps /proc/config.gz or .config if diff'ed against the non-working kernel will provide some clue. Also, how did you create the current .config? If moving to a major release then running 'make oldconfig' is probably not a good idea. 

 

 *Lebkoungcity wrote:*   

> khay, maybe I have some new input ;). Yes, I didn't have the working .config from last August anymore but I thought I couldn't loose anything if I'd tried something 'new'. I emerged gentoo-sources-3.18.25-r1 and took the .config from the running kernel (gentoo-sources-4.1.15-r1) and run 'make oldconfig' hoping that would create a valid .config for the 3.18.25-r1. Afterwards I built it, copied it to /boot, edited grub.conf (still using the legacy-branch) and rebooted. And what should I say? Everything works, including dimming of the display - even without your changes/additions and the mentioned kernel parameters.

 

Lebkoungcity ... all of which suggests the issue is not configuration but the kernel driver. You could do a 'git bisect' and track down the commit that caused it to stop working ... and then report it to kernel devs.

best ... khay

----------

## Lebkoungcity

 *khayyam wrote:*   

> Lebkoungcity ... all of which suggests the issue is not configuration but the kernel driver. You could do a 'git bisect' and track down the commit that caused it to stop working ... and then report it to kernel devs.

 

OK, I've never done this but I think I should be able to handle it  :Wink:  It will only take some time to build all those kernel on my little fellow  :Very Happy: 

Thank you very much! Without your help I wouldn't have known what I could do with this issue  :Smile: 

----------

## khayyam

 *Lebkoungcity wrote:*   

>  *khayyam wrote:*   Lebkoungcity ... all of which suggests the issue is not configuration but the kernel driver. You could do a 'git bisect' and track down the commit that caused it to stop working ... and then report it to kernel devs. 
> 
> OK, I've never done this but I think I should be able to handle it ;) It will only take some time to build all those kernel on my little fellow :D

 

Lebkoungcity ... it shouldn't as you're just rebuilding the changes.

 *Lebkoungcity wrote:*   

> Thank you very much! Without your help I wouldn't have known what I could do with this issue :)

 

Again, you're welcome. Let me/us know if the issue gets resolved, or any developments.

best ... khay

----------

## Roman_Gruber

that xrandr thing should work on any box. you need to figure out which display device, how it is named. (xrandr is very verbose, you need to check manpage and see the output)

----------

## khayyam

Lebkoungcity ...

I just noticed the following ... genpatches-4.3-8.base.tar.xz contains a '2700_ThinkPad-30-brightness-control-fix.patch' is this patch contained in the genpatches for =sys-kernel/gentoo-sources-4.1.15-r1? If not you might try and apply, build, and test.

HTH & best ... khay

----------

## Lebkoungcity

 *khayyam wrote:*   

> Lebkoungcity ...
> 
> I just noticed the following ... genpatches-4.3-8.base.tar.xz contains a '2700_ThinkPad-30-brightness-control-fix.patch' is this patch contained in the genpatches for =sys-kernel/gentoo-sources-4.1.15-r1? If not you might try and apply, build, and test.
> 
> HTH & best ... khay

 

Yeah, I've already tried this last August or September or so. But thanks for giving me a note  :Smile: 

So, now I've ran through the bisecting-process and it gave me this:

 *Quote:*   

> 
> 
> 146755923262037fc4c54abc28c04b1103f3cc51 is the first bad commit
> 
> commit 146755923262037fc4c54abc28c04b1103f3cc51
> ...

 

But I'm not really sure if this is a correct result. The date of the patch is a year older than when the problem occurred on my machine. And also I'd like to know if I made a mistake. Is there some kind of way to verify this result? I want to be sure before I open a bug  :Wink: 

----------

## khayyam

 *Lebkoungcity wrote:*   

>  *khayyam wrote:*   I just noticed the following ... genpatches-4.3-8.base.tar.xz contains a '2700_ThinkPad-30-brightness-control-fix.patch' is this patch contained in the genpatches for =sys-kernel/gentoo-sources-4.1.15-r1? If not you might try and apply, build, and test. 
> 
> Yeah, I've already tried this last August or September or so. But thanks for giving me a note :)

 

Lebkoungcity ... ok, no problem.

 *Lebkoungcity wrote:*   

> But I'm not really sure if this is a correct result. The date of the patch is a year older than when the problem occurred on my machine. And also I'd like to know if I made a mistake. Is there some kind of way to verify this result? I want to be sure before I open a bug ;)

 

Other than booting the kernels with and without that specific patch then no. The continuity of application and the issue being visable may be due to some other factor (ie, userland) ... but I'm speculating.

best ... khay

----------

## Lebkoungcity

OK, now I've opened a bug on this topic:

https://bugs.gentoo.org/show_bug.cgi?id=578504

Again, thank you very much!

 :Smile: 

----------

## khayyam

 *Lebkoungcity wrote:*   

> OK, now I've opened a bug on this topic:

 

Lebkoungcity ... that will probably be taken as a kernel bug (non-gentoo related) and so you'll no doubt be asked to report it upstream (LKML).

 *Lebkoungcity wrote:*   

> Again, thank you very much!

 

You're welcome & best ... khay

----------

## Sakaki

 *khayyam wrote:*   

> have you tried passing 'video.use_native_backlight=1', and '=0', as a kernel parameter?

 

Hi Lebkoungcity, I appreciate your issue occurred with a kernel < 4.2, but just FYI, as noted in this RedHat bug report, the "video.use_native_backlight" parameter went away in kernel 4.2.

As suggested there, you might try using one of "acpi_backlight=native", "acpi_backlight=video", "acpi_backlight=vendor" with a >= 4.2 kernel, and see what happens.

FWIW, I have two laptops that require "acpi_backlight=video" for the backlight to work properly, and it was quite a frustrating thing to chase down.

----------

