Bug 1354662 - xbacklight doesn't work
Summary: xbacklight doesn't work
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: xbacklight
Version: 28
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Michel Alexandre Salim
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-11 22:03 UTC by Artem S. Tashkinov
Modified: 2019-05-03 07:55 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-03 07:55:57 UTC


Attachments (Terms of Use)
X.org independent brightness configuration via acpid (654 bytes, application/x-gzip)
2017-07-24 22:02 UTC, Artem S. Tashkinov
no flags Details


Links
System ID Priority Status Summary Last Updated
FreeDesktop.org 96572 None None None 2016-07-11 22:03:05 UTC

Description Artem S. Tashkinov 2016-07-11 22:03:06 UTC
Description of problem:

$ xbacklight -set 5
No outputs have backlight property

$ ls -l /sys/class/backlight/
total 0
lrwxrwxrwx. 1 root root 0 Jul 12 00:59 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight



Version-Release number of selected component (if applicable):

1.2.1-3.fc24


How reproducible: always

Perhaps a dupe of https://bugs.freedesktop.org/show_bug.cgi?id=96572

In Fedora 23 everything worked fine.

Additional info:

# lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)

Intel Core i5 6200U

$ xrandr 
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
eDP-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 293mm x 165mm
   1920x1080     60.00*+  40.00  
   1400x1050     59.98  
   1280x1024     60.02  
   1280x960      60.00  
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   800x600       60.00    60.32    56.25  
   700x525       59.98  
   640x512       60.02  
   640x480       60.00    59.94  
   512x384       60.00  
   400x300       60.32    56.34  
   320x240       60.05  
HDMI-1 disconnected (normal left inverted right x axis y axis)

Comment 1 Andrey Ivanov 2016-10-13 04:28:32 UTC
Not sure if it's the same issue, but I'm also getting the error 
xbacklight -set 5
No outputs have backlight property

The only difference - I have integrated and discrete VGA:
lspci:
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 960M] (rev ff)


