4

I have had a strange problem here - the integrated synaptic mouse/the rubber mouse does not work in Linux.

The integrated mouse/mousepad only works as long Windows has activated them firstly. I can do many reboots in Linux and they do keep working. They will be recognized as long the notebook has not lost power.

If the notebook depletes all battery, I will only able to use the mousepad/mouse again if I boot in Windows firstly.

So I can reproduce the bug easily taking the battery out while Linux is running. In that way, the mousepad won't be recognized until I boot up in Windows again. So it seems the opensource drivers are not able to recognized the device when the hardware it is in an unknown (initialization) state.

I am using Debian 9/Antix 17.1 in a 2016 Lenovo ThinkPad E560, i7-6500U CPU @ 2.50GHz, 16GB of RAM and an SSD disk.

The machine has a dual card, however I deactived the radeon with radeon.modeset=0 in the kernel parameters. So the relevant parameters are:

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)

My xserver-xorg relevant packages are:

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

I already tried running the stock Debian kernels present in the Antix repositories, 4.10.5-antix.3-amd64-smp and 4.18.4-antix.1-amd64-smp without any changes in symptoms; as @StephenKitt told me there were changes on synaptics handling on newer versions.

My current kernel parameters are:

$ 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

I also followed some recommendations online to change in xorg the mousepad handling from xserver-xorg-input-synaptics to xserver-xorg-input-libinput, installing the latter, and doing:

 cd /etc/X11/xorg.conf.d
 ln -s /usr/share/X11/xorg.conf.d/40-libinput.conf 

The symptoms remain unchanged.

I went also to in Device Manager in Windows 10 to see the name of the device/driver and it is a dual mouse mousepad/keyboard rubber-thingy called "Ultranav". libinput-list-devices also names it as "AlpsPS/2 ALPS DualPoint TouchPad". Some others also call in other Lenovo models this mouse Elantech.

I also installed libinput-tools to debug the situation. Interestingly enough, running the command libinput-list-devices the mouse is seen after having run Windows, and before it is as it does not exist.

I already have suggestions of filling up a bug with the kernel team.

What to do?

The relevant dmidecode data about the maker and model is:

# dmidecode -s system-manufacturer
LENOVO
# dmidecode -s system-product-name
20EV000YPG
# dmidecode -s system-version
ThinkPad E560

The difference in libunput-list-devices before and after booting 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
  • Strange that the E560 has been awarded the status of certified pre-install for Ubuntu. certification.ubuntu.com/hardware/201605-22009 – user8779 Sep 6 '18 at 9:25
  • @arochester More stranger yet when the radeon is even more problematic than the mousepad. – Rui F Ribeiro Sep 6 '18 at 16:41
4

Interestingly enough, searching on variations of words of the bug, including Lenovo, Alps, and Ultranav, I found an article suggesting kernel parameters on the post in the Arch Linux wiki libinput

Touchpad not detected at all

Notes: Not a libinput issue. An explanation of the parameters is linked in Touchpad_Synaptics#No_Multi-touch_in_some_Elantech_touchpads, which is much better than saying "try some of these".

If a touchpad device is not detected and shown as a device at all, a possible solution might be using one or more of these kernel parameters.

i8042.noloop i8042.nomux i8042.nopnp i8042.reset

I made then some tests, and found in my case it was enough to add the kernel parameter i8042.reset to GRUB_CMDLINE_LINUX_DEFAULT in the /etc/grub/default file and run:

update-grub2

After that, I took out the battery to try to replicate the bug. After the machine dying and rebooting Linux, the Ultranav/Elantech internal mouse already was recognized and worked at first, without needing to go through booting Windows 10 firstly.

I would say that this qualifies as a kernel bug.

Similarly to other notebooks, the Lenovo Thinkpad needs to be added to i8042 reset list of devices in the Linux kernel, where there is a list of family machines that need the i8042 chipset reset in order to consistently detect its Elantech TouchPad.

I found this later requirement upon finding these bug entries Input: i8042 - add Lenovo LaVie Z to the i8042 reset list and Input: i8042: add Lenovo ThinkPad L460 to i8042 reset list

From visual inpection of the Linux kernel source code, the source code for adding the Lenovo ThinkPad E560 to the i8042 reset list is also not present in the latest 4.19-rc2 kernel sources.

So for adding it, I wrote a simple diff/patch that can be used instead of using the i8042.reset kernel parameter in grub:

--- drivers/input/serio/i8042-x86ia64io.h.old   2018-09-06 04:53:36.460003164 +0100
+++ drivers/input/serio/i8042-x86ia64io.h   2018-09-06 04:57:16.833465129 +0100
@@ -655,6 +655,14 @@
            DMI_MATCH(DMI_PRODUCT_NAME, "P65xRP"),
        },
    },
+   {
+                /* Lenovo ThinkPad E560 */
+                .matches = {
+                        DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+                        DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad E560"),
+                },
+        },
+
    { }
 };

PS. Following @StephenKitt suggestion, I have tried sending this post as a Linux kernel bug report to linux-input@vger.kernel.org

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.