Brightness control "jumps" uncontrolled using brightness control keys

[orschiro]

Dear all,

I use Ubuntu MATE 17.04 on a Thinkpad X230.

Pressing the brightness keyboard keys results in uncontrolled jumps.

1. Sometimes it increases or decreases by more than one step
2. Sometimes it displays a change in the opposing direction

I tried to capture it in this screencast:

https://youtu.be/fONhpcEMrIk

[wyatt8740]

Reminds me of an issue I had several months ago; if I remember correctly, mate-power-manager was conflicting with my thinkpad X201's ACPI lighting function, or something with the BIOS. I suspect this is involved: http://www.thinkwiki.org/wiki/Problem_with_LCD_brightness_buttons

It's all rather fuzzy now, though.

BTW, for the below I am running with the kernel parameter acpi_backlight=video passed at boot.

Try applying these patches to your source. I don't remember exactly why I did everything I did here, but I suspect this will work with the side effect of the OSD no longer displaying. It makes mate-power-manager ignore the brightness keystrokes so it is handled properly by the BIOS, IIRC.

They're tested in 1.16.2 and 1.16.0, on my own ThinkPad X201, running Debian Sid.

--- a/mate-power-manager-1.16.0/src/gpm-button.c    2016-09-19 01:17:00.000000000 -0400
+++ b/mate-power-manager-1.16.0/src/gpm-button.c    2016-11-21 10:43:09.552051811 -0500
@@ -391,8 +391,9 @@
 #ifdef HAVE_XF86XK_HIBERNATE
    gpm_button_xevent_key (button, XF86XK_Hibernate, GPM_BUTTON_HIBERNATE);
 #endif
-   gpm_button_xevent_key (button, XF86XK_MonBrightnessUp, GPM_BUTTON_BRIGHT_UP);
-   gpm_button_xevent_key (button, XF86XK_MonBrightnessDown, GPM_BUTTON_BRIGHT_DOWN);
+/* wyatt - disabled brightness keys because of conflict */
+/* gpm_button_xevent_key (button, XF86XK_MonBrightnessUp, GPM_BUTTON_BRIGHT_UP);
+   gpm_button_xevent_key (button, XF86XK_MonBrightnessDown, GPM_BUTTON_BRIGHT_DOWN);*/
    gpm_button_xevent_key (button, XF86XK_ScreenSaver, GPM_BUTTON_LOCK);
 #ifdef HAVE_XF86XK_BATTERY
    gpm_button_xevent_key (button, XF86XK_Battery, GPM_BUTTON_BATTERY);

This next patch might not be necessary; I have replaced Systemd init with a System V shim, which broke a couple things. I think this was to fix some systemd-as-init dependency, Try it if you have trouble making it compile with only the above patch:

--- a/mate-power-manager-1.16.0/src/gpm-manager.c   2016-09-19 01:17:00.000000000 -0400
+++ b/mate-power-manager-1.16.0/src/gpm-manager.c   2016-11-21 00:06:54.692112266 -0500
@@ -1806,9 +1806,11 @@
    g_connection = g_bus_get_sync (G_BUS_TYPE_SESSION, NULL, &error);

    /* We want to inhibit the systemd suspend options, and take care of them ourselves */
