What laptop is this? We should probably just hide the slider on those types of keyboard (that's the reason why I didn't implement the kernel driver for the Lenovo X1 Carbon, for example).

I don't think you should hide the slider, because the keyboard backlight itself works perfectly fine. I'm only saying that the slider should behave a bit better.
I'm now using Gnome 3.14.2 and the bug is now different: now if I click on the slider, it always goes to zero. But if I change the backlight with the Fn+F3 / Fn+F4 keys, the slider goes to the correct value.

The machine is an Asus UX31A, and I can create a video for you that shows the problem, if the description is not descriptive enough.

> if I click on the slider, it always goes to zero.

This is still present on a fresh Fedora 22 install.

We have similar problems for some sound devices (like Bluetooth devices), which don't have fine-grained volume levels (limited to, say, 9).

See bug 581915

I have this same problem on my XPS 13. The slider always remains at 0%, but if I click at the 50% mark or the 100% mark I can control the keyboard brightness levels. However, like I said before, the slider stays visually at 0% the whole time. I agree with the OP that for keyboards with fixed brightness settings (rather than a flexible scale) the slider should snap to those points.

Also seen with 3.20.x (see https://bugzilla.opensuse.org/show_bug.cgi?id=978348)

Confirming the same thing on my Inspiron 15 7000 series that has values 0, 1, and 2 for keyboard backlight on 3.20.2 Arch Linux.

Same thing is still reproducible on Fedora 24 and Gnome 3.20.2

Somebody with the hardware will need to fix this.

I looked very briefly at the code involved. It looks like upower and even gnome-settings-daemon do read out the max_brightness properly. Probably there is some factor missing to map the max_brightness to 100 on the scale?

As I drag the slider, I see the value sent across in percent, but the return in absolute numbers:

method call time=1484891064.141822 sender=:1.374 -> destination=:1.33 serial=672 path=/org/gnome/SettingsDaemon/Power; interface=org.freedesktop.DBus.Properties; member=Set
   string "org.gnome.SettingsDaemon.Power.Keyboard"
   string "Brightness"
   variant       int32 56
signal time=1484891064.149065 sender=:1.33 -> destination=(null destination) serial=4248 path=/org/gnome/SettingsDaemon/Power; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.gnome.SettingsDaemon.Power.Keyboard"
   array [
      dict entry(
         string "Brightness"
         variant             int32 1
      )
   ]
   array [
   ]
method return time=1484891064.149236 sender=:1.33 -> destination=:1.374 serial=4249 reply_serial=672

So I'm guessing it's a bug in settings daemon?

It's here:

brightness_value = PERCENTAGE_TO_ABS (0, manager->priv->kbd_brightness_max,
                                                      brightness_value);
                if (upower_kbd_set_brightness (manager, brightness_value, error)) {
                        backlight_iface_emit_changed (manager, GSD_POWER_DBUS_INTERFACE_KEYBOARD, brightness_value);
                        return TRUE;
  


It converts brightness_value from percent to abs, calls upower, but then emits the abs, not the percent.

I will look into making a patch in the next few days.

Created attachment 344256 [details] [review]
power: emit correct value for set keyboard backlight

Works for me, awesome Adam!

Do I need to do anything else to have someone review the patch? Thanks!

Ping

Review of attachment 344256 [details] [review]:

thanks for the patch. I think this was fixed in https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=2b28b00a7e9ef21d3b94277e517692896e46e58c

please re-open if this still happens with versions >= 3.24

Fantastic!