i3lock-blur
i3lock-blur copied to clipboard
karulont
Blurring not working with fglrx
I have a hybrid intel/amd laptop, which means I also have Intel and AMD GPUs. When using intel, i3lock -f works as expected. However when on AMD (using proprietary fglrx) it does not work. It blurs for a moment and then it probably crashes or something, as my screen is not locked and unblurred. I don't know how to debug this, so any suggestion is appreciated.
Hi, There are some stuff in file blur.c, which can be enabled by defining DEBUG_GL. This can be done by adding -DDEBUG_GL to CPPFLAGS in makefile.
Find line: CPPFLAGS += -DVERSION="${GIT_VERSION}" And replace it with this one: +CPPFLAGS += -DVERSION="${GIT_VERSION}" -DDEBUG_GL
After recompiling (make clean; make), i3lock should print some additional info to stdout.
Ok, here is what I get in stdout with ati: V Shader: 1 F Shader: 1 Program: 1
And this is what I get with intel (where it works as expected): V Shader: 1 shader_infolog: F Shader: 1 shader_infolog: Program: 1 shader_infolog: program_infolog: V Shader: 1 shader_infolog: F Shader: 1 shader_infolog: Program: 1 shader_infolog: program_infolog:
Don't see how this could help, but I hope it will. I'm available you need any more info/tests.
I looked at my code a little found out that actually there was a programming error on my part, which might trigger the crash by using ati driver.
I did a commit, which might fix it.
Just did git pull and tested. It didn't work :/ However using LD_DEBUG=libs i get the following errors: ./i3lock: error: symbol lookup error: undefined symbol: __glXSetTexBufferInfo (fatal) ./i3lock: error: symbol lookup error: undefined symbol: __glXgetGLXPixmapInfo (fatal)
Note that I also get those errors using LD_DEBUG=libs with other programs when I use ati card, (although the programs seem to work fine, like fgl_glxgears).
@karulont I just found out that for some reason ./i3lock -f --nofork works fine for me even with catalyst drivers. That is weird as --norfork option is not required with i915 driver.
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.