linux-kernel - Re: 3.13 i915 brightness settings broken when going from docked -> undocked

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+5PVA6Td43Zzd8L59_mE7E5hFuVSxhAwd+tczs_BSHXNOx5yw@mail.gmail.com>
Date:	Thu, 20 Feb 2014 19:31:41 -0500
From:	Josh Boyer <jwboyer@...oraproject.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Jani Nikula <jani.nikula@...el.com>
Cc:	David Airlie <airlied@...ux.ie>, intel-gfx@...ts.freedesktop.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: 3.13 i915 brightness settings broken when going from docked -> undocked

On Wed, Feb 19, 2014 at 9:20 PM, Josh Boyer <jwboyer@...oraproject.org> wrote:
> Hi All,
>
> We've had a rather weird report[1] of the brightness adjustments being
> broken in a specific case with Thinkpad x220 hardware (SandyBridge
> based).  If you boot the machine with it in a dock and then undock,
> the brightness adjustments do not work.  That is with either the FN
> keys or the GNOME brightness slider.
>
> I can see that the value of
> /sys/class/backlight/acpi_video0/brightness increases/decreases but
> /sys/class/backlight/intel_backlight/brightness doesn't reflect any
> changes.  With 3.12 this works, and oddly with 3.14-rc1 it works
> (specifically, it starts working around v3.13-10231-g53d8ab2 which is
> right after the first DRM merge for 3.14).  With 3.13, if I undock and
> echo a higher value in the intel_backlight_brightness sysfs entry, the
> brightness will actually increase so it can be done manually, but it
> does not work as you'd expect.
>
> I'm in the middle of trying to do a reverse bisect for which patch
> fixes it in the 3.14-rcX series, but that's taking a while.  I thought
> I'd email and see if anyone already knows about this situation, what
> patch in 3.13 broke this, and which one then fixed it again.  Thus far
> all I've gathered is that backlight handling is confusing.

The reverse bisect between 3.13 and 3.14-rc1 didn't prove fruitful,
either because I messed it up or there's a combination of things that
fix the issue.  So instead I did a regular git bisect between 3.12 and
3.13 to see which commit _broke_ things and caused the above behavior.
 That landed me at:

Author: Jesse Barnes <jbarnes@...tuousgeek.org>
Date:   Thu Oct 31 18:55:49 2013 +0200

    drm/i915: make backlight functions take a connector

I have no idea if that makes sense or not, but it's at least something
that seems to be in a relevant area of code.  Does anyone involved in
that know why it would cause the above symptoms on 3.13, and which
commit(s) fix it in 3.14-rc1?

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/