Bug 35072

same thing on 2.6.39.. please fix it

This bug was introduced on kernel
2.6.38.8, on 2.6.38.6 was working fine. (ubuntu 10.10 -> 11.04).


A lot of people have this problem, i found this workaround:

http://linux-on-acer-aspire-5732z.blogspot.com/2011/06/backlight-workaround-for-linux-mint-11.html

I'm willing to be your ginea pig if you like :P

"P1 Low" status is unnacceptable and quite frankly insulting.  This is a MAJOR bug that deserves IMMEDIATE attention.  I don't see how a bug that prevents the screen from working can be seen as "minor".  I guess you guys think having to use a flashlight to navigate the screen to be a "minor" inconvenience.

Disgusting.

Yes, there's a workaround. But what's not usually mentioned is that in order to apply that workaround, it is necessary to USE A FLASHLIGHT to see the screen while you open the terminal, edit the rc.local file, and save the changes.  If you're lucky enough to have an external monitor, you can avoid that "(P1) minor" inconvenience, but it's not an easy thing to do if you're brand new to Linux.  Also, when you close the laptop lid, you're back to square one as far as the black screen goes.

Another workaround: 

"sudo gedit /etc/default/grub" 

remove "rhgb" and "quiet" from the boot options, then run

"sudo grub2-mkconfig -o /boot/grub2/grub.cfg"

With this solution I have backlight.
Sorry for my bad English

(In reply to comment #5)
> Another workaround: 
> 
> "sudo gedit /etc/default/grub" 
> 
> remove "rhgb" and "quiet" from the boot options, then run
> 
> "sudo grub2-mkconfig -o /boot/grub2/grub.cfg"
> 
> With this solution I have backlight.
I don't have those enabled in my syslinux config.
The bug is still present in 3.2.5.

This sounds like brightness inversion, which we already quirk on another acer. Please try the drm-intel-testing branch from http://cgit.freedesktop.org/~danvet/drm-intel/

Also please attach the full output of

$ lspci -vmmn

in case we need to add another quirk entry to the table.

Created attachment 72711 [details]
lspci -vmmn output

This is the output of 'lspci -vmmn'.

... and you please test the drm-intel-testing branch from git://people.freedesktop.org/~danvet/drm-intel

Andrea, are you attaching your PCI output because you also see this problem and need a quirk?  Please test Daniel's testing tree and get back to us.  If you still see the issue, please attach the output from dmidecode.

I'll try to build it and try it ASAP.

I'm incapable to build the kernel from Daniel's branch, is there some patch I can apply to the kernel 3.4?

Still not fixed in 3.5. Can you provide build steps?
Thank you

There's a known issue with backlights on gen4. I'm waiting for feedback from another reporter on a test-patch, I'll update as soon as a have a final patch for it.

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.

I get a black screen booting with that option. linux 3.5.4.

$ dmesg| grep i915
[    0.000000] Command line: root=/dev/sda6 ro i915.invert_brightness=1 initrd=../initramfs-linux.img BOOT_IMAGE=../vmlinuz-linux 
[    0.000000] Kernel command line: root=/dev/sda6 ro i915.invert_brightness=1 initrd=../initramfs-linux.img BOOT_IMAGE=../vmlinuz-linux 
[    0.544159] i915 0000:00:02.0: setting latency timer to 64
[    0.639737] i915 0000:00:02.0: irq 43 for MSI/MSI-X
[    1.085251] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

(In reply to comment #16)
> I get a black screen booting with that option. linux 3.5.4.

Right, comment #2 and comment #7 mislead me to think this was about brightness inversion too. Sorry.

Do you have CONFIG_ACPI_TOSHIBA enabled? Do you have toshiba-acpi loaded?

What do you have in /sys/class/backlight? Does changing brightness through the brightness sysfs files work? (sudo sh -c "echo N > brightness", where N is in range 0...`cat max_brightness`)

CONFIG_ACPI_TOSHIBA=m

$ lsmod| grep toshiba_acpi
toshiba_acpi           13367  0 
sparse_keymap           3056  1 toshiba_acpi
rfkill                 15604  5 cfg80211,toshiba_acpi,bluetooth
wmi                     8475  1 toshiba_acpi

ls /sys/class/backlight -l
total 0
lrwxrwxrwx 1 root root 0 Sep 17 15:00 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/
lrwxrwxrwx 1 root root 0 Sep 17 15:00 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/
lrwxrwxrwx 1 root root 0 Sep 17 15:01 toshiba -> ../../devices/LNXSYSTM:00/device:00/TOS1900:00/backlight/toshiba/

yes, setting a value in /sys/class/backlight/intel_backlight/brightness works.

(In reply to comment #18)
> yes, setting a value in /sys/class/backlight/intel_backlight/brightness
> works.

So acpi_video0/brightness does not work? Do you have an input device that's registered by toshiba-acpi in /sys/class/input? Does the corresponding /dev/input input device work?

What if you try acpi_backlight=vendor on the kernel cmdline?

> So acpi_video0/brightness does not work?

Yes, it doesn't. (In reply to comment #19)

> Do you have an input device that's
> registered by toshiba-acpi in /sys/class/input? Does the corresponding
> /dev/input input device work?
> 

Sorry I guess I don't know how to check this.

> What if you try acpi_backlight=vendor on the kernel cmdline?

I'll try and report back later.

(In reply to comment #18)
> yes, setting a value in /sys/class/backlight/intel_backlight/brightness
> works.

Bittersad truth, but if that works it's no longer our problem, but either an issue with ACPI or with a vendor-specific method to control the backlight. The best is probably to file this against ACPI so that they blacklist the defunct ACPI backlight, since then the userspace driver will pick the intel backlight. Or you could set the xorg.conf option to force a specific backlight (which iirc needs the very latest driver release of xf86-video-intel).

Thank you Daniel, fixed using:
Option      "Backlight"  "intel_backlight"