Bug 1354662

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

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.

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.

Ping? Any progress with this?

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

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

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.

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.

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.

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

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.

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.

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.

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

This is NOT fix by xorg-x11-server-1.19.3-6.fc27.src.rpm

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.

To make it work do this

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

Artem, thank you very much for your script.
Your script worked for me.

Note that also brightnessctl seems to work nicely, available in Fedora repos.

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

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

Still broken on 27

still broken for f28

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

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

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.

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.

Works for me on Fedora 29/30.

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