My keyboard generates spurious events

Question

I have an annoying problem using the terminal and I cannot look for a solution on Google because I don't know how to phrase it.

When I have load of text on terminal (for instance after a dmesg) and I try to scroll up to look for the bit of text I am interested in, after a random amount of time the terminal automatically scrolls down where the cursor is.

Also, I noticed that when xscreensaver is running, the login gui comes out without any input from keyboard. And do you know in xscreensaver there is an "elapsing time" bar that gives you more time (the bar increase) when you start type in? Well, it increase once without any input from me...

I thought I have some random input from the keyboard, but how to solve this annoying problem?

I have been trying to track down the event generated with xev but it is quite difficult.

On the terminal I have temporarily solved it by un-ticking "scroll on keyboard press", but it is not a reasonable permanent solution. The whole system, as xscreensaver confirms, is affected.

It is a laptop Acer Aspire e1-571g. I recently installed Funtoo. I am still finishing to configure ad-hoc every single piece of my hardware.

Before installing Funtoo I had Arch Linux and everything was working fine, so I assume no issue with the hardware, but just a problem with the current configuration.

cpu:                                                            
                   Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 1383 MHz
                   Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 1400 MHz
                   Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 1350 MHz
                   Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 1472 MHz
keyboard:
  /dev/input/event4    AT Translated Set 2 keyboard
mouse:
  /dev/input/mice      SynPS/2 Synaptics TouchPad
graphics card:
                       Intel 3rd Gen Core processor Graphics Controller
                       nVidia VGA compatible controller
sound:
                       Intel 7 Series/C210 Series Chipset Family High Definition Audio Controller
storage:
                       Intel 7 Series Chipset Family 6-port SATA Controller [AHCI mode]
network:
  eth0                 Broadcom NetLink BCM57785 Gigabit Ethernet PCIe
  wlan0                Intel Centrino Wireless-N 105 BGN
network interface:
  wlan0                WLAN network interface
  lo                   Loopback network interface
  eth0                 Ethernet network interface
  sit0                 Network Interface
disk:
  /dev/sda             KINGSTON SH103S3
partition:
  /dev/sda1            Partition
  /dev/sda2            Partition
  /dev/sda3            Partition
  /dev/sda4            Partition
cdrom:
  /dev/sr0             HL-DT-ST DVDRAM GT51N
usb controller:
                       Intel 7 Series/C210 Series Chipset Family USB xHCI Host Controller
                       Intel 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2
                       Intel 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1
bios:
                       BIOS
bridge:
                       Intel 3rd Gen Core processor DRAM Controller
                       Intel Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port
                       Intel 7 Series/C210 Series Chipset Family PCI Express Root Port 1
                       Intel 7 Series/C210 Series Chipset Family PCI Express Root Port 2
                       Intel HM77 Express Chipset LPC Controller
hub:
                       Linux 4.3.0-gentoo ehci_hcd EHCI Host Controller
                       Hub
                       Linux 4.3.0-gentoo ehci_hcd EHCI Host Controller
                       Hub
                       Linux 4.3.0-gentoo xhci-hcd xHCI Host Controller
                       Linux 4.3.0-gentoo xhci-hcd xHCI Host Controller
memory:
                       Main Memory
unknown:
                       FPU
                       DMA controller
                       PIC
                       Keyboard controller
                       PS/2 Controller
                       Intel 7 Series/C210 Series Chipset Family MEI Controller #1
                       Intel 7 Series/C210 Series Chipset Family SMBus Controller
                       Broadcom NetXtreme BCM57765 Memory Card Reader
                       Broadcom System peripheral
                       Broadcom System peripheral
                       Chicony Electronics HD WebCam

Any idea/solution?

UPDATE: thanks to Stéphane I found out the device the generates spurious events is id=5.

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

...and to confirm I also did:

xinput test-xi2 --root 5

and the output is :

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

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

...still don't know how to solve. I've tried also to disable it but I got an error.

Answer 1

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.