On Dell XPS 9510 laptops, accidental hand contact with the touchpad causes an exit and reboot

[tim-seoss]

On Dell a XPS 9510 (and presumably other related models) accidental contact with the touchpad whilst memtest86+ is running causes an exit and reboot.

The touchpad is quite large on this model of laptop, so it's easy to accidentally contact the touchpad when moving the laptop or typing (e.g. to configure memtest86+).

I thought it might be sending ESC somehow, but PassMark MemTest86 (which also responds to ESC during tests) doesn't seem to have the same behaviour on this laptop.

[martinwhitaker]

Is this UEFI or legacy boot?

[tim-seoss]

UEFI. It looks like the closed source PassMark software makes use of the pointer (I assume via UEFI mechanisms?), so perhaps activating that cancels this odd touchpad behaviour?

[martinwhitaker]

The PassMark software is a UEFI application, so has access to all the UEFI drivers and boot services. Memtest86+ is not. At the point it exits the UEFI boot services, the BIOS should unload any UEFI drivers and put the hardware in a safe state. Unless your touchpad identifies as a USB HID keyboard device, Memtest86+ will ignore it, but if the BIOS has left it active, anything may happen once its UEFI driver has been removed.

If you use the nightly build or build from source, you can use the usbdebug boot command line option to see how many keyboard devices Memtest86+ has found. I would be surprised if a touchpad identified as a keyboard, but who knows...

[tim-seoss]

The built-in keyboard doesn't show up as a usb keyboard. Booting with keyboard=usb and using an external keyboard stops the behaviour, so it looks like the trackpad-created keyboard events are coming in through the legacy interface. In Linux the input subsystem reports a PS/2 mouse detected /devices/platform/i8042/serio1/input/input3, and later on as an i2c device. I don't know how it's physically wired up, but I'm guessing that the device itself is i2c only, and the firmware is doing PS/2 mouse emulation in SMM, and that Linux then disables this by taking over the trackpad via the i2c interface.

I don't know what Linux is doing to detect it as a PS2 mouse, but maybe it would be possible for memtest86 to do something like the sequence described here:

https://wiki.osdev.org/%228042%22_PS/2_Controller#Detecting_PS/2_Device_Types

... to detect the mouse, and then disable any PS/2 ports which identify themselves as mice?

[martinwhitaker]

According to https://wiki.osdev.org/Mouse_Input, we should be able to distinguish between keyboard and mouse input by testing bit 5 of the PS/2 status register. Could you test this patch:

--- a/system/keyboard.c
+++ b/system/keyboard.c
@@ -248,9 +248,13 @@ char get_key(void)

     static bool escaped = false;
     if (keyboard_types & KT_LEGACY) {
-        uint8_t c = inb(0x64);
-        if (c & 0x01) {
-            c = inb(0x60);
+        uint8_t status = inb(0x64);
+        if (status & 0x01) {
+            uint8_t c = inb(0x60);
+            if (status & 0x20) {
+                // Ignore mouse events.
+                return '\0';
+            }
             if (escaped) {
                 escaped = false;
                 switch (c) {

[tim-seoss]

That works perfectly, thanks!

[mrbigmouth502]

Having the exact same problem, but on an HP Elitebook 840 G1. I'm booting the 64-bit Linux ISO from Ventoy in EFI mode.

[tim-seoss]

@mrbigmouth502 here's the test binary I built. You'll need to decompress it, and then it should be possible to boot it directly from ventoy. If you need to add commandline args then hit c to get a command line, and use something like linuxefi (hd0,msdos1)/memtest.efi usbdebug and then boot binary: memtest.efi.gz