Created attachment 126908 [details] [review] Patch to add the Lenovo L440 to the OpRegion whitelist Linux 4.7.4 included commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details"), which improved backlight handling on the Lenovo ThinkPad L440 laptop: it allowed a greater range of brightnesses near zero. Linux 4.7.5 reverted back to not using the OpRegion panel type, which means that the improvement regressed. The OpRegion panel type did not cause any problems, and worked better than the other implementation. The attached patch adds the Lenovo L440 to the OpRegion panel type whitelist. Is this the correct way to add the laptop? Could it be upstreamed?
Cc Ville. I'm rather reluctant to add more and more quirks for this. There is no end to the rabbit hole. Please attach /sys/kernel/debug/dri/0/i915_vbt.
Created attachment 126963 [details] /sys/kernel/debug/dri/0/i915_vbt for Lenovo ThinkPad L440 Attached is `/sys/kernel/debug/dri/0/i915_vbt` from the Lenovo ThinkPad L440. From dmidecode (in case it helps): System Information Manufacturer: LENOVO Product Name: 20AT0038MS Version: ThinkPad L440 Serial Number: R901226H UUID: 8C0A2301-52F9-11CB-99DF-E1436B74D49E Wake-up Type: Power Switch SKU Number: LENOVO_MT_20AT_BU_Think_FM_ThinkPad L440 Family: ThinkPad L440
Created attachment 127522 [details] /sys/kernel/debug/dri/0/i915_vbt for Dell Inspiron 7720 Identical issue, found those commits by bisecting. Dell Inspiron 7720 (17r SE) MB: Dell 04M3YM vA00 UEFI: vA13 (BIOS mode)
information provided - moving bug back to reopen
Do you boot the machines in UEFI mode? If not, please try it.
I boot in UEFI mode. The problem persists in version 4.10.2. Another option to adding a whitelist entry would be allowing this to be set via commandline parameter. Would that be better?
I presume the two have a different minimum backlight level setting. Which is silly. I'm also rather reluctant to add a module parameter for this, because what we add can't easily be removed later on. It really should all work automatically, and I don't want the use of module parameters to workaround issues proliferate, because then we'll lose some of the visibility to the issues people have, and make it harder for us to fix issues. And I freely admit this approach can suck for an individual hitting some specific issues.
(In reply to Jani Nikula from comment #7) > I presume the two have a different minimum backlight level setting. Which is > silly. > > I'm also rather reluctant to add a module parameter for this, because what > we add can't easily be removed later on. It really should all work > automatically, and I don't want the use of module parameters to workaround > issues proliferate, because then we'll lose some of the visibility to the > issues people have, and make it harder for us to fix issues. And I freely > admit this approach can suck for an individual hitting some specific issues. Good afternoon Jani, Is there any update in this bug? Are the workarounds valid or there is a different approach for this case? Thank you.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Closing, please re-open if still occurs.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.