Linux – How to disable keyboard

Disable device

Here's one idea towards identifying which keyboard is which. You can use the command xinput to enable and disable devices.

Example

$ xinput list
⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad                id=12   [slave  pointer  (2)]
⎜   ↳ TPPS/2 IBM TrackPoint                     id=13   [slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver                     id=9    [slave  pointer  (2)]
⎜   ↳ Logitech USB Receiver                     id=10   [slave  pointer  (2)]
⎣ Virtual core keyboard                     id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Sleep Button                              id=8    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=11   [slave  keyboard (3)]
    ↳ ThinkPad Extra Buttons                    id=14   [slave  keyboard (3)]

The above output shows the various devices that I have on my Thinkpad laptop. I only have 1 keyboard attached, this one:

    ↳ AT Translated Set 2 keyboard              id=11   [slave  keyboard (3)]

Now take a look at the properties available through this device:

$ xinput list-props "AT Translated Set 2 keyboard"
Device 'AT Translated Set 2 keyboard':
    Device Enabled (124):   1
    Coordinate Transformation Matrix (126): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.

From the above you can see that it's enabled, so let's disable it:

$ xinput set-prop "AT Translated Set 2 keyboard" "Device Enabled" 0

To enable it:

$ xinput set-prop "AT Translated Set 2 keyboard" "Device Enabled" 1

The idea?

You could enable disable one of the keyboards using this command to determine which one you're on.

References

• second keyboard to run commands

That's not a problem with a real keyboard but with fake key events sent by xfce4-power-manager.

xfce4-power-manager is faking dummy (keycode 255, unassigned) keyboard events (keypress followed by keyrelease, every 20 seconds according to the source) to make sure the screen saver doesn't kick in when in presentation mode (typically, when you're watching a film or giving a presentation).

That behaviour was added in 1.5.2 (latest release as of 2015-01-06) to fix this bug to disable all possible types of screen savers when in presentation mode.

That has that side effect you're affected by, and which was already noted at that bug.

So, you'd want to leave that presentation mode to avoid the problem. That issue should probably be raised as a bug against xfce4-power-manager so that change be reverted, or a better fix to #11083 be found.

As interesting as the explanation to the problem is how we ended up finding the culprit:

xinput test-xi2 --root

Reports all X input events, telling us their source and nature. Which led to:

EVENT type 13 (RawKeyPress)
    device: 5 (5)
    detail: 255
    valuators:

EVENT type 14 (RawKeyRelease)
    device: 5 (5)
    detail: 255
    valuators:

That is a key press followed by a key release event for keycode 255 coming from device 5.

xinput list lets us identify the input device:

⎣ Virtual core keyboard                      id=3    [master keyboard (2)]
 ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]

That id=5 device is a virtual device that acts as source for software generated events like you can generate with:

xdotool key x

or

xte 'key x'

If you run that xte command under ltrace, you'll notice it does:

XStringToKeysym(0x7ffed76983e0, 0x7ffed76983e0, 0, 0x7f34e491deb0) = 120
XKeysymToKeycode(0x23abfe0, 120, 120, 0x7f34e4ce7139)              = 53
XTestFakeKeyEvent(0x23abfe0, 53, 1, 0)                             = 1

That XTestFakeKeyEvent is the standard X API to send those keypress events.

Now, we want to know what is sending those 255 keypress events. We can try and find which of the currently running applications use that API.

sudo lsof -Fn -nPd txt | sed -n '/proc/!s/^n//p' | sort -u | xargs grep -l XTestFakeKeyEvent

Or its more robust equivalent:

sudo lsof -Fn -nPd txt | sed -n '/^n\/proc/!s/^n//p' |
  sort -u | xargs -d '\n' grep -l XTestFakeKeyEvent

Lists the files that are currently open and mmapped as executable (txt) to any process (that includes libraries and executables) and grep for XTestFakeKeyEvent in them.

That returned xfce4-power-manager.

All was left to do is look in the source for why that process does those XTestFakeKeyEvent.