Eu tive um problema estranho aqui - o mouse sináptico integrado/o mouse de borracha não funciona no Linux.
O mouse/mousepad integrado só funciona desde que o Windows os tenha ativado primeiro. Eu posso fazer muitas reinicializações no Linux e elas continuam funcionando. Eles serão reconhecidos desde que o notebook não tenha perdido energia.
Se o notebook descarregar toda a bateria, só poderei usar o mousepad/mouse novamente se inicializar primeiro no Windows .
Assim posso reproduzir o bug facilmente tirando a bateria enquanto o Linux está rodando. Dessa forma, o mousepad não será reconhecido até que eu inicialize no Windows novamente. Portanto, parece que os drivers de código aberto não são capazes de reconhecer o dispositivo quando o hardware está em um estado desconhecido (inicialização).
Estou usando o Debian 9/Antix 17.1 em um Lenovo ThinkPad E560 2016, CPU i7-6500U @ 2,50 GHz, 16 GB de RAM e um disco SSD.
A máquina tem dual card, porém eu desativei a radeon radeon.modeset=0
nos parâmetros do kernel. Então os parâmetros relevantes são:
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)
Meus xserver-xorg
pacotes relevantes são:
xserver-xorg - 7.7+19
xserver-xorg-core - 1.19.2-1.0nosystemd2
xserver-xorg-input-libinput - 0.23.0-2
xserver-xorg-input-synaptics - 1.9.0-1+b1
xserver-xorg-video-intel - 2.99.917+git20161206-1
Já tentei rodar os kernels Debian stock presentes nos repositórios Antix, 4.10.5-antix.3-amd64-smp
e 4.18.4-antix.1-amd64-smp
sem nenhuma alteração nos sintomas; como @StephenKitt me disse que havia mudanças no manuseio de sinápticos em versões mais recentes.
Meus parâmetros atuais do kernel são:
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.18.4-antix.1-amd64-smp root=UUID=00c17984-859f-4197-8bd8-b346ddd092bd ro iommu=1 intel_iommu=on iommu=pt ipv6.disable=1 intremap=no_x2apic_optout radeon.modeset=0
Também segui algumas recomendações online para alterar no xorg o manuseio do mousepad de xserver-xorg-input-synaptics para xserver-xorg-input-libinput, instalando o último e fazendo:
cd /etc/X11/xorg.conf.d
ln -s /usr/share/X11/xorg.conf.d/40-libinput.conf
Os sintomas permanecem inalterados.
Eu também fui no Gerenciador de dispositivos no Windows 10 para ver o nome do dispositivo / driver e é um mouse duplo / teclado de borracha chamado "Ultranav". libinput-list-devices
também o nomeia como "AlpsPS/2 ALPS DualPoint TouchPad". Alguns outros também chamam outros modelos da Lenovo deste mouse Elantech.
Eu também instalei libinput-tools
para depurar a situação. Curiosamente, executando o comando libinput-list-devices
o mouse é visto depois de ter executado o Windows, e antes que ele não exista.
Já tenho sugestões de preencher um bug com a equipe do kernel.
O que fazer?
Os dmidecode
dados relevantes sobre o fabricante e o modelo são:
# dmidecode -s system-manufacturer
LENOVO
# dmidecode -s system-product-name
20EV000YPG
# dmidecode -s system-version
ThinkPad E560
A diferença entre libunput-list-devices
antes e depois de inicializar o Windows 10.
$ diff libunput-list-devices-before_windows.txt after-windows.txt
2c2
< Kernel: /dev/input/event8
---
> Kernel: /dev/input/event10
20c20
< Kernel: /dev/input/event10
---
> Kernel: /dev/input/event12
38c38
< Kernel: /dev/input/event7
---
> Kernel: /dev/input/event9
128c128
< Kernel: /dev/input/event18
---
> Kernel: /dev/input/event20
163,164c163,164
< Device: ThinkPad Extra Buttons
< Kernel: /dev/input/event9
---
> Device: AlpsPS/2 ALPS DualPoint Stick
> Kernel: /dev/input/event6
165a166,202
> Seat: seat0, default
> Capabilities: pointer
> Tap-to-click: n/a
> Tap-and-drag: n/a
> Tap drag lock: n/a
> Left-handed: disabled
> Nat.scrolling: disabled
> Middle emulation: disabled
> Calibration: n/a
> Scroll methods: *button
> Click methods: none
> Disable-w-typing: n/a
> Accel profiles: flat *adaptive
> Rotation: n/a
>
> Device: AlpsPS/2 ALPS DualPoint TouchPad
> Kernel: /dev/input/event7
> Group: 7
> Seat: seat0, default
> Size: 97.50x53.87mm
> Capabilities: pointer
> Tap-to-click: disabled
> Tap-and-drag: enabled
> Tap drag lock: disabled
> Left-handed: disabled
> Nat.scrolling: disabled
> Middle emulation: disabled
> Calibration: n/a
> Scroll methods: *two-finger edge
> Click methods: *button-areas clickfinger
> Disable-w-typing: enabled
> Accel profiles: none
> Rotation: n/a
>
> Device: ThinkPad Extra Buttons
> Kernel: /dev/input/event11
> Group: 8
Curiosamente, pesquisando variações de palavras do bug, incluindo Lenovo, Alps e Ultranav, encontrei um artigo sugerindo parâmetros do kernel na postagem no wiki do Arch Linux libinput
Fiz então alguns testes, e descobri que no meu caso bastava adicionar o parâmetro do kernel
i8042.reset
noGRUB_CMDLINE_LINUX_DEFAULT
arquivo/etc/default/grub
e executar:Depois disso, tirei a bateria para tentar replicar o bug. Após a máquina morrer e reiniciar o Linux, o mouse interno Ultranav/Elantech já foi reconhecido e funcionou de primeira, sem a necessidade de iniciar o Windows 10 primeiro.
Eu diria que isso se qualifica como um bug do kernel.
Da mesma forma que outros notebooks, o Lenovo Thinkpad precisa ser adicionado à lista de reinicialização i8042 de dispositivos no kernel Linux, onde há uma lista de máquinas da família que precisam da reinicialização do chipset i8042 para detectar consistentemente seu Elantech TouchPad.
Encontrei esse requisito posterior ao encontrar essas entradas de bug Entrada: i8042 - adicione Lenovo LaVie Z à lista de redefinição i8042 e Entrada: i8042: adicione Lenovo ThinkPad L460 à lista de redefinição i8042
Da inspeção visual do código-fonte do kernel Linux, o código-fonte para adicionar o Lenovo ThinkPad E560 à lista de redefinição do i8042 também não está presente nas fontes do kernel 4.19-rc2 mais recentes.
Então, para adicioná-lo, escrevi um diff/patch simples que pode ser usado em vez de usar o parâmetro do kernel i8042.reset no grub:
PS. Seguindo a sugestão do @StephenKitt, tentei enviar este post como um relatório de bug do kernel Linux para [email protected]