Bug 983342

Same behaviour here on a new Acer TravelMate P653-M.
The only workaround is echoing the value in /sys/class/backlight/intel_backlight/brightness as already mentioned.

After adding the kernel parameter acpi_backlight=vendor, it's possible to control the brightness with the Gnome screen applet too (settings>power management).
Hence, the problem seems to be related to an incorrect keycode.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Maybe the problem is solved?
Let me sum up. My Acer Travelmate notebook is similar to the one owned by N. Jackson. It also has an Intel HD4000 integrated card and the maximum brightness value is 976.
After adding the kernel parameters acpi_osi=Linux and acpi_backlight=vendor, I was able to control the brightness via the Gnome screen applet or echoing the value in /sys/class/backlight/intel_backlight/brightness (the last method works without the acpi_backlight=vendor parameter too).
Then I blacklisted the acer_wmi kernel module and now I'm able to change the brightness via the keyboard brightness keys too (Fn-Left and Fn-Right).
The control works perfectly: is very "granular" and the "slider" (a sort of "sun") appears on screen, allowing the bar to move left and right as one might expect.
Now I'm running kernel 3.11.1-200.fc19.x86_64.

Laptop Fujitsu Lifebook E8420 doesn't work too.
The FN-Keys don't change the backlight. The symbol occurs on the screen, but the backlight doesn't change the brightness. In gnome-shell the slider in the upper right menu works fine.

lspci
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

Fedora 20 beta, kernel 3.11.9

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.12.6-200.fc19.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20.

If you experience different issues, please open a new bug report for those.

