From: Paul Bolle <pebolle@tiscali.nl>
To: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
intel-gfx@lists.freedesktop.org,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
DRI mailing list <dri-devel@lists.freedesktop.org>
Subject: Re: 3.13 i915 brightness settings broken when going from docked -> undocked
Date: Thu, 20 Feb 2014 08:53:39 +0100 [thread overview]
Message-ID: <1392882819.5070.15.camel@x220> (raw)
In-Reply-To: <CA+5PVA4zC1+TPWWdANnm7RuBDduwNetdTknfzSkVTpFcPSGZww@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Paul Bolle <pebolle@tiscali.nl>
To: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
David Airlie <airlied@linux.ie>,
intel-gfx@lists.freedesktop.org,
DRI mailing list <dri-devel@lists.freedesktop.org>,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: Re: 3.13 i915 brightness settings broken when going from docked -> undocked
Date: Thu, 20 Feb 2014 08:53:39 +0100 [thread overview]
Message-ID: <1392882819.5070.15.camel@x220> (raw)
In-Reply-To: <CA+5PVA4zC1+TPWWdANnm7RuBDduwNetdTknfzSkVTpFcPSGZww@mail.gmail.com>
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
next prev parent reply other threads:[~2014-02-20 7:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-20 2:20 3.13 i915 brightness settings broken when going from docked -> undocked Josh Boyer
2014-02-20 7:53 ` Paul Bolle [this message]
2014-02-20 7:53 ` Paul Bolle
2014-02-25 8:05 ` Jani Nikula
2014-02-25 8:05 ` Jani Nikula
2014-02-26 0:52 ` Kodiak Furr
2014-03-04 8:31 ` Paul Bolle
2014-03-04 8:31 ` Paul Bolle
2014-03-04 8:54 ` Jani Nikula
2014-03-04 8:54 ` Jani Nikula
2014-02-21 0:31 ` Josh Boyer
2014-02-21 0:31 ` Josh Boyer
2014-02-23 15:50 ` Josh Boyer
2014-02-23 15:50 ` Josh Boyer
2014-02-24 16:15 ` Jesse Barnes
2014-02-24 16:15 ` Jesse Barnes
2014-02-25 8:36 ` Jani Nikula
2014-02-25 8:36 ` Jani Nikula
2014-02-27 1:38 ` Josh Boyer
2014-02-27 1:38 ` Josh Boyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1392882819.5070.15.camel@x220 \
--to=pebolle@tiscali.nl \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jwboyer@fedoraproject.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.