Page MenuHomeFreeBSD

evdev: Extend EVIOCGRAB ioctl scope to cover kbd/sysmouse interfaces
ClosedPublic

Authored by wulf on May 29 2021, 1:12 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 7 2024, 11:38 PM
Unknown Object (File)
Jan 29 2024, 4:50 AM
Unknown Object (File)
Jan 29 2024, 4:50 AM
Unknown Object (File)
Jan 29 2024, 4:50 AM
Unknown Object (File)
Jan 29 2024, 4:36 AM
Unknown Object (File)
Dec 17 2023, 5:33 PM
Unknown Object (File)
Dec 10 2023, 9:24 PM
Unknown Object (File)
Oct 10 2023, 7:43 PM
Subscribers

Details

Summary

EVIOCGRAB ioctl execution on /dev/input/event# device node gains exclusive
access to this device. It is used mostly for development purposes and
remote control software. See e.g. https://reviews.freebsd.org/D30020
which is the reason of creation of this patch.

Extending EVIOCGRAB to kbd interface increases chances of foot shooting
as terminal control commands in K_CODE and K_XLATE modes are ignored.
So runnig of libinput debug-events --grab will effectively break all
inputs, but that behavior is consistent with what we have in Xorg server.

To reduce negative effects grabbing is disabled in KDB and during panics.

Test Plan

run in vt console # libinput debug-events --grab
than ensure that no symbols are echoed to the screen on keypresses.
Only libinput events are shown.
Don't forget to open remote ssh session to kill libinput or you will need
to push reset button otherwise.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 39561
Build 36450: arc lint + arc unit

Event Timeline

wulf requested review of this revision.May 29 2021, 1:12 PM
wulf created this revision.

Ping. What's the state of this commit? The issue still exists.
I've tested this commit some time ago and it worked. I'm going to test it again.

This revision was not accepted when it landed; it landed in state Needs Review.Nov 17 2022, 9:52 PM
This revision was automatically updated to reflect the committed changes.

I forgot about this revision. Sorry.
Mouse part has been committed. Let me know if keyboard part is needed too.

In D30542#850947, @wulf wrote:

I forgot about this revision. Sorry.
Mouse part has been committed. Let me know if keyboard part is needed too.

Thanks. Yes, the keyboard part is even more important.