Created attachment 65152 [details] The xorg.conf file generated by Xorg -configure (this one allows me to start X) Please see http://www.debianuserforums.org/viewtopic.php?f=55&t=2044 Chipset: Mobile Intel® GL40 Express Chipset Architecture: i686 (32-bit) xserver-xorg-video-intel version: 2:2.19.0-5 Kernel version: 3.2.0-3-686-pae (also tested on 3.2.0-3-486-pae and 3.5+) Distro: Debian GNU/Linux testing (wheezy) Laptop model: Acer Aspire 5736Z-4460 Displays: Integrated display: 15.6" LCD, native resolution 1366 x 768, aspect ratio 16:9, brightness 220 nit 1 x HDMI™ port with HDCP support (not used) 1 x External display (VGA) port (not used) Reproduction steps: Simply boot with KMS enabled and backlight will shut off. Boot with KMS enabled and X will fall back to VESA driver. Occurs 100% of the time. Here is the output of xrandr --verbose: jay@jay-debian:~$ xrandr --verbose xrandr: Failed to get size of gamma for output default Screen 0: minimum 1024 x 768, current 1024 x 768, maximum 1024 x 768 default connected 1024x768+0+0 (0x13a) normal (normal) 0mm x 0mm Identifier: 0x139 Timestamp: 47403 Subpixel: horizontal rgb Clones: CRTC: 0 CRTCs: 0 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: 1024x768 (0x13a) 0.0MHz *current h: width 1024 start 0 end 0 total 1024 skew 0 clock 0.0KHz v: height 768 start 0 end 0 total 768 clock 0.0Hz Notes: When I boot Debian, messages appear on the screen for about 15 seconds; the display then blacks out. Close inspection with a flashlight on the screen resulted in me being able to see the OS running. In order to fix this, I have amended grub.cfg to disable KMS: I added "i915.modeset=0" to the line " GRUB_CMDLINE_LINUX_DEFAULT="" ". When I try to force X to use the Intel driver by modifying xorg.conf, it outputs "No screen detected". I'm therefore stuck using the VESA driver at 1024x768 resolution - very crowded and ugly! From what I've gathered, the Intel driver requires KMS to be enabled; with my computer, however, enabling KMS causes a buggy ACPI that shuts off the backlight. Another ACPI issue is that I cannot use the brightness controls on my keyboard (Fn+Left/RightArrow); I am stuck on maximum brightness all the time. This is likely related to the backlight issue. See bug report: https://bugs.freedesktop.org/show_bug.cgi?id=48435 I have been corresponding with Joel and this is the same issue. I installed the drm-3.5 kernel here: http://cgit.freedesktop.org/~danvet/drm-intel/ but the fix didn't work for my chipset. I still have it installed for testing purposes. An excerpt from: http://wiki.debian.org/KernelModesetting#Intel_GfxCards : After last (ca. 20th October 2010) update of my debian/testing systems, the xserver-xorg-video-intel stopped to work with i915 modeset set to 0. Therefore the workaround mentioned in the previous point was not applicable any more. Setting of i915 modeset to 1 still caused blank screen, as soon as the i915 module is loaded. After more investigations I've found, that the problem is related to framebuffer console. If KMS is switched on, the framebuffer console support must be selected. In my systems (self compiled kernel without initial ramdisk) I had to to set CONFIG_FRAMEBUFFER_CONSOLE=y, CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y . Maybe with initial ramdisk, compiling it as module would be sufficient, but I've not checked it. Unfortunately the kernel "make menuconfig" doesn't check if the framebuffer console support is selected when CONFIG_DRM_I915_KMS is set to "y" I'm not entirely literate with Linux drivers so I have no clue what that means, but it refers this issue and may be helpful to you. If you visit the page, after the excerpted section there are links to some bug reports from a few years ago. More information (lspci, lsmod, grub.conf) is available at the link at the top of my bug report. While xorg.conf and Xorg.0.log are available there also, I will upload them separately here for convenience. First I am attaching the xorg.conf file generated by "Xorg -configure". This is the unmodified version of xorg.conf that runs fine. I think that X tries to use Screen0 - which is configured to use the Intel driver - and then sees the Intel driver isn't working. I don't know what Screen1 is but it skips it and settles on Screen2 because the VESA driver works. I'll then upload the xorg.conf which I modified to force the Intel driver. When I try to start X with that configuration, this is when I get the "No screens detected" error.
Created attachment 65153 [details] The xorg.conf file I modified (this one causes X to report "No screens")
Please attach dmesg (from 3.5) and Xorg.log. I'll attach a quick hack for you to test shortly.
Created attachment 65155 [details] Xorg.0.log - Shows "no screens found" error
(In reply to comment #2) > Please attach dmesg (from 3.5) and Xorg.log. I'll attach a quick hack for you > to test shortly. Where can I find dmesg?
Created attachment 65156 [details] [review] disable combination mode Please test this patch. When testing, please also check whether the backlight works across a suspend/resume cycle, too.
I need the Xorg.log _withtout_ i915.modeset=0, otherwise things won't work. dmesg can be read with the command dmesg (again, without disabling kms).
(In reply to comment #6) > I need the Xorg.log _withtout_ i915.modeset=0, otherwise things won't work. > dmesg can be read with the command dmesg (again, without disabling kms). How can I do this when I'm unable to see anything on my screen? Would it work if I booted the computer with KMS enabled, then rebooted with it disabled and copied the log from the shell without starting X? Or would it be overwritten?
(In reply to comment #5) > Created attachment 65156 [details] [review] [review] > disable combination mode > > Please test this patch. When testing, please also check whether the backlight > works across a suspend/resume cycle, too. You are going to need to help me with this; I don't know how to apply a patch.
Created attachment 65165 [details] dmesg from 3.5 kernel with KMS enabled
Created attachment 65166 [details] Xorg.0.log from 3.5 kernel with KMS enabled
I was able to blindly log in to my computer, start X, and copy those logs for you. These were both generated with KMS enabled on the 3.5 kernel. Also of note, I plugged an external monitor into my VGA port (on a separate boot, with KMS enabled). The intel driver was loaded. But that's nothing unexpected.
(In reply to comment #8) > (In reply to comment #5) > > Created attachment 65156 [details] [review] [review] [review] > > disable combination mode > > > > Please test this patch. When testing, please also check whether the backlight > > works across a suspend/resume cycle, too. > > You are going to need to help me with this; I don't know how to apply a patch. If you have kernel sources already around, simply do $ patch -p1 -i patchfile.patch in the source dir, then compile the kernel as usual.
Daniel, the patch worked for me. I am viewing this page in my native resolution, it feels great! :) The backlight indeed works after a suspend/resume cycle. Is there anything else you'd like me to check, or can we mark this resolved?
The brightness controls still do not work.I'm not sure if this is related because it has to do with buggy ACPI. I have tried amending grub with acpi_acpi_osi=Linux, acpi_backlight=vendor and acpi=off but none of these worked.
> --- Comment #14 from Jay Abbott <jphilipabbott@gmail.com> 2012-08-06 16:08:41 UTC --- > The brightness controls still do not work.I'm not sure if this is related > because it has to do with buggy ACPI. I have tried amending grub with > acpi_acpi_osi=Linux, acpi_backlight=vendor and acpi=off but none of these > worked. Hm, do only the keys on the keyboard not work, or does backlihg brightness adjusting generally not work (you can frob them directly in /sys/class/backlight, if none works it's busted)? For the patch itself, it's just a quick hack, I need to write a proper patch. But thanks a lot for testing. Please don't close this bug until the final patch has been merged (otherwise I might lose track of this issue).
(In reply to comment #15) > > --- Comment #14 from Jay Abbott <jphilipabbott@gmail.com> 2012-08-06 16:08:41 UTC --- > > The brightness controls still do not work.I'm not sure if this is related > > because it has to do with buggy ACPI. I have tried amending grub with > > acpi_acpi_osi=Linux, acpi_backlight=vendor and acpi=off but none of these > > worked. > > Hm, do only the keys on the keyboard not work, or does backlihg > brightness adjusting generally not work (you can frob them directly in > /sys/class/backlight, if none works it's busted)? In /sys/class/backlight I see a symlink to acpi_video0 and another to intel_backlight. Which one do I choose?
(In reply to comment #16) > (In reply to comment #15) > > > --- Comment #14 from Jay Abbott <jphilipabbott@gmail.com> 2012-08-06 16:08:41 UTC --- > > > The brightness controls still do not work.I'm not sure if this is related > > > because it has to do with buggy ACPI. I have tried amending grub with > > > acpi_acpi_osi=Linux, acpi_backlight=vendor and acpi=off but none of these > > > worked. > > > > Hm, do only the keys on the keyboard not work, or does backlihg > > brightness adjusting generally not work (you can frob them directly in > > /sys/class/backlight, if none works it's busted)? > > In /sys/class/backlight I see a symlink to acpi_video0 and another to > intel_backlight. Which one do I choose? Try both. If none works, we have a problem. Userspace /should/ change all available backlight controllers together.
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > > --- Comment #14 from Jay Abbott <jphilipabbott@gmail.com> 2012-08-06 16:08:41 UTC --- > > > > The brightness controls still do not work.I'm not sure if this is related > > > > because it has to do with buggy ACPI. I have tried amending grub with > > > > acpi_acpi_osi=Linux, acpi_backlight=vendor and acpi=off but none of these > > > > worked. > > > > > > Hm, do only the keys on the keyboard not work, or does backlihg > > > brightness adjusting generally not work (you can frob them directly in > > > /sys/class/backlight, if none works it's busted)? > > > > In /sys/class/backlight I see a symlink to acpi_video0 and another to > > intel_backlight. Which one do I choose? > > Try both. If none works, we have a problem. Userspace /should/ change all > available backlight controllers together. (In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > > --- Comment #14 from Jay Abbott <jphilipabbott@gmail.com> 2012-08-06 16:08:41 UTC --- > > > > The brightness controls still do not work.I'm not sure if this is related > > > > because it has to do with buggy ACPI. I have tried amending grub with > > > > acpi_acpi_osi=Linux, acpi_backlight=vendor and acpi=off but none of these > > > > worked. > > > > > > Hm, do only the keys on the keyboard not work, or does backlihg > > > brightness adjusting generally not work (you can frob them directly in > > > /sys/class/backlight, if none works it's busted)? > > > > In /sys/class/backlight I see a symlink to acpi_video0 and another to > > intel_backlight. Which one do I choose? > > Try both. If none works, we have a problem. Userspace /should/ change all > available backlight controllers together. Could you be more specific? There are multiple values I could change: jay@jay-debian:/sys/class/backlight/acpi_video0$ ls actual_brightness bl_power brightness device max_brightness power subsystem type uevent jay@jay-debian:/sys/class/backlight/acpi_video0$ cd ../intel_backlight jay@jay-debian:/sys/class/backlight/intel_backlight$ ls actual_brightness bl_power brightness device max_brightness power subsystem type uevent They are read-only, by the way, but that's no problem ;)
I should add that I know this isn't a hardware failure - I dual boot Windows 7 and have no issues with brightness.
max_brightness is the maximum brightness, 0 the minimal. You should be able to change the brightness by writing something in that interval into brightness, i.e. # cat 1234 > brightness
(In reply to comment #20) > max_brightness is the maximum brightness, 0 the minimal. You should be able to > change the brightness by writing something in that interval into brightness, > i.e. > > # cat 1234 > brightness Okay, the value for brightness in the intel folder was four digits (I forget the value honestly, somewhere around 2000-3000). I changed the value to 1234 and nothing changed when I saved the file. So I went to the acpi_video0 folder. The value for brightness was 3, so I changed it to 2. Again, when I saved, nothing happened.
Can you try 0 and the value in max_brightness? Just to make sure it doesn't work, the levels are sometimes rather fine-grained.
(In reply to comment #22) > Can you try 0 and the value in max_brightness? Just to make sure it doesn't > work, the levels are sometimes rather fine-grained. In acpi_video0: The value in max_brightness was 9. I tried it. No result. I tried 0. Again, no result. In intel_backlight: max_brightness = 4335 ; changing brightness to this value did nothing and 0 did nothing either
Is this bug report still active? I haven't found a solution to this brightness issue yet.
(In reply to comment #24) > Is this bug report still active? I haven't found a solution to this brightness > issue yet. Still alive. New patches and discussion at [1], also available in the "backlight" branch of [2]. Please test. [1] http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/13642 [2] git://gitorious.org/jani/drm.git
At [1] which patch(es) should I apply? Or should I just build and install the kernel at [2]/backlight?
(In reply to comment #26) > At [1] which patch(es) should I apply? > > Or should I just build and install the kernel at [2]/backlight? I'm afraid there were other issues with the patches. To check out an idea, please attach the output of: $ cat /sys/kernel/debug/dri/0/i915_opregion | od -t x1
Created attachment 66926 [details] [review] always use LBPC 0xff in combination mode Please try the attached patch and report back. Thanks.
Please try i915.invert_brightness=1 module parameter with kernel version v3.5 or later, see if that fixes the brightness issue, and report 'lspci -vmmnn' if it does.
Any chance to test these patches Jay?
(In reply to comment #27) > (In reply to comment #26) > > At [1] which patch(es) should I apply? > > > > Or should I just build and install the kernel at [2]/backlight? > > I'm afraid there were other issues with the patches. To check out an idea, > please attach the output of: > > $ cat /sys/kernel/debug/dri/0/i915_opregion | od -t x1 I apologize for the correspondence gap. Here is the output: jay@jay-debian:~$ cat /sys/kernel/debug/dri/0/i915_opregion | od -t x1 cat: /sys/kernel/debug/dri/0/i915_opregion: No such file or directory 0000000 I will now test the patch (attachment 66926 [details] [review]), and if this does not solve the problem I'll try the booting with the i915.invert_brightness=1 parameter...
Created attachment 72416 [details] '#lspci -vmmnn' w/ inverted brightness (patches: "disable combination mode" and "always use LBPC 0xff in combination mode") Success! I first applied the patch (attachment 66926 [details] [review]) to kernel 3.7.1 and this resulted in the backlight shutting off during boot. I tried the 'i915.invert_brightness=1' parameter and it had no effect. Then I applied the patch (attachment 66926 [details] [review]) as well as the "disable combination mode" patch (attachment 65156 [details] [review]), and it happened again. But this time, the problem was solved when booting with the 'i915.invert_brightness=1' module parameter, and I've finally been able to change the brightness e.g. # echo 3000 > /sys/class/backlight/intel_backlight/brightness Thank you so much! :) I'm not sure if this is your problem or not, but I still can't adjust the brightness using the function keys on my keyboard, even when logged into the root account. If this is an unrelated issue, then let me know so I can search for a solution elsewhere. For now I guess I'll just write a script for it. I am attaching the output of '#lspci -vmmnn'. Please tell me if there is anything else you'd like me to test. Jay
Okay, so I just tried adjusting the backlight by changing the value in '/sys/class/backlight/acpi_backlight0/backlight', and it had no effect. Seems that the ACPI control for the backlight is the culprit, this would explain why the FN keys fail to frob the brightness. intel_backlight being a fallback, I imagine that during boot, the system tries to set the brightness using the ACPI control and fails? I'll take a look at dmesg and see what I can get out of it...
Trying to change the brightness with the wmi hotkeys DOES send a value to '/sys/class/backlight/acpi_video0', but the screen does not change. Each time I press Fn+[RightArrow] the value will change in this sequence: [0,2,4,6,8,9]. I'm stating the obvious here, but to consolidate what we know up to this point: The ACPI backlight control does not work, so we're forced to use the drm to adjust it instead. The drm backlight control is buggy - the max brightness is the minimum and vice versa. So when the drm kicks in during boot and tries to set the brightness to max, the backlight shuts off. The parameter i915.invert_brightness=1 solves this problem. So the issue here is really twofold. There is a buggy ACPI which fails to set the brightness, and a buggy drm which sees brightness values as their inverse. Now here's the game-changer: I was looking at dmesg and I noticed it always returns this line: [ 11.089157] acer_wmi: Brightness must be controlled by acpi video driver I realized that the above line must be critical in understanding what is wrong with the brightness controller, but I wasn't sure how to interpret it. So I did some research on the acer_wmi module, and it turns out I need to enable the backlight subsystem in my kernel config. Take a look, there needs to be an additional controller called "backlight" here: jay@jay-debian:/sys/devices/platform/acer-wmi$ ls driver interface modalias power rfkill subsystem uevent I will recompile with this enabled and let you know how it goes. With this finally out of the way, we can focus on figuring out why the drm brightness control is working backwards.
Okay, I'm sorry about all the posts, but I forgot there was something else I wanted to point out. When using the invert_brightness parameter, the backlight is restored after a suspend/resume cycle. When NOT using the invert_brightness parameter (booting to a dark screen and then turning on the backlight at ../intel_backlight/brightness), it is not restored after suspend/resume. I have to manually turn it back on myself. So I take it this must mean the system always sets the backlight to the value in max_brightness, regardless of what was set before.
(In reply to comment #33) > Okay, so I just tried adjusting the backlight by changing the value in > '/sys/class/backlight/acpi_backlight0/backlight', and it had no effect. (In reply to comment #34) > Trying to change the brightness with the wmi hotkeys DOES send a value to > '/sys/class/backlight/acpi_video0', but the screen does not change. Each > time I press Fn+[RightArrow] the value will change in this sequence: > [0,2,4,6,8,9]. > > The ACPI backlight control does not work, so we're forced to use the drm to > adjust it instead. Right. Therefore you should use acpi_backlight=vendor kernel parameter to disable the broken backlight interface /sys/class/backlight/acpi_video0. Looking at acer-wmi, it's not obvious to me whether this should bring up a platform backlight interface /sys/class/backlight/acer-wmi or similar. Please check this and try whether this interface works or not. Also check what acer-wmi says in dmesg. If it works, it should be preferred over /sys/class/backlight/intel_backlight. > The drm backlight control is buggy - the max brightness is the minimum and > vice versa. So when the drm kicks in during boot and tries to set the > brightness to max, the backlight shuts off. > > The parameter i915.invert_brightness=1 solves this problem. > > So the issue here is really twofold. There is a buggy ACPI which fails to > set the brightness, and a buggy drm which sees brightness values as their > inverse. Yes. If acer-wmi backlight does not exist or work, it seems you need to set both acpi_backlight=vendor and i915.invert_brightness=1. > I was looking at dmesg and I noticed it always returns this line: > [ 11.089157] acer_wmi: Brightness must be controlled by acpi video driver This means acer-wmi *thinks* ACPI should work, so it does not create a backlight interface of its own. See above. > So I did some research on the acer_wmi module, and it turns out I need to > enable the backlight subsystem in my kernel config. If you have anything under /sys/class/backlight, you already have CONFIG_BACKLIGHT_CLASS_DEVICE=y. Or do you mean something else? In all of the above, please use the /sys/class/backlight interfaces directly, and worry about the hotkeys afterwards.
Timeout. Please reopen if the acpi backlight interface is still broken... Probably worth bugging the acpi maintainers.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.