From: Petter Reinholdtsen Date: Tue, 11 Jun 2013 08:54:07 +0000 (+0000) Subject: New post. X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/commitdiff_plain/c08f23d223f802799c1fe7810bdd986039f8e0c2?ds=sidebyside New post. --- diff --git a/blog/data/2013-06-11-linux-easynote-lv.txt b/blog/data/2013-06-11-linux-easynote-lv.txt new file mode 100644 index 0000000000..55038aa31b --- /dev/null +++ b/blog/data/2013-06-11-linux-easynote-lv.txt @@ -0,0 +1,99 @@ +Title: Fixing the Linux black screen of death on machines with Intel HD video +Tags: english, debian +Date: 2013-06-27 11:00 + +

When installing RedHat, Fedora, Debian and Ubuntu on some machines, +the screen just turn black when Linux boot, either during installation +or on first boot from the hard disk. I've seen it once in a while the +last few years, but only recently understood the cause. I've seen it +on HP laptops, and on my latest acquaintance the Packard Bell laptop. +The reason seem to be in the wiring of some laptops. The system to +control the screen background light is inverted, so when Linux try to +turn the brightness fully on, it end up turning it off instead. I do +not know which Linux drivers are affected, but this post is about the +i915 driver used by the +Packard Bell +EasyNote LV, Thinkpad X40 and many other laptops.

+ +

The problem can be worked around two ways. Either by adding +i915.invert_brightness=1 as a kernel option, or by adding a file in +/etc/modprobe.d/ to tell modprobe to add the invert_brightness=1 +option when it load the i915 kernel module. On Debian and Ubuntu, it +can be done by running these commands as root:

+ +
+echo options i915 invert_brightness=1 | tee /etc/modprobe.d/i915.conf
+update-initramfs -u -k all
+
+ +

Since March 2012 there is +a +mechanism in the Linux kernel to tell the i915 driver which +hardware have this problem, and get the driver to invert the +brightness setting automatically. To use it, one need to add a row in +the +intel_quirks array in the driver source +drivers/gpu/drm/i915/intel_display.c (look for "static +struct intel_quirk intel_quirks"), specifying the PCI device +number (vendor number 8086 is assumed) and subdevice vendor and device +number.

+ +

My Packard Bell EasyNote LV got this output from lspci +-vvnn for the video card in question:

+ +

+00:02.0 VGA compatible controller [0300]: Intel Corporation \
+    3rd Gen Core processor Graphics Controller [8086:0156] \
+    (rev 09) (prog-if 00 [VGA controller])
+ Subsystem: Acer Incorporated [ALI] Device [1025:0688]
+ Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- \
+    ParErr- Stepping- SE RR- FastB2B- DisINTx+
+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- \
+    SERR-  [disabled]
+ Capabilities: 
+ Kernel driver in use: i915
+

+ +

The resulting intel_quirks entry would then look like this:

+ +

+struct intel_quirk intel_quirks[] = {
+       ...
+        /* Packard Bell EasyNote LV11HC needs invert brightness quirk */
+	{ 0x0156, 0x1025, 0x0688, quirk_invert_brightness },
+       ...
+}
+

+ +

According to the kernel module instructions (as seen using +modinfo i915), information about hardware needing the +invert_brightness flag should be sent to the +dri-devel +(at) lists.freedesktop.org mailing list to reach the kernel +developers. But my email about the laptop sent 2013-06-03 have not +yet shown up in +the +web archive for the mailing list, so I suspect they do not accept +emails from non-subscribers. Because of this, I sent my patch also to +the Debian bug tracking system instead as +BTS report #710938, to make +sure the patch is not lost.

+ +

Unfortunately, it is not enough to fix the kernel to get Laptops +with this problem working properly with Linux. If you use Gnome, your +worries should be over at this point. But if you use KDE, there is +something in KDE ignoring the invert_brightness setting and turning on +the screen during login. I've reported it to Debian as +BTS report #711237, and +have no idea yet how to figure out exactly what subsystem is doing +this. Perhaps you can help? Perhaps you know what the Gnome +developers did to handle this, and this can give a clue to the KDE +developers? Or you know where in KDE the screen brightness is changed +during login? If so, please update the BTS report (or get in touch if +you do not know how to update BTS).