X11 errors when blurring about i3lock-blur HOT 6 OPEN

I am running Arch Linux with i3wm, with an Intel CPU and Intel integrated graphics card, and while I don't get the same glitches as elonus, i3lock-blur does makes my screen glitch for a few seconds when started over certain windows, like qutebrowser.

Also, regardless of the glitch, using plain i3lock --debug works fine, no output on stderr, no errors, no glitches, but using i3lock --fuzzy --debug gives a bunch of error messages, virtually the same as posted by Elonus:

X11 Error received! sequence 0x106, error_code = 8, major = 0x3e, minor = 0x0
X11 Error received! sequence 0x107, error_code = 8, major = 0x3e, minor = 0x0
X11 Error received! sequence 0x108, error_code = 8, major = 0x3e, minor = 0x0
[...]
X11 Error received! sequence 0x[NUM], error_code = 8, major = 0x3e, minor = 0x0

...where [NUM] goes higher (up to 5000 and beyond) the longer I leave the i3lock running.

So, even if it the error above was a local issue, I believe it should be worthwhile to look into these error messages, as they aren't happening on vanilla i3lock, and they could indicate some deeper error.

Here's the full log from i3lock --fuzzy --debug 2> debug-log.txt:
debug-log.txt

EDIT:
AUR package version:
i3lock-blur 2.9-1
i3lock: version 2.9 (2017-02-03) © 2010 Michael Stapelberg

from i3lock-blur.

@elonus

When I do "i3lock -f" it will show a blurred screenshot as expected. However it seems to stop workin after that. It will just show the screenshot and not any lock symbol. And when I try to type my password to unlock the screen nothing happens. Neither any indication on the lockscreen that it registered me typing nor unlocking the screen. I have to go to another tty to kill the process. When I run "i3lock -f --debug" I get these errors:

I have the same problem. Using the option "--nofork" as suggested in #6 solves this problem for me.

from i3lock-blur.

@tmlrbgfz do you think --fuzzy should imply --nofork?

As for others, if you still have problems even with using --nofork, let me know. We also have an option to blur only once called --once.

from i3lock-blur.

@karulont I'd consider that bad style. I too am running an AMD GPU, so that change would unnecessarily break the forking feature when using the --fuzzy option for people not running AMD GPUs.

From #6

Probably the driver does something funky with the process ID. And after a fork the process ID changes.
To be more accurate: parent process will open up a connection to Xserver and does some stuff. Then a fork happens and the child remains. However child has a different Process ID than the parent, which opened the connection to Xserver.

Could you try to do all interaction with the Xserver after forking?

from i3lock-blur.

@tmlrbgfz Doing all interactions with the Xserver from the child process defeats the purpose of forking.

The forking feature:

i3lock forks, so you can combine it with an alias to suspend to RAM (run "i3lock && echo mem > /sys/power/state" to get a locked screen after waking up your computer from suspend to RAM)

i3lock should fork only when the screen is locked. Screen cannot be locked without interacting with the Xserver.

However, it might be possible to lock the screen from the parent process, then fork, and from the child process, initialize the blurring and OpenGL context. That way the process ID should stay the same for the OpenGL context.

from i3lock-blur.

@karulont That sounds like a good idea!

i3lock should fork only when the screen is locked. Screen cannot be locked without interacting with the Xserver.

True, but using IPC the child could signal successful screen locking to the parent. I forked this project and hacked something like that using System V semaphores. Not beautiful but does the job.
Your idea seems more elegant, however, so that should be investigated.

from i3lock-blur.