Bug 96572

Summary: xbacklight doesn't work with modesetting on intel
Product: xorg Reporter: Vincent Bernat <bernat>
Component: Driver/modesettingAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: ben-bugs, bernat, cravchik, edward, eero.t.tamminen, eugen.dedu, felix+freedesktop, fhatat, freedesktop, guillaume.horel, jani.saarinen, jon, martin.peres, moritz.kiefer, nanleychery, ngharo, pete, timabraldes, tjaalton, tm, xavier.miller
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
xorg.log none

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.
Comment 19 Pander 2017-05-02 08:42:27 UTC
More people mention that it doesn't work out of the box and that the man page is not helping them how to get started. Please see https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xbacklight and https://bugs.launchpad.net/ubuntu/+source/xbacklight/+bugs?field.status:list=NEW

Perhaps the installer (in e.g. ncurses) should ask if all users should be allowed to run this or not (default). In this way, the majority of the users would be able to use this application with more ease.
Comment 20 Nathan Schulte 2017-12-21 21:56:37 UTC
On Debian (Buster), there is a package, brightness-udev, which includes only the udev scripts of brightnessctl (scripts to allow users of video group to manage brightness and input group manage leds).

Installing this package avoids the need to modify system files (like /etc/rc.local noted above).  Also, brightnessctl works to control the backlight in this case.
Comment 21 nico-freedesktop.org 2018-03-30 12:23:40 UTC
Fyi - I just wrote cbacklight to cleanly / easily fix this problem:

[14:21] line:~% cbacklight --help
usage: cbacklight [-h] [--inc INC | --dec DEC | --set SET] [--get]

cbacklight

optional arguments:
  -h, --help  show this help message and exit
  --inc INC   Increment by percentage (points)
  --dec DEC   Decrement by percentage (points)
  --set SET   Set to percentage
  --get       Get percentage (default)
[14:21] line:~% cbacklight --inc 5  
[14:21] line:~% cbacklight --dec 5 --get
intel_backlight: 65.19%
[14:22] line:~% 


It was inspired by Sebastian's ybacklight, however it only requires python3 and has no external dependencies.

You can find it in the nsbin repository on https://github.com/telmich/nsbin

Requires you to have sane permissions on the files, but that should be solved by udev or rc.local
Comment 22 GitLab Migration User 2018-12-13 18:10:51 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/47.

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.