3

Laptop: MacbookPro 11,5 with AMD gpu

OS: Lubuntu 17.04

I followed the instruction at https://wiki.archlinux.org/index.php/MacBookPro11,x and it worked.

  1. disable automatic gpu switching in MacOS X (not sure if that helped).
  2. download and compile https://github.com/problame/gmux_backlight
  3. sudo setpci -v -H1 -s 00:01.00 BRIDGE_CONTROL=0
  4. sudo gmux_backlight 120
  5. can adjust brightness with script.

The problem is that

  1. Have to use sudo everytime
  2. The F1/F2 key do not change brightness.

How to fix this?


Update (following terdon's answer)

Moved the compiled gmux_backlight to /usr/sbin/

Used sudo visudo to let each of the user run gmux_backlight with sudo and without entering password.

<username1> ALL=NOPASSWD:/usr/sbin/gmux_backlight
<username2> ALL=NOPASSWD:/usr/sbin/gmux_backlight
<username3> ALL=NOPASSWD:/usr/sbin/gmux_backlight

Create /etc/init.d/gmux_backlight_fix and sudo chmod +x the script.

#!/bin/bash -e
setpci -v -H1 -s 00:01.00 BRIDGE_CONTROL=0 >/dev/null

Symlink the script to run level 2 (the grpahical run level for Ubuntu) with lowest priority (99) by following How to run a script during boot as root.

sudo ln -s /etc/init.d/gmux_backlight_fix /etc/rc2.d/S99gmux_backlight_fix

Added to section of ~/.config/openbox/lubuntu-rc.xml for each user.

<keyboard>
  <chainQuitKey>C-g</chainQuitKey>

  <!-- My Keys -->
  <keybind key="XF86LaunchA">
    <action name="Execute">
      <command>sudo gmux_backlight -10</command>
    </action>
  </keybind>
  <keybind key="XF86LaunchB">
    <action name="Execute">
      <command>sudo gmux_backlight +10</command>
    </action>
  </keybind>

I use Fn-F3 and Fn-F4 because Lubuntu can not automatically detect Fn-F1 and Fn-F2 on the laptop.

Initially I wrote a bash script that takes argument and grant every user to run it with sudo. A while later, I worry that people can break the bash script and run any command with sudo privilege. So I use the compiled binary instead of my bash script.

The old bash script is /usr/sbin/gmux_capped_backlight:

#!/bin/bash -e

# setpci
setpci -v -H1 -s 00:01.00 BRIDGE_CONTROL=0 >/dev/null

# Get current brightness
CB="$( cat /sys/class/backlight/gmux_backlight/brightness )"

# Split characters of argument
arg=$1
first_char=${arg:0:1}
other_char=${arg:1}

# Desired Brightness
if [ $first_char == "+" ]; then 
    Brightness=$(expr $CB + $other_char)
elif [ $first_char == "-" ]; then
    Brightness=$(expr $CB - $other_char)
else
    Brightness=$arg
fi

# Limit the range of brightness #
Max=1024
Min=0

if [ $Brightness -gt $Max ]; then
    Brightness=$Max
fi
if [ $Brightness -lt $Min ]; then
    Brightness=$Min
fi
derHugo
  • 3,356
  • 5
  • 31
  • 51

1 Answers1

2

Since you say you can already adjust this using a script, it looks like you're almost there already. You just need to:

  1. Set up sudo to allow executing that particular script by your user without a password. First, open a terminal and run sudo visudo. That will bring up a window of your default editor. Add this line to the file:

    terdon  ALL=NOPASSWD:/path/to/your/script
    

    Obviously, change terdon to your user name and change /path/to/your/script to whatever the path to your script is. It will make your life easier if you can make sure that path has no spaces. Now, save the file and close it.

  2. You can now run the script without needing to enter root's password, so all you need to do is assign the commands to raise and lower brightness to the F1/F2 keys. I don't use LXDE, but I found a forum thread here which suggests you can do it by editing ~/.config/openbox/lxde-rc.xml and adding something like this:

    <keybind key="F2">
      <action name="Execute">
        <command>/path/to/your/script increaseBrightness</command>
      </action>
    </keybind>
    <keybind key="F1">
      <action name="Execute">
        <command>/path/to/your/script decreaseBrightness</command>
      </action>
    </keybind>
    

    For both cases, use whatever parameter your script would take to raise/lower the brightness.

    Alternatively, you can also do this by installing xbindkeys:

    sudo apt-get install xbindkeys
    

    Create the default settings file:

    xbindkeys --defaults > `~/.xbindkeysrc`
    

    Get the right keycodes for your keys. It will likely be something like F1. Then, edit ~/.xbindkeysrc and add these:

    "/path/to/your/script increaseBrightness"
    F2
    
    "/path/to/your/script decreaseBrightness"
    F1
    

    Finally, run xbindkeys and your shortcuts should work. Add it to your list of startup programs so it is always run when you log in.

terdon
  • 100,812
  • +1 for great informative answer that is also well-written. Minor point is on all laptop keyboards I've seen it would be Fn+F1 and Fn+F2 insted of F1/F2 because your F1 and F2 keys would never reach normal apps. Obviously, this would be OP oversight and not yours. But I'm curious if xbindkeys can trap Fn+Fx as I've never tried it and it might make a great user-friendly GUI project down the road to link key combos to scripts. – WinEunuuchs2Unix Jul 09 '17 at 00:07
  • @win macs use the F keys with no modifier for this sort of thing, so the OP meant what they wrote, I think. But that's why I mentioned they should get the right code using xbindkeys -k, to be sure. And yes, it can bind them. On my keyboard, for example, which has a function key, that's recognized. – terdon Jul 09 '17 at 00:10
  • Thanks for the info. I haven't used Mac since 1984 and they've changed a lot since then. Nice to know xbindkeys recognizes Fn key combos. I'm just so used to other OS's not being able to recognize that in the past. – WinEunuuchs2Unix Jul 09 '17 at 00:14
  • Is it a good idea to let all users run that script with sudo? – hamster on wheels Jul 09 '17 at 00:30
  • @rxu that only allows your user to run the script with sudo. That's why you need to put your user name where I put terdon. And yes, it is a risk. To make it slightly less risky, put the script in a directory other users don't have write access to, like /usr/local/bin. The real danger here is someone maliciously changing the script to something destructive (consider rm -rf /usr /etc /lib for example). Since you run it with sudo, anything dangerous put in there will be run with elevated privileges. Saving it in /usr/bin makes that harder to do. – terdon Jul 09 '17 at 23:46