- 14 3月, 2011 1 次提交
-
-
由 Dave Airlie 提交于
At least on my HP 2540p this is wrong at bootup, fine at any other time once a lid event has occured. This is due to _REG vs _INI ordering in the ACPI tables. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 22 2月, 2011 2 次提交
-
-
由 Chris Wilson 提交于
Seems like we are forever to be cursed with buggy firmware, so allow the user to explicitly set the panel connection status. Of secondary utility for cases where I run laptops with the lid closed, but still want to configure the LVDS. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Indan Zupancic 提交于
The current code does not follow Intel documentation: It misses some things and does other, undocumented things. This causes wrong backlight values in certain conditions. Instead of adding tricky code handling badly documented and rare corner cases, don't handle combination mode specially at all. This way PCI_LBPC is never touched and weird things shouldn't happen. If combination mode is enabled, then the only downside is that changing the brightness has a greater granularity (the LBPC value), but LBPC is at most 254 and the maximum is in the thousands, so this is no real functional loss. A potential problem with not handling combined mode is that a brightness of max * PCI_LBPC is not bright enough. However, this is very unlikely because from the documentation LBPC seems to act as a scaling factor and doesn't look like it's supposed to be changed after boot. The value at boot should always result in a bright enough screen. IMPORTANT: However, although usually the above is true, it may not be when people ran an older (2.6.37) kernel which messed up the LBPC register, and they are unlucky enough to have a BIOS that saves and restores the LBPC value. Then a good kernel may seem to not work: Max brightness isn't bright enough. If this happens people should boot back into the old kernel, set brightness to the maximum, and then reboot. After that everything should be fine. For more information see the below links. This fixes bugs: http://bugzilla.kernel.org/show_bug.cgi?id=23472 http://bugzilla.kernel.org/show_bug.cgi?id=25072Signed-off-by: NIndan Zupancic <indan@nul.nu> Tested-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 16 2月, 2011 1 次提交
-
-
由 Chris Wilson 提交于
Share the lid detection code for the all panels for consistent behaviour and a single place to add the eventual quirks for crap hardware. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 13 1月, 2011 1 次提交
-
-
由 Indan Zupancic 提交于
... and not if the maximum is non-zero. This fixes the typo introduced in 47356eb6 and preserves the backlight value from boot. [ickle: My thanks also to Indan Zupancic for diagnosing the original regression and suggesting the appropriate fix.] Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org # after 47356eb6
-
- 12 1月, 2011 1 次提交
-
-
由 Chris Wilson 提交于
By tracking the current status of the backlight we can prevent recording the value of the current backlight when we have disabled it. And so prevent restoring it to 'off' after an unbalanced sequence of intel_lvds_disable/enable. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=22672Tested-by: NAlex Riesen <raa.lkml@gmail.com> Tested-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org
-
- 23 11月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
After a GPU reset, the backlight controller registers may be also reset to 0. In that case we should restore those to the original values programmed by the BIOS. Note that we still lack the code to handle the case where the BIOS failed to program those registers at all... Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 21 9月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
Avoid confusion between i965g meaning broadwater and the gen4+ chipset families. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 08 9月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
There were two instances of code to control the panel backlight and neither handled the complete set of device variations. Fixes: Bug 29716 - [GM965] Regression: Backlight resets to minimum when changing resolution https://bugs.freedesktop.org/show_bug.cgi?id=29716 And a bug on one of my PineView boxes which overflowed the backlight value. Incorporates part of a similar patch by Matthew Garrett that exposes a native Intel backlight controller. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 10 8月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
v2: Hook in DP paths to keep FULLSCREEN panel fitting on eDP. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-