memtest86plus / memtest86plus

Official repo for Memtest86+
https://memtest.org
GNU General Public License v2.0
1.08k stars 80 forks source link

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

Open tim-seoss opened 2 days ago

tim-seoss commented 2 days ago

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 commented 2 days ago

Is this UEFI or legacy boot?

tim-seoss commented 2 days ago

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 commented 2 days ago

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 commented 1 day ago

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 commented 1 day ago

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 commented 16 hours ago

That works perfectly, thanks!