Repository navigation
Surface Laptop 7th Edition Support #1590
Description
Activity
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/2084951So 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).
Reacted by BreakfastBerryaccording 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 fdtlspci -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: nvmesudo dmesg: dmesg.txt
Output of
sudo dtc -I fs -O dts -o full-device-tree.dts /sys/firmware/devicetree/base/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"; }; };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 00After 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] ETIMEDOUTTimeout 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 01Trackpad 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] ETIMEDOUTAnother 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 the00indicates that it accepted the command. The01later for device03(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> 0for
<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.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.dtsidiff -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.cdiff -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 link2: 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:ffTried 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-killI 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.cdiff -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-killI 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.msiFinally 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:
Reacted by Angelo Verlain, 两米 and Nigel BaillieI noticed this file was not present in my /lib/firmware folder
Did you run the
qcom-firmware-extracttool 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#n116The firmware should be located in
/lib/firmware/updates/qcom/x1e80100/microsoft/Romulusafter you run the script.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_cdevto load the debug interface. The patch forsurface_aggregator_registrydoesn't have any effect. That's only for ACPI based devices. Upstream already has the equivalent change for DT.304 remaining items
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 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.
Reacted by Craige Leeder and Binozo- 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 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
Reacted by Doloro, Felix N. and Liam TFair 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,
ChristianCan 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: ***@***.***>Reacted by Oliver White
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.).
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 Reacted by Vladimir Alekseev, andreasbjorshol, Patrik Buhring, Badhri and OliveHey, 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)
Reacted by Patrik BuhringTo 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/LinuxThis 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.isoI 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!
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.