Created attachment 892176 [details] Dmesg output This post on the Planet... http://hansdegoede.livejournal.com/13889.html ... requests us to file bugs if we know how to fix laptops with backlight problems. 30 months ago, I filed this bug, which got no response: https://bugzilla.redhat.com/show_bug.cgi?id=767487 Today I updated to Fedora 20, and the same issue and almost the same fix apply. (And FWIW the same issue exists, and the same fix works when trying to boot a GParted or Fedora 18 Live CD). As mentioned in that bug, this is the magic I've added to my grub command line (nothing needed removing, unlike in the Fedora 16 report): acpi_osi="Linux" acpi_backlight=vendor It's also still the case that the screen starts blank, but using the brightness controls on the keyboard (Fn-left arrow or Fn-right arrow) brings it to life. (Without the above additions to the grub command line, they do nothing - the screen is blank at all times). As requested in that blog post, dmesg.log is attached. Here is dmi.log: /sys/class/dmi/id/bios_date:09/23/2010 /sys/class/dmi/id/bios_vendor:Acer /sys/class/dmi/id/bios_version:V1.04 /sys/class/dmi/id/board_asset_tag:Base Board Asset Tag /sys/class/dmi/id/board_name:JE51_MV /sys/class/dmi/id/board_vendor:Acer /sys/class/dmi/id/board_version:V1.04 /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:V1.04 /sys/class/dmi/id/product_name:Aspire 5736Z /sys/class/dmi/id/product_version:V1.04 /sys/class/dmi/id/sys_vendor:Acer
*********** 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 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. 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 experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
The problem still exists, as it has done since December 2011 (https://bugzilla.redhat.com/show_bug.cgi?id=767487).
As requested in https://hansdegoede.livejournal.com/13889.html, here is the output of ls /sys/class/backlight (only from when it is working - I can't see the screen when not working): $ ls -l /sys/class/backlight total 0 lrwxrwxrwx. 1 root root 0 Jun 24 07:59 acer-wmi -> ../../devices/platform/acer-wmi/backlight/acer-wmi lrwxrwxrwx. 1 root root 0 Jun 24 12:36 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight
Hi David, Thanks for the bug report. Can you please try booting with just acpi_backlight=vendor, so without acpi_osi="Linux" and see if things still work then? It is always best to avoid messing with acpi_osi. Regards, Hans
Hi Hans, I've tried that - it is insufficient. David
(In reply to David Anderson from comment #6) > I've tried that - it is insufficient. Thanks for the quick response. If I understand things correctly there are 2 distinct problems: 1) No matter what you do the laptop comes up with a black screen (backlight is turned off), correct ? 2) You need the acpi_osi="Linux" acpi_backlight=vendor kernel commandline options to allow you to control the backlight, so that at-least you can turn it on, correct ? While booted with the 2 kernel cmdline options in place, can you please do: cd /sys/class/backlight/acer-wmi cat max_brightness And let me know the output of the cat command ? There has been a regression in the kernel causing a problem similar to 1) on the Dell Latitude d630 recently which has the same chipset as your laptop. I know you've been having this issue for quite a long time, but the regression was caused by some major backlight changes for intel machines. So perhaps we'll get lucky and the fix for it also fixes problem 1). Can you please do a "yum upate kernel*" this should give you kernel 3.14.8-200.fc20, note 3.14.7-200.fc20 or anything newer is fine. Can you then please try booting without any kernel commandline options at all and see what happens ? One other thing I would like to know is if the intel_backlight interface works, an you do (as root:) cd /sys/class/backlight/intel_backlight cat max_brightness And then: echo ### > brightness Where ### is half of max_brightness, and then again with the full max_brightness, and see if you can control the backlight properly that way? One last question, if necessary can you setup ssh so that you can ssh into the machine when the screen is black, or plug in an external monitor to help debug things somewhat more?
One last request, can you try booting with the following on the kernel cmdline: acpi_backlight=vendor modprobe.blacklist=acer-wmi After this you should only have intel_backlight in /sys/class/backlight , and maybe it will fix the initial black backlight issue.
While riding my bike I had another idea. Instead of doing a yum update to get a newer 3.14, can you download the kernel for your arch (i686 or x86_64) here: http://koji.fedoraproject.org/koji/taskinfo?taskID=7066918 And then install it with "sudo rpm -ivh kernel...rpm". And boot into it with only acpi_backlight=vendor on the kernel commandline ? This build contains a fix which I hope will fix you needing acpi_osi to get the backlight hotkeys to work. Thanks, Hans
Thanks very much! I am on 3.14.8-200.fc20.x86_64, and something has definitely changed - when I work off battery and then add AC, the screen goes to maximum brightness. Until this kernel, for the last 3 years it used to do the opposite: go to zero brightness. There were other indications that the brightness was reversed somewhere - on battery, instead of blanking the screen used to go to maximum brightness when idle. So I assumed that got fixed too. Anyway - I'll get the rest of the data when I've got a spare moment this week hopefully. Manically busy right now!
Hi, I can confirm that this now boots normally without either kernel command line option or other manual options being needed, since 3.14.8. lsmod shows that the acer_wmi is being loaded. Thank you! David
*********** 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 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. 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 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.