Bug 1018908

What's the different too https://bugzilla.redhat.com/show_bug.cgi?id=1018915  ?
With my MSI fx700 i can change the brightness with fn+up/down keyboard keys with m-p-m-1.6.2-4.

(In reply to Wolfgang Ulbrich from comment #1)
> What's the different too https://bugzilla.redhat.com/show_bug.cgi?id=1018915
> ?

There are at least 3 ways to change brightness in MATE: 1. Use the keyboard keys. 2. Use the power management preferences. 3. Use the brightness applet.

Using the brightness applet, brightness setting can be changed in at least 2 ways: 1. Use the mouse to click on the slider in the applet or 2. Click on the applet and use the scroll wheel to change settings.

The referenced bug (#1018915) only addresses the fact that the mouse click on the applet slide didn't work.  It doesn't address whether or not the settings thus changed actually change the backlight brightness -- that's what this bug addresses.  In addition, this bug also addresses the fact that none of the other methods of changing the backlight brightness work on this hardware with MATE.

> With my MSI fx700 i can change the brightness with fn+up/down keyboard keys
> with m-p-m-1.6.2-4.

It certainly seems to be hardware-dependent.  I can also change backlight brightness using the keyboard keys on another laptop with Intel graphics chip, but not on this one with an NVIDIA GPU.

Let me stress again what is in the above bug report: backlight brightness adjustment works in XFCE and KDE (using keyboard keys and the brightness applets that are shipped with those DEs).  It also works in MATE, but using xbacklight rather than the applet or the power management preferences or the keyboard keys.  So I think it's a bug in MATE that can be fixed, I just don't know where to look.

Can you do in a terminal:
killall mate-power-manager
mate-power-manager --verbose

Than use fn+up or fn+down keys to change the brightness.
Please attached the output.

Created attachment 812244 [details]
m-p-m --verbose output

I used both the keyboard keys and the backlight applet.  Looks to me as though mpm saw the change requests, but didn't actually change the backlight.  When I changed the brightness via xbacklight, the change didn't register in the mpm --verbose output.

I ran the following test today on a fresh install of Fedora 20 (Alpha), with the latest updates.  In each case, I logged in to the specific desktop environment and tried to change the backlight brightness using the keyboard keys.  In each case, a desktop indicator showed the brightness setting was changing.  The question is: was backlight brightness actually changed when the settings were changed?

Nouveau driver:

1. Cinnamon: *no* change
2. Gnome Shell: *no* change
3. MATE: *no* change
4. XFCE: *no* change
5. KDE: *no* change

Obviously, none of the DE's were able to change the backlight brightness with the Nouveau driver.

Proprietary NVidia driver:

1. Cinnamon: *no* change
2. Gnome Shell: *no* change
3. MATE: *no* change
4. XFCE: backlight brightness *was* changed successfully
5. KDE: backlight brightness *was* changed successfully

So, none of the Gnome-based DE's were successful, but KDE and XFCE were.  There must be something broader going on -- any ideas?

It seems that your kernel backlight interfaces isn't supported well in mate-power-manager.
What is the output of
ls /sys/class/backlight  ?

==>[~] $ ls /sys/class/backlight/
acpi_video0@
==>[~] $ ls /sys/class/backlight/acpi_video0/
actual_brightness  bl_power  brightness  device@  max_brightness  power/  subsystem@  type  uevent
==>[~] $ cat /sys/class/backlight/acpi_video0/actual_brightness 
20
==>[~] $ cat /sys/class/backlight/acpi_video0/brightness 
20
==>[~] $ cat /sys/class/backlight/acpi_video0/max_brightness 
20

It doesn't look like XFCE uses the kernel backlight interface -- none of those last 3 values where changed when I changed the backlight brightness in XFCE.

Ok, it seems that acpi_video0@ isn't supported by mate-power-manager.
The '@' is a bit weird. The whitelist in gpm-backlight-helper.c

	/* available kernel interfaces in priority order */
	static const gchar *backlight_interfaces[] = {
		"nv_backlight",
		"nvidia_backlight",
		"asus_laptop",
		"toshiba",
		"eeepc",
		"thinkpad_screen",
		"acpi_video1",
		"mbp_backlight",
		"acpi_video0",
		"fujitsu-laptop",
		"sony",
		"samsung",
		NULL,
	};

Output of my notebook with intel integrated graphic.
ls /sys/class/backlight/
acpi_video0 intel_backlight

Here is acpi_video0 working, i will do a scratch build for testing for you with adding missing interfaces.
acpi_video0@
intel_backlight
dell_backlight
eeepc-wmi

The second prob is that it seems we have a issue with the nvidia driver.
https://bbs.archlinux.org/viewtopic.php?id=167893
Downgrading to nvidia 319.32 helps here, also using
 Option 		"RegistryDwords" "EnableBrightnessControl=1"
in xorg.conf helps maybe.

The posted output from comment 8 was with nvidia driver?
Can you post the output of both nvidia and nouveau please, i forgot to mention this.
I wanna know the name of the nouveau interface before i do the scratch build.

I found a archlinux wiki with good hints.
https://wiki.archlinux.org/index.php/backlight

see https://bugzilla.kernel.org/show_bug.cgi?id=60659#c5
can you boot with acpi_backlight=vendor in kernel boot line?
This should help for nouveau.

> The '@' is a bit weird.

I alias "ls" to "ls -F" and the '@' just means it's a soft link (it's really acpi_video0).

>  Option 		"RegistryDwords" "EnableBrightnessControl=1"
> can you boot with acpi_backlight=vendor in kernel boot line?

I already tried both of those, but I tried again just now.  The xorg.conf addition doesn't change anything.  The acpi_backlight=vendor removes all entries from /sys/class/backlight, so I don't even get the on-screen notification that brightness setting is being changed.

> Can you post the output of both nvidia and nouveau please

I haven't found a good way to uninstall the nvidia driver to revert to nouveau, so I'll have to re-install F20 to test.  I'll do that when I get a chance.

Good news with nouveau!  /sys/class/backlight contains acpi_video0 out of the box, but with acpi_backlight=vendor kernel parameter, /sys/class/backlight contains nv_backlight -- and the backlight actually changes when the setting changes.

I wonder why the nvidia driver doesn't work?  How does xbacklight do it (and XFCE and KDE)?

Fwiw, last I checked, kde primarily uses x randr for brightness handling

Fine, that it works with nouveau. I hope you agree with me that it isn't a issue with mate-power-manager. But thanks, you pointed me to missing support of some other interfaces.

'yum list *nvidia*' shows you the installed nvidia packages, remove them and check if there is no blacklist for nouveau in /etc/modprobe.d  .
Also those entries shouldn't be there in kernelboot line in /boot/grub2/grub.cfg.
nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off

Maybe xfce use xbacklight or xrandr, i don't know.
It would be helpful if you file out a report to nvidia support for this, it seems you're not the only one.
https://bbs.archlinux.org/viewtopic.php?id=167893

PS: nv-forum is also a good address.

Is there no way we can get MATE to use the same method that KDE and XFCE use?  

Nouveau is not an option as it does not support re-clocking -- reducing performance and power savings (http://www.phoronix.com/scan.php?page=article&item=nvidia_310_nouveau510&num=1).

(In reply to Andrew Lofthouse from comment #17)
> Is there no way we can get MATE to use the same method that KDE and XFCE
> use?  
> 
> Nouveau is not an option as it does not support re-clocking -- reducing
> performance and power savings
> (http://www.phoronix.com/scan.
> php?page=article&item=nvidia_310_nouveau510&num=1).

I don't think that this will happen in the next future, mate has a small developer base and our goals are fixed for 1.8 release.
http://wiki.mate-desktop.org/roadmap
And porting to GTK3 is big thing.

But the real prob is that backlight support is broken in current nvidia driver.
Filing out a report at nvidia will fix this issue much faster.
Did you try out downgrading nvidia driver to <=319.32 ?
This is the mentioned solution in the archlinux report.

Downgrading wasn't an option, at least not with the RPMFusion driver since they don't have the older driver built for the newer kernels.

(In reply to Andrew Lofthouse from comment #19)
> Downgrading wasn't an option, at least not with the RPMFusion driver since
> they don't have the older driver built for the newer kernels.

Not if you use only the akmod-nvidia package, here the akomds daemon build the kernel module for you.
http://download1.rpmfusion.org/nonfree/fedora/updates/19/x86_64/repoview/akmod-nvidia.html