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]

Date:	Thu, 20 Feb 2014 08:53:39 +0100
From:	Paul Bolle <pebolle@...cali.nl>
To:	Josh Boyer <jwboyer@...oraproject.org>
Cc:	Daniel Vetter <daniel.vetter@...ll.ch>,
	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, 2014-02-19 at 21:20 -0500, Josh Boyer wrote:
> 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.

On an (rather old) ThinkPad X41, which also uses i915, brightness
adjustments stopped working altogether in v3.14-rc1 (I haven't used its
docking station in the v3.14 release cycle). In v3.13.y things behave as
expected. So perhaps there's actually a more general problem here.

> I can see that the value of
> /sys/class/backlight/acpi_video0/brightness

On the X41 I check /proc/acpi/ibm/brightness ...

>  increases/decreases but
> /sys/class/backlight/intel_backlight/brightness doesn't reflect any
> changes.

but otherwise things look similar.

>  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.

Echoing values into /sys/class/backlight/intel_backlight/brightness
works too (that's a new trick for me!). But, again, no docking station
is required, so the problem looks less odd than the problem on that
x220.

> 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.

I haven't yet tried bisecting.

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1067071


Paul Bolle

--
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/