Can circumvent i3lock screen by using Super button in GNOME

[soamaven]

Using GNOME 3.22.2. After locking with i3lock, I am able to see the windows I have open by using the super key short cut. I feel like this should not be possible, correct?

[Airblader]

I assume that this is a compositing issue. Can you try running the patch from https://github.com/i3/i3lock/pull/96 and see if it still behaves that way?

[soamaven]

Sure, need to build from source, etc? As an amateur, it may take me a little bit of time, but I'll get back to you.

[Airblader]

Yes, you'll need to build that PR from source to test it. Let me know if you need help!

[soamaven]

make all gives:

Package xcb-atom was not found in the pkg-config search path.
Perhaps you should add the directory containing `xcb-atom.pc'
to the PKG_CONFIG_PATH environment variable
No package 'xcb-atom' found
Package xcb-image was not found in the pkg-config search path.
Perhaps you should add the directory containing `xcb-image.pc'
to the PKG_CONFIG_PATH environment variable
No package 'xcb-image' found
cc -std=c99 -pipe -Wall  -D_GNU_SOURCE -DVERSION=\""2.7-11-gac09db7 (2016-05-21)"\"  -c -o xinerama.o xinerama.c
Package xcb-atom was not found in the pkg-config search path.
Perhaps you should add the directory containing `xcb-atom.pc'
to the PKG_CONFIG_PATH environment variable
No package 'xcb-atom' found
Package xcb-image was not found in the pkg-config search path.
Perhaps you should add the directory containing `xcb-image.pc'
to the PKG_CONFIG_PATH environment variable
No package 'xcb-image' found
cc -std=c99 -pipe -Wall  -D_GNU_SOURCE -DVERSION=\""2.7-11-gac09db7 (2016-05-21)"\"  -c -o xcb.o xcb.c
xcb.c:11:27: fatal error: xcb/xcb_image.h: No such file or directory
 #include <xcb/xcb_image.h>
                           ^
compilation terminated.
<builtin>: recipe for target 'xcb.o' failed
make: *** [xcb.o] Error 1

Know which package I need? I can't find it via dnf search xcb-atom

[Airblader]

I assume you're on Fedora? I'm not familiar with Fedora, but you could take a look at how the i3lock Fedora package is built and simply modify the source it uses. It should be this here: http://pkgs.fedoraproject.org/cgit/rpms/i3lock.git/tree/

[soamaven]

Okay. Yes on Fedora. I know i3lock is most popular for Arch. I fell in love with some of the screen savers on r/unixporn, and thus am trying. Thanks for the help so far, I'll see what I can do!

[luebking]

Assuming the effective input is the main and bigger problem, it's probably the lack of XIGrabDevice/XIUngrabDevice, compare eg. https://git.reviewboard.kde.org/r/122558/diff/1#index_header

In case, as workaround export GDK_CORE_DEVICE_EVENTS=1 (to gnome, not i3lock)

[stapelberg]

Assuming the effective input is the main and bigger problem, it's probably the lack of XIGrabDevice/XIUngrabDevice, compare eg. https://git.reviewboard.kde.org/r/122558/diff/1#index_header

Thanks for the hint. Unfortunately, KDE’s reviewboard infrastructure seems to have vanished, but https://github.com/KDE/plasma-workspace/commit/23b6cfb14457063eb8121f97c2d5371b7e8fe3ed is the commit in question (the code itself has since moved to https://github.com/KDE/kscreenlocker/blob/dee0f3207ed1351236117c91a2b31b23b2d571df/ksldapp.cpp#L444).

The commit message mentions that XCB doesn’t provide xinput, which was true at the time, but has changed in libxcb 1.13 (see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733227).

We should most likely grab all keyboard/pointer devices via xinput.

[stapelberg]

Looking at this more closely, I think the xinput-specific code is only required when multiple input devices (?) are attached. As long as the xinput command shows only master pointer “Virtual core pointer” and master keyboard “Virtual core keyboard”, that should be covered by our existing code.

Does anyone have a setup where the xinput command shows more master keyboards/pointers than that? Can you paste your xinput output please?

[stapelberg]

Pushed branch https://github.com/i3/i3lock/commits/xinput with a work-in-progress, untested implementation. We can complete it once we’re convinced that xinput support is helping here.

[luebking]

The amount of devices doesn't matter. There're essentially 2 different and distinct input processing mechanisms and grabbing the keyboard through XGrabKeyboard will not prevent XI input processing (thus the user is able to access gnome-shell through a global shortcut which in this case will make the compositor to expose windows, but that's random. It could also wipe your drive or kill i3lock)

It is only that XInput is mandatory if you want to handle multiple input devices (eg. direct keyboard A to client X and keyboard B to client Y at the same time)

[stapelberg]

There're essentially 2 different and distinct input processing mechanisms and grabbing the keyboard through XGrabKeyboard will not prevent XI input processing

That directly contradicts the code you have linked, though: https://github.com/KDE/kscreenlocker/blob/dee0f3207ed1351236117c91a2b31b23b2d571df/ksldapp.cpp#L451

The way I read the code, grabbing the keyboard/pointer with plain X11 will also grab them for xinput. In fact, on my setup, where the only listed master devices are virtual core keyboard/pointer, I think that code is a no-op.

Am I missing something?