Surface Laptop 7th Edition Support

While I don't own this particular device, now that device tree support exists for it in the mainline kernel, are there any plans to support it?

Someone who does own this device reported that the only things that don't work right now are the touchpad and touchscreen, which sounds similar to the situation with IPTS.

There's also some ongoing discussion about this on Ubuntu forum, although SL7 is not bootable there (yet)
https://bugs.launchpad.net/ubuntu-concept/+bug/2084951

So the problem is that right now we only properly support x86 devices. There is some stuff for the SPX, but that would need to be fleshed out a bit to support other ARM devices. In principle, I'd love to support all the ARM Surface models, but at the moment I barely have time to keep things running here.

Getting the touchscreen/touchpad to work will probably require 2 parts: The SPI HID driver (code is there, for example in the SPX kernel branchs but may need to be adapted) and IPTSD (which already supports the SPX, so getting it to work on the SL7 should very likely just be config stuff).

according to reports from the linked ubuntu thread, wireless, bluetooth and speakers don't work either.

I installed the ubuntu image on my Surface 7 13 inch and can confirm that the touchpad, touchscreen, wifi, bluetooth, and speakers do not work. Not sure about GPU acceleration or webcam / mic yet. I'm willing to test any patches on my device.

Tried following the steps on this page to generate the acpidump but it doesn't work because there is no acpi folder.

The contents of /sys/firmware are:

devicetree
dmi
efi
fdt

lspci -v:

