On Wed, May 22, 2013 at 8:51 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Wed, May 22, 2013 at 5:25 PM, Stéphane Marchesin stephane.marchesin@gmail.com wrote:
On Wed, May 22, 2013 at 12:13 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Wed, May 22, 2013 at 3:24 AM, Stéphane Marchesin stephane.marchesin@gmail.com wrote:
On Mon, Sep 10, 2012 at 12:28 AM, Daniel Vetter daniel@ffwll.ch wrote:
Hi Dave,
You're pull just reminded me that I've been sitting on a few small -fixes, too. Nothing really major at all:
- fixup edp setup sequence (Dave)
- disable sdvo hotplug for real, this is a fixup for a messed-up regression fixer (Jani)
- don't expose dysfunctional backlight driver (Jani)
Hi Daniel,
This change ("don't expose dysfunctional backlight driver") regresses the backlight on Chromebooks, where we don't run the vbios.
Presuming the patch works as advertised it only stops publishing an intel backlight driver which won't work. How does that break stuff?
Well it probably works as advertised to avoid exposing some broken backlight, but the problem is that it also stops exposing a working backlight on Chromebooks. However it sounds like the initial patch is specific to a broken machine, so maybe a dmi match is more appropriate?
I prefer a dmi match for chromebooks since the behaviour of fixing up the backlight after i915.ko is loaded seems rather peculiar to your setup.
It has nothing to do with Chromebooks though, but more with the fact that we don't run vbios. This isn't a property of the hardware.
Or do you somehow update the max blc stuff only once i915.ko is loaded?
Yup that's what used to happen.
What/when exactly does that happen?
Before the regression, the code was:
if (max == 0) { i915_set_default_max_backlight
which would make it work. And now that doesn't run and therefore it breaks.
Stéphane
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch