Surface Pro 12in (X1P42100): touchscreen variant, different GPIOs

Surface Pro 12in (X1P42100): touchscreen variant, different GPIOs

[François Roux]

Hi,

Reporting a hardware variant rather than sending a patch, because I do
not know how you would want it discriminated and a naive patch would
break the other units.

x1p42100-microsoft-sp12.dts describes the touchscreen as:

	/* ILIT2911 or GTCH1563 */
	touchscreen@16 {
		compatible = "hid-over-i2c";
		reg = <0x16>;
		hid-descr-addr = <0x1>;
		interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>;
		vddl-supply = <&vreg_l15b_1p8>;
		pinctrl-0 = <&ts0_default>;
		pinctrl-names = "default";
	};

	ts0_default: ts0-default-state {
		int-n-pins   { pins = "gpio51"; ... };
		reset-n-pins { pins = "gpio52"; ... };
	};

My unit has neither of those controllers, and different pins.

What is on this machine
=======================

	hid-over-i2c 04F3:4377 Touchscreen

04F3 is ELAN. It sits at the same address (0x16) on the same bus, but
the interrupt and reset lines differ:

	                  upstream DTS      this unit
	interrupt GPIO    51                38
	reset GPIO        52                48

Both descriptions are internally consistent -- the interrupt property
and the pinctrl state agree with each other in each case -- so this is
not a typo in either. It is a genuinely different board wiring.

The vendor DTB shipped with Windows on this unit uses 38/48, and it
works: touchscreen, pen and multitouch all register. Booting the
upstream DTS on this machine would leave the touchscreen dead, since the
driver would be waiting on a pin the controller does not drive.

The unit also has `wakeup-source` on that node in the vendor DTB, which
upstream does not carry. I have not tested whether it matters, so I
mention it only for completeness.

Machine identification
======================

	sys_vendor       Microsoft Corporation
	product_name     Surface Pro 12in 1st Ed with Snapdragon
	product_sku      Surface_Pro_12in_1st_Ed_with_Snapdragon_2110
	product_version  124I:00125T:000M:0000000F:0B:10C:08M:00D:00U:00T:2R:10
	bios_version     9.166.235
	DT compatible    microsoft,surface-pro-12in / qcom,x1p42100

Note the DT compatible above is from the vendor DTB, which predates the
rename to `microsoft,sp12`.

Why I am not sending a patch
============================

Both variants would advertise the same compatible, and the DTB is
selected before Linux runs, so a second DTS would need something the
bootloader can key on. `product_sku` ends in `2110` here and might be
that discriminator, but I have exactly one unit and no way to confirm it
distinguishes anything.

Changing the GPIOs in place would obviously break whichever units the
current values were written for.

So: how would you like this handled? A separate board DTS, a runtime
quirk, or something else entirely? I am happy to write and test whatever
shape you prefer, and to dump any register or property from this
machine.

Environment: linux-next next-20260626 on Arch Linux ARM (aarch64), with
the vendor DTB rather than the upstream one, for exactly this reason.

Thanks,
François Roux

Re: Surface Pro 12in (X1P42100): touchscreen variant, different GPIOs

[François Roux]

Thank you — and I owe the list a correction, because my report was wrong at
its root.

I claimed the upstream DTS describes the touchscreen on GPIO 51/52 while my
unit uses 38/48, and concluded this was a hardware variant. It is not. There
is no variant, and there is nothing here for anyone to act on.

What I actually did wrong
=========================

x1p42100-microsoft-sp12.dts does not exist in the tree I was working from
(next-20260626). It was created *in my own tree* by a patch I had applied
myself -- Harrison's v1, which carries the GPIO 51 that he has since
described as an early mistake copied from similar devices.

So when I wrote "upstream describes 51", I was reading an obsolete patch I
had applied, and reporting it as the state of upstream. One `git log` on the
file would have shown me that. I did not run it.

Two further claims of mine were also wrong:

  - I wrote that booting the upstream DTS would leave the touchscreen dead.
    Per Harrison, GPIO 51 works but with degraded performance and missing
    pen events. Degraded, not dead.

  - I wrote that both descriptions were "internally consistent, so this is
    not a typo in either". The consistency was real but proved nothing: a
    mistake copied consistently across the interrupt property and the
    pinctrl state is still a mistake.

Where things actually stand
===========================

Harrison's v2 already fixed this, and v4

  https://lore.kernel.org/all/20260609145906.40854-2-harrison.vanderbyl@gmail.com/

is the one expected to land in 7.3. My machine's wiring (38/48) is what that
patch describes. Nothing needs discriminating, and no separate board DTS is
warranted.

Sorry for the noise. Thanks to Harrison for the quick and precise answer.

François Roux