0003:00:00.0 PCI bridge: Qualcomm Technologies, Inc Device 0111 (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 190
	Memory at 78300000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
	I/O behind bridge: [disabled] [16-bit]
	Memory behind bridge: [disabled] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable+ Count=1/32 Maskable+ 64bit+
	Capabilities: [70] Express Root Port (Slot+), IntMsgNum 0
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [148] Secondary PCI Express
	Capabilities: [168] Physical Layer 16.0 GT/s <?>
	Capabilities: [190] Lane Margining at the Receiver
	Capabilities: [1b8] Transaction Processing Hints
	Capabilities: [24c] L1 PM Substates
	Capabilities: [25c] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?>
	Capabilities: [35c] Data Link Feature <?>
	Kernel driver in use: pcieport

0004:00:00.0 PCI bridge: Qualcomm Technologies, Inc Device 0111 (prog-if 00 [Normal decode])
	Device tree node: /sys/firmware/devicetree/base/soc@0/pci@1c08000/pcie@0
	Flags: bus master, fast devsel, latency 0, IRQ 192
	Memory at 7c300000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
	I/O behind bridge: [disabled] [16-bit]
	Memory behind bridge: 7c400000-7c5fffff [size=2M] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable+ Count=1/32 Maskable+ 64bit+
	Capabilities: [70] Express Root Port (Slot+), IntMsgNum 0
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [148] Secondary PCI Express
	Capabilities: [168] Transaction Processing Hints
	Capabilities: [1fc] L1 PM Substates
	Capabilities: [20c] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?>
	Kernel driver in use: pcieport

0004:01:00.0 Network controller: Qualcomm Technologies, Inc WCN785x Wi-Fi 7(802.11be) 320MHz 2x2 [FastConnect 7800] (rev 01)
	Subsystem: Qualcomm Technologies, Inc WCN785x Wi-Fi 7(802.11be) 320MHz 2x2 [FastConnect 7800]
	Flags: bus master, fast devsel, latency 0, IRQ 238
	Memory at 7c400000 (64-bit, non-prefetchable) [size=2M]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable+ Count=16/32 Maskable+ 64bit-
	Capabilities: [70] Express Endpoint, IntMsgNum 0
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [148] Secondary PCI Express
	Capabilities: [158] Transaction Processing Hints
	Capabilities: [1e4] Latency Tolerance Reporting
	Capabilities: [1ec] L1 PM Substates
	Kernel driver in use: ath12k_pci
	Kernel modules: ath12k

0006:00:00.0 PCI bridge: Qualcomm Technologies, Inc Device 0111 (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 194
	Memory at 70400000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=01, subordinate=ff, sec-latency=0
	I/O behind bridge: [disabled] [16-bit]
	Memory behind bridge: 70300000-703fffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable+ Count=8/32 Maskable+ 64bit+
	Capabilities: [70] Express Root Port (Slot+), IntMsgNum 5
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [148] Secondary PCI Express
	Capabilities: [168] Physical Layer 16.0 GT/s <?>
	Capabilities: [18c] Lane Margining at the Receiver
	Capabilities: [1a4] Transaction Processing Hints
	Capabilities: [238] L1 PM Substates
	Capabilities: [248] Downstream Port Containment
	Capabilities: [28c] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?>
	Capabilities: [38c] Data Link Feature <?>
	Kernel driver in use: pcieport

0006:01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller PM9B1 (DRAM-less) (rev 02) (prog-if 02 [NVM Express])
	Subsystem: Samsung Electronics Co Ltd NVMe SSD Controller PM9B1 (DRAM-less)
	Flags: bus master, fast devsel, latency 0, IRQ 193
	Memory at 70300000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
	Capabilities: [70] Express Endpoint, IntMsgNum 0
	Capabilities: [b0] MSI-X: Enable+ Count=67 Masked-
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [148] Device Serial Number 00-00-00-00-00-00-00-00
	Capabilities: [158] Power Budgeting <?>
	Capabilities: [168] Alternative Routing-ID Interpretation (ARI)
	Capabilities: [178] Secondary PCI Express
	Capabilities: [198] Physical Layer 16.0 GT/s <?>
	Capabilities: [1bc] Lane Margining at the Receiver
	Capabilities: [224] Latency Tolerance Reporting
	Capabilities: [22c] L1 PM Substates
	Kernel driver in use: nvme
	Kernel modules: nvme

sudo dmesg: dmesg.txt

Output of sudo dtc -I fs -O dts -o full-device-tree.dts /sys/firmware/devicetree/base/

full-device-tree.dts.txt

This section looks promising?

			serial@b88000 {
				power-domains = <0x3b 0x00>;
				pinctrl-names = "default";
				interconnect-names = "qup-core\0qup-config";
				pinctrl-0 = <0x80>;
				clock-names = "se";
				interconnects = <0x3e 0x01 0x07 0x3e 0x05 0x07 0x3f 0x03 0x03 0x40 0x19 0x03>;
				interrupts = <0x00 0x248 0x04>;
				clocks = <0x3d 0xa6>;
				compatible = "qcom,geni-uart";
				status = "okay";
				reg = <0x00 0xb88000 0x00 0x4000>;
				operating-points-v2 = <0x4a>;

				embedded-controller {
					pinctrl-names = "default";
					pinctrl-0 = <0x82>;
					interrupts-extended = <0x81 0x5b 0x01>;
					current-speed = "\0=\t";
					compatible = "microsoft,surface-sam";
				};
			};

ACPI Dump

Tried to follow instructions from related issue, but ran into multiple errors:

sudo python3 ssam/evreg.py reg-disable 0x15 0x00 0x01

$ sudo python3 ssam/evreg.py reg-disable 0x15 0x00 0x01
Traceback (most recent call last):
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 81, in <module>
    main()
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 77, in main
    run_command(event_command(cmd_name, ev_tc, ev_seq, ev_iid))
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 39, in event_command
    return command(**EVCMDS[name], payload=payload)
                     ~~~~~~^^^^^^
KeyError: 'reg-disable'

Got a keyerror for reg-disable. I opened the script and found that it had apparently been replaced by reg1-disable and reg2-disable

sudo python3 ssam/evreg.py reg1-disable 0x15 0x00 0x01

$ sudo python3 ssam/evreg.py reg1-disable 0x15 0x00 0x01
00

After running this command the keyboard was still working normally.

sudo python3 ssam/evreg.py reg2-disable 0x15 0x00 0x01

$ sudo python3 ssam/evreg.py reg2-disable 0x15 0x00 0x01
Traceback (most recent call last):
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 81, in <module>
    main()
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 77, in main
    run_command(event_command(cmd_name, ev_tc, ev_seq, ev_iid))
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 44, in run_command
    data = ctrl.request(rqst)
           ^^^^^^^^^^^^^^^^^^
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/libssam.py", line 355, in request
    return _request(self.fd, request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/libssam.py", line 263, in _request
    raise OSError(-raw.status, errno.errorcode.get(-raw.status))
TimeoutError: [Errno 110] ETIMEDOUT

Timeout error, seems to occur with every attempt of using reg2-disable

sudo python3 ssam/evreg.py reg1-enable 0x15 0x00 0x03

$ sudo python3 ssam/evreg.py reg1-enable 0x15 0x00 0x03
01

Trackpad was not working anyway, no change

sudo python3 ssam/evreg.py reg2-disable 0x15 0x00 0x03

$ sudo python3 ssam/evreg.py reg2-disable 0x15 0x00 0x03
Traceback (most recent call last):
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 81, in <module>
    main()
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 77, in main
    run_command(event_command(cmd_name, ev_tc, ev_seq, ev_iid))
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 44, in run_command
    data = ctrl.request(rqst)
           ^^^^^^^^^^^^^^^^^^
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/libssam.py", line 355, in request
    return _request(self.fd, request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/libssam.py", line 263, in _request
    raise OSError(-raw.status, errno.errorcode.get(-raw.status))
TimeoutError: [Errno 110] ETIMEDOUT

Another timeout error.

sudo python3 ssam/evreg.py command 0x15 0x04 1 0x02 0x01 0x02 0x00 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x00:

$ sudo python3 ssam/evreg.py command 0x15 0x04 1 0x02 0x01  0x02  0x00 0x00 0x00 0x00  0x10 0x00 0x00 0x00  0x00
Traceback (most recent call last):
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 81, in <module>
    main()
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 77, in main
    run_command(event_command(cmd_name, ev_tc, ev_seq, ev_iid))
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 39, in event_command
    return command(**EVCMDS[name], payload=payload)
                     ~~~~~~^^^^^^
KeyError: 'command'

"Command" is not defined in EVCMDS

Got a keyerror for reg-disable. I opened the script and found that it had apparently been replaced by reg1-disable and reg2-disable

Ah yeah sorry, should have checked that. The post that I linked is quite out of date...

It should be reg1-disable, not sure why that's not working... Maybe they changed something again. At least the 00 indicates that it accepted the command. The 01 later for device 03 (usually touchpad) indicates that the touchpad isn't connected via SAM, which I guess is why it works out of the box. Could be it's ITHC/IPTS like (I think) on the SLS2.

Can you also try sudo python3 ssam/evreg.py kip-disable 0x15 0x00 0x01?

And can you also run

sudo python3 ssam/hid.py hid-get-descriptor <tid> <iid> 0

for <tid> 1 and 2 and <iid> 1 to 7 each? I guess <tid> 2 should time out again, but for 1 it should show some output. Basically, this tries to read the HID descriptor for each device. If it returns some numbers, that means there's a device there at that IID/TID combo.

@konradybcio

This section looks promising?

Yeah, that's basic upstream DT support, thanks to @konradybcio.

Touchscreen is likely similar to the SPX and connected via HID-over-SPI: https://github.com/linux-surface/kernel/blob/03d94f64f9988b4f01cf7f971d24c3fdd160bb3e/arch/arm64/boot/dts/qcom/sc8180x-surface-pro-x.dts#L1115-L1139. Meaning it sends HID data for single-touch and raw heatmap data over HID that needs IPTS for additional processing. If the touchpad is ITHC/IPTS based, it's probably similarly connected.

Note that I am currently running the x1e kernel from this project: https://launchpad.net/~ubuntu-concept/+archive/ubuntu/x1e, which I suspect is missing some sort of SAM support. I'm going to be playing around with the kernel patches this evening and hopefully try again.

sudo python3 ssam/evreg.py kip-disable 0x15 0x00 0x01

$ sudo python3 ssam/evreg.py kip-disable 0x15 0x00 0x01
Traceback (most recent call last):
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 81, in <module>
    main()
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 77, in main
    run_command(event_command(cmd_name, ev_tc, ev_seq, ev_iid))
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/evreg.py", line 43, in run_command
    with Controller() as ctrl:
         ^^^^^^^^^^^^
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/libssam.py", line 345, in __enter__
    self.open()
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/libssam.py", line 338, in open
    self.fd = os.open(_PATH_SSAM_DBGDEV, os.O_RDWR)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/dev/surface/aggregator'

sudo python3 ssam/hid.py hid-get-descriptor 1 1 0

$ sudo python3 ssam/hid.py hid-get-descriptor 1 1 0
Traceback (most recent call last):
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/hid.py", line 133, in <module>
    main()
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/hid.py", line 123, in main
    with Controller() as ctrl:
         ^^^^^^^^^^^^
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/libssam.py", line 345, in __enter__
    self.open()
  File "/home/bryce/Downloads/surface-aggregator-module/scripts/ssam/libssam.py", line 338, in open
    self.fd = os.open(_PATH_SSAM_DBGDEV, os.O_RDWR)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/dev/surface/aggregator'

Same error occurs for every variation of <tid> and <iid>.

Patches applied so far:

x1e80100-microsoft-romulus.dtsi

diff -r Documents/linux-qcom-x1e/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi Downloads/linux-qcom-x1e/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
1440a1441,1466
> 
> &spi1 {
> 	status = "okay";
> 
> 	pinctrl-names = "default";
> 	pinctrl-0 = <&spi1_active>;
> 
> 	hid@0 {
> 		compatible = "hid-over-spi";
> 
> 		reg = <0>;
> 		// spi-max-frequency = <25000000>;
> 		spi-max-frequency = <12500000>;
> 
> 		interrupts-extended = <&tlmm 122 IRQ_TYPE_EDGE_FALLING>;
> 
> 		pinctrl-names = "active", "sleep", "reset";
> 		pinctrl-0 = <&spi1_hid0_reset_deassert &spi1_hid0_int_bias>;
> 		pinctrl-1 = <&spi1_hid0_reset_assert &spi1_hid0_int_unbias>;
> 		pinctrl-2 = <&spi1_hid0_reset_assert &spi1_hid0_int_bias>;
> 
> 		vdd-supply = <&vreg_ts_5p0>;
> 
> 		hid-descr-addr = <1>;
> 	};
> };

Result: No change

drivers/platform/surface/surface_aggregator_registry.c

diff -r Documents/linux-qcom-x1e/drivers/platform/surface/surface_aggregator_registry.c Downloads/linux-qcom-x1e/drivers/platform/surface/surface_aggregator_registry.c
462a463,465
> 	/* Surface Laptop 7 */
> 	{ "MSHW0462", (unsigned long)ssam_node_group_sl7 },
>

Result: Hoped this would fix the 'FileNotFoundError: [Errno 2] No such file or directory: '/dev/surface/aggregator'' error, but no change.

Trying to get wifi working. I first followed the instructions from this post: https://discourse.ubuntu.com/t/ubuntu-24-10-concept-snapdragon-x-elite/48800/216 and made the following change:

board-2.json

@@ 28,7
            {
                "names": [
                    "bus=pci,vendor=17cb,device=1107,subsystem-vendor=17cb,subsystem-device=3378,qmi-chip-id=2,qmi-board-id=255",
>                    "bus=pci,vendor=17cb,device=1107,subsystem-vendor=17cb,subsystem-device=1107,qmi-chip-id=2,qmi-board->id=255"
                ],
                "data": "bus=pci,vendor=17cb,device=1107,subsystem-vendor=17cb,subsystem-device=3378,qmi-chip-id=2,qmi-board-id=255.bin"
            },

Result: After applying this patch and installing the new board, the wifi adapter is now detected but still non functional.

ip link

2: wlP4p1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:03:7f:12:ae:bc brd ff:ff:ff:ff:ff:ff

Tried to bring the interface up and got an rfkill error:

sudo ip link set wlP4p1s0 up

$ sudo ip link set wlP4p1s0 up
RTNETLINK answers: Operation not possible due to RF-kill

I then borrowed the following patch from the work on the surface pro 11 which describes a similar error: https://github.com/dwhinham/kernel-surface-pro-11/commit/fcc769be9eaa9823d55e98a28402104621fa6784

drivers/net/wireless/ath/ath12k/core.c

diff -r Documents/linux-qcom-x1e/drivers/net/wireless/ath/ath12k/core.c Downloads/linux-qcom-x1e/drivers/net/wireless/ath/ath12k/core.c
38a39,40
> 	return 0;
>

Unfortunately, after this I still get the same RF-Kill error

$ sudo ip link set wlP4p1s0 up
RTNETLINK answers: Operation not possible due to RF-kill

I did however get GPU acceleration working!

While digging through the dtsi folder I found this line:

&gpu {
	status = "okay";

	zap-shader {
		memory-region = <&gpu_microcode_mem>;
		firmware-name = "qcom/x1e80100/microsoft/qcdxkmsuc8380.mbn";
	};
};

I noticed this file was not present in my /lib/firmware folder, so I extracted it from the firmware on Microsoft's website: https://www.microsoft.com/en-us/download/details.aspx?id=106120

$ msiextract SurfaceLaptop7_ARM_Win11_26100_25.013.35106.0.msi

Finally I found the file qcdxkmsuc8380.mbn in the extracted archive and copied it to my firmware folder.

sudo cp ./SurfaceUpdate/proextadsp8380/qcadsp8380.mbn /lib/firmware/qcom/x1e80100/microsoft/

After rebooting, the GPU is now listed correctly in system info:

I noticed this file was not present in my /lib/firmware folder

Did you run the qcom-firmware-extract tool from Ubuntu X1E concept? I think that should pull that firmware and a few more that would be useful: https://git.launchpad.net/~ubuntu-concept/ubuntu/+source/qcom-firmware-extract/tree/qcom-firmware-extract?h=ubuntu#n116

The firmware should be located in /lib/firmware/updates/qcom/x1e80100/microsoft/Romulus after you run the script.

@fotnite-vevo

Also, @giantdwarf17 @fotnite-vevo it would be nice to collect the feature support of this device somewhere. Possibly using a template similar to this section: https://github.com/dwhinham/linux-surface-pro-11?tab=readme-ov-file#whats-working

In the notes part, it would be nice to show what you needed to do for this to work.

Result: Hoped this would fix the 'FileNotFoundError: [Errno 2] No such file or directory: '/dev/surface/aggregator'' error, but no change.

You will need to manually modprobe surface_aggregator_cdev to load the debug interface. The patch for surface_aggregator_registry doesn't have any effect. That's only for ACPI based devices. Upstream already has the equivalent change for DT.

@dwhinham

I agree with @dwhinham and the sentiment from others. The AI madness is hurting things.

At first it seemed dubious, but acceptable as a prototype for the few missing pieces that still existed. Then it seemed like are several different people/groups out there all duplicating each others work with lazy slop output, and none of it is driving to a single cohesive goal. Worse, it seems like many might be redoing human-written and vetted components because they were too lazy to go find the work that was already done so they just asked Claude to spit it out. Even if the output was good (which I doubt), that is still madness. There is a flood of noise to very little signal out there right now.

I wish I knew how to help more.

@horizontblau

@horizontblau This is frustrating. I made a relatively personal attack (too much so, I apologize for that) and you couldn't muster any of your own words for a response. I mean you literally saw criticism, put it into an LLM, and then regurgitated the AI's output. How is that productive to anyone? Why do you exist in this pipeline if the AI controls all of your output? Maybe I'm getting a little too philosophical, but do you truly derive meaning in life from being an interface for AI? Do you think the people in your life would enjoy you the same if you communicated like this in real life?

I have no doubt you intended well: You own a certain device and want to do a certain thing with it, and you're unable to. That is the same frustration everyone else here has faced. You presumably find this thread, or more likely some agent does, and it helps you to some degree down the road but doesn't fully get you where you want to go. And so you use AI to inch closer to the solution.

But that requires hubris. It first requires you to assume that the agent is more capable than those who have tried before it. And it further requires you to assume that you have a unique ability to prompt or control the agent in such a way that will create more favorable results than anybody else who has tried to use AI to solve this problem. Did you ever consider that? That other people have tried the exact same thing as you? It creates a feedback loop of LLM to LLM to LLM and, as mentioned above, it becomes impossible to find useful conversation.

Also, I interchange "agent," "LLM," and "AI" because at this point I have no clue what I'm supposed to call it. I am probably using these words incorrectly but I have decided that I don't care.

The AI written responses weren't just artificial— they did not add new information. And that distinction matters. The smoking gun here is that most of the information presented was already known, though I do think the webpages were somewhat useful as summaries of the work that has been done to be honest and I can appreciate that to an extent

…

On Wed, Sep 2, 2026, 10:13 AM Craige Leeder ***@***.***> wrote: *Craige* left a comment (linux-surface/linux-surface#1590) <#1590 (comment)> I agree with @dwhinham <https://github.com/dwhinham> and the sentiment from others. The AI madness is hurting things. At first it seemed dubious, but acceptable as a prototype for the few missing pieces that still existed. Then it seemed like are several different people/groups out there right now all duplicating each others work with lazy slop output, and none of it is driving to a single cohesive goal, and re-doing human-written and vetted components because they were too lazy to go find the work that was already done. Even if the output was *good* (which I doubt), that is still *madness*. There is a flood of noise to very little signal out there right now. I wish I knew how to help more. — Reply to this email directly, view it on GitHub <#1590?email_source=notifications&email_token=AHKFT2K3LJAFRHUMGM4D7JL5NATJRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJRGA4TEOBXGIZKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5510928722>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHKFT2N3XJQCJIK7SAGIUGL5NATJRAVCNFSNUABFKJSXA33TNF2G64TZHMYTKNJQGA4TONRXHNEXG43VMU5TENJZGI2TQOJXHA42C5QC> . You are receiving this because you were mentioned.Message ID: ***@***.***>

@orvitpng

@orvitpng 100% agree. This AI slop noise is nauseating and counter-productive.

I've been busy with work for the last year or so and had to pause SP11 development because I needed the machine to carry out that work, but have recently been motivated to pick things back up.

I've been testing yours and @scuggo's touchscreen work on top of Jingyuan Liang's spi-hid v4 patchset and it works perfectly on Surface Pro 11 too, including the pen.

I think we should reach out to Jingyuan Liang to give them feedback/add a few 'Tested-by's to help nudge things towards a merge. Then perhaps we could try to submit the QSPI/touchscreen code.

Happy to help with this or take the lead on it (appreciate you no longer have the machine) as I was successful in getting SP11 devicetree merged along with other fixes (eDP etc).

Really hoping qspi Geni support can be upstreamed, it's an annoying downstream burden presently and a Qualcomm employee I had spoken with said it was coming last July, though I did not see any patch posted unfortunately (or I missed it! Please correct me if I'm wrong, a patch would be lovely).

I've been inactive on my work here since Nvidia released the windows on arm eGPU driver, and since Linux doesn't have USB 4 on qcom there wasn't much point in me using it over windows especially while docked (and on the go: the worse battery life makes it a non starter). Previously I had used Linux when docked with a USB C dock since surprisingly Linux handled my MST DP Altmode dock better than windows did. I do applogize for that

@orvitpng 100% agree. This AI slop noise is nauseating and counter-productive.
I've been busy with work for the last year or so and had to pause SP11 development because I needed the machine to carry out that work, but have recently been motivated to pick things back up.
I've been testing yours and @scuggo's touchscreen work on top of Jingyuan Liang's spi-hid v4 patchset and it works perfectly on Surface Pro 11 too, including the pen.
I think we should reach out to Jingyuan Liang to give them feedback/add a few 'Tested-by's to help nudge things towards a merge. Then perhaps we could try to submit the QSPI/touchscreen code.
Happy to help with this or take the lead on it (appreciate you no longer have the machine) as I was successful in getting SP11 devicetree merged along with other fixes (eDP etc).

Really hoping qspi Geni support can be upstreamed, it's an annoying downstream burden presently and a Qualcomm employee I had spoken with said it was coming last July, though I did not see any patch posted unfortunately (or I missed it! Please correct me if I'm wrong, a patch would be lovely).

Support for it has been coming, and there have been patchsets submitted to the msm list. They are kind of buggy however, and there is overall a pretty big attempt at refactoring going on in the msm world so that has slowed things down. I took in the latest patchset when I was using it, but even then it had to be modified because the driver was communicating in a way that, while I think is technically standard, the devices weren't communicating with well. So I had to patch it a bit further.

I've been inactive on my work here since Nvidia released the windows on arm eGPU driver, and since Linux doesn't have USB 4 on qcom there wasn't much point in me using it over windows especially while docked (and on the go: the worse battery life makes it a non starter). Previously I had used Linux when docked with a USB C dock since surprisingly Linux handled my MST DP Altmode dock better than windows did. I do applogize for that

I do think that they are working on USB 4. Again, this is part of that major refactor. One big thing that frustrated me was that, when I docked my laptop, I could only have one monitor active in the dock. I was able to patch that up and get it working just before I got rid of the laptop by using another patchset. But that entire area was being refactored so it was annoying to mess with other patches and I ended up letting it be.

I'm thinking in the next year or so these refactors will take shape making further development far easier, and hopefully one day the kernel will overall have a much better relationship with Qualcomm and its devices.

Unfortunately, I think there is probably no real human behind that account, it seems to be automated with openclaw or something

Fair point about the wording. English is not my first language, and technical English even less so — without help I would not have written anything here at all. That is the honest reason, not an excuse.

I should have written it myself anyway, even if badly. So, plainly: this text is mine.

To everyone here: I only pushed all this with the best intentions. What I wanted was to give other people a guide for getting Linux running on their ARM Surface without having to put that much work into the research. I never meant to give anyone the impression that I had worked this out alone, or that I would be able to. I was more afraid of distorting the result by putting it into my own words.

And of course I do not understand all of it. I am only human. I do not think anybody here understands all of it either — one person knows the device trees, another knows the upstream process, someone else has the hardware in front of them. That is how this works.

Have a nice weekend,
Christian

@horizontblau

Can you all please report @horizontblau and can some maintainer please ban him from contributing here? It was a really valuable discussion so far, so reason to bloat it with AI slop answers. AI is a valid tool in helping with research, especially when reverse engineering or troubleshooting drivers, but without knowing anything about this whole process it is just wasting everybodies time...

Are you sure he's not just using Claude as a translator because that's what the prose felt like to me, I don't think it's a fully automated acc

…

On Sat, Sep 12, 2026, 12:18 AM Jan-Henrik Damaschke < ***@***.***> wrote: *itpropro* left a comment (linux-surface/linux-surface#1590) <#1590 (comment)> Can you all please report @horizontblau <https://github.com/horizontblau> and can some maintainer please ban him from contributing here? It was a really valuable discussion so far, so reason to bloat it with AI slop answers. AI is a valid tool in helping with research, especially when reverse engineering or troubleshooting drivers, but without knowing anything about this whole process it is just wasting everybodies time... — Reply to this email directly, view it on GitHub <#1590?email_source=notifications&email_token=AHKFT2PVJSYXTP2OSTA4STD5OTFDHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRUGM2DANZUGA22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5643407405>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHKFT2JYVP4VAVIH6HODTRD5OTFDHAVCNFSNUABFKJSXA33TNF2G64TZHMYTKNJQGA4TONRXHNEXG43VMU5TENJZGI2TQOJXHA42C5QC> . You are receiving this because you were mentioned.Message ID: ***@***.***>

Are you sure he's not just using Claude as a translator because that's what
the prose felt like to me, I don't think it's a fully automated acc
…

On Sat, Sep 12, 2026, 12:18 AM Jan-Henrik Damaschke < @.***> wrote:
itpropro left a comment (linux-surface/linux-surface#1590)
<#1590 (comment)>

Can you all please report @horizontblau https://github.com/horizontblau
and can some maintainer please ban him from contributing here? It was a
really valuable discussion so far, so reason to bloat it with AI slop
answers. AI is a valid tool in helping with research, especially when
reverse engineering or troubleshooting drivers, but without knowing
anything about this whole process it is just wasting everybodies time...

—
Reply to this email directly, view it on GitHub
<#1590?email_source=notifications&email_token=AHKFT2PVJSYXTP2OSTA4STD5OTFDHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRUGM2DANZUGA22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5643407405>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHKFT2JYVP4VAVIH6HODTRD5OTFDHAVCNFSNUABFKJSXA33TNF2G64TZHMYTKNJQGA4TONRXHNEXG43VMU5TENJZGI2TQOJXHA42C5QC
.
You are receiving this because you were mentioned.Message ID:
@.***>

Every single sentence down to the way the sentences are structured screams AI. But I don't want to jump in on this discussion, so let's keep it about the actual Surface Laptop topic :)

Hey, I own a surface laptop and would like to get Linux running on it. However, I'm not super well versed in kernel development, so I am unsure of how many needed drivers are missing from upstream? (If that's the right term? Basically, if I went and downloaded some random distro today, what would be missing?)

Alternatively, if there are things missing from upstream, would it be as "simple" as installing some random distro, then "replacing" it with the ELLX kernel linked above?

Finally, what does the experience feel like? Is it worth it to do this, or am I better off dealing with Windows anyway? (e.g. battery issues were mentioned above, as a result of threads not being parked correctly for a mobile use-case, etc. etc.).

@ProgrammerIn-wonderland

Depends if it were me I can't stand windows anymore. But there are definitely some issues that make me keep going back to my old laptop. The touch pad doesn't behave normaly last I tried (4 months ago).

It definitely worth a try if you know how to install linux semi-profiently. I installed latest Ubuntu ISO then used external perferials while I installed @ProgrammerIn-wonderland patches and kernel.

Just released https://public.hgci.org/software/ELLX/kernels/7.3.0-rc3-15.15/ which should be safer for sound, and is overall a newer kernel. No installer iso yet, I may not release one for a while so I'd just download regular ubuntu arm64 and install this kernel overtop it

as usual don't forget the trackpad and GPU fixes: https://public.hgci.org/software/ELLX/fixes/
IPTSD (for multitouch): https://public.hgci.org/software/ELLX/iptsd/ (much improved with the debounce this time, It's actually very usable and comparable to most other laptops imo, compared to before where it was borderline unusable)
Firmware (for WiFi/GPU/Audio): https://public.hgci.org/software/ELLX/surface-laptop-7-firmware/

bluetooth still requires manual configuration, camera works. It's pretty usable for a daily driver. Only thing which personally gets my to reboot to windows now is USB 4 peripherals. My kernel still doesn't support touchscreen though and its low priority since I don't use the touchscreen on my laptop

Note: This kernel is based on the kernel for Ubuntu 26.10, but I have only used it on Ubuntu 26.04. It should not matter though

Note: resume from suspend seems broken on this version, for daily use I'd still use 7.0.0-rc4 (though with audio off). I'll try and debug suspend in the coming days

Hey, I own a surface laptop and would like to get Linux running on it. However, I'm not super well versed in kernel development, so I am unsure of how many needed drivers are missing from upstream? (If that's the right term? Basically, if I went and downloaded some random distro today, what would be missing?)

Alternatively, if there are things missing from upstream, would it be as "simple" as installing some random distro, then "replacing" it with the ELLX kernel linked above?

Finally, what does the experience feel like? Is it worth it to do this, or am I better off dealing with Windows anyway? (e.g. battery issues were mentioned above, as a result of threads not being parked correctly for a mobile use-case, etc. etc.).

For the most part, you can install Regular Ubuntu 26.04 arm and just install the ELLX kernel and firmware and have a mostly working system. You wont have networking out of the box so you'll need to put the files on a USB stick, after they're installed you're mostly fine, it's just like any other linux laptop (except with a really good screen!)

Battery life is def worse on linux, not unusably slow, but it feels only a bit better than my Framework 13 from 2021 and 2021 was not a good year for laptop battery life, 6-7 hrs with normal use is what you can mostly expect (after disabling cores when not in use)

@orvitpng

To be completely clear to everybody, and I'd be willing to provide support where I can, the real solution to making touchscreen work is looking at what I've done. I'm sure newer versions of Linux might have a slightly different way about this and that new patches are out, but look at my NixOS flake and see how those device trees are done and how the kernel modules are built. I do believe that, soon enough, everything will be merged in so device trees will be the only thing needed on mainline. @horizontblau has provided device trees which, while they may work, are riddled with misconceptions about what the options do and are not equivalent to how Windows manages it. I'm not sure if anyone else has commented on this, but I also got close to or did fix the mousepad not waking up properly. I'm not sure if I committed that, and if I didn't, that is lost (but it shouldn't be too far off the trail from what was pushed to GitHub).

Hey @orvitpng can we get a small guide on how to use your flake? I'm a nix beginner (and in kernel stuff) and though I have been using it on a x86_64 machine for a while I struggled a lot when it comes down to more advanced nix config.

I tried using your module exposed in the flake by importing it into a nixosConfiguration as you can see in my flake below. Unfortunately a link and a hash was broken and I had to update those by forking your flake. My plan was to then build an Iso as I read on the wiki with this command while in my flake: nix build .#nixosConfigurations.surface-nixos.config.system.build.isoImage.

I had to do this on my nixos wsl on the surface laptop bc on my x86 pc it would not compile. Currently, I cant compile one of the C files you provided, maybe because my WSL kernel is older? Here's the output:

cpu_parking.c:63:26: error: implicit declaration of function 'get_cpu_idle_time_us' [-Wimplicit-function-declaration]
63 | prev_idle[cpu] = get_cpu_idle_time_us(cpu, &wall);
|

$ uname -a
Linux surface-nixos-wsl 6.18.33.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 18 21:38:49 UTC 2026 aarch64 GNU/Linux

This is where I am stuck rn.

Oh yeah, the whole reason I wanted to make an ISO is because trying to flash with the vanilla nixos ISO https://channels.nixos.org/nixos-26.05/latest-nixos-graphical-aarch64-linux.iso I was boot looping. I did disable secure boot. I read others had similar issues, sorry If I didn't read the solution I couldn't find it.

I'm on the 13 Inch and 16GB Ram version.

thanks in advance!

Navigation Menu

Repository navigation

Surface Laptop 7th Edition Support #1590

304 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Surface Laptop 7th Edition Support #1590

Description

Activity

the-quantum-nargle commented on Nov 2, 2024

qzed commented on Nov 2, 2024

vixalien commented on Jan 27, 2025

bryce-hoehn commented on Mar 12, 2025

bryce-hoehn commented on Mar 12, 2025

bryce-hoehn commented on Mar 14, 2025

bryce-hoehn commented on Mar 19, 2025

qzed commented on Mar 19, 2025

qzed commented on Mar 19, 2025

qzed commented on Mar 19, 2025

bryce-hoehn commented on Mar 19, 2025

bryce-hoehn commented on Mar 20, 2025

vixalien commented on Mar 20, 2025

vixalien commented on Mar 20, 2025

qzed commented on Mar 20, 2025

304 remaining items

Craige commented on Sep 2, 2026

orvitpng commented on Sep 2, 2026

ProgrammerIn-wonderland commented on Sep 2, 2026

ProgrammerIn-wonderland commented on Sep 2, 2026

orvitpng commented on Sep 2, 2026

vixalien commented on Sep 2, 2026

horizontblau commented on Sep 11, 2026

itpropro commented on Sep 12, 2026

ProgrammerIn-wonderland commented on Sep 12, 2026

itpropro commented on Sep 13, 2026

OptimisticPeach commented on Sep 21, 2026

Notliam99 commented on Sep 23, 2026

ProgrammerIn-wonderland commented on Sep 24, 2026

ProgrammerIn-wonderland commented on Sep 24, 2026

EnzyZero commented on Oct 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions