On 10/28/15 20:03, Alex Deucher wrote:
>>
>> My only doubt about this patch is: Should we also fall back to the old
>> beahviour in the !(rdev->mode_info.firmware_flags &
>> ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU) case?
>
> Theoretically, it's not necessary, but I guess better safe than sorry.
> Upda
On 10/27/15 17:43, Alex Deucher wrote:
>
> I see the problem. We don't enable native backlight control on older
> asics like yours by default. Does the attached patch help?
>
Yes, backlight is on again. (tested against mainline:
858e904bd71dd0057a548d6785d94ce5ec4aeabd)
thanks
On 10/27/15 16:10, Alex Deucher wrote:
>
> It would appear that your system does not use the gpu backlight
> controller. Either it's lying or messing with the GPU backlight
> controller causes some bad interaction with whatever does control it.
> Does the attached radeon patch help? I'm also at
On 10/27/15 10:17, Michel Dänzer wrote:
>
> I'm not familiar with the ATOM bytecode, but since the number of
> bytecode instructions executed seems the same in both cases, I suspect
> that dig->backlight_level == 0 => ATOM_LCD_BLOFF is executed. (The
> debugging output in my patch would have prov
On 10/27/15 03:36, Michel Dänzer wrote:
>>
>> [0] contains dmesg output with your patch applied (which fixes the backlight
>> issue)
>
> This is very surprising: The patch just adds some debugging output, it's
> not supposed to have any functional effect. Also, I don't see any of the
> debugging
