Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

i3 4.18

i3wm.org

Post reply on HN
Print view View original

181–188 of 188 posts

Re: i3 4.18

#181

Post by blux »

majewsky wrote: post #170
blux wrote: post #127

Earlier quoted context omitted.

Agree, I do not understand the need for more than one monitor as your eyes can only focus on one monitor at the same time anyway. It looks cool to have a bunch of monitors in front of you and of course eyes notice stuff going on in your peripheral vision as well but for that one could use some notifier daemon to get the same effect.

> your eyes can only focus on one monitor at the same time anyway True, but peripheral vision is a thing. I have Slack and stuff on a separate monitor, so I can see from the corner of my eye if there are any unreads.

I agree, but as I said, you can have some notification daemon or tray icon to achieve the same.

Re: i3 4.18

#182

Post by raoof »

shabble wrote: post #126
raoof wrote: post #33

I'm using i3 for a long time, the only feature I'm really missing is `bindsym j [class="google-chrome"] xdotool key Down` so I can make vi like key binding for every program that I use.

If you're still looking, I quite like XKeysnail ( https://github.com/mooz/xkeysnail ) for that, although it does occasionally get confused. It does seem like it's something a WM should be capable of though.

thanks I'll look into it

Re: i3 4.18

#183

Post by blaser-waffle »

city41 wrote: post #27
mbreedlove wrote: post #25

Earlier quoted context omitted.

I used i3 for a while and really enjoyed it. Though, I eventually switched back to KDE. I didn't like having to fiddle with power management and configuring screen locking. I was noticing that I was only using 1-2 tiles at a time and I could easily emulate that by just side-by-siding windows in KDE. I think if I ever have the chance to use a Linux machine professionally, especially with multiple monitors, I'll defini…

i3 couples with desktop environments rather nicely. I've used it with KDE and MATE, and others have used it successfully with XFCE. My success with it with KDE was a little mixed, but I also didn't make any effort to resolve the little issues. With MATE though, it works flawlessly with no downsides or really any config needed. It's fantastic. Here is how I set it up with MATE: https://www.mattgreer.org/articles/mate-…

Cheers for the MATE panel applet you put together (that's in the blog post): https://github.com/city41/mate-i3-applet

Also, got any pictures of the desktop?

Re: i3 4.18

#184

Post by tomxor »

aunetx wrote: post #134
tomxor wrote: post #131

Earlier quoted context omitted.

> getting full integration to work on their laptop ( sleep, screen brightness, etc. ) I managed to golf some tiny generic inline bash scripts that fit directly inside my i3 config for screen brightness and keyboard brightness using /sys/class with generic name matching and no hardcoded values. They do require an external sudoers entry for each /sys/class unfortunately but that's because they require root perms by def…

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

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  $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  $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.

Re: i3 4.18

#185

Post by ColanR »

tomxor wrote: post #184
aunetx wrote: post #134

Earlier quoted context omitted.

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

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 $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 - $ma…

> 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

Re: i3 4.18

#186

Post by qzx_pierri »

capableweb wrote: post #116
qzx_pierri wrote: post #44

Earlier quoted context omitted.

Why change if Awesome works for you?

Just because it works doesn't mean there isn't better things out there. Wouldn't change if the benefits are not greater, obviously, but I find it healthy to always reconsider past choices every now and then.

true. I never thought about it that way.

Re: i3 4.18

#187

Post by tomxor »

ColanR wrote: post #185
tomxor wrote: post #184

Earlier quoted context omitted.

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 $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 - $ma…

> 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…

> 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.

Re: i3 4.18

#188

Post by ColanR »

tomxor wrote: post #187
ColanR wrote: post #185

Earlier quoted context omitted.

> 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…

> 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:…

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.
Post reply on HN