Backlight uncontrollable on Samsung NP740UE3 since upgrade to Xenial

[Matthew]

Stopped working since I upgraded from 14.04 to 16.04 - now stuck at full brightness. The only subdirectory in /sys/class/backlight is intel_backlight and while the function keys control the value in actual_brightness it has no effect.

If I boot with the previous kernel (3.13.0-34) there are two more subdirectories: acpi_video0 and acpi_video0. Either of these can be used to control the brightness by writing to the brightness entry, though the function keys no longer control it because they change values in intel_backlight instead.

If I give the Xenial kernel the parameter acpi_backlight=video, those two subdirectories also appear and are controllable, though the function keys still try to control intel_backlight.

Seems to be similar to https://bugzilla.kernel.org/show_bug.cgi?id=108971. From that I have tried acpi_backlight=native and acpi_backlight="!Windows 2012" and neither has any effect, nor does video.use_bios_initial or acpi_osi=Linux.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.4.0-31-generic 4.4.0-31.50
ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13
Uname: Linux 4.4.0-31-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: matthew 3526 F.... pulseaudio
CurrentDesktop: Unity
Date: Tue Aug 2 01:41:24 2016
HibernationDevice: RESUME=UUID=0adbc2db-fe30-4c7e-9189-6e241093a9db
MachineType: SAMSUNG ELECTRONICS CO., LTD. 740U
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-31-generic root=UUID=11a96955-be22-4e0d-ba57-9da738ace79d ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-31-generic N/A
 linux-backports-modules-4.4.0-31-generic N/A
 linux-firmware 1.157.2
SourcePackage: linux
UpgradeStatus: Upgraded to xenial on 2016-08-01 (0 days ago)
dmi.bios.date: 02/26/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P07ABW.065.140226.dg
dmi.board.asset.tag: No Asset Tag
dmi.board.name: NP740U3E-S02UK
dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.board.version: SEC_SW_REVISION_1234567890ABCD
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 9
dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD.
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP07ABW.065.140226.dg:bd02/26/2014:svnSAMSUNGELECTRONICSCO.,LTD.:pn740U:pvrNP740U3E-S02UK:rvnSAMSUNGELECTRONICSCO.,LTD.:rnNP740U3E-S02UK:rvrSEC_SW_REVISION_1234567890ABCD:cvnSAMSUNGELECTRONICSCO.,LTD.:ct9:cvrN/A:
dmi.product.name: 740U
dmi.product.version: NP740U3E-S02UK
dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD.

[Matthew (gromituk)]

In the description I of course meant acpi_video0 and acpi_video1.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.7 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7

[Matthew (gromituk)]

Thanks for the advice. I installed 4.7.0-040700.201608021801 and it doesn't make any difference.

I did discover, though, that with either kernel, if you give intel_backlight a brightness of 0, the backlight switches off completely.

[Balazs Pere (perebal-sze)]

ASUS X202E - same problem

[penalvch (penalvch)]

Matthew, to keep this relevant to upstream, one would want to test the latest mainline kernel (now 4.8-rc4) as it is released.

Could you please advise?

[Matthew (gromituk)]

4.8.0-040800rc4-generic

No change I'm afraid. actual_brightness is changed with the function keys but has no effect. Backlight off when brightness is set to 0; otherwise on.

Shouldn't I be reporting this upstream?

[penalvch (penalvch)]

Matthew, the next step is to fully commit bisect from kernel 3.13 to 4.4 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Also, the kernel release names are irrelevant for the purposes of bisecting.

It is most helpful that after the fix commit (not kernel version) has been identified, you then mark this report Status Confirmed.

Thank you for your help.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]