Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#35774 - Minimum backlight corresponds to blank screen
Attached to Project:
Arch Linux
Opened by marco (toketin) - Thursday, 13 June 2013, 10:03 GMT
Last edited by Dave Reisner (falconindy) - Friday, 14 June 2013, 14:44 GMT
Opened by marco (toketin) - Thursday, 13 June 2013, 10:03 GMT
Last edited by Dave Reisner (falconindy) - Friday, 14 June 2013, 14:44 GMT
|
DetailsWith the notebook Lenovo Ideapad S300 with the integrated Intel HD 3000, the backlight sets to the minimum level corresponds to the complete black screen, you can't see anything. This is particular annoying during the Arch's installation, because the kernel sets the backlight to the level 0 and you get the black screen.
You can reproduce it simply running the Arch's live from usb in this notebook, after the grub loading you'll get the blank screen that you can't change pushing the function backlight buttons. You have to log in again in any working system (Windows 8 or another Linux distro and set it again because the backlight is been memorized even after the reboot, you have to use a torch in order to see something and been able to log in). I managed to install arch by disabling first the KMS and then after the complete installation i add an Udev rule that sets to 10% the level of brightness: ACTION=="add", KERNEL=="acpi_video0", SUBSYSTEM=="backlight", SUBSYSTEMS=="pci", DRIVERS=="i915", ATTR{brightness}="10" I think this rule should be added by default in the Arch's live in order to avoid this bad situation! |
This task depends upon
Closed by Dave Reisner (falconindy)
Friday, 14 June 2013, 14:44 GMT
Reason for closing: Won't implement
Additional comments about closing: Fix the problem where it exists.
Friday, 14 June 2013, 14:44 GMT
Reason for closing: Won't implement
Additional comments about closing: Fix the problem where it exists.
No, this needs to be fixed in the kernel.