(In reply to Justin M. Forbes from comment #6)

> Fedora 19 has now been rebased to 3.12.6-200.fc19.  Please test this 
> kernel update (or newer) and let us know if you issue has been 
> resolved or if it is still present with the newer kernel.

No. This latest kernel (3.12.6-200.fc19.x86_64) does not resolve the issue.

I have been using the workaround of appending acpi_osi=Linux to my kernel boot options. With this workaround the keyboard brightness keys work but the onscreen slider is not displayed and after a restart the display is always reset to full brightness.

With kernel 3.12.6-200 the workaround continues to work (to the same limited extent that it worked previously), but the original bug remains: that is if I don't boot with the acpi_osi=Linux option, the behaviour is the same as it was in the original bug report.

I've installed Fedora 20 and the behaviour is the same as described above.
Works with the workaround.

From a naive, superficial viewpoint this bug seems extremely simple: Changing the value in /sys/class/backlight/intel_backlight/brightness changes the display brightness. Changing the values in /sys/class/backlight/acpi_video0/brightness does not change the display brightness. But using the keyboard brightness keys changes the values in the later file rather than the former. Consequently the keyboard brightness keys do not change the display brightness.

I can add that for an Asus UL50VT running on intel graphics, with F20, echoing into /sys/class/backlight/intel_backlight/brightness does change brightness.

[root@host intel_backlight]# cat max_brightness 
2583660
[root@host intel_backlight]# echo "1000000" > brightness 

kernel.x86_64                    3.12.6-300.fc20

Giving the kernel parameter "acpi_backlight=vendor" at boot solved the problem.
This is system (Asus UL50VT) has hybrid graphics and uses bumblebee with Intel / Nvidia. I don't know that contributes to the confusion.

<metoo> on an HP Spectre Envy laptop.  acpi_backlight=vendor makes things work right.  Interestingly, I did *not* have this problem until the F20 upgrade; now it happens even with the F19 3.11 kernel.  So something else has changed in there somewhere...

Same issue occurs on HP EliteBook 8470p running F20 with the 3.12.9 kernel. Adding acpi_backlight=vendor to the kernel parameters fixes the issue though.

uname -r
3.12.9-301.fc20.x86_64

lspci
VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.13.5-100.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Just tried; this bug is still present with kernel-3.13.6-200.fc20.x86_64 on F20.

I'm running Fedora 20 (kernel-3.13.6) and the behaviour is the same as described above.
Works with the workaround.

(In reply to Justin M. Forbes from comment #14)
> Fedora 19 has now been rebased to 3.13.5-100.fc19.  Please test this kernel
> update and let us know if you issue has been resolved or if it is still
> present with the newer kernel.

I am now running with 3.13.7-100.fc19.x86_64 and the bug is still present.

There is no change to the behaviour I described in my initial bug report last July. I'm still using the workaround I reported in Comment #7 (acpi_osi=Linux) and it continues to work in the limited sense that it was working then.

N.

Note that I have tried using the acpi_backlight=vendor workaround and it does not work for me:

Used in combination with acpi_osi=Linux the behaviour is no different from using acpi_osi=Linux alone (the screen brightness changes in response to Fn-Left and Fn-Right, but the system always starts up at full brightness, and the onscreen slider does not appear).

Used alone, acpi_backlight=vendor stops the onscreen slider from appearing but has no effect on the display brightness.

N.

I think this is really an X issue.  The keyboard commands and OSD are controlled by X, and you want X to use the intel_backlight.

On a little asus netbook that I have but don't much use, I had this with 3.13.7 also, but it worked fairly nicely if I added a file to /etc/X11/xorg.conf.d 
containing

    Section "Device"
        Identifier "Intel Graphics"
        Driver "intel"
        Option "Backlight" "intel_backlight"
    EndSection

There was no need for any extra options to kernel command line in grub. 

Does that work for you?

Hi All,

I've been researching backlight issues for the last few days and I think I'm starting to get a handle on them, or at least to some degree.

For the original reporter of this bug with the Acer Aspire V5-171-9620, I expect that using the latest fedora kernel and then adding  "use_native_backlight=1" on the kernel cmdline, and removing any other special kernel parameters should make things work properly.

Also please run:

grep '.*' /sys/class/dmi/id/*_* 2> /dev/null

And copy and paste the output here, then I can add a quirk to the kernel to do this automatically for your laptop.

For the others / for all the me-too-s here. Unless you've the exact same model laptop as the reporter, please file a new bug against the kernel with me in the CC. I'm going to be enforcing a strict one laptop model per bug policy for these brightness bugs otherwise things will become very hard to track.

When you file a new bug please start with trying the "use_native_backlight=1" kernel cmdline option mentioned above (with all other backlight options / customization removed), and add a note to the
bug if hat helps. Also please run:

grep '.*' /sys/class/dmi/id/*_* 2> /dev/null

And add the output of that to the bug report.

Thanks,

Hans

Oops, correction, please try with: "video.use_native_backlight=1" on the kernel cmdline rather then just "use_native_backlight=1".

ACPI / video: Add systems that should favour native backlight interface
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/acpi/blacklist.c?id=0e9f81d

Possible duplicates - Brightness related:

Brightness adjustment FN keys doesn't work
https://bugzilla.redhat.com/show_bug.cgi?id=702352

Brightness/backlight keys (fn+F8, fn+F9) does not work on lenovo T530 out of the box
https://bugzilla.redhat.com/show_bug.cgi?id=947976

Dell brightness keys register multiple times
https://bugzilla.redhat.com/show_bug.cgi?id=986653

unable to adjust monitor brightness with nouveua, Toshiba, and 3.11.0 kernel
https://bugzilla.redhat.com/show_bug.cgi?id=999684

Cannot adjust brightness anymore using Fn keys with F19 x86_64
https://bugzilla.redhat.com/show_bug.cgi?id=1012674

Brightness does not change on Intel graphics (using keys or slider) since about 3.9 kernels
https://bugzilla.redhat.com/show_bug.cgi?id=1025690

Brightness keys stopped working between kernel 3.12.10-300 and 3.13.3-201 on Asus EEE PC
https://bugzilla.redhat.com/show_bug.cgi?id=1067181

T530: Unsupported brightness interface
https://bugzilla.redhat.com/show_bug.cgi?id=1089545

Can't change display brightness on HP EliteBook 8470p
https://bugzilla.redhat.com/show_bug.cgi?id=1093120

(In reply to Hans de Goede from comment #20)
>
> For the original reporter of this bug with the Acer Aspire V5-171-9620, I
> expect that using the latest fedora kernel and then adding 
> "use_native_backlight=1" on the kernel cmdline, and removing any other
> special kernel parameters should make things work properly.

This doesn't make things work properly. But see my response to your Comment #21.

> Also please run:
> 
> grep '.*' /sys/class/dmi/id/*_* 2> /dev/null

/sys/class/dmi/id/bios_date:03/08/2013
/sys/class/dmi/id/bios_vendor:Acer
/sys/class/dmi/id/bios_version:V2.15
/sys/class/dmi/id/board_asset_tag:Type2 - Board Asset Tag
/sys/class/dmi/id/board_name:Mimic             
/sys/class/dmi/id/board_vendor:Acer
/sys/class/dmi/id/board_version:Type2 - Board Version
/sys/class/dmi/id/chassis_asset_tag:        
/sys/class/dmi/id/chassis_type:10
/sys/class/dmi/id/chassis_vendor:Acer
/sys/class/dmi/id/chassis_version:V2.15
/sys/class/dmi/id/product_name:V5-171
/sys/class/dmi/id/product_version:V2.15
/sys/class/dmi/id/sys_vendor:Acer

(In reply to Hans de Goede from comment #21)
>
> Oops, correction, please try with: "video.use_native_backlight=1" on the
> kernel cmdline rather then just "use_native_backlight=1".

Yes! This fixes the problem. With this setting the keyboard brightness keys work _and_ I get the onscreen slider. The granularity is also nice and fine. Thank you.

Not really wanting to be too nitpicky, but it _is_ a little sluggish -- when making a large change in brightness there's a very noticeable lag.

Thank you and best regards,
N.

Hi,

Thanks for the testing. I've written a patch and added it to the Fedora-20 kernel package, where it will get picked up automatically by the next build.

I've also started a kernel (scratch) build with the patch added for testing:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6803021
Note it is currently still building.

Can you please give this build a try, it should work without you needing to specify any kernel cmdline parameters.

Regards,

Hans

(In reply to Hans de Goede from comment #26)
> Hi,
> 
> Thanks for the testing. I've written a patch and added it to the Fedora-20
> kernel package, where it will get picked up automatically by the next build.
> 
> I've also started a kernel (scratch) build with the patch added for testing:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6803021
> Note it is currently still building.
> 
> Can you please give this build a try, it should work without you needing to
> specify any kernel cmdline parameters.
> 
> Regards,
> 
> Hans

Hi Hans,

Just to clarify, I'm still on Fedora 19. Can I run your test kernel without upgrading to Fedora 20, or should I upgrade first?

Thanks.

N.

(In reply to N. Jackson from comment #27)
> 
> Just to clarify, I'm still on Fedora 19. Can I run your test kernel without
> upgrading to Fedora 20, or should I upgrade first?

You should be able to download the i686 or x86_64 rpm (depending on what you're running) and install it with "rpm -ivh kernel...rpm" without problems. Note it is important to use rpm -ivh and not rpm -Uvh so that your current kernel stays installed, that way in case of problems you can always select your old kernel in the bootloader menu.

kernel-3.14.3-200.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kernel-3.14.3-200.fc20

Package kernel-3.14.3-200.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.14.3-200.fc20'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-6122/kernel-3.14.3-200.fc20
then log in and leave karma (feedback).

kernel-3.14.3-200.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to Fedora Update System from comment #30)
> Package kernel-3.14.3-200.fc20:
> * should fix your issue,
> * was pushed to the Fedora 20 testing repository,
> * should be available at your local mirror within two days.
> Update it with:
> # su -c 'yum update --enablerepo=updates-testing kernel-3.14.3-200.fc20'
> as soon as you are able to, then reboot.

I was unable to retrieve this kernel, perhaps because I tried to get it without waiting the stipulated two days or perhaps because I was still on Fedora 19. Subsequently I got busy with other things and didn't get back to this until this weekend; sorry.

Removing my acpi_osi=Linux workaround yesterday revealed that the bug is fixed for me in Fedora 19 with kernel 3.14.27-100.fc19.x86_64. I have the on-screen brightness notification slider thing working correctly with plenty of discrete steps. (It's a little sluggish/laggy but it's perfectly usable now I'm used to it.) Thank you.

Also, after installing Fedora 21 (kernel 3.17.8-300.fc21.x86_64) today, the bug remains fixed. 

Thank you very much.

(In reply to N. Jackson from comment #32)
> Removing my acpi_osi=Linux workaround yesterday revealed that the bug is
> fixed for me in Fedora 19 with kernel 3.14.27-100.fc19.x86_64. I have the
> on-screen brightness notification slider thing working correctly with plenty
> of discrete steps. (It's a little sluggish/laggy but it's perfectly usable
> now I'm used to it.) Thank you.
> 
> Also, after installing Fedora 21 (kernel 3.17.8-300.fc21.x86_64) today, the
> bug remains fixed. 
> 
> Thank you very much.

Great, thanks for re-testing and for the feedback.