Surface Laptop (2024), Windows 11 Copilot+ PC, 13.8" Touchscreen Display, Snapdragon X Elite (12 core), 16GB RAM, 1TB SSD Storage, Black

I recently purchased the Microsoft Surface Laptop (2024), and overall, I’m incredibly impressed with its performance. The 13.8" touchscreen display is vibrant and crisp, and the Snapdragon X Elite (12-core) processor makes multitasking a breeze. With 16GB of RAM and 1TB SSD storage, this laptop handles everything I throw at it—whether it’s video editing, running complex software, or just casual browsing. Windows 11 runs smoothly, and the device feels premium and well-built. Battery life is outstanding, and it’s surprisingly lightweight, making it great for both work and travel. The laptop is fast, responsive, and does exactly what I need without any hiccups. However, my one gripe is that after spending nearly $2,000 on this high-end machine, I still have to pay extra for Copilot+. Given the price of the laptop, I would have expected this feature to be included, especially since it’s one of Windows 11's flagship features. While Copilot+ is a helpful AI tool, it feels like it should be a standard part of the package. Overall, I’m still giving it 5 stars because the hardware is fantastic, and it excels at everything I use it for. I just wish Microsoft would rethink the pricing model for Copilot+.

I'm a software engineer, and purchased this mainly out of curiosity to try and boot Linux on it. I managed to get a custom version of Ubuntu to boot to desktop, launch Firefox, etc using a USB keyboard, mouse, and boot drive (the installer for Ubuntu even sort of works, minus some bootloader issues regarding efivars). I was also able to install to the internal NVME drive as well, but unfortunately it seems that this is where things are a bit problematic from a standardization standpoint. Qualcomm's EFI implementation doesn't seem to support efivars, so you can't set Ubuntu as a boot option in the EFI boot menu (it only supports actual hardware drives as boot options). Installing the EFI executable in the standard location for the EFI boot directory doesn't work either. It turns out, that the EFI bootloader checks in the Microsoft directory first, then in the regular boot directory, so it's necessary to rename the Microsoft one to something else if you want to dual-boot Linux and Windows. This also means that it's currently not possible to enroll a custom secure boot key, so secure boot must be turned completely off to dual-boot Linux (as it can't be done with the signed Canoncical kernels, as each board will likely require a different kernel, and none of this is supported by the official kernels yet, this would also be very difficult for Canonical to maintain if they need to make a separate kernel for each board, which is unfortunately fairly typical for ARM devices in general. This is a problem I thought Microsoft would have solved, given how they standardized the PC platform on x64, but this doesn't seem to be the case).Another major issue with booting Linux even before you get to the kernel, is the bootloader starts in EL1, not EL2. There's a proprietary mechanism by which to escalate from EL1 to EL2 (Qualcomm secure launch) , but this only works for signed Windows binaries, so makes hypervisors effectively impossible to implement in Linux for this board.Additionally, Qualcomm uses non-standard ACPI descriptors for USB (XHCI). To initialize USB, you need to patch xHCI to bind to QCOM0D08, as it uses this descriptor rather than the standard PNP0D10, and isn't on the PCI bus like you'd expect on a PC (it's an ARM peripheral instead). Bringing up wifi didn't work with standard openly available firmware either, so relevant files had to be extracted from the Windows drivers for firmware, which got the ATH12k chip (which is actually on the PCI bus, along with NVME) to start up.Unfortunately, very little about this is standard, and each ARM board is likely to be slightly different. HID for example appears to be on a proprietary bus, and bringup of all these new ARM PCs will be very tricky for the Linux community to try and support. Virtualization support for Linux in Windows is also poor, with the USBIPD driver not supporting aarch64, and no way for the vendor to support aarch64 due to the closed-source nature of Windows Drivers (they currently rely on a shim driver from VirtualBox).Also from what I can tell there's no exposed serial port for debugging on this board, so if you're also bringing up Linux on this, make sure to use console=efifb as a kernel parameter to get debug output during bringup.