Created attachment 110820 [details]
Xorg.0.log

Created attachment 110821 [details]
Contents of all files in /sys/class/backlight/intel_backlight/

Created attachment 110822 [details]
Output of dmidecode

I forgot that in the report:

Big thanks in advance and for all your other work! I'd be happy to help any further.

Jens

(In reply to jre.winesim from comment #0)
> Brightness can only be regulated up to 5% while being at the GDM login
> prompt if an external HDMI monitor is connected.
> 
> It works again after logging in to Gnome.
> If the HDMI monitor is not connected it also works.

If you boot without HDMI, ensure backlight control works, then hotplug HDMI, does the backlight control cease to work?

Vice versa, if you boot with HDMI, confirm the bug is present, then unplug HDMI ,does the problem go away?

Created attachment 110859 [details] [review]
Disable native backlight for SAMSUNG 900X3C/900X3D/900X3E/900X4C/900X4D

Based upon a patch by Aaron Lu (https://bugzilla.kernel.org/show_bug.cgi?id=84561) for a similar issue.
Applies to git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git,
head at 9ea18f8cab5f1c36cdd0f09717e35ceb48c36a87, Linus Torvalds 2014-12-13 23:22:26

Created attachment 110860 [details]
acpidump -o acpidump

(In reply to Jani Nikula from comment #5)
> If you boot without HDMI, ensure backlight control works, then hotplug HDMI,
> does the backlight control cease to work?

Yes, without it works, after hotpluging it stops working. 


> Vice versa, if you boot with HDMI, confirm the bug is present, then unplug
> HDMI ,does the problem go away?

No, it doesn't work even after unpluging.


Just to clarify: with "does not work" I mean the backlight control OSD bar moves, but only between 0 and about 5%. This has no practical effect (especially not if the screen is dimmed to complete black as it was with kernel 3.16).


I successfully tested the attached patch which fixes the issue by disabling the native backlight (based upon a patch by Aaron Lu for a similar bug (84561) for *another* product).
I can't judge if this is sufficient, or if we should try to fix intel_backlight. For the latter I'll also include the output of acpidump.


Thanks again
Jens Reyer

Aaron, maybe another one that needs firmware backlight.

This is still in 3.18.6.

A friend of mine has a laptop from the same product family SAMSUNG 900X3C/900X3D/900X3E/900X4C/900X4D running Debian Wheezy (contrary to my Debian Jessie) without an external monitor connected (I have one connected on HDMI):
There with all kernel >3.14 (from Debian backports) the GDM login screen is black and brightness not adjustable at all until she logs in. Disabling intel_backlight also fixes the problem there.

So my proposed patch would help both of us.

Forgot this issue, sorry about that.

Jre,
so we already have this patch that works for you and your friend, please make sure it applies on top of Rafael's linux-next branch:
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
and then send it to linux-acpi(linux-acpi@vger.kernel.org) and the maintainer "Rafael J. Wysocki" <rjw@rjwysocki.net>.

Thanks for the fix.

(In reply to Aaron Lu from comment #11)
> so we already have this patch that works for you and your friend, please
> make sure it applies on top of Rafael's linux-next branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
> linux-next
> and then send it to linux-acpi(linux-acpi@vger.kernel.org) and the
> maintainer "Rafael J. Wysocki" <rjw@rjwysocki.net>.

Done.

Hello,

I have a Dell Latitude E5540, running an Intel Haswell i7-4600U with GPU HD Graphics 4400, and I have the same problem. But I noticed that upgrading the Intel driver to a version that ships a new backlight helper binary fixes the problem.

In my case, I am running Debian Jessie. The driver is part of the package xserver-xorg-video-intel and the version that ships the new backlight helper, according to the changelog, is:

xserver-xorg-video-intel (2:2.99.911+git20140529-1~exp1) experimental;
urgency=low

  * New upstream prerelease. (closes: #748753)
  * Install new backlight helper.

Kind regards,
Luca Boccassi

Confirmed, Debian's xserver-xorg-video-intel 2:2.99.917-1~exp1 fixes both the brightness control issue and the initally black screen when I'm testing with Linux 3.16.

So there is another way to fix this. No idea what this means for my proposed kernel patch and all those other similar disable_native_backlight quirks.

(In reply to jre.winesim from comment #14)
> Confirmed, Debian's xserver-xorg-video-intel 2:2.99.917-1~exp1 fixes both
> the brightness control issue and the initally black screen when I'm testing
> with Linux 3.16.
> 
> So there is another way to fix this. No idea what this means for my proposed
> kernel patch and all those other similar disable_native_backlight quirks.

If the native backlight helper works, my opinion would be that it's best to keep using it.

My patch has been accepted by Rafael and subsequently merged to:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ master

  commit 3120d03cf64d7f9fd71231827af2c1550aa4caa7
  Author: Jens Reyer <jens.reyer@gmail.com>
  Date:   Tue Feb 17 19:07:29 2015 +0100
  ACPI / video: Disable native backlight on Samsung Series 9 laptops

Thanks Aaron Lu for guiding me through my first kernel patch submission.

So this bug will be fixed in Linux 3.20/4.0 and this report here may be closed.

Still I'd like to know if there are any plans to reenable native backlight, now that we know (thanks Luca Boccassi) that a newer xserver-xorg-video-intel also fixes the issues. Aaron?

Thanks again
jre/Jens Reyer

(In reply to jre.winesim from comment #16)
> So this bug will be fixed in Linux 3.20/4.0 and this report here may be
> closed.

Closing, thanks for the report - and the fix!

(In reply to jre.winesim from comment #16)
> My patch has been accepted by Rafael and subsequently merged to:
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ master
> 
>   commit 3120d03cf64d7f9fd71231827af2c1550aa4caa7
>   Author: Jens Reyer <jens.reyer@gmail.com>
>   Date:   Tue Feb 17 19:07:29 2015 +0100
>   ACPI / video: Disable native backlight on Samsung Series 9 laptops
> 
> Thanks Aaron Lu for guiding me through my first kernel patch submission.
> 
> So this bug will be fixed in Linux 3.20/4.0 and this report here may be
> closed.
> 
> Still I'd like to know if there are any plans to reenable native backlight,
> now that we know (thanks Luca Boccassi) that a newer
> xserver-xorg-video-intel also fixes the issues. Aaron?

I'm not sure how exactly the updated xserver-xorg-video-intel package fixed the problem. The native backlight control interface is provided by the in kernel i915 driver and shouldn't be possible to be fixed by an user space package. If this remains true, I don't see there is a need to enable the native backlight interface.

(In reply to Aaron Lu from comment #18)
> (In reply to jre.winesim from comment #16)
> > My patch has been accepted by Rafael and subsequently merged to:
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ master
> > 
> >   commit 3120d03cf64d7f9fd71231827af2c1550aa4caa7
> >   Author: Jens Reyer <jens.reyer@gmail.com>
> >   Date:   Tue Feb 17 19:07:29 2015 +0100
> >   ACPI / video: Disable native backlight on Samsung Series 9 laptops
> > 
> > Thanks Aaron Lu for guiding me through my first kernel patch submission.
> > 
> > So this bug will be fixed in Linux 3.20/4.0 and this report here may be
> > closed.
> > 
> > Still I'd like to know if there are any plans to reenable native backlight,
> > now that we know (thanks Luca Boccassi) that a newer
> > xserver-xorg-video-intel also fixes the issues. Aaron?
> 
> I'm not sure how exactly the updated xserver-xorg-video-intel package fixed
> the problem. The native backlight control interface is provided by the in
> kernel i915 driver and shouldn't be possible to be fixed by an user space
> package. If this remains true, I don't see there is a need to enable the
> native backlight interface.

Hello Aaron,

That package ships a binary, xf86-video-intel-backlight-helper, which apparently is used to regulate the brightness. I'm not familiar with the code myself or the project itself, but with a quick Google search this Xorg mailer thread came up and it does shed some light on how this is used:
http://lists.x.org/archives/xorg-devel/2014-February/040575.html

Kind regards,
Luca Boccassi

(In reply to Luca Boccassi from comment #19)
> Hello Aaron,
> 
> That package ships a binary, xf86-video-intel-backlight-helper, which
> apparently is used to regulate the brightness. I'm not familiar with the
> code myself or the project itself, but with a quick Google search this Xorg
> mailer thread came up and it does shed some light on how this is used:
> http://lists.x.org/archives/xorg-devel/2014-February/040575.html

Thanks for the pointer. The helper is used to write a value to the /sys/class/backlight/X/brightness and the fact that it now works means that the native interface works and the original problem may be due to broken user space tool. You can verify by doing this(when the native interface is still there):
# cd /sys/class/backlight/intel_backlight
# cat max_brightness
XXX
# echo some_value_less_than_max > brightness
See if backlight level changes. Of source you will also need to verify if the interface still works after hotplug as your original scenario.

If the backlight indeed works, then we have mistakenly disabled the native interface and I think we should revert that patch.

(In reply to Aaron Lu from comment #20)
> (In reply to Luca Boccassi from comment #19)
> > Hello Aaron,
> > 
> > That package ships a binary, xf86-video-intel-backlight-helper, which
> > apparently is used to regulate the brightness. I'm not familiar with the
> > code myself or the project itself, but with a quick Google search this Xorg
> > mailer thread came up and it does shed some light on how this is used:
> > http://lists.x.org/archives/xorg-devel/2014-February/040575.html
> 
> Thanks for the pointer. The helper is used to write a value to the
> /sys/class/backlight/X/brightness and the fact that it now works means that
> the native interface works and the original problem may be due to broken
> user space tool. You can verify by doing this(when the native interface is
> still there):
> # cd /sys/class/backlight/intel_backlight
> # cat max_brightness
> XXX
> # echo some_value_less_than_max > brightness
> See if backlight level changes. Of source you will also need to verify if
> the interface still works after hotplug as your original scenario.
> 
> If the backlight indeed works, then we have mistakenly disabled the native
> interface and I think we should revert that patch.

Hello Aaron,

I just tested and it works as expected, brightness changes. Tested on Jessie with both 3.18 and 3.19, and the 2.99.917-1 xserver-xorg-video-intel.

But please note that, although I believe the problem is the same since the GPU family and drivers are the same, I have a different laptop: Dell Latitude E5540, running an Intel Haswell i7-4600U with GPU HD Graphics 4400.
So we should have someone with the Samsung laptop (which has an HD4000 I think) to confirm as well, to be sure.

Kind regards,
Luca Boccassi

1.)
I can confirm that indeed the xserver-xorg-video-intel backlight helper fixes the issue (and not an unrelated change).

If I build my own packages based on the preceding commit [1] the problem still exists. After applying the next 2 commits [2] everything works (there are some more related commits in the repo, but this is the minimal changeset).

[1]:
git://anonscm.debian.org/pkg-xorg/driver/xserver-xorg-video-intel
commit a01548ccf192a5b1fa1f4a3e31e1634db39f6b39
    intel: export fd_set_cloexec / fd_set_nonblock

[2]:
commit b71f3d8bd4d6773899c1bdc903911cf240e68ead
    Backlight helper build fixes
commit 3d629c91cfa98b75c6685c2a2003e64fd1b612c4
    intel: Add a helper for setting backlight without root rights


2.)
I can also confirm that while the problem exists (GDM login screen black and brightness not adjustable) I can adjust the brightness with e.g.:
# echo 4647 > /sys/class/backlight/intel_backlight/brightness

(In reply to Aaron Lu from comment #20)
> (In reply to Luca Boccassi from comment #19)
> > Hello Aaron,
> > 
> > That package ships a binary, xf86-video-intel-backlight-helper, which
> > apparently is used to regulate the brightness. I'm not familiar with the
> > code myself or the project itself, but with a quick Google search this Xorg
> > mailer thread came up and it does shed some light on how this is used:
> > http://lists.x.org/archives/xorg-devel/2014-February/040575.html
> 
> Thanks for the pointer. The helper is used to write a value to the
> /sys/class/backlight/X/brightness and the fact that it now works means that
> the native interface works and the original problem may be due to broken
> user space tool.

If I understood it correctly, the helper is used to write a value to the /sys/class/backlight/X/brightness *with root rights*, because xf86-video-intel requires them (contrary to all other drivers). Still I don't understand why this is a problem here before login to Gnome, but not after. (I'm running a "normal" Debian Jessie here with Xorg/gdm3 running as root.) So probably yes, broken user space tool.


(In reply to Aaron Lu from comment #20)
> If the backlight indeed works, then we have mistakenly disabled the native
> interface and I think we should revert that patch.

Based on Linus "We do not break userspace" I disagree. Everything works fine here with an older kernel <3.16. And it works again for every newer kernel I tested if I disable intel_backlight. So there was a regression in the kernel which had to be fixed.

Having said that the above mentioned thread (and it links) show that the complete backlight implementation would gain from a redesign coordinated between X/kernel/... . Until then IMO the ugly blacklist to disable native blacklight has to remain.

Greets
jre

(In reply to jre.winesim from comment #22)
> (In reply to Aaron Lu from comment #20)
> > If the backlight indeed works, then we have mistakenly disabled the native
> > interface and I think we should revert that patch.
> 
> Based on Linus "We do not break userspace" I disagree. Everything works fine
> here with an older kernel <3.16. And it works again for every newer kernel I
> tested if I disable intel_backlight. So there was a regression in the kernel
> which had to be fixed.

I still don't understand what the problem is: if setting a brightness value requires root privilege, then it is true for both acpi_video and intel_backlight and if intel_backlight always works(i.e. by doing echo), I don't see why the broken user space tool works with acpi_video but not with intel_backlight...