Meu teclado gera eventos espúrios

Question

Eu tenho um problema chato usando o terminal e não posso procurar uma solução no Google porque não sei como expressá-lo.

Quando tenho carga de texto no terminal (por exemplo, após um dmesg) e tento rolar para cima para procurar o bit de texto em que estou interessado, após um período de tempo aleatório, o terminal rola automaticamente para baixo, onde o cursor é.

Além disso, notei que quando o xscreensaver está sendo executado, o login gui é exibido sem nenhuma entrada do teclado. E você sabe no xscreensaver lá é uma barra de "tempo decorrido" que lhe dá mais tempo (o aumento da barra) quando você inicia o digitação? Bem, isso aumenta uma vez sem qualquer contribuição minha ...

Eu pensei que eu tenho alguma entrada aleatória do teclado, mas como resolver esse problema chato?

Eu tenho tentado rastrear o evento gerado com o xev, mas é bem difícil.

No terminal, eu o resolvi temporariamente marcando "scroll on keyboard press", mas não é uma solução permanente razoável. Todo o sistema, como confirma o xscreensaver, é afetado.

É um laptop Acer Aspire e1-571g. Eu instalei recentemente o Funtoo. Ainda estou terminando de configurar o ad-hoc em cada peça do meu hardware.

Antes de instalar o Funtoo, eu tinha o Arch Linux e tudo estava funcionando bem, então eu não assumi nenhum problema com o hardware, mas apenas um problema com a configuração atual.

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

Alguma ideia / solução?

UPDATE : graças a Stéphane descobri que o dispositivo gera eventos espúrios é id = 5.

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

... e confirmo que também fiz:

xinput test-xi2 --root 5

e a saída é:

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

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

... ainda não sei como resolver. Eu também tentei desativá-lo, mas recebi um erro.

    

Answer 1

Isso não é um problema com um teclado real, mas com eventos-chave falsos enviados por xfce4-power-manager .

xfce4-power-manager está fingindo dummy (código-chave 255, não atribuído) eventos de teclado (pressionamento de tecla seguido de liberação de tecla, a cada 20 segundos de acordo com a fonte) para garantir que a proteção de tela não entra em ação quando no modo de apresentação (normalmente, quando você está assistindo a um filme ou fazendo uma apresentação).

Esse comportamento foi adicionado na versão 1.5.2 (última versão de 2015-01-06) para corrigir este bug para desativar todos os tipos possíveis de proteções de tela no modo de apresentação.

Isso tem aquele efeito colateral pelo qual você é afetado, e que foi já observado nesse bug .

Então, você gostaria de deixar esse modo de apresentação para evitar o problema. Esse problema provavelmente deve ser levantado como um bug contra o xfce4-power-manager, para que essa mudança seja revertida, ou uma correção melhor para # 11083 seja encontrada.

Tão interessante quanto a explicação para o problema é como acabamos encontrando o culpado:

xinput test-xi2 --root

Relata todos os eventos de entrada X, informando sua origem e natureza. O que levou a:

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

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

Essa é uma tecla pressionada seguida por um evento de lançamento de chave para o código de tecla 255 vindo do dispositivo 5.

xinput list nos permite identificar o dispositivo de entrada:

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

Esse dispositivo id = 5 é um dispositivo virtual que atua como fonte de eventos gerados por software, como você pode gerar com:

xdotool key x

ou

xte 'key x'

Se você executar o comando xte em ltrace , perceberá que:

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

Esse XTestFakeKeyEvent é a API X padrão para enviar esses eventos keypress.

Agora, queremos saber o que está enviando esses 255 eventos keypress. Podemos tentar descobrir quais dos aplicativos atualmente em execução usam essa API.

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

Ou seu equivalente mais robusto:

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

Lista os arquivos que estão atualmente abertos e mapeados como executáveis ( txt ) para qualquer processo (que inclua bibliotecas e executáveis) e grep para XTestFakeKeyEvent neles.

Isso retornou o xfce4-power-manager.

Tudo o que resta a fazer é procurar na fonte por que esse processo faz aqueles XTestFakeKeyEvent.