5 ms·

Yup, if you can post it, it will be greatly appreciated! I honestly find it hard to configure i3, especially for brightness...

• tomxor 7y ago
  Sorry for delay: In your i3config for screen and keyboard... bindsym XF86MonBrightnessDown exec "sys='/sys/class/backlight/*backlight';\ bri=$(cat ${sys}/bri*); max=$(cat ${sys}/max*);\ val=$(($bri - $max / 32)); val=$(($val < 0 ? 0 : $val));\ echo $val | sudo tee ${sys}/bri*;" bindsym XF86MonBrightnessUp exec "sys='/sys/class/backlight/*backlight';\ bri=$(cat ${sys}/bri*); max=$(cat ${sys}/max*);\ val=$(($bri + $max / 32)); val=$(($val > $max ? $max : $val));\ echo $val | sudo tee ${sys}/bri*;" bindsym XF86KbdBrightnessDown exec "sys='/sys/class/leds/*backlight';\ bri=$(cat ${sys}/bri*); max=$(cat ${sys}/max*);\ val=$(($bri - $max / 32)); val=$(($val < 0 ? 0 : $val));\ echo $val | sudo tee ${sys}/bri*;" bindsym XF86KbdBrightnessUp exec "sys='/sys/class/leds/*backlight';\ bri=$(cat ${sys}/bri*); max=$(cat ${sys}/max*);\ val=$(($bri + $max / 32)); val=$(($val > $max ? $max : $val));\ echo $val | sudo tee ${sys}/bri*;" The only annoying things is that you will need to add NOPASSWD sudoers entries separately for: /usr/bin/tee /sys/class/backlight/*/brightness and /usr/bin/tee /sys/class/leds/*/brightness These are the only complex part of my i3config, it might seem a bit lengthy compared to installing xbacklight but for me that tool could only ever fake it by changing the pixels rather than the backlight (on every piece of hardware I have tried). The nice thing about scripting /sys/class directly is that other than the permissions it is self contained and you can easily adapt above to any other stuff it presents on your particular piece of hardware. The value 32 is the number of divisions over the range, so it should be consistent across different hardware, but you may want to adjust it to taste still. ... awaiting more golfing like a sed oneliner :P i wrote this quite a long time ago.
  • ColanR 7y ago
    > for me that tool could only ever fake it by changing the pixels rather than the backlight (on every piece of hardware I have tried) I'm curious - I've done it both ways, scripting /sys/class and using xbacklight. On my X230 I used xbacklight, and it seemed to work fine. How would I tell if it wasn't changing the backlight itself? I'd rather use /sys/class to get it right. Also, here's my /sys/class code - not sure where I got it, but I probably adapted something I found. I assume it works, but it's been commented out above the xbacklight version for some time. :) bindsym XF86MonBrightnessDown exec bctl="/sys/class/backlight/intel_backlight/brightness" && echo $((`cat $bctl`-68)) | tee $bctl bindsym XF86MonBrightnessUp exec bctl="/sys/class/backlight/intel_backlight/brightness" && echo $((`cat $bctl`+68)) | tee $bctl
    • tomxor 7y ago
      > How would I tell if it wasn't changing the backlight itself? With the exception of OLED (no idea if laptops use that stuff yet), when the LCD is fully opaque on i.e rgb 0,0,0 the backlight LED will still bleed through - Modern LCDs are much better at blocking out the LED than they used to be so it's not always obvious in a well lit room. If you reduce the brightness to 0 with xbacklight and then sleep the computer: The display will perceptibly dimm much further as it turns off (since this guarantees the back-light is turned off). If you use sys/class method it's possible to turn the backlight completely off so that there is no perceptible difference when you sleep/poweroff the computer. On the older LCD panels when poor contrast ratios were common it's very obvious that xbacklight is only affecting pixels. I've never seen this tool affect the actual backlight but maybe it does have that mode? Your script is essentially using the same method although in theory it's not as portable since the path is exact and it uses a hardcoded interval, you may have to tweak both for different machines. My one uses bash path expansion that is more likely to match other path names, and derives the interval from the max value... I honestly haven't looked at the variety of possible paths for /sys/class/backlight and max values so maybe I was over anticipating when i wrote this.
      • ColanR 7y ago
        Interesting. Thanks for the explanation. And I agree, my script isn't that flexible. I believe that " | tee" was left in there from when I tried to skip the sudoers entry...it's definitely not pretty.
• ravar 7y ago
  one hacky way to configure it is too install xfce4-power-manager and then run it in your config file. then the power manager will also handle the brightness keys.
  • Naac 7y ago
    What about sleep, display management when pluging in another monitor? etc.
    • riccardomc 7y ago
      I have a set of scripts that extend my screen to the right at max resolutions and reflows the workspaces in numeric order. It is generic enough to work with any number of displays. You might need X11 python bindings and other dependencies that in general should be available on most distros. See if it works for you, enjoy: https://github.com/riccardomc/rcs/blob/master/scripts/.scripts/display-config.sh https://github.com/riccardomc/rcs/blob/master/scripts/.scrip...
    • leeman2016 7y ago
      If you are looking for usage from just i3, I am using xrandr to enable/disable multi-monitor: $mod+Shift+p exec "xrandr --output HDMI1 --auto --right-of eDP1" (that with enable second screen through HDMI when Win+Shift+p is pressed) $mod+Shift+o exec "xrandr --output HDMI1 --off" (that disables second screen) bindsym $mod+Shift+x move workspace to output HDMI1 (that moves an entire workspace to the 2nd screen or any screen with the given id)
      • downtide 7y ago
        Shunting workspaces about is a great idea.
• dpbriggs 7y ago
  Not OP, but here are the lines my i3 config: bindsym XF86MonBrightnessDown exec "xbacklight -dec 10" bindsym XF86MonBrightnessUp exec "xbacklight -inc 10"