Closed skmexyz closed 7 years ago
I'm having similar problems when compton is on. When it's off, everything works correctly, but when it's on, the locker doesn't completely blank my screen until a key is pressed, the X process starts using a bunch of CPU, and keypresses are slow, like you described.
Quick guess: It might be this commit: https://github.com/i3/i3lock/commit/80d4452ec680bcb0e57418f69d44d88ded82047c Try applying this patch, which reverts the commit: http://chunk.io/f/dff8163151934a5ca20a86f61211372c.patch (or revert it manually with git revert, and resolve the conflict in Makefile)
At least, reverting this commit fixed it for me.
There's been a couple of people who've poked on my fork's issues about compositors, so I guess I'll chime in here (maybe I should make a separate issue? Not sure if these should fall under this or not).
A few people are having problems with compositors not properly dealing with i3lock in a few ways - sometimes the compositor doesn't clean up after i3lock or something, and sometimes compositors cause flickering and stuff in i3lock.
All of their issues have been present in xsecurelock, so whatever's going on, it's probably something wholly with the compositor, and not a locking program.
Personally, I've had no issues using compton (with a fairly minimal config): i3lock works fine on top of it, notifications don't show up, and there's no graphical issues during or after. Apparently that's not the case across the board, though.
I've put a --no-composite
argument into my fork for now (see https://github.com/chrjguill/i3lock-color/commit/d9f2e04bab3c5f2bed674edd085355da255f892b); I don't think it's good enough to go into upstream i3lock, though, since it just feels... hacky.
I've been messing with my compton config, and I've noticed that the cause for this problem is compton's fading option. When that's disabled, the screen is properly blanked. However, even with a completely "clean" compton config, the X process starts using a bunch of CPU, and there's the input lag. Like @chrjguill said, though, I'm sure it's a problem with the compositor, not so much the locker.
@sandsmark Is this issue related to your https://github.com/i3/i3lock/pull/96?
Same issue for me these past days... takes up to 6 seconds before removing the lock screen v2.9-1 on archlinux.
Verified that killing compton fixes the issue.
what compositors, versions of the compositors, and mesa drivers do you all use?
@sandsmark compton-git-316eac0 (2017-04-30) xf86-video-intel-git_20160601_b617f80 mesa-11.2.2 I might need updates on some of these, but that's what I use.
The same problem happens with xcompmgr.
Versions: xcompmgr 1.1.7-2 mesa 17.1.2-1 xf86-video-intel 2.99.917+777+g6babcf15-1
Same here, xcompmgr 1.1.7, mesa 17.1.2, xorg-drivers 1.19 (modesetting ddx on intel).
Can anyone here please test again with the current HEAD? We just merged the reversal of #96 and I assume this fixes it.
Looks good. Snappy as ever. Thanks.
Thanks for the feedback!
Works now!
still super slow for me, built from 3009ab422d136b8aefda080f585e51cd8d93b7fd
@hossbeast In that case please open a new issue and bisect where the problem starts.
I'm having this issue on Ubuntu 17.10 with i3-gaps. Not sure where to go from here... I didn't have compton, and after installing and running compton, the issue remains.
I am using i3lock (version: 2.9-1~~xenial1) from the http://debian.sur5r.net/i3 repo and it appears to be extremely slow after the latest update (I've rebooted just to be sure). I am using it on Ubuntu 16.04.
it's slow: