[Intel-gfx] [pull] drm-intel-fixes

Daniel Vetter daniel at ffwll.ch
Wed May 22 17:51:27 CEST 2013


On Wed, May 22, 2013 at 5:25 PM, St├ęphane Marchesin
<stephane.marchesin at gmail.com> wrote:
> On Wed, May 22, 2013 at 12:13 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> On Wed, May 22, 2013 at 3:24 AM, St├ęphane Marchesin
>> <stephane.marchesin at gmail.com> wrote:
>>> On Mon, Sep 10, 2012 at 12:28 AM, Daniel Vetter <daniel at 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.

>> 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?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list