-   if (LOGIND_RUNNING()) {
+/* wyatt patch - fix evil systemd bug */
+/* if (LOGIND_RUNNING()) {
        manager->priv->systemd_inhibit = gpm_manager_systemd_inhibit (manager->priv->systemd_inhibit_proxy);
-   }
+   }*/
+

    /* init to unthrottled */
    manager->priv->screensaver_ac_throttle_id = 0;

[orschiro]

@wyatt8740 thank you for your patches!

I added acpi_backlight=vendor to my bootloader parameters and it solved the issue.

So, maybe it's not a problem of mate-power-manager?

[wyatt8740]

@orschiro I think it's a problem of a conflict between mate-power-manager and ACPI's management. My patches force mate-power-manager to not listen for the brightness adjustment keys.

The BIOS sends both the keypress event for the brightness keys and the ACPI events, so the ACPI driver and mate-power-manager both try to change the brightness almost simultaneously.

[orschiro]

@wyatt8740, I think I understand now, thanks!

[SebastJava]

I have a similar problem of double steps in brightness up or down on my ASUS EeePC X101CH. As @wyatt8740 said, I think it's a problem of a conflict between mate-power-manager and ACPI's management. I did this simple TEST: open mate-system-monitor to TEMPORARILY stop mate-power-manager: brightness controls are now more precise !

FEATURE REQUEST: GUI "checkbox" or terminal command to simply switch-off mate-power-manager's handling of brightness keystrokes.

[SebastJava]

UPDATE for @orschiro, @wyatt8740, and others:

I think i found the perfect solution. It works on my ASUS EeePC and i guess it fits your computers too.

Just add this to your boot parameters: acpi_backlight=none You must TEST IT first, and then make it permanent. You must CAREFULLY follow these instructions: https://wiki.ubuntu.com/Kernel/KernelBootParameters That's for Ubuntu MATE or Linux Mint MATE; else, find the Kernel Boot Parameters instructions for your system.

You should get:

1. Precise screen brightness control via keyboard.
2. OSD still working.
3. Brightness settings "remembered" from last session (after login screen at 100% brightness).

   Explanation:

   As we said before, it looks like there is a conflict between mate-power-manager and ACPI's backlight management. In this case you can deactivate acpi_backlight since mate-power-manager does that job.

P.S.: Of course, if you modified your mate-power-manager to disable the brightness keys on it, you will have to re-install it !!!

[orschiro]

@Sebastien-Bouchard thanks a lot for your research!

I guess your laptop as well as mine (X230) are mature enough to not need any additional kernel parameter to work well with Ubuntu MATE. Hence, adding a kernel parameter for me sounds like a workaround but the solution should come from changing Mate power manager as you had outlined above.

[pizzadude]

I didn't even notice I had this issue until @orschiro brought it up in ubuntu-mate.community. The "acpi_backlight=none" parameter solved the issue. Thanks!

[wyatt8740]

acpi_backlight=none didn't work for me properly, IIRC. I would agree that an option called something like "Manage backlight brightness" would be ideal, even if it's something hidden that has to be done from dconf. A description of the setting would read something like:

"On some computers, the brightness keys create both keypress events and ACPI events, causing erratic behavior when pressing them. Setting this to false makes mate-power-manager leave adjusting brightness entirely up to the ACPI subsystem."

I would prefer this because I don't actually like the OSD, anyway, but I understand I am a minority opinion here.

[wyatt8740]

Just an update - I had to patch and recompile mate-power-manager again after running an apt-get dist-upgrade in Debian Sid. The issue is still present here (in 1.18.0).

A way to prevent mate-power-manager from handling keyboard shortcuts would be great. This could be presented in a cleaner way to the end user by simply making the power manager keyboard shortcuts configurable at run-time, similar to how one can change keyboard shortcuts for volume, switching workspaces, etc. in mate-keybinding-properties. There, clearing the shortcuts (like pressing 'backspace' in the keybinding properties program) would disable mate-power-manager's control of brightness via keyboard shortcuts.

Alternately a checkbox or an option that can be accessed via dconf would be handy, too.

[joakim-tjernlund]

brightness buttons does not work at all for us. Booting into Plasma(KDE) works great though. Also, in KDE more buttons work: mic-mute, bluetooth and change screen pop up an icon too.

[wyatt8740]

I am experiencing this same issue (again) on my PowerBook G4. Would love to have a way to disable mate-power-manager's control of LCD brightness altogether.

[vincent-rg]

Have a similar issue, like pressing brightness-up then brightness-down. Hardware values goes this way (with mate-power-manager --verbose): brighness-up: 618 -> 664 brightness-down: 592 -> 546 So, something external to mate-power-manager seems to change internal brightness value.

Setting "acpi_backlight=vendor" kernel parameter solved the issue. Now brightness goes by 5% steps correctly.

Mate v1.20.3 / Debian 10 on MSI GS60 6QE