Bug 96572 - xbacklight doesn't work with modesetting on intel
Summary: xbacklight doesn't work with modesetting on intel
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/modesetting (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-18 06:42 UTC by Vincent Bernat
Modified: 2017-03-11 15:10 UTC (History)
18 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg.log (42.06 KB, text/x-log)
2016-06-18 06:42 UTC, Vincent Bernat
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Bernat 2016-06-18 06:42:44 UTC
Created attachment 124584 [details]
xorg.log

Hey!

After switching from intel to modesetting, xbacklight doesn't work anymore:

$ xbacklight = 20
No outputs have backlight property

However, a backlight control is present in sysfs:

/sys/class/backlight/intel_backlight

In Debian:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824987
Comment 1 peterbjorgensen 2016-06-24 09:38:09 UTC
I have the same problem running Arch linux.
xbacklight works with the xf86-video-intel driver, but not without it, even though /sys/class/backlight/intel_backlight is still present.
Comment 2 Tim Falletta Abraldes 2016-07-07 15:20:07 UTC
I'm not sure what the etiquette is about "me too" comments in this Bugzilla instance, but I see the same behavior on a Lenovo Thinkpad T440s: /sys/class/backlight/intel_backlight is present but xbacklight simply says "No outputs have backlight property" when I try to run it. I have not installed the intel driver so I'm using modesetting by default.
Comment 3 Michele Lacchia 2016-07-29 07:17:30 UTC
Experiencing the same problem. For me it's a real problem because the intel driver freezes constantly, so my only option is modesetting.
Is there something I can do to help?
Comment 4 Martin Peres 2016-08-03 16:09:21 UTC
Thanks for the bug report, I will be looking it starting from today.
Comment 5 Jani Nikula 2016-08-04 06:27:05 UTC
IIUC xf86-video-intel provides the backlight property itself; such a property is not supplied by the kernel.
Comment 6 Martin Peres 2016-08-04 14:46:03 UTC
(In reply to Jani Nikula from comment #5)
> IIUC xf86-video-intel provides the backlight property itself; such a
> property is not supplied by the kernel.

Indeed. Here is a relevant thread: https://lists.freedesktop.org/archives/dri-devel/2014-September/thread.html#67984
Comment 7 Timo Aaltonen 2016-08-23 10:38:51 UTC
so is that set of patches going to be revived soon?
Comment 8 nico-freedesktop.org 2016-09-10 19:42:26 UTC
I wonder if anyone of the developers is reading here at all?

The only reason not to use the modesetting driver is the missing backlight capability - as it is faster and more reliable than the intel driver (for intel hardware!).
Comment 9 Eero Tamminen 2016-09-12 15:20:26 UTC
(In reply to nico-freedesktop.org from comment #8)
> I wonder if anyone of the developers is reading here at all?

Martin's soon back from vacation.

I don't see Jani on the CC, but if this needs new API from kernel, bug about that should be linked here. Is there one?


> The only reason not to use the modesetting driver is the missing backlight
> capability - as it is faster and more reliable than the intel driver (for
> intel hardware!).

You didn't mention in which use-case, on which distro and with which exact HW you've compared modesetting and Intel DDX performance, but in our tests Intel DDX has been somewhat faster on average.  As to reliability, there have been issues with DRI3, but those have been fixed in X libraries, Mesa, Intel DDX etc.  Mainly you need to use new enough (full) stack.
Comment 10 Martin Peres 2016-09-14 10:34:07 UTC
This bug is also a problem for Wayland. The proper fix is to export a new property (backlight) attached to the DRM connector object and let the userspace deal with this. Once this lands, modesetting could be accessing it.

Now, if older distros require modesetting to work, we would need to port the workaround found in the intel ddx, but it really is a workaround and I would rather avoid adding this code in X, so it could live as an external patch.
Comment 11 Eugen Dedu 2016-10-28 17:47:02 UTC
Hi,

Is there any progress on this bug?  xorg-server 1.19 is being released, is this bug too risky to fix for the oncoming release?
Comment 12 Martin Peres 2016-11-02 09:05:26 UTC
(In reply to Eugen Dedu from comment #11)
> Hi,
> 
> Is there any progress on this bug?  xorg-server 1.19 is being released, is
> this bug too risky to fix for the oncoming release?

We have a patch series on the kernel side that is being polished right now. This introduces a backlight property on connectors and basically allow using the KMS interface to control the backlight.

In the coming days, we will start implementing support for it in the modesetting driver and everything should just work at this point. This is the cleanest design we could think of even though the kernel side is way more complex than it used to be.

Do not expect this feature to be ready before Linux 4.11 though :s We may work on a workaround in the mean time, but I am not sure this will be worth the effort. Stable distros could backport the patchset if they care.
Comment 13 Jos de Kloe 2017-02-09 18:21:32 UTC
Thanks for reporting the status.
For me it is somewhat disappointing that a feature like this breaks and stays broken for such a long time. If a workaround can be provided to fill the get I would very much appreciate it.

Meanwhile, I would just like to add a reference here to the Fedora/RedHat bugzilla where some more people have reported probably the same issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1354662
Comment 14 Jos de Kloe 2017-02-09 18:22:18 UTC
sorry, should read "fill the gap:
Comment 15 Eugen Dedu 2017-02-10 16:31:46 UTC
In my case, I was using xbacklight in awesome WM to change screen backlight.  Noticing that it is not going to be fixed soon, I replaced xbacklight command with an echo XYZ >/sys/class/backlight/intel_backlight/brightness, and added a chmod go+w /sys/class/backlight/intel_backlight/brightness in /etc/rc.local so that I, as a non-root user, can modify that file.
Comment 16 Martin Peres 2017-02-10 17:27:27 UTC
If you(In reply to Jos de Kloe from comment #13)
> Thanks for reporting the status.
> For me it is somewhat disappointing that a feature like this breaks and
> stays broken for such a long time. If a workaround can be provided to fill
> the get I would very much appreciate it.
> 
> Meanwhile, I would just like to add a reference here to the Fedora/RedHat
> bugzilla where some more people have reported probably the same issue:
> https://bugzilla.redhat.com/show_bug.cgi?id=1354662

If you don't mind compiling your own kernel and xserver, I have branches that work for us. We are in the process of getting everyone to agree on an ABI for this new KMS property and it won't be easy.

Here are the patches:
 - https://cgit.freedesktop.org/~mperes/linux/log/?h=backlight
 - https://cgit.freedesktop.org/~mperes/xserver/log/?h=backlight
Comment 17 Sebastian Schmidt 2017-03-11 14:49:27 UTC
(In reply to Jos de Kloe from comment #13)
> If a workaround can be provided to fill
> the get I would very much appreciate it.

https://github.com/yath/ybacklight/blob/master/ybacklight

HTH,
 Sebastian
Comment 18 Eugen Dedu 2017-03-11 15:10:52 UTC
You need write access to /sys/class/backlight/*/brightness file, right?  I was using:
chmod o+w /sys/class/backlight/intel_backlight/brightness
in my /etc/rc.local file for that.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.