Bug 153401
Summary: | REGRESSION: Dell XPS 13 ACPI screen brigthness regression | ||
---|---|---|---|
Product: | ACPI | Reporter: | Luca Viggiani (lviggiani) |
Component: | Power-Video | Assignee: | Zhang Rui (rui.zhang) |
Status: | CLOSED UNREPRODUCIBLE | ||
Severity: | normal | CC: | aklyatne, christian-schaefer, danyer, gary, lenb, lv.zheng, lviggiani, nathan.currier, perry_yuan, rui.zhang |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.7.x | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
lshw output
lspci output lspci output acpidump with BIOS option ON acpidump with BIOS option OFF Patch to correct Lenovo -30 generation backlight behavior |
Description
Luca Viggiani
2016-08-19 09:12:18 UTC
Created attachment 229341 [details]
lshw output
This is the lshw command output.
Created attachment 229351 [details]
lspci output
Created attachment 229361 [details]
lspci output
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 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! 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. @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 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 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 . 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. (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? 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%. 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. I can confirm this is back again in this kernel version on my Dell XPS 13 L321X. Luca's fix not working for me. (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? (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. (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. (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 (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. (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? (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? > > 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
> 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)
(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.
>
> 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
...
(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. (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. > 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
so in 4.7 kernel, with BIOS Option On, what if you boot with kernel option acpi_backlight=video? 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... 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 please attach the acpidump with both BIOS option On&Off Created attachment 233101 [details]
acpidump with BIOS option ON
Created attachment 233111 [details]
acpidump with BIOS option OFF
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. 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. 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. 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. (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 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? 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!
(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 (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. 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. 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. (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 (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. Luca, can you do a git bisect and find out which commit introduces the problem? 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... will close in 1 more week as not reproducible if no update before then. thanks. 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. Removing regression mark as it is related to distribution specific quirk. No response from the bug reporter. Plus according to comment #51, the problem should have been fixed in 4.8. |