My keyboard generates spurious events

keyboard

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.

Best Answer

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

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.

Related Solutions

Second Keyboard – How to Use for Running Commands

This is my third answer when I can recommend actkbd... :)

So if you want to configure all keys of second keyboard to run commands not to type letters you can use actkbd... :)

After installing actkbd we need to find what device file is used to receive events from out keyboard:

pbm@tauri ~ $ cat /proc/bus/input/devices 
[cut]
I: Bus=0003 Vendor=046d Product=c31c Version=0110
N: Name="Logitech USB Keyboard"
P: Phys=usb-0000:00:1a.0-1.1/input0
S: Sysfs=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0/input/input7
U: Uniq=
H: Handlers=sysrq kbd event5 
B: PROP=0
B: EV=120013
B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=1f

I: Bus=0003 Vendor=046d Product=c31c Version=0110
N: Name="Logitech USB Keyboard"
P: Phys=usb-0000:00:1a.0-1.1/input1
S: Sysfs=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1/input/input8
U: Uniq=
H: Handlers=kbd event6 
B: PROP=0
B: EV=1b
B: KEY=2010000 397ad801d001 1e000000000000 0
B: ABS=100000000
B: MSC=10
[cut]

On this list you should find your keyboard, and check it handlers. Use sudo actkbd -s -d /dev/input/HANDLER_NAME to check if that handler send events. If you run this command and press key on keyboard (check for keys that you want to bind to commands) you should get something like that:

pbm@tauri ~ $ sudo actkbd -s -d /dev/input/event5 
Keys: 57
Keys: 35

If you have keycodes we could create actkbd config file:

pbm@tauri ~ $ sudo nano /etc/actkbd.conf 
30:::sudo -u pbm DISPLAY=:0 amarok
//30 is keycode for letter a

When you save that file we should test if configuration works:

pbm@tauri ~ $ sudo actkbd -d /dev/input/event5 -D

When you press key that you have in your config file command from last column of config file will be started.

I think that there is a way to disable sending keys to applications, but I was unable to find it - check out README file.

Instead of trying to disable it using actkbd you could turn off your keyboard in X.

pbm@tauri ~ $ xinput list
[cut]
    ↳ Logitech USB Keyboard                     id=12   [slave  keyboard (3)]
    ↳ Logitech USB Keyboard                     id=11   [slave  keyboard (3)]
pbm@tauri ~ $ xinput set-prop 11 "Device Enabled" 0
pbm@tauri ~ $ xinput set-prop 12 "Device Enabled" 0

It should do the work... :) For more information about actkbd check out this answer.

Using actkbd (and few scripts probably) you can also configure your keyboard to change modes from command mode to input mode with Russian letters. For this read Ulrich Schwarz's answer.

Make Key Bindings Send Keyboard Events in Awesome Window Manager

You would do this via Xmodmap and not via your window manager. This is directly related to your keyboard layout/keymap and not your window manager.

To change your xmodmap create a file named ~/.Xmodmap and add the following content. This should allow you to to type üäöß directly with altgr+u

keysym a = a A adiaeresis Adiaeresis
keysym o = o O odiaeresis Odiaeresis
keysym u = u U udiaeresis Udiaeresis
keysym s = s S ssharp section

Afterwards you have to apply the content from this file with xmodmap ~/.Xmodmap

Another way to input umlauts is to use the us international layout. This allows you to enter umlauts with " + char. To enter ä you would need to enter "a. The international layout is also available in Windows and as far as i know in OSX.

setxkbmap -layout us -variant intl

Best Answer

Related Solutions

Second Keyboard – How to Use for Running Commands

Make Key Bindings Send Keyboard Events in Awesome Window Manager

Related Question