Created attachment 87851 [details] dmesg log (kernel 3.6.8) Every time I boot-up my notebook's display stays black. Since most of the time I'm using an external display I found out that the backlight brightness in GNOME settings is set to zero – I can temporarily solve the issue by increasing the screen brightness but next time I boot this setting is lost, screen brightness is set back to zero again. Using the kernel boot parameter i915.invert_brightness=1 works fine as workaround. When I looked into /sys/class/backlight/acpi_video0/brightness to confirm that it's set to zero I realized that I have two entries in backlight: - 'acpi_video0' (with brightness set to 0, actual_brightness set to 0) and - 'intel_backlight' (with brightness set to 4882, actual_brightness set to 0). When I increase screen brightness to 100% in GNOME settings, the values change to: - 'acpi_video0' brightness & actual_brightness 10, - 'intel_backlight' brightness & actual_brightness 4882. Next time I boot, ACPI display backlight brightness is set to 0 again. I'm affected by this bug since kernel v3.6, before that I was affected by Bug #46481. My notebook is a HP Folio 13-200, I'll attach a dmesg-log and the output of acpidump.
Created attachment 87861 [details] acpidump output
what if you build in video driver and boot with kernel parameter "video.use_bios_initial_backlight=0"?
I tried to build-in the video driver by changing two settings (CONFIG_VIDEO_OUTPUT_CONTROL and CONFIG_ACPI_VIDEO) in the kernel configuration: both from 'm' to 'y' – I hope that's what you suggested. When I boot this kernel with the parameter video.use_bios_initial_backlight=0 my display's backlight brightness is set to 100% at every boot-up (even if I set display backlight brightness to 50% before): - 'acpi_video0': brightness = 10, actual_brightness = 10 - 'intel_backlight' brightness = 4882, actual_brightness = 4882 I realized that I don't even know which behavior to expect exactly. Is it normal that backlight brightness is set to 100%? Sorry, I just don't know – I never cared about this too much before the brightness was set to zero at every boot-up…
first of all, OS is not responsible to cache the brightness value whn shutdown and restore it back in next boot. the backlight is initialized by BIOS. we can only 1. trust BIOS initialized Backlight, which works on most of the laptops 2. ignore the broken initialized Backlight. like what I told you to do in comment #2. another suggestion is that you can search the BIOS menu and see if there is anything related, but I'd say this is not a software bug and I'll close it. is this okay with you?
I searched the BIOS menu for related options – without any luck… In the meantime I found out that at least two other submodels of the HP Folio 13 ultrabook (1050la [1] and dm3-1008TU [2]) are affected by this or at least a similar bug. If I understand you correctly, this is not an OS issue but a BIOS bug, so all I can hope for is a BIOS update by the vendor. Since then the best thing to do is to use a workaround like the kernel boot parameter video.use_bios_initial_backlight=0 or acpi_backlight=vendor. Is this correct? I just want to be sure because I'd like to help other users of this notebook with this information. Thanks! [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1066211 [2] https://wiki.archlinux.org/index.php/HP_Folio_13#Video
Oh, I just noticed that i915.invert_brightness=1 solved the problem. this means that the i915 driver is already aware of this problem, so please attach the dmidecode of this laptop so that i can generate a quirk for this laptop.
Created attachment 87991 [details] dmidecode (folio 13-2000) I tested i915.invert_brightness=1 successfully with vanilla kernel v3.6.8 and debian kernel v3.6.8-1 now. Debian kernel v3.2.32-1 won't boot completely with this boot parameter.
(In reply to comment #7) > Created an attachment (id=87991) [details] > dmidecode (folio 13-2000) > > I tested i915.invert_brightness=1 successfully with vanilla kernel v3.6.8 and > debian kernel v3.6.8-1 now. > great. please attach the lspci -vvxxx output of your laptops as well. > Debian kernel v3.2.32-1 won't boot completely with this boot parameter. what if you boot without the parameter? this parameter is introduced in 3.5, thus I do not think using it would bring some problem for debian v3.2.32-1.
Created attachment 88021 [details] output of lspci -vvxxx >> Debian kernel v3.2.32-1 won't boot completely with this boot parameter. > what if you boot without the parameter? It depends… when I have my external display connected the display's backlight is on, even though /sys/class/backlight/acpi_video0/brightness is 0. It seems like the values from /sys/class/backlight/intel_backlight/brightness (4882) are taken into account here. However, when I close the lid and open it again, display backlight stays off and also intel_backlight brightness is set to zero. When I boot without my external display connected the display's backlight stays off. Since my media keys to control backlight brightness aren't working I can't do anything else without connecting an external display. > this parameter is introduced in 3.5, thus I do not think using it would bring > some problem for debian v3.2.32-1. That's strange. I'm sure it does *something* because I can reproduce the problem with this boot parameter – everytime I use it with v3.2.32-1 the kernel won't boot completely.
please attach the output of "grep . /sys/bus/pci/devices/0000\:00\:02.0/*".
Created attachment 88061 [details] Patch: HP Folio 13-2000 must invert brightness please apply this patch and boot without any parameter to see if it helps.
Created attachment 88071 [details] output of 'grep . /sys/bus/pci/devices/0000\:00\:02.0/*'
I applied the patch from comment #11 and the display backlight is switched on now at boot time. When I said I tested i915.invert_brightness=1 *successfully* with vanilla kernel v3.6.8 and debian kernel v3.6.8-1 in comment #7 I ment nothing more but that display backlight was switched on too. However, in both cases (with the boot parameter and with the applied patch) the display backlight brightness control in GNOME for example is inverted. I don't know if this is the expected behavior, so I just wanted to mention it.
Okay, I see. the backlight is actually not inverted for your laptop. But i915.invert_brightness=1 happens to fix the problem because this "invert_brightness" makes the i915 driver to turn on the backlight when BIOS told it to dim the screen, right?
Yes, exactly. With the patch from comment #11 applied (or the boot parameter i915.invert_brightness=1) the actual display backlight brightness is at 100%, but the values I get are: 1. /sys/class/backlight/acpi_video0/brightness = 0 2. /sys/class/backlight/acpi_video0/actual_brightness = 0 3. /sys/class/backlight/intel_backlight/brightness = 0 4. /sys/class/backlight/intel_backlight/actual_brightness = 0 The settings in GNOME settings manager correspond to these values. When I set the brightness to 20% in GNOME settings manager I get the following values: 1. = 2, 2. = 2, 3. = 0, 4. = 976. I presume that value 3. = 0 because the brightness is controlled by the ACPI video driver, not the vendor driver (I'm no developer, I don't know what's really going on – I'm just guessing). To me as a user, the kernel boot parameters video.use_bios_initial_backlight=0 and acpi_backlight=vendor make more sense. However, I wouldn't know if it's better to tell the ACPI backlight driver not to use the BIOS initial setting or to let the vendor specific backlight driver take over.
Created attachment 88121 [details] quirks for ignoring BIOS initial backlight please revert that patch and try this one without any kernel parameters.
I applied the patch from comment #16 on top of kernel v3.6.8 – and display backlight brightness now works as expected (with just one exception we already discussed in comment #3 and comment #4: display's backlight brightness is set to 100% at every boot-up).
Great. I'll close this bug. re: display's backlight brightness is set to 100% at every boot-up this is the problem we can not solve. :(
Thanks!!
(In reply to comment #18) > Great. I'll close this bug. I don't see the patch in linux-next or acpi-next. Was this fixed some other way there? When applying a fix, please include "Cc: stable@vger.kernel.org" in the description so this can be fixed in older kernels, too. Many thanks, Jonathan
Reopening.
A patch referencing this bug report has been merged in Linux v3.8-rc1: commit 129ff8f8d58297b04f47b5d6fad81aa2d08404e1 Author: Zhang Rui <rui.zhang@intel.com> Date: Tue Dec 4 23:30:19 2012 +0100 ACPI / video: ignore BIOS initial backlight value for HP Folio 13-2000
I've recently seen a lot of such problems and came up with a patch: commit 2c62333a408f5badd2d2ffd7177f95deeccc5ca4 Author: Aaron Lu <aaron.lu@intel.com> Date: Wed Nov 6 09:07:10 2013 +0800 ACPI / video: Quirk initial backlight level 0 It is now in Rafael's linux-next branch: http://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git Possible to give it a test? If confirmed, we can save an entry in the DMI table, thanks.
For easy testing, I've prepared a branch for you: https://github.com/aaronlu/linux acpi_video_dmi It is based on Rafael's linux-next branch(thus it already has the above mentioned fix patch), with only one patch on top: Remove the affected system from the DMI table to test if the above mentioned fix patch can work for it.
I tested your patch today and it works fine for me (HP Folio 13-2000): backlight brightness is set to 100% at every boot-up.
Thanks Stefan! The maintainer has merged it into his tree: commit 545ef368e08fda654b6e63ce522c66339aa29156 Author: Aaron Lu <aaron.lu@intel.com> Date: Fri Nov 15 14:39:12 2013 +0800 ACPI / video: clean up DMI table for initial black screen problem Thanks again for the test.