xbacklight doesn'twork with modesetting driver

Created attachment 124584
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

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.

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.

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?

Thanks for the bug report, I will be looking it starting from today.

IIUC xf86-video-intel provides the backlight property itself; such a property is not supplied by the kernel.

(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

so is that set of patches going to be revived soon?

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!).

(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.

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.

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?

(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.

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

sorry, should read "fill the gap:

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.

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

(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

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.

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.

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.

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

-- 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.