Bug 153401 - REGRESSION: Dell XPS 13 ACPI screen brigthness regression
Summary: REGRESSION: Dell XPS 13 ACPI screen brigthness regression
Status: CLOSED UNREPRODUCIBLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Video (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-19 09:12 UTC by Luca Viggiani
Modified: 2016-11-29 05:08 UTC (History)
10 users (show)

See Also:
Kernel Version: 4.7.x
Tree: Mainline
Regression: No


Attachments
lshw output (12.87 KB, text/plain)
2016-08-19 09:18 UTC, Luca Viggiani
Details
lspci output (1.22 KB, application/octet-stream)
2016-08-19 09:22 UTC, Luca Viggiani
Details
lspci output (1.22 KB, text/plain)
2016-08-19 09:24 UTC, Luca Viggiani
Details
acpidump with BIOS option ON (245.19 KB, text/plain)
2016-09-12 15:55 UTC, Luca Viggiani
Details
acpidump with BIOS option OFF (245.19 KB, text/plain)
2016-09-12 15:56 UTC, Luca Viggiani
Details
Patch to correct Lenovo -30 generation backlight behavior (1.80 KB, patch)
2016-09-15 22:10 UTC, aklyatne
Details | Diff

Description Luca Viggiani 2016-08-19 09:12:18 UTC
Since I've upgraded to linux 4.7, if I set the screen brightness to any value other than 100% (with either fn keys or gnome sliders) it starts flashing from the brightness level I've set (e.g. 50%) to 100% and back. It's a combination of both flash and smooth up and down continuous adjustments. I've tried with the kernel parameters suggested in the arch wiki and with acpi_backlight=video or acpi_backlight=vendor the backlight control does not work, whereas with acpi_backlight=native I have the same behavior as described above (flashing). Any ideas? This happens on a Dell XPS 13 (old ivybridge model).

Also, after issuing this command (I've found some suggestions to old similar problems), pressing the fn keys, the level (and the indicators) are stuck to 100%:

sudo chmod u-w /sys/class/backlight/intel_backlight/brightness

Downgrading to linux 4.6.x fixes the issue. So it looks like it's a regression bug.

With linux 4.7.x:

$ ls /sys/class/backlight/
intel_backlight

With linux prior to 4.7 (e.g. 4.6.x)
$ ls /sys/class/backlight/
acpi_video0
Comment 1 Luca Viggiani 2016-08-19 09:18:06 UTC
Created attachment 229341 [details]
lshw output

This is the lshw command output.
Comment 2 Luca Viggiani 2016-08-19 09:22:19 UTC
Created attachment 229351 [details]
lspci output
Comment 3 Luca Viggiani 2016-08-19 09:24:32 UTC
Created attachment 229361 [details]
lspci output
Comment 4 Lv Zheng 2016-08-19 09:40:57 UTC
Hi,

Since this is a regression, can do a git bisect for us so that we can get more hints to fix the issue?

Thanks
Lv
Comment 5 Luca Viggiani 2016-08-19 11:59:23 UTC
Hi, I'm not familiar with git bisect but I can try.
Can you give me some guidelines? I've found this: http://webchick.net/node/99
So, I need to identify the two commits (last good and where things stopped working) as first step.
To me, last good kernel (which I could try) is 4.6.5, whereas the first time the issue showed up is 4.7.0. How do I find the relevant commits?
Also, do I have to run the git bisect to the full kernel tree or can I narrow the bisect to a specific component?

Thanks!
Comment 6 Lv Zheng 2016-08-21 22:45:58 UTC
4.6.5 and 4.7.0 can only be found in the stable kernel.
So you need to clone the stable tree for doing the git bisect:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
They can be found as tags with "git tag":
# git remote add stable https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
# git fetch stable
# git checkout stable
# git tag
If you can find them (for example linux-4.6.5 and linux-4.7.0) and confirm that they are really good/bad via:
# git branch stable-4.6.5 stable/linux-4.6.5
# git checkout stable-4.6.5
Then you can mark them as good/bad:
# git bisect good linux-4.6.5
# git bisect bad linux-4.7.0

But be aware of that: most kernel developers are only working with the upstream kernels.
So if you want to work with the developers, you may try to use the upstream kernel, you can type "git tag" and choose the tags closer to 4.6.5/4.7.0.
So the good/bad should be one of the v4.5.x, v4.6.x, v4.7.x tags.
You confirm if it is good/bad via:
# git branch v4.y.x origin/v4.y.x
# git checkout v4.y.x
After finding out which is last good and which is the first bad.
You can start to bisect between the last good and the first bad.
Comment 7 Luca Viggiani 2016-08-23 12:01:44 UTC
@Lv_Zheng: thanks for the instructions. In order to work with upstream, I guess I have to clone the upstream git, right? So url https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/ does not work in this case.
Also this part needs to be changed, right?

# git remote add stable https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
# git fetch stable
# git checkout stable
Comment 8 Luca Viggiani 2016-08-23 12:22:04 UTC
Is this correct?

# git clone https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
# git remote add upstream http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
# git fetch upstream
# git checkout upstream

Then looking here (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/refs/tags) I found that closest tags to good and bad are v4.6 and v4.7 respectively, so:

# git branch v4.6 origin/v4.6
# git checkout v4.6

# git bisect good v4.6
# git bisect bad v4.7
Comment 9 Perry_Yuan 2016-08-24 02:06:05 UTC
Hi  Luca .
you  just need to clone the upstream code ,then  do git bisect to find out the bad commit from commits history .

for example . 
git biset start 
git  bisect bad  v4.7-rc7
git bisect good  v4.6.4

then git  will help you to check the middle commit between bad and good  tag .

build it and test it .

if is is good , then mark it good with below command .
git bisect good 

or you will use " git bisect bad "

Then git will help you to choose another middle commit from good and bad commit .

Loop the build and test operation .

Finally  you wiill get the regression commit .

Good luck .
Comment 10 Luca Viggiani 2016-09-05 07:25:20 UTC
Hi, sorry for my late answer but I've been away for a couple of weeks and thanks for your help. I'll try to do the bisect in the next days an post the log here.
Comment 11 Zhang Rui 2016-09-05 07:54:06 UTC
(In reply to Luca Viggiani from comment #0)

> With linux 4.7.x:
> 
> $ ls /sys/class/backlight/
> intel_backlight
> 
> With linux prior to 4.7 (e.g. 4.6.x)
> $ ls /sys/class/backlight/
> acpi_video0

hmmm, it seems that the acpi video backlight interface works on this platform.

> Since I've upgraded to linux 4.7, if I set the screen brightness to any
> value other than 100% (with either fn keys or gnome sliders) it starts
> flashing from the brightness level I've set (e.g. 50%) to 100% and back.
> It's a combination of both flash and smooth up and down continuous
> adjustments. I've tried with the kernel parameters suggested in the arch
> wiki and with acpi_backlight=video or acpi_backlight=vendor the backlight
> control does not work,

This sounds strange. when using acpi_backlight=video, it should gives you back the /sys/class/backlight/acpi_video0 interface, no? Can you please check?
Comment 12 Luca Viggiani 2016-09-05 08:46:35 UTC
Yes, with 4.7.2 and acpi_backlight=video I have /sys/class/backlight/acpi_video0 interface back.
However, If I use the fn keys to adjust brigthness or echoing any value to /sys/class/backlight/acpi_video0/brigthness the screen brightness stais to 100%.

the value of "brightness" (cat /sys/class/backlight/acpi_video0/brigthness) changes (e.g. 30 vs max_brightness = 100) but the actual display brightness stays to 100%.
Comment 13 Luca Viggiani 2016-09-06 08:28:45 UTC
Ok I have found a solution...
In BIOS settings of the laptop I have disabled "Load Legacy Boot Options" from the Boot menu.
That setting was required to be enabled before kernel 4.7.x in order to make the fn keys to work. Now it must be disabled.
As a side effect now brightness changes in steps; before it was changing in a smooth way. But this is very minor thing.

So perhaps this is not actually a regression but a change in the behavior which requires some laptops settings to be adjusted like mine.
Comment 14 gazza 2016-09-09 15:20:21 UTC
I can confirm this is back again in this kernel version on my Dell XPS 13 L321X.  Luca's fix not working for me.
Comment 15 Zhang Rui 2016-09-12 02:00:28 UTC

(In reply to Luca Viggiani from comment #13)
> Ok I have found a solution...
> In BIOS settings of the laptop I have disabled "Load Legacy Boot Options"
> from the Boot menu.
> That setting was required to be enabled before kernel 4.7.x in order to make
> the fn keys to work. Now it must be disabled.

why it must be disabled?

> As a side effect now brightness changes in steps; before it was changing in
> a smooth way. But this is very minor thing.
> 
how does it change in steps?

I'm still confused.
some questions:
1. in 4.6 kernel, with BIOS option disabled, what it behaves like?
1. in 4.6 kernel, with BIOS option enabled, what it behaves like?
1. in 4.7 kernel, with BIOS option disabled, what it behaves like?
1. in 4.7 kernel, with BIOS option enabled, what it behaves like?
Comment 16 Zhang Rui 2016-09-12 02:02:12 UTC
(In reply to gazza from comment #14)
> I can confirm this is back again in this kernel version on my Dell XPS 13
> L321X.  Luca's fix not working for me.

does the brightness change work in 4.6 kernel?
has the brightness change ever worked for you? I need to confirm if this is a regression.
Comment 17 Luca Viggiani 2016-09-12 06:06:54 UTC
(In reply to Zhang Rui from comment #15)
> 
> (In reply to Luca Viggiani from comment #13)
> > Ok I have found a solution...
> > In BIOS settings of the laptop I have disabled "Load Legacy Boot Options"
> > from the Boot menu.
> > That setting was required to be enabled before kernel 4.7.x in order to
> make
> > the fn keys to work. Now it must be disabled.
> 
> why it must be disabled?

Otherwise you get the flash effect (see my original report) with kernel 4.7

> 
> > As a side effect now brightness changes in steps; before it was changing in
> > a smooth way. But this is very minor thing.
> > 
> how does it change in steps?

For example if you are at 100% and set it at 90% it jumps immediately to 90%. The old behavior (kernel 4.6 + BIOS setting enabled) it changes smoothly from 100% to 90% in about one second. 
> 
> I'm still confused.
> some questions:
> 1. in 4.6 kernel, with BIOS option disabled, what it behaves like?
fn keys to adjust brightness do not work

> 1. in 4.6 kernel, with BIOS option enabled, what it behaves like?
brightness can be adjusted; smooth transition between current and new value

> 1. in 4.7 kernel, with BIOS option disabled, what it behaves like?
brightness can be adjusted; step transition

> 1. in 4.7 kernel, with BIOS option enabled, what it behaves like?
Flash effect (smooth changes): for example if I set it to 50% it starts "bouncing" from 100% to 50% and back in a smooth way.
Comment 18 gazza 2016-09-12 07:29:41 UTC
(In reply to Zhang Rui from comment #16)
> (In reply to gazza from comment #14)
> > I can confirm this is back again in this kernel version on my Dell XPS 13
> > L321X.  Luca's fix not working for me.
> 
> does the brightness change work in 4.6 kernel?
> has the brightness change ever worked for you? I need to confirm if this is
> a regression.

I don't have 4.6 on this laptop but I do have 4.5.2 & 4.5.7, both these work fine.  This bug goes back to about 3.8 and has been fixed, only to come back a few revisions later.  Was patched by Kamal Mostafa as part of the Dell sputnik team if I remember correctly.  It was incorperated in to the main kernel versions but seemed to pop up again a few times.

On 4.7, function keys won't change brightness and software controlls don't either.

Both work on 4.5
Comment 19 Zhang Rui 2016-09-12 08:06:05 UTC
(In reply to gazza from comment #18)
> (In reply to Zhang Rui from comment #16)
> > (In reply to gazza from comment #14)
> > > I can confirm this is back again in this kernel version on my Dell XPS 13
> > > L321X.  Luca's fix not working for me.
> > 
> > does the brightness change work in 4.6 kernel?
> > has the brightness change ever worked for you? I need to confirm if this is
> > a regression.
> 
> I don't have 4.6 on this laptop but I do have 4.5.2 & 4.5.7, both these work
> fine.  This bug goes back to about 3.8 and has been fixed, only to come back
> a few revisions later.  Was patched by Kamal Mostafa as part of the Dell
> sputnik team if I remember correctly.  It was incorperated in to the main
> kernel versions but seemed to pop up again a few times.
> 
> On 4.7, function keys won't change brightness and software controlls don't
> either.
> 
> Both work on 4.5

this sounds like a different problem to me.
please file a new bug report instead.
Comment 20 Zhang Rui 2016-09-12 08:08:08 UTC
(In reply to Luca Viggiani from comment #17)
> (In reply to Zhang Rui from comment #15)
> > 
> > (In reply to Luca Viggiani from comment #13)
> > > Ok I have found a solution...
> > > In BIOS settings of the laptop I have disabled "Load Legacy Boot Options"
> > > from the Boot menu.
> > > That setting was required to be enabled before kernel 4.7.x in order to
> make
> > > the fn keys to work. Now it must be disabled.
> > 
> > why it must be disabled?
> 
> Otherwise you get the flash effect (see my original report) with kernel 4.7
> 
> > 
> > > As a side effect now brightness changes in steps; before it was changing
> in
> > > a smooth way. But this is very minor thing.
> > > 
> > how does it change in steps?
> 
> For example if you are at 100% and set it at 90% it jumps immediately to
> 90%. The old behavior (kernel 4.6 + BIOS setting enabled) it changes
> smoothly from 100% to 90% in about one second. 
> > 
> > I'm still confused.
> > some questions:
> > 1. in 4.6 kernel, with BIOS option disabled, what it behaves like?
> fn keys to adjust brightness do not work
> 
> > 1. in 4.6 kernel, with BIOS option enabled, what it behaves like?
> brightness can be adjusted; smooth transition between current and new value
> 
> > 1. in 4.7 kernel, with BIOS option disabled, what it behaves like?
> brightness can be adjusted; step transition
> 
> > 1. in 4.7 kernel, with BIOS option enabled, what it behaves like?
> Flash effect (smooth changes): for example if I set it to 50% it starts
> "bouncing" from 100% to 50% and back in a smooth way.

so you mean the brightness changes, then restores back?
If the BIOS option keeps enabled, but you got different behavior in 4.6 and 4.7 kernel, this does sounds like a regression.

BTW, can you please provide the kernel config you're using so that gazza can try the same configuration with you?
Comment 21 Zhang Rui 2016-09-12 08:09:11 UTC
(In reply to Zhang Rui from comment #20)
> (In reply to Luca Viggiani from comment #17)
> > (In reply to Zhang Rui from comment #15)
> > > 
> > > (In reply to Luca Viggiani from comment #13)
> > > > Ok I have found a solution...
> > > > In BIOS settings of the laptop I have disabled "Load Legacy Boot
> Options"
> > > > from the Boot menu.
> > > > That setting was required to be enabled before kernel 4.7.x in order to
> make
> > > > the fn keys to work. Now it must be disabled.
> > > 
> > > why it must be disabled?
> > 
> > Otherwise you get the flash effect (see my original report) with kernel 4.7
> > 
> > > 
> > > > As a side effect now brightness changes in steps; before it was
> changing in
> > > > a smooth way. But this is very minor thing.
> > > > 
> > > how does it change in steps?
> > 
> > For example if you are at 100% and set it at 90% it jumps immediately to
> > 90%. The old behavior (kernel 4.6 + BIOS setting enabled) it changes
> > smoothly from 100% to 90% in about one second. 
> > > 
> > > I'm still confused.
> > > some questions:
> > > 1. in 4.6 kernel, with BIOS option disabled, what it behaves like?
> > fn keys to adjust brightness do not work
> > 
> > > 1. in 4.6 kernel, with BIOS option enabled, what it behaves like?
> > brightness can be adjusted; smooth transition between current and new value
> > 
> > > 1. in 4.7 kernel, with BIOS option disabled, what it behaves like?
> > brightness can be adjusted; step transition
> > 
> > > 1. in 4.7 kernel, with BIOS option enabled, what it behaves like?
> > Flash effect (smooth changes): for example if I set it to 50% it starts
> > "bouncing" from 100% to 50% and back in a smooth way.
> 
you're changing the BIOS option because of this flash, right?
Comment 22 Luca Viggiani 2016-09-12 08:33:31 UTC
> 
> so you mean the brightness changes, then restores back?
Yes but only in 4.7 with BIOS oprion enabled

> If the BIOS option keeps enabled, but you got different behavior in 4.6 and
> 4.7 kernel, this does sounds like a regression.
> 
> BTW, can you please provide the kernel config you're using so that gazza can
> try the same configuration with you?

What do you exactly mean with kernel config? Is this enough?

$ uname -r
4.7.2-1-ARCH

$ cat /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="quiet loglevel=2 intel_pstate=disable"
GRUB_CMDLINE_LINUX=""

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable Hidden Menu, and optionally hide the timeout count
GRUB_HIDDEN_TIMEOUT=1
GRUB_HIDDEN_TIMEOUT_QUIET=true
Comment 23 Luca Viggiani 2016-09-12 08:35:24 UTC
> you're changing the BIOS option because of this flash, right?

Right, with kernel 4.7, BIOS option on = flash/bounce effect; BIOS option off = correct behavior (but no smooth transition)
Comment 24 gazza 2016-09-12 09:32:46 UTC
(In reply to Zhang Rui from comment #19)
> (In reply to gazza from comment #18)
> > (In reply to Zhang Rui from comment #16)
> > > (In reply to gazza from comment #14)
> > > > I can confirm this is back again in this kernel version on my Dell XPS
> 13
> > > > L321X.  Luca's fix not working for me.
> > > 
> > > does the brightness change work in 4.6 kernel?
> > > has the brightness change ever worked for you? I need to confirm if this
> is
> > > a regression.
> > 
> > I don't have 4.6 on this laptop but I do have 4.5.2 & 4.5.7, both these
> work
> > fine.  This bug goes back to about 3.8 and has been fixed, only to come
> back
> > a few revisions later.  Was patched by Kamal Mostafa as part of the Dell
> > sputnik team if I remember correctly.  It was incorperated in to the main
> > kernel versions but seemed to pop up again a few times.
> > 
> > On 4.7, function keys won't change brightness and software controlls don't
> > either.
> > 
> > Both work on 4.5
> 
> this sounds like a different problem to me.
> please file a new bug report instead.

The version of the xps 13 I have does not have UFI bios.  I don't have the bios option Luca mentioned.  This did seem to be related to the same bug historically though.
Comment 25 Luca Viggiani 2016-09-12 09:39:06 UTC
> 
> The version of the xps 13 I have does not have UFI bios.  I don't have the
> bios option Luca mentioned.  This did seem to be related to the same bug
> historically though.

Mine is L322X with BIOS rel. A10:

$ lshw

...
    description: Portable Computer
    product: XPS L322X (XPS L322X)
    vendor: Dell Inc.
    version: 0.1
...
    *-firmware
          description: BIOS
          vendor: Dell Inc.
          physical id: 0
          version: A10
          date: 08/28/2013
          size: 128KiB
          capacity: 6592KiB
...
Comment 26 Zhang Rui 2016-09-12 10:43:27 UTC
(In reply to gazza from comment #24)
> (In reply to Zhang Rui from comment #19)
> > (In reply to gazza from comment #18)
> > > (In reply to Zhang Rui from comment #16)
> > > > (In reply to gazza from comment #14)
> > > > > I can confirm this is back again in this kernel version on my Dell
> XPS 13
> > > > > L321X.  Luca's fix not working for me.
> > > > 
> > > > does the brightness change work in 4.6 kernel?
> > > > has the brightness change ever worked for you? I need to confirm if
> this is
> > > > a regression.
> > > 
> > > I don't have 4.6 on this laptop but I do have 4.5.2 & 4.5.7, both these
> work
> > > fine.  This bug goes back to about 3.8 and has been fixed, only to come
> back
> > > a few revisions later.  Was patched by Kamal Mostafa as part of the Dell
> > > sputnik team if I remember correctly.  It was incorperated in to the main
> > > kernel versions but seemed to pop up again a few times.
> > > 
> > > On 4.7, function keys won't change brightness and software controlls
> don't
> > > either.
> > > 
> > > Both work on 4.5
> > 
> > this sounds like a different problem to me.
> > please file a new bug report instead.
> 
> The version of the xps 13 I have does not have UFI bios.  I don't have the
> bios option Luca mentioned.  This did seem to be related to the same bug
> historically though.

Then please file another bug report.
Comment 27 Zhang Rui 2016-09-12 10:44:31 UTC
(In reply to Luca Viggiani from comment #23)
> > you're changing the BIOS option because of this flash, right?
> 
> Right, with kernel 4.7, BIOS option on = flash/bounce effect; BIOS option
> off = correct behavior (but no smooth transition)

please attach the output of "grep . /sys/class/backlight/*/*" in both 4.6 and 4.7 kernel, with both BIOS option enabled $ disabled.
Comment 28 Luca Viggiani 2016-09-12 12:04:15 UTC
> please attach the output of "grep . /sys/class/backlight/*/*" in both 4.6
> and 4.7 kernel, with both BIOS option enabled $ disabled.


Kernel 4.7.2, BIOS Option OFF:
Brightness changes but not in smooth way

/sys/class/backlight/intel_backlight/actual_brightness:1952
/sys/class/backlight/intel_backlight/bl_power:0
/sys/class/backlight/intel_backlight/brightness:1952
/sys/class/backlight/intel_backlight/max_brightness:4882
/sys/class/backlight/intel_backlight/type:raw



Kernel 4.7.2, BIOS option ON:
(NEW) Brightness now does not change anymore (before I had the flash/bounce effect; not sure if depends on the fact I have updated from 4.7.1 or after enabligne and disabling the BIOS option). It means that the OSD slider and also value of /sys/class/backlight/intel_backlight/brightness changes but the display stays at 100%

/sys/class/backlight/intel_backlight/actual_brightness:1710
/sys/class/backlight/intel_backlight/bl_power:0
/sys/class/backlight/intel_backlight/brightness:1710
/sys/class/backlight/intel_backlight/max_brightness:4882
/sys/class/backlight/intel_backlight/type:raw



Kernel 4.6.5, BIOS option OFF:
Now it behaves like Kernel 4.7.2, BIOS Option OFF:

/sys/class/backlight/intel_backlight/actual_brightness:2686
/sys/class/backlight/intel_backlight/bl_power:0
/sys/class/backlight/intel_backlight/brightness:2686
/sys/class/backlight/intel_backlight/max_brightness:4882
/sys/class/backlight/intel_backlight/type:raw


Kernel 4.6.5, BIOS option ON:
Smooth transitions

/sys/class/backlight/acpi_video0/actual_brightness:60
/sys/class/backlight/acpi_video0/bl_power:0
/sys/class/backlight/acpi_video0/brightness:60
/sys/class/backlight/acpi_video0/max_brightness:100
/sys/class/backlight/acpi_video0/type:firmware
Comment 29 Zhang Rui 2016-09-12 13:52:27 UTC
so in 4.7 kernel, with BIOS Option On, what if you boot with kernel option acpi_backlight=video?
Comment 30 Luca Viggiani 2016-09-12 14:37:32 UTC
Kernel 4.7.2, BIOS option ON, acpi_backlight=video:

Brightness now does not change anymore:
/sys/class/backlight/acpi_video0/brightness changes
/sys/class/backlight/intel_backlight/brightness **does not** change
actual video brightness stays to 100%

/sys/class/backlight/acpi_video0/actual_brightness:75
/sys/class/backlight/acpi_video0/bl_power:0
/sys/class/backlight/acpi_video0/brightness:75
/sys/class/backlight/acpi_video0/max_brightness:100
/sys/class/backlight/acpi_video0/type:firmware
/sys/class/backlight/intel_backlight/actual_brightness:4882
/sys/class/backlight/intel_backlight/bl_power:0
/sys/class/backlight/intel_backlight/brightness:4882
/sys/class/backlight/intel_backlight/max_brightness:4882
/sys/class/backlight/intel_backlight/type:raw

...I'm going to reboot and test without the acpi_backlight=video kernel param...
Comment 31 Luca Viggiani 2016-09-12 14:41:38 UTC
Kernel 4.7.2, BIOS option OFF, acpi_backlight=video

Brightness can be adjusted ok (no smooth transition)

/sys/class/backlight/acpi_video0/actual_brightness:34
/sys/class/backlight/acpi_video0/bl_power:0
/sys/class/backlight/acpi_video0/brightness:34
/sys/class/backlight/acpi_video0/max_brightness:100
/sys/class/backlight/acpi_video0/type:firmware
/sys/class/backlight/intel_backlight/actual_brightness:1646
/sys/class/backlight/intel_backlight/bl_power:0
/sys/class/backlight/intel_backlight/brightness:1646
/sys/class/backlight/intel_backlight/max_brightness:4882
/sys/class/backlight/intel_backlight/type:raw

I still have two backlight interfaces, however now brightness changes for both acpi_video0 and intel_backlight with BIOS option OFF
Comment 32 Zhang Rui 2016-09-12 15:47:11 UTC
please attach the acpidump with both BIOS option On&Off
Comment 33 Luca Viggiani 2016-09-12 15:55:52 UTC
Created attachment 233101 [details]
acpidump with BIOS option ON
Comment 34 Luca Viggiani 2016-09-12 15:56:19 UTC
Created attachment 233111 [details]
acpidump with BIOS option OFF
Comment 35 Luca Viggiani 2016-09-12 15:56:39 UTC
I have attached the two files (both BIOS option on and off).

Just a side note: now the flash / bounce is back again with BIOS option ON.
Comment 36 Zhang Rui 2016-09-12 16:18:26 UTC
commit aeddda06c1a704bb97c8a7bfe7a472120193bd56
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Jul 12 15:00:37 2016 +0300

    drm/i915: Ignore panel type from OpRegion on SKL
    
    Dell XPS 13 9350 apparently doesn't like it when we use the panel type
    from OpRegion. The OpRegion panel type (0) tells us to use use low
    vswing for eDP, whereas the VBT panel type (2) tells us to use normal
    vswing. The problem is that low vswing results in some display flickers.
    Since no one seems to know how this stuff is supposed to be handled,
    let's just ignore the OpRegion panel type on SKL for now.
    
    v2: Print the panel type correctly in the debug output
    
    Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
    Cc: drm-intel-fixes@lists.freedesktop.org
    References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html
    Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/1468324837-29237-1-git-send-email-ville.syrjala@linux.intel.com
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Tested-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    (cherry picked from commit bb10d4ec3be4b069bfb61c60ca4f708f58f440f1)
    [danvet: Fix up cherry-pick conflict with an s/dev_priv/dev/.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

diff --git a/drivers/gpu/drm/i915/intel_opregion.c b/drivers/gpu/drm/i915/intel_opregion.c
index 99e2603..16e209d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -1038,5 +1038,16 @@ intel_opregion_get_panel_type(struct drm_device *dev)
                return -ENODEV;
        }
 
+       /*
+        * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
+        * low vswing for eDP, whereas the VBT panel type (2) gives us normal
+        * vswing instead. Low vswing results in some display flickers, so
+        * let's simply ignore the OpRegion panel type on SKL for now.
+        */
+       if (IS_SKYLAKE(dev)) {
+               DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
+               return -ENODEV;
+       }
+
        return ret - 1;
 }

This seems to be something related, please check if your code contains this commit, if yes, please check if the problem still exists with the commit reverted, if no, please apply this and see if the problem still exists.
Comment 37 aklyatne 2016-09-13 05:59:57 UTC
Hello, I am having the same issue on a ThinkPad x230.

I got a bisect going, but realized that I have been relying on a patch to make the backlight work in the first place, as a part of Gentoo's 'genpatches'.  It adds the lines,


         * The following Lenovo models have a broken workaround in the
	 * acpi_video backlight implementation to meet the Windows 8
	 * requirement of 101 backlight levels. Reverting to pre-Win8
	 * behavior fixes the problem.


{
	.callback = dmi_disable_osi_win8,
	.ident = "Lenovo ThinkPad X230",
	.matches = {
		     DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
		     DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X230"),
		},
	},


which make the backlight work correctly for my machine, and other similar entries make it work for all *30 generation ThinkPads -

https://github.com/svn2github/genpatches-26/blob/master/genpatches-2.6/trunk/3.15/2700_ThinkPad-30-brightness-control-fix.patch


This causes the backlight to work in 4.4.6, but changes to drivers/acpi/blacklist.c (things were moved to a new file, osi.c) seem to have caused it to stop functioning.  I wouldn't be surprised if this is where the other problems are from as well -

https://github.com/torvalds/linux/commits/master/drivers/acpi/blacklist.c


It seems like I will not be able to do a proper bisect, but in my case, the changes to blacklist.c and its behavior on May 3 seem to be the source of this problem.
Comment 38 aklyatne 2016-09-13 06:23:30 UTC
And sure enough, when I add that dmi_disable_osi_win8 callback to osi.c, I have a working backlight again on the 4.8 kernel.

Perhaps some of the problems people are having are from distro-provided fixes, like mine, that were broken by the changes?

Would this be a fix upstream is willing to incorporate?  It really is HUGELY better with this workaround.  

If not, I'll take the worse option and try getting it put back into Gentoo's tiny patchset.
Comment 39 Luca Viggiani 2016-09-13 15:40:02 UTC
(In reply to Zhang Rui from comment #36)
> commit aeddda06c1a704bb97c8a7bfe7a472120193bd56
> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Date:   Tue Jul 12 15:00:37 2016 +0300
> 
>     drm/i915: Ignore panel type from OpRegion on SKL
>     
>     Dell XPS 13 9350 apparently doesn't like it when we use the panel type
>     from OpRegion. The OpRegion panel type (0) tells us to use use low
>     vswing for eDP, whereas the VBT panel type (2) tells us to use normal
>     vswing. The problem is that low vswing results in some display flickers.
>     Since no one seems to know how this stuff is supposed to be handled,
>     let's just ignore the OpRegion panel type on SKL for now.
>     
>     v2: Print the panel type correctly in the debug output
>     
>     Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
>     Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
>     Cc: drm-intel-fixes@lists.freedesktop.org
>     References:
> https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html
>     Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel
> details")
>     Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>     Link:
> http://patchwork.freedesktop.org/patch/msgid/1468324837-29237-1-git-send-
> email-ville.syrjala@linux.intel.com
>     Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>     Tested-by: James Bottomley <James.Bottomley@HansenPartnership.com>
>     Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>     (cherry picked from commit bb10d4ec3be4b069bfb61c60ca4f708f58f440f1)
>     [danvet: Fix up cherry-pick conflict with an s/dev_priv/dev/.]
>     Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 99e2603..16e209d 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1038,5 +1038,16 @@ intel_opregion_get_panel_type(struct drm_device *dev)
>                 return -ENODEV;
>         }
>  
> +       /*
> +        * FIXME On Dell XPS 13 9350 the OpRegion panel type (0) gives us
> +        * low vswing for eDP, whereas the VBT panel type (2) gives us normal
> +        * vswing instead. Low vswing results in some display flickers, so
> +        * let's simply ignore the OpRegion panel type on SKL for now.
> +        */
> +       if (IS_SKYLAKE(dev)) {
> +               DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret -
> 1);
> +               return -ENODEV;
> +       }
> +
>         return ret - 1;
>  }
> 
> This seems to be something related, please check if your code contains this
> commit, if yes, please check if the problem still exists with the commit
> reverted, if no, please apply this and see if the problem still exists.

The patch is there. I've commented it out and I'm currently rebuilding kernel package.
Once it finish I'll test it and let you know
Comment 40 Luca Viggiani 2016-09-13 17:23:23 UTC
I've installed the kernel 4.7.2 without the patch and nothing changed in the behavior with BIOS option both ON and OFF.

Just to make sure I followed the correct procedure:

I have followed this method:
https://wiki.archlinux.org/index.php/Kernels/Arch_Build_System

In PKGBUILD I have uncommented 'make menuconfig' in order to stop the build process and have the chance to remove the patch

Then I started the build process ($ makepkg -s)

When the menuconfig window came out I edit
src/linux-4.7/drivers/gpu/drm/i915/intel_opregion.c

and emoved the patch (commented out)

and finally resumed the build and installed the generated packages.
Is that correct?
Comment 41 aklyatne 2016-09-15 22:10:20 UTC
Created attachment 233511 [details]
Patch to correct Lenovo -30 generation backlight behavior

This is a patch that was originally included in Gentoo's tiny set of kernel patches.  It was rendered inert by changes to blacklist.c, and abandoned.  

Applying the same changes to osi.c, where the relevant code was moved, fixes the regression with v4.7 for the affected machines.  

Please incorporate these DMI matches, they make backlight behavior truly perfect out of the box.  I was always frustrated with the difficulty of controlling the backlight in Linux until I started using Gentoo's kernel sources, and it turns out that this is the reason why.  

It's a small change that will do A LOT toward making these machines work perfectly with Linux.  EVERY distro should be able to handle these machines well!
Comment 42 Zhang Rui 2016-09-18 02:18:47 UTC
(In reply to Luca Viggiani from comment #40)
> I've installed the kernel 4.7.2 without the patch and nothing changed in the
> behavior with BIOS option both ON and OFF.

what do you mean by "without the patch"?
do you mean the 4.7.2 kernel does not contain the patch? Or you reverted it manually?

> 
> Just to make sure I followed the correct procedure:
> 
> I have followed this method:
> https://wiki.archlinux.org/index.php/Kernels/Arch_Build_System
> 
> In PKGBUILD I have uncommented 'make menuconfig' in order to stop the build
> process and have the chance to remove the patch
> 
> Then I started the build process ($ makepkg -s)
> 
> When the menuconfig window came out I edit
> src/linux-4.7/drivers/gpu/drm/i915/intel_opregion.c
> 
> and emoved the patch (commented out)
> 
> and finally resumed the build and installed the generated packages.
> Is that correct?

I don't see anything wrong, but I'm not 100% sure because I don't play archlinux.
Maybe this video may help https://www.youtube.com/watch?v=nsTc45wRaIM
Comment 43 Luca Viggiani 2016-09-19 05:56:20 UTC
(In reply to Zhang Rui from comment #42)
> 
> what do you mean by "without the patch"?
> do you mean the 4.7.2 kernel does not contain the patch? Or you reverted it
> manually?

Default linux-4.7.2 from Arch does contain the patch.
I have reverted it manually following the procedure described in my previous comment.
Comment 44 Zhang Rui 2016-09-20 02:42:54 UTC
hmmm, as this is a regression, it would be nice if you can do a git bisect and find out which commit introduces the problem.
Comment 45 Zhang Rui 2016-09-20 02:44:09 UTC
aklyatne,

thanks a lot for your kindly help. The problem on the Dell system is different from yours, so the patch you attached won't help. But thank you all the same.
Comment 46 Lv Zheng 2016-09-23 00:14:06 UTC
(In reply to aklyatne from comment #41)
> This is a patch that was originally included in Gentoo's tiny set of kernel
> patches.  It was rendered inert by changes to blacklist.c, and abandoned. 

Do you mean a conflict between the upstream and the Gentoo's private tree?
Yes, I've moved all _OSI stuffs to a single file, including quirks related to _OSI.
This probably could hurt distribution vendors' non-published quirks.

Thanks
Comment 47 Lv Zheng 2016-09-23 00:17:34 UTC
(In reply to aklyatne from comment #41)
> Created attachment 233511 [details]
> Patch to correct Lenovo -30 generation backlight behavior

If this works, it should be split into several patches, each of the patches holds one single quirk.
And if there is more information around the quirks (BUG URL), such information should also be added into the comments of the quirks.
And someone should help to make these patches upstreamed.
Comment 48 Zhang Rui 2016-09-28 01:11:56 UTC
Luca, can you do a git bisect and find out which commit introduces the problem?
Comment 49 Luca Viggiani 2016-09-28 05:30:40 UTC
Yes I can but unfortunately not before October as this is my production machine and I super busy at the moment with some deadlines with my job. I'll try to find a window asap. Thanks for your patience...
Comment 50 Len Brown 2016-10-25 00:02:59 UTC
will close in 1 more week as not reproducible if no update before then.  thanks.
Comment 51 christian-schaefer 2016-10-25 07:17:54 UTC
I had the same problem with the same XPS 13 (Ivy Bridge). With kernel 4.8.4 (arch linux: linux 4.8.4-1) it is working again.
Comment 52 Lv Zheng 2016-10-25 07:47:33 UTC
Removing regression mark as it is related to distribution specific quirk.
Comment 53 Zhang Rui 2016-11-29 05:08:17 UTC
No response from the bug reporter.
Plus according to comment #51, the problem should have been fixed in 4.8.

Note You need to log in before you can comment on or make changes to this bug.