[Surface Laptop 2] Touchscreen does not work on 5.3

[swinzy]

I've tried the newest Ubuntu 19.04 on Surface Laptop 2.
Keyboard didn't work.
WiFi and Touchpad were working fine.

Then I tried the forked 5.3.1 version by @qzed , Keyboard now works but Touchscreen died. Also the Caps Lock Light won't work (Light is always off even if Caps Locks is on)

Now WiFi died after half an hour of apt installing.

[qzed]

For the touchscreen, please re-run the setup script from my repository. The wifi problem is known and discussed in a couple of other issues (no real solution yet, I think, AFAIK this should happen on all kernels). The caps lock light is currently not implemented as I'm missing some information on that, see linux-surface/surface-aggregator-module#8.

[swinzy]

For the touchscreen, please re-run the setup script from my repository. The wifi problem is known and discussed in a couple of other issues (no real solution yet, I think, AFAIK this should happen on all kernels). The caps lock light is currently not implemented as I'm missing some information on that, see qzed/linux-surfacegen5-acpi#8.

I re-ran the script from your repository. After a reboot, touchscreen still doesn't work somehow.
BTW, after a suspend, WiFi will stop working as well.

Thanks for developing and improving the whole thing anyway.

[qzed]

Do you have the proprietary firmware package installed (I think this should be linux-firmware on Ubuntu)? Can you make sure the IPTS firmware is installed properly (e.g. check /lib/firmware/intel/ipts? And if that all checks out, can you send me a dmesg log?

[swinzy]

Do you have the proprietary firmware package installed (I think this should be linux-firmware on Ubuntu)? Can you make sure the IPTS firmware is installed properly (e.g. check /lib/firmware/intel/ipts? And if that all checks out, can you send me a dmesg log?

linux-firmware is already the newest version (1.178.3).

/lib/firmware/intel/ipts exsists and contains:
config.bin
iaPreciseTouchDescriptor.bin
intel_desc.bin
ipts_fw_config.bin
MSHW0076
MSHW0078
MSHW0079
MSHW0101
MSHW0102
MSHW0103
MSHW0137
SurfaceTouchServicingDescriptorMSHW0079.bin
SurfaceTouchServicingKernelMSHW0079.bin
SurfaceTouchServicingKernelMSHW0079.bin.sig
SurfaceTouchServicingKernelSKLMSHW0079.bin
SurfaceTouchServicingSFTConfigMSHW0079.bin
SurfaceTouchServicingTouchBlobMSHW0079.bin
vendor_desc.bin
vendor_kernel.bin

And the dmesg log attached.
dmesg.txt

Thank you!

[qzed]

Alright, dmesg log shows that the firmware is being loaded and IPTS is properly initialized. Can you run sudo evtest? There should be two ipts xxxx:xxxx devices. One for the stylus, one for touch. Select one of them and try if you get some messages when you touch the screen with the stylus or your hand.

[swinzy]

It seems in my case 3 is for stylus and 4 is for touch.
It did respond when I touch the screen.
(The stylus always works fine from the moment I install the kernel BTW.)
evtest.txt

Thanks a lot.

[qzed]

Okay, so this looks definitely wrong, there should be multiple EV_ABS events (containing the actual touch information) for each timestamp event. I'm not really sure what would cause that, maybe wrong/corrupted firmware? Can you remove all files under /lib/firmware/intel/ipts and re-download the firmware from Jake's repo (do not run setup.sh), specifically ipts_firmware_v79.zip and run sudo unzip -o ipts_firmware_v79.zip -d /lib/firmware/intel/ipts/.

[qzed]

Also can you check if there is an MSHW0079 device under /sys/bus/acpi/devices? If not can you send me a list of devices that are there?

[qzed]

CC @StollD

[swinzy]

Okay, so this looks definitely wrong, there should be multiple EV_ABS events (containing the actual touch information) for each timestamp event. I'm not really sure what would cause that, maybe wrong/corrupted firmware? Can you remove all files under /lib/firmware/intel/ipts and re-download the firmware from Jake's repo (do not run setup.sh), specifically ipts_firmware_v79.zip and run sudo unzip -o ipts_firmware_v79.zip -d /lib/firmware/intel/ipts/.

I've done extracting the firmware from Jake's repo. After a reboot, touchscreen still doesn't work.

Also, there is no MSHW0079 under /sys/bus/acpi/devices, so a list of files are attached below.
Sorry for my mistake. There IS a file called MSHW0079:00.
AcpiDevices.txt

Thanks!

[qzed]

You did remove the other firmware files before, right (including the other folders, specifically the MSHW0079 firmware folder, otherwise the firmware in the ipts root folder will not be loaded)? So firmware-wise you should then have the correct firmware. Do you by any chance have Windows still installed and had any issues there? Have you also tried a firmware reset (not sure how that works on the Laptops, on the SB2 it's performed by pressing power and volume up buttons for 15 seconds)?

[StollD]

Hmm, that is an interesting one. Some random thoughs:

• Have you tried an older kernel, to see if touch is working there?
• What is the output of lsmod, sudo libinput list-devices and sudo libinput debug-events (touch the screen for the latter one).
• What UEFI / firmware versions to you have installed? You could try reflashing it with fwupd and this

Since HID events are generated in hardware, you might have faulty hardware. As @qzed said, do you have windows installed? Have you tried if touch works correctly there?

In your dmesg there is sth. that looks like a crash when the kernel tries to load it's certificate for verifying modules. Some lines below, it complains about the signature of the HID module being wrong. Maybe your downloaded kernel, or the .deb package that qzed uploaded got corruped? (As said above, you could check that by trying an older kernel).

@qzed another random thought: maybe IPTS somehow got stuck in single-touch mode? With the latest release that just sends all touch events to /dev/null. Is that even possible? Again, downgrading the kernel could fix that if it was the case.

[swinzy]

You did remove the other firmware files before, right (including the other folders, specifically the MSHW0079 firmware folder, otherwise the firmware in the ipts root folder will not be loaded)? So firmware-wise you should then have the correct firmware. Do you by any chance have Windows still installed and had any issues there? Have you also tried a firmware reset (not sure how that works on the Laptops, on the SB2 it's performed by pressing power and volume up buttons for 15 seconds)?

I did remove the whole /lib/firmware/intel/ipts and then put the new files into it.
I wiped the whole disk so I do not have Windows installed but the touchscreen in Surface UEFI works perfectly.

[swinzy]

Hmm, that is an interesting one. Some random thoughs:

• Have you tried an older kernel, to see if touch is working there?
• What is the output of lsmod, sudo libinput list-devices and sudo libinput debug-events (touch the screen for the latter one).
• What UEFI / firmware versions to you have installed? You could try reflashing it with fwupd and this

Since HID events are generated in hardware, you might have faulty hardware. As @qzed said, do you have windows installed? Have you tried if touch works correctly there?

In your dmesg there is sth. that looks like a crash when the kernel tries to load it's certificate for verifying modules. Some lines below, it complains about the signature of the HID module being wrong. Maybe your downloaded kernel, or the .deb package that qzed uploaded got corruped? (As said above, you could check that by trying an older kernel).

@qzed another random thought: maybe IPTS somehow got stuck in single-touch mode? With the latest release that just sends all touch events to /dev/null. Is that even possible? Again, downgrading the kernel could fix that if it was the case.

• I do not have Windows installed but I've just checked that the touchscreen works perfectly in Surface UEFI.
• The output of lsmod, sudo libinput list-devices and sudo libinput debug-events are attached down below. (I touched multiple times during debug-events and I didn't see any event triggered by my touch, the only event I can recognise is triggered by my Ctrl-C interrupt.)
  lsmod.txt
  list-devices.txt
  debug-events.txt

Firmware versions:

• System UEFI: 137.2706.768
• SAM Controller: 145.210.139
• KIP Controller: 135.2179.256
• Intel Management Engine: 11.8.56.3522
• Touch Firmware: 1.189.5.30.20.8
• Trackpad Controller: 2.122.2683

BTW, I signed the kernel myself following the instruction given by Jake in SIGNING.md in order to remove the ugly red lock during boot time by turning on Secure Boot. Maybe something went wrong that caused it to complain about the signature. It can boot normally with Secure Boot on though.

Also I will try downgrading the Kernel and flashing a newer version of Firmware then.

[qzed]

@qzed another random thought: maybe IPTS somehow got stuck in single-touch mode? With the latest release that just sends all touch events to /dev/null. Is that even possible? Again, downgrading the kernel could fix that if it was the case.

@StollD Maybe, but I think that'd have to be switched by the MEI device itself, I don't know if that's possible. Also there are the timestamp events in the evtest log, would they be there in single-touch mode?

[qzed]

BTW, I signed the kernel myself following the instruction given by Jake in SIGNING.md in order to remove the ugly red lock during boot time by turning on Secure Boot. Maybe something went wrong that caused it to complain about the signature. It can boot normally with Secure Boot on though.

That shouldn't cause any issues. The signature it was complaining about was in-kernel and could have to do something with how I compile the kernels. Unfortunately I can't test/verify that as I'm not using a Debian based distro.

[johncaseyjones1]

I’m not sure how set you are on 19.04, but my surface laptop 2 had issues with the keyboard not working using 19.04 and no issues at all with 18.04, including no WiFi issues. The only downside is scaling on the high resolution surface display is more of a hassle on 18.04, but everything else works fine for me.

[swinzy]

@qzed @StollD :
Problem solved.
Let me explain what I did:
First, I tried some old kernels from qzed's repo, they were 4.19.75, 5.2.5, 5.2.17. They all didn't work. Then, I assumed that the problem had nothing to do with kernel, so I tried Jake's 5.1.15 which I had installed before and at that time touchscreen was working but keyboard didn't work. However, this time touchscreen still didn't work but keyboard worked. This confused me so I decided to reinstall Jake's kernel. I purged all linux-image and linux-headers except the latest signed 5.3.1 by qzed on which the system was running. I ran the setup.sh from Jake's repo and let it download the latest kernel and install automatically. After a reboot, touchscreen AND keyboard now works pretty fine on 5.1.15 by Jake.

Thank you guys a lot for helping me out!
I will close this issue if I'm no longer contributive.

[swinzy]

Also, I just tested that qzed's 5.3.1 still has the touchscreen problem here.
What I can see is somehow Jake's keyboard problem has been fixed by installing qzed's kernel and reinstall Jake's kernel.

[qzed]

@SG-M1niCrusher That might not be a permanent solution. The previous kernels do not initialize the keyboard properly (thus the problems). By installing the newer kernel you have set-up the keyboard, which may work until the EC is reset or changes something (e.g. by booting into Windows).

Are you absolutely certain that the touchscreen does not work on the 5.2.x kernels (even when re-running the setup script)?

[alturismo]

rerunning setup.sh (libwrt... yes) worked here on 5.2.x kernel as note (Surface Laptop 1)

dead wifi while running was an issue before, but meanwhile its working, energy savings off.

wifi is completely dead after resume here as note, only reboot will make it work again.

[qzed]

To elaborate a bit: Pre 5.3, IPTS driver had two modes: (apart from implementation changes) they can be seen as single- and multi-touch mode. In 5.3, we scrapped the single-touch implementation as we assumed that it's unused and devices would normally work in multi-touch mode. Now that may have been wrong (basically it's the only change to 5.2 that I can think of that would be capable of breaking touch).

So, @alturismo and @SG-M1niCrusher, can you check if multi-touch works on 5.2/5.1 or previous versions? There are some resources for Ubuntu here, but a simple way to do this would be to run sudo evtest. There should be multiple ipts xxxx:xxxx devices listed, try to select one and see if you get some messages if you touch the screen. You might need a couple of tries to find the right one, just ctrl-c to exit. Once you've found the right one can you touch the screen with 5 fingers or so at the same time and send me the output? There should be multiple events with ABS_MT_SLOT and different values for value, one for each finger.

[swinzy]

@qzed:
The evtest of Jake's kernel (5.1.15) and your older kernel is down below (5.2.5)
After rerunning setup.sh in your repo just now. The touchscreen on your 5.2.5 works perfectly now.
touch.jake.txt
touch.qzed52.txt

I've noticed if touchscreen works, there will be 4 ipts 1B96:0979 shown in evtest; one says "Touchscreen" and if not works there will only be 2 of it and none of these says "Touchscreen".

[alturismo]

@qzed here from Surface Laptop 1 with 5.2.17 and setup.sh

alturismo@AlsSurface:~$ sudo evtest > touch_5.2-17.txt [sudo] Passwort für alturismo: No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: Video Bus /dev/input/event1: MSHW0092:00 045E:0933 Mouse /dev/input/event2: MSHW0092:00 045E:0933 Touchpad /dev/input/event3: Lid Switch /dev/input/event4: ipts 1B96:0979 UNKNOWN /dev/input/event5: ipts 1B96:0979 /dev/input/event6: ipts 1B96:0979 Touchscreen /dev/input/event7: ipts 1B96:0979 Mouse /dev/input/event8: gpio-keys /dev/input/event9: Microsoft Virtual HID Framework Device Keyboard /dev/input/event10: Microsoft Virtual HID Framework Device Consumer Control /dev/input/event11: HDA Intel PCH Mic /dev/input/event12: HDA Intel PCH Headphone Select the device event number [0-12]: 6

touch_5.2-17.txt

[StollD]

So I think I know what is going on. As @qzed said, in 5.3 the changes that IPTS did to the HID subsystem got reverted, because we assumed that they were only used for single-touch. But, at some point Jake seems to added some fixes to them, which we reverted as well: 78f1e81

I think those are software mitigations for firmware that produces wrong HID events, especially this:

static int mt_touch_input_mapped(struct hid_device *hdev, struct hid_input *hi,
		struct hid_field *field, struct hid_usage *usage,
		unsigned long **bit, int *max)
{
	if (usage->type == EV_KEY || usage->type == EV_ABS)
		set_bit(usage->type, hi->input->evbit);

	return -1;
}

which seems to forcefully apply some events (the ones that are missing in your evtest results).

I was even able to test this: I replaced the MSHW0137 firmware for SB2 with MSHW0079 for Surface Laptop. Then I rebooted, ran evtest and my results were the same as the ones that were posted here: No EV_ABS etc, but a lot of timestamps.

As the next step I readded those mitigations and recompiled the kernel. And it did actually fix the issue! Well, sort of. My touch input is now upside down, which doesn't really matter for testing though. It confirms where the issue lies.

---

@SG-M1niCrusher @alturismo I know this sounds dumb (and it is tbh), but would you be open to trying out the other IPTS firmwares to see if they can fix the problem? Basically, install the 5.3 kernel, make sure that touch is broken, then do something like this:

# Backup your current FW
$ cp -r /lib/firmware/intel/ipts/MSHW0079 .

# Remove it and replace it with another one
$ sudo rm -r /lib/firmware/intel/ipts/MSHW0079
$ sudo cp -r /lib/firmware/intel/ipts/$FIRMWARE /lib/firmware/intel/ipts/MSHW0079

# Reboot

You can try to use the SB2 firmware to verify that this tricks works and actually restores touch for you, but that won't be the final solution as said above. I'd suggest trying MSHW0101 (thats the 15" SB2) or MSHW0102 (SP5). Those are the most similar ones to the Laptop, CPU wise. If they don't work, just try all the other ones.

If nothing of that works we will have to put those mitigations back in place.

[swinzy]

@StollD :
MSHW0076 and MSHW0137 work but upside down.
And any other (MSHW0078, MSHW0101, MSHW0102 and MSHW0103) don't work.

[StollD]

Thank you for testing!

I did some further testing. As it turns out, using the HID descriptor from MSHW0079 is enough to trigger the bug for me. At the same time, using the MSHW0079 firmware with the HID descriptor for MSHW0137 results in working touch, but upside down, just like with the kernel mitgations.

This means that the firmware (responsible for rotation) works, but the HID descriptor (required for telling the kernel which events it can process) is bugged.

On IPTS, the HID descriptor consists of intel_desc.bin and vendor_desc.bin concatinated together by the driver. intel_desc.bin is the same for all IPTS variants.

@SG-M1niCrusher Could you please try to restore the MSHW0079 firmware, and then only copy vendor_desc.bin from MSHW0137? If that combination works for me with upside down touch, the chances are high that it will work for you too, with properly oriented touch.

$ sudo rm -r /lib/firmware/intel/ipts/MSHW0079
$ sudo cp -r MSHW0079 /lib/firmware/intel/ipts/
$ sudo cp /lib/firmware/intel/ipts/MSHW0137/vendor_desc.bin /lib/firmware/intel/ipts/MSHW0079

[qzed]

@StollD Nice work! Given that the vendor_desc.bins are only raw HID descriptors, we should be able to figure out the difference between the two and what causes the problem. Based on the size difference of the two firmware files, there may be some additional differences, so I think it's best if we could patch the flaw in the firmware instead of replacing it.

[qzed]

So I've just checked the firmware packages for the SL1 and SL2, and it looks like the firmware is up-to-date (although I had to use msiexec on Windows to extract the package as msiextract on Linux somehow messed the file contents up).

[swinzy]

Thank you for testing!

I did some further testing. As it turns out, using the HID descriptor from MSHW0079 is enough to trigger the bug for me. At the same time, using the MSHW0079 firmware with the HID descriptor for MSHW0137 results in working touch, but upside down, just like with the kernel mitgations.

This means that the firmware (responsible for rotation) works, but the HID descriptor (required for telling the kernel which events it can process) is bugged.

On IPTS, the HID descriptor consists of intel_desc.bin and vendor_desc.bin concatinated together by the driver. intel_desc.bin is the same for all IPTS variants.

@SG-M1niCrusher Could you please try to restore the MSHW0079 firmware, and then only copy vendor_desc.bin from MSHW0137? If that combination works for me with upside down touch, the chances are high that it will work for you too, with properly oriented touch.

$ sudo rm -r /lib/firmware/intel/ipts/MSHW0079
$ sudo cp -r MSHW0079 /lib/firmware/intel/ipts/
$ sudo cp /lib/firmware/intel/ipts/MSHW0137/vendor_desc.bin /lib/firmware/intel/ipts/MSHW0079

Yes it works for me after I replaced the vendor_desc.bin; the touch works perfectly with 5.3.1.
And it's not upside down anymore.

[alturismo]

g morning, i also can confirum touch working with this procedure on SL1 with 5.3.1 on ubuntu 19.04

but i didnt have the subfolder /lib/firmware/intel/ipts/MSHW0079

so i replaced in /lib/firmware/intel/ipts/

config.bin
intel_desc.bin
ipts_fw_config.bin
vendor_desc.bin
vendor_kernel.bin

while the vendor_desc.bin then from the MSHW0137 package.

touch seems fine here now

[qzed]

@m1nicrusher @alturismo Can you check if this works with the latest vendor_desc.bin in https://github.com/qzed/linux-surface/tree/master/firmware/intel/ipts/MSHW0079?

[alturismo]

@qzed confirmed working here,

tested on the 5.3.2 kernel from your repo

#offtopic
reverted now back to linux mint with jake 5.1.15 due the suspend wifi issue with all later kernels,
and for ubuntu 19 i needed a later kernel to get the keyboard working, so mint was the choice ;)
may a question wich MSHWxxxx package would be the default one for SL1, i forgot to backup the files before testing ;)

[qzed]

@alturismo Thanks! Those are the MSHW0079 files, I've patched the original vendor_desc.bin, the patched version should work with all kernels, so you should already have the correct files.