ls -1 /sys/class/backlight/*/brightness
/sys/class/backlight/acpi_video0/brightness
/sys/class/backlight/intel_backlight/brightness

and I'm able to change brightness using xrandr:
xrandr --output eDP-1 --brightness 0.8

Comment 2 Jos de Kloe 2017-01-14 09:14:05 UTC
seeing a similar issue in Fedora 25:

>xbacklight -get
No outputs have backlight property

Also in the gnome-control-center I cannot change the screen brightness anymore. In the Displays menu I get:
   "Could not get screen information"

could be connected to the update of some x11 packages I applied yesterday:

xorg-x11-server-Xorg.x86_64 1.19.1-1.fc25
xorg-x11-server-Xwayland.x86_64 1.19.1-1.fc25
xorg-x11-server-common.x86_64 1.19.1-1.fc25

The xrandr workaround mentioned in Comment #1 does work for me.

Comment 3 Jos de Kloe 2017-01-14 09:31:48 UTC
dowgrading the x11 packages does show they are indeed related.
After this command and a reboot:

dnf downgrade xorg-x11-server-Xorg xorg-x11-server-Xwayland xorg-x11-server-common

everything again works as it should.

Comment 4 Reverend Homer 2017-02-09 15:46:35 UTC
Ping? Any progress with this?

I have Fedora 25 on Lenovo T460 and can reproduce this bug.

Comment 5 Artem S. Tashkinov 2017-02-09 15:53:01 UTC
(In reply to Reverend Homer from comment #4)

No one cares.

It's open source: you're free to debug the issue and write a patch which might or might not be accepted.

Comment 6 Jos de Kloe 2017-02-09 18:18:20 UTC
well, posting comments like this does not help much, and I am disappointed as well to not see a single comment by the package maintainer some 6 months after this was first reported.

If I read the upstream bugzilla correctly, see: 
https://bugs.freedesktop.org/show_bug.cgi?id=96572
then this will be solved in the kernel 4.11 series, which unfortunately means we will have to wait for yet another number of months before that will land in fedora.

Comment 7 Artem S. Tashkinov 2017-02-09 18:31:10 UTC
Exactly.

A "maintainer" hasn't even bothered to comment on this bug report even once.

I'm inclined to believe it's a bug in the X.org server and not in the kernel, for I can perfectly manage backlight using the /sys filesystem.

Comment 8 Jos de Kloe 2017-02-12 13:11:34 UTC
After running the latest set of F25 updates the problem disappeared for me.
xbacklight works again as it should now.

Since xbacklight itself was not updated, it must be the xorg-x11 packages.
They are now at these versions:                                          
  xorg-x11-server-Xorg.x86_64 1.19.1-3.fc25                                               
  xorg-x11-server-Xwayland.x86_64 1.19.1-3.fc25                                           
  xorg-x11-server-common.x86_64 1.19.1-3.fc25                                             

browsing through the changes for 1.19.1-2 and 1.19.1-3 I guess this was fixed by version 1.19.1-2 in response to bug #1413251

If the other reporters can check if this also solves the issue on their side, we could maybe mark this bug as a duplicate and close it.

Comment 9 Reverend Homer 2017-02-14 10:50:31 UTC
(In reply to Jos de Kloe from comment #8)
> After running the latest set of F25 updates the problem disappeared for me.
> xbacklight works again as it should now.
Nope, still can reproduce this problem. So for now I have to downgrade back to fc23-version of xorg-x11-drv-* packages

> 
> Since xbacklight itself was not updated, it must be the xorg-x11 packages.
Indeed, the problem is in package xorg-x11-drv-intel

> They are now at these versions:                                          
>   xorg-x11-server-Xorg.x86_64 1.19.1-3.fc25                                 
> 
>   xorg-x11-server-Xwayland.x86_64 1.19.1-3.fc25                             
> 
>   xorg-x11-server-common.x86_64 1.19.1-3.fc25                               
> 
> 
> browsing through the changes for 1.19.1-2 and 1.19.1-3 I guess this was
> fixed by version 1.19.1-2 in response to bug #1413251
> 
> If the other reporters can check if this also solves the issue on their
> side, we could maybe mark this bug as a duplicate and close it.

Comment 10 Tomas Orsava 2017-07-04 08:22:39 UTC
On my Lenovo T450s xbacklight worked fine on F25 but upgrading to F26 caused this issue to appear.

Here's the version of the xorg-x11-drv-intel package I have on my system:

Name        : xorg-x11-drv-intel
Version     : 2.99.917
Release     : 28.20160929.fc26
Architecture: x86_64

Note that the xrandr workaround of setting brightness "works" but it changes brightness only on the software side so it appears dimmer, not on the hardware side so it actually draws less power.

Comment 11 Alex Williamson 2017-07-15 02:07:08 UTC
Broke for me after upgrade from F25 to F26, MATE desktop, neither the hotkey nor the applet changes screen brightness on Lenovo W520.  The raw sysfs interface works find.  xbacklight behaves the same as described in op.  This is a dual graphics laptop like comment 1.

Comment 12 Alex Williamson 2017-07-15 02:42:22 UTC
Rebuilt xorg-x11-server from F25 SRPM (xorg-x11-server-1.19.0-0.3.20161026.fc25.src.rpm), installed, rebooted and all mechanism of the backlight setting mechanisms work around, MATE hotkeys, MATE brightness applet, xbacklight as well.  Moving to xorg-x11-server.

Comment 13 Alex Williamson 2017-07-15 03:31:46 UTC
s/around/again/

dnf history:

Packages Altered:
    Downgrade  xorg-x11-server-Xephyr-1.19.0-0.3.20161026.fc26.x86_64 @@commandline
    Downgraded                        1.19.3-4.fc26.x86_64            @@commandline
    Downgrade  xorg-x11-server-Xorg-1.19.0-0.3.20161026.fc26.x86_64   @@commandline
    Downgraded                      1.19.3-4.fc26.x86_64              @@commandline
    Downgrade  xorg-x11-server-Xvfb-1.19.0-0.3.20161026.fc26.x86_64   @@commandline
    Downgraded                      1.19.3-4.fc26.x86_64              @@commandline
    Downgrade  xorg-x11-server-common-1.19.0-0.3.20161026.fc26.x86_64 @@commandline
    Downgraded                        1.19.3-4.fc26.x86_64            @@commandline

Comment 14 Alex Williamson 2017-07-15 04:31:16 UTC
This is NOT fix by xorg-x11-server-1.19.3-6.fc27.src.rpm

Comment 15 Artem S. Tashkinov 2017-07-24 22:02:06 UTC
Created attachment 1303888 [details]
X.org independent brightness configuration via acpid

Here's a solution which will work unless someone breaks acpid.

Tested to work with Intel's SkyLake GPU and my particular display - fix as needed.

Comment 16 Artem S. Tashkinov 2017-07-24 22:04:33 UTC
To make it work do this

$ cd /etc
# sudo tar xf /home/user/Downloads/acpid.tar.gz
# sudo systemctl restart acpid

Comment 17 Daniel 2017-08-17 03:30:42 UTC
Artem, thank you very much for your script.
Your script worked for me.

Comment 18 Miroslav Vadkerti 2017-09-18 17:07:34 UTC
Note that also brightnessctl seems to work nicely, available in Fedora repos.

$ rpm -q brightnessctl
brightnessctl-0.2.1-2.fc26.x86_64

Comment 19 Tomas Orsava 2017-09-19 15:57:07 UTC
(In reply to Miroslav Vadkerti from comment #18)
> Note that also brightnessctl seems to work nicely, available in Fedora repos.
> 
> $ rpm -q brightnessctl
> brightnessctl-0.2.1-2.fc26.x86_64

Thank you, Miroslav, that's a great replacement!

Comment 20 Alex Williamson 2017-12-11 22:41:30 UTC
Still broken on 27

Comment 21 Jos de Kloe 2018-05-09 14:55:47 UTC
still broken for f28

Comment 22 Hans de Goede 2018-10-04 13:30:31 UTC
Hi,

I just stumbled over this bug.

First of all, apologies that it took so long for a developer to get around to look at this bug.

I'm afraid I've some bad news, xbacklight depends on the xrandr backlight property which is not a standard property. This property used to be added by the Intel DDX (device dependent X) driver, aka xorg-x11-driver-intel.

For one this means that it never worked for ATI / NVIDIA cards, but for quite some time now we've stopped using the xorg-x11-driver-intel driver even on Intel GPUs as it is not properly maintained upstream. Instead we have switched to the generic xorg-x11-driver-modesetting driver.

This means that under current Fedora xbacklight can no longer work, unless it is modified to directly access the /sys/class/backlight interface as e.g. GNOME and KDE are doing.

I did not know about brightnessctl, but if that works to control the brightness from the commandline with recent X versions then that indeed seems like a great replacement.

I'm going to change the component of this bug to xbacklight, since as mentione it really needs to be modified to directly access the /sys/class/backlight interface, or perhaps better be replaces with a shell script which is a wrapper around brightnessctl which maintains commandline compatibilty as we really don't need another duplication of the code to pick the right /sys/class/backlight  interface.

Regards,

Hans

Comment 23 Hans de Goede 2018-10-04 13:32:48 UTC
Some more notes:

1) I've not looked at brightnessctl myself at all, I'm just assuming it does something similar to xbacklight but then directly accessing /sys/class/backlight based on comment 18

2) Another advantage of directly accessing /sys/class/backlight is that it will also work under Wayland compositors

Comment 24 Jos de Kloe 2018-10-04 16:01:50 UTC
Thanks for your comments.
My current method is to just directly write brightness values to /sys/class/backlight/intel_backlight/brightness taking the max allowed value in /sys/class/backlight/intel_backlight/max_brightness in to account.

I am using two little python scripts to increase/decrease by 10% of the max value, making sure it stays in the 5% to 100% range, and this works very reliably for me now.

Comment 25 Ben Cotton 2019-05-02 20:44:47 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 26 Artem S. Tashkinov 2019-05-03 07:55:57 UTC
Works for me on Fedora 29/30.

If people still experience it, I'll reopen the bug.


Note You need to log in before you can comment on or make changes to this bug.