Status #27

Sonicadvance1 · 2019-12-24T05:52:56Z

Sonicadvance1 · 2019-12-24T11:36:53Z

https://twitter.com/Sonicadvance1/status/1199894673013137408
This is the device booting, but it is with ACPI boot and has severe limitations.
ACPI isn't really desired for ARM devices under Linux (I don't believe Freedreno even supports ACPI booting devices), so Device Tree needs to be generated.

Dmole · 2020-07-17T12:23:37Z

Might be worth asking the kernel contributors with Microsoft/Qualcomm emails for help.

git log --format=fuller | grep -P '@(microsoft|.*qualcomm)' | perl -pe 's/.*<|>//g' | grep -v " " | sort | uniq -c | sort -rn | grep -P '\d{3} '
   5212 [email protected]
   3012 [email protected]
   1774 [email protected]
   1697 [email protected]
   1245 [email protected]
    929 [email protected]
    634 [email protected]
    613 [email protected]
    536 [email protected]
    469 [email protected]
    450 [email protected]
    402 [email protected]
    396 [email protected]
    390 [email protected]
    347 [email protected]
    297 [email protected]
    284 [email protected]
    280 [email protected]
    264 [email protected]
    259 [email protected]
    184 [email protected]
    144 [email protected]
    134 [email protected]
    106 [email protected]
    101 [email protected]

lkocman · 2020-08-22T19:43:15Z

Hello @Sonicadvance1 how did you get the system to the internal storage? Install image on a USB pen drive, or did you write image/system to the internal storage directly?

I'm just trying to get TW aarch64 image booting from a pen drive, so far it's not being recognized when I choose to boot from USB drive in the Surface/UEFI menu.

I did buy a usb c reader for the internal drive, but unfortunately it seems to be broken, so I'm stuck with pendrive.

I must say that the option to easily swap disks and have one installation WIP is a big plus in otherwise hostile environment :-)

lkocman · 2020-08-22T20:22:08Z

My experience with booting a USB install image:

I've tried to boot from The advanced recovery options, however that messed up the underlying windows installation and generally always took longer as it asks me for a bitlocker recovery key.

Bitlocker drive encryption can be turned off from Windows. Control Panel -> System and Security -> BitLocker Drive Encryption -> Turn off Bitlocker (Triggers disk decryption on background).

If you go to Surface UEFI - > Boot Configuration and simply swipe left, then the entire cycle takes few seconds.
I did turn of the secure boot, however I didn't yet get to the point where it would make the difference.

My setup is a usb-c connected dell docking station with 1GB SandDisk USB-3.0 flash drive with latest openSUSE TW aarch64 image connected to the docking station. I'm using usb based mouse+keyboard connected to the dock and they both work well in the Surface UEFI area.

I didn't get the usb pen drive with aarch64 openSUSE TW booting via docking station, but I suppose it's because the was simply not recognized. Next step is to try usb-c pendrive directly connected to the surface device. That will have to wait until mid of next week as shops are closed on Sunday and I'll be travelling Monday/Tuesday.

So current goal is to get grub2 screen, next goal is to get kernel loaded.

lkocman · 2020-08-25T19:53:50Z

Just for keeping track of progress

So default openSUSE Tumbleweed aarch64 image on a usb-c flash disk plugged directly to surface boots (Volume Up+ power button -> Surface UEFI -> Boot from USB) for about 3 seconds and freezes on following
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual adress map...

lkocman · 2020-08-25T21:51:43Z

I'm now trying to build openSUSE Tumbleweed minimal CD with a kernel patch from Ryan
https://build.opensuse.org/project/show/home:lkocman:aarch64-laptops

My 5.8 based-branch where I'll add individual changes from Ryan and hopefully later some more
https://github.com/lkocman/linux/tree/wip/sq1_surface_prox
Patched kernel will be then built here https://build.opensuse.org/package/show/home:lkocman:aarch64-laptops/kernel-source

RussianNeuroMancer · 2020-10-03T03:17:01Z

I'm now trying to build openSUSE Tumbleweed minimal CD with a kernel patch from Ryan

Does it help?

kachapman · 2020-10-22T15:20:39Z

Has there been any improvement to device functionality since the Dec post last year?

lewurm · 2020-10-28T10:33:53Z

Leaving this as a reference: Patches to support the embedded controller in Surface devices are about to be upstreamed: https://lkml.org/lkml/2020/9/23/535

This should help to get the keyboard cover working (if not more).

Dmole · 2020-10-28T13:37:23Z

This should help

The Surface Pro X is, however, currently considered unsupported due
to a lack of test candidates and, as it seems, general lack of
Linux support on other parts. AFAIK there is an issue preventing
serial devices from being registered, on which the core driver in
this series is build on, thus there is no way to even test that at
this point. I'd be happy to work out any issues regarding SAM on
the Pro X at some point in the future, provided someone can/wants
to actually test it.

qzed · 2020-10-28T15:33:27Z

My information for the comment above comes from #7 (comment). If that still holds true, i.e. if the Surface Serial Hub (SSH/MSHW0084) device still is not present, the SAM modules won't load. SSH is basically the interface to the EC. Also it's a UART, if that matters (essentially handled via the serdev interface, should show up at /sys/bus/serial/devices).

Also if anyone has access to an acpidump/DSDT, can you post one to https://github.com/linux-surface/acpidumps (see here for more details)? I'd love to have a look at it, although I'm not sure I can do much about it if the UART device doesn't show up.

Regarding there being no keyboard "device": Are you sure it's connected via SAM (if so, how?). If it is, we'll have to figure out what interface it's using. Likely the updated HID interface, but we'll have to confirm that and manually add the device. Also we'll need to figure out how detachment is handled (i.e. are there any GPIOs that signal this?) and if we have to take care of that ourselves (which is quite likely).

Edit: Feel free to report back at linux-surface/surface-aggregator-module#53.

RussianNeuroMancer · 2020-10-28T21:12:26Z

Also if anyone has access to an acpidump/DSDT,

You can take it here: https://github.com/aarch64-laptops/build/tree/master/misc/microsoft-surface-prox

qzed · 2020-10-28T22:23:51Z

Thanks. According to the DSDT the underlying UART has HID QCOM0418. I can't seem to find any driver for that upstream, so could be that it's missing one (or at least an ACPI version for it). If so, you'll have to fix that first (or, of course, describe everything with DTs, but then you'll also have to adapt the SSH driver to load as that currently only supports ACPI, shouldn't be a huge change though).

Also, depending on the kernel version (and if you decide to use ACPI) you may need to back-port torvalds@33364d6 (required for the SSH device to be created) and torvalds@6d232b2 (required for the SAN device to behave properly).

thmichel · 2020-11-08T19:28:44Z

Just for keeping track of progress

So default openSUSE Tumbleweed aarch64 image on a usb-c flash disk plugged directly to surface boots (Volume Up+ power button -> Surface UEFI -> Boot from USB) for about 3 seconds and freezes on following
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual adress map...

Same here. Downloaded the latest iso from the OpenSuse build server.

denysvitali · 2021-01-28T01:13:31Z

Uhm, same here, stuck at:

EFI stub: Exiting boot services and installing virtual adress map...

I've tried with a modified kernel using this patch:
b1fc9ae

but it still stuck there.

I'm using a Surface Pro X SQ2 and I'm manually booting the kernel via GRUB (any tip on how to speed up the kernel trial and errors would be great!)

denysvitali · 2021-01-28T08:02:23Z

I would also like to point out that @lkocman 's iso image (OpenSUSE ISO) has the exact same problem: stuck at EFI stub: Exiting boot services and installing virtual address map....

I'm not sure if there might be a huge difference between SQ1 and SQ2 that may require a different patch... 🤔

Can someone with a SPX SQ1 check if the above mentioned iso gets stuck as well?

Here is a mega.co.nz mirror of that image, since it is built every night:
https://mega.nz/file/xuB1QaLC#j--JPwNDFVSOHYtiUPZ0vWsVHDQHsKJ5omBxBdTPuwA

SHA256:

dba6a104e21a144aa7de89048d53bf2f57a6f9b740ae32725ac6924f145d4e9d  openSUSE-Tumbleweed-NET-aarch64-Build4.71-Media.iso

denysvitali · 2021-01-28T15:11:02Z

Apparently it gets stuck here after update_fdt:

denysvitali · 2021-01-28T17:04:16Z

Status update: after applying the patch again, it doesn't get stuck anymore at the efi_exit_boot_services anymore. The kernel panics though and thus the device restarts as soon as the kernel loads (the penguins are visible for a couple of ms)

denysvitali · 2021-01-29T08:04:10Z

Okay, so for some strange reason the b1fc9ae patch doesn't work, but mine (with the debugging information) denysvitali/surface-pro-x-linux@4494427 does.

Could it be maybe related to some delay that we have to add? In any case, I can't seem to get past a quick three penguins screen (that is shown very distorted for < 20ms) and a reboot that happens after the penguins disappear and after ~ 6 seconds have elapsed. I feel like the kernel is booting but the display is not correctly initialized. I'm now trying to force the screen to not take over and keep the fbcon.

No luck with nomodeset and vga=0 :(

klardotsh · 2021-01-30T09:26:53Z

Sorry to jump in if you've already tried this, but do you by chance get more context with earlycon=efifb? I think earlycon might be gone by the time you see Tuxen but it's worth a shot perhaps (my C630 would spit out useful debugging context with that when I was testing kernel builds)

denysvitali · 2021-01-30T12:23:45Z

Thanks Josh for your help! This indeed has helped me understand better what happens. The kernel starts (duh!) but anything past the earlyprintk is basically hidden. I think that the display might get initialized and thus the console output is hidden since I can clearly see the display becoming black for 5 seconds. Then the device reboots.

I guess that underneath the kernel does indeed start, but then it panics somewhere. Without a tty it is really difficult to see what's going on: maybe a look at the DT might help me somehow

denysvitali · 2021-01-30T14:15:01Z

Okay, another status update, booting with earlycon=efifb console=efifb gives waay more output and shows where the screen gets blank (I had to take a video). I can spot some ACPI and firmware errors, but I don't think they're relevant for a successful boot. What happens is that after this last line (related to SMMU), the screen goes black and the device restarts after ~5 seconds.

Here is a picture of the kernel messages right before the screen goes black:

denysvitali · 2021-01-31T11:59:43Z

Okay, silly me, I wasn't using any dtb when booting 🤦‍♂️

It now kind of works (no reboot) and the penguins are shown correctly, with a nice kernel log output on screen that unfortunately gets stuck after a while.

My setup:

USB-C HUB (HooToo, as used in my linux-pixelc project)
64 GB SD Card
16 GB USB drive

On the 64 GB SD Card I keep an iso of Ubuntu 20.04 Server for aarch64, and since iso images aren't that easy to edit, I use an external USB drive to quickly put new kernel images and other useful files that I later on load with GRUB using the partition name (in my case (hd1,msdos1))

My GRUB entry is:

devicetree (hd1,msdos1)/prox_sc8180.dtb
linux (hd1,msdos1)/Image
initrd /casper/initrd

denysvitali · 2021-01-31T19:11:09Z

I've tried the ACPI way (extracting the ACPI tables from Windows and using them when compiling the kernel), but unfortunately I don't get anything more than a boot that is stuck at the EFI messages

denysvitali · 2021-02-01T05:03:47Z

@mirh suggested me that this patch might be helpful: https://gitlab.freedesktop.org/drm/msm/-/commit/aded8c7c2b72f846a07a2c736b8e75bb8cf50a87

I'll look into it ASAP

Nevermind, that patch is already in the kernel I'm using, therefore it is not needed and doesn't fix the boot problem :(

Vascro · 2021-12-21T23:41:32Z

There's not much in the way of information for this project on the web, might be a good idea to post in r/surfacelinux or r/surfaceprox to drum up support. I'd love to see a full linux kernel released for my SPX in the next year.

qzed · 2022-05-01T22:41:14Z

I've had some time to look at the SPX again and tried to figure out why some GRUB versions work and some don't. Upstream v2.06 works out of the box and the issues seem to be caused by some Fedora/RHEL patches (which are likely in some form also used by other distributions). I've written down the details in linux-surface/grub#1 and I might set up a GitHub build for a basic GRUB image at some point, so that we have a more or less reproducible way to get a working bootloader.

qzed · 2022-05-06T00:26:36Z

Did anyone get recent kernels working with a DT? I've tried to update to https://github.com/andersson/kernel/tree/wip/sc8180x-next-20220502, but I'm running into a black screen. My guess is that it's trying to do some graphics hand-off that fails. Any idea how I can prevent this and get some standard (efifb?) terminal?

qzed · 2022-05-15T19:42:57Z

Okay, turns out that's an issue with the panel, GPU, or SMMU. Disabling SM_DISPCC_8250 is a workaround for now. That prevents the SMMU stuff from probing and thus probably some reconfiguration... I'll have to deal with that once I get to GPU support.

And with that sorted, I've been able to get a working DT again. This time also with proper PCI and NVME support (although I still have some questions about that... and I'm not 100% sure if it's fully reliable yet). The two USB-C ports also work, but the surface connect port needs some more work. I also haven't implemented SAM support just yet (so no keyboard/touchpad etc.) but that's next on my list. You can find the kernel at https://github.com/linux-surface/kernel/tree/spx/next-20220502.

I've also posted a minimal-ish config at https://github.com/qzed/aarch64-kernel-configs/blob/main/spx-5.18.0-base.config. Just note that I've disabled a ton of stuff that I don't need (and enabled some debugging options), so you'll probably need to enable a couple of things to make it work for your setup (e.g. if you use an USB ethernet adapter that's not based on the RTL8152/RTL8153 chips).

qzed · 2022-05-16T23:42:28Z

SAM clients work (so we again have keyboard/touchpad and battery info support). Bluetooth works as well. However, I'm running into the same issues as before with regards to wifi.

Trying to use the non-modem firmware results in

[  345.265964] remoteproc remoteproc0: powering up 4080000.remoteproc
[  345.321934] remoteproc remoteproc0: Booting fw image qcom/MS/spxsq2/qcmpss8180_nm.mbn, size 5217520
[  345.358976] qcom_q6v5_pas 4080000.remoteproc: error -22 initializing firmware qcom/MS/spxsq2/qcmpss8180_nm.mbn
[  345.358986] remoteproc remoteproc0: Failed to load program segments: -22
[  345.359342] remoteproc remoteproc0: Boot failed: -22

Trying to use the modem-enabled firmware results in

[   98.042942] remoteproc remoteproc0: powering up 4080000.remoteproc
[   98.834875] remoteproc remoteproc0: Booting fw image qcom/MS/spxsq2/qcmpss8180.mbn, size 75470832
[   98.953517] regulator-dummy: DRMS operation not allowed
[   99.366675] regulator-dummy: DRMS operation not allowed
[   99.369246] remoteproc remoteproc0: remote processor 4080000.remoteproc is now up
[   99.394470] qcom_q6v5_pas 4080000.remoteproc: fatal error without message
[   99.394555] remoteproc remoteproc0: crash detected in 4080000.remoteproc: type fatal error
[   99.394665] remoteproc remoteproc0: handling crash #1 in 4080000.remoteproc
[   99.394718] remoteproc remoteproc0: recovering 4080000.remoteproc

followed by a CPU stall, presumably on the CPU trying to initialize and recover the remoteproc.

qzed · 2022-05-18T01:23:16Z

Okay, WiFi still doesn't work but I managed to get the HID-over-SPI touchscreen working with the driver form the Surface Duo 2. Not that it's of much use without proper GPU/display panel support... I'll try to figure out that next before going back to WiFi.

I've also added bindings for the ambient light sensor, although I think that should be a TCS3430 instead of an APDS9960. The interface seems to be similar and the reported intensity values react proportional to light, but it's very insensitive and you have to directly shine a flashlight onto it for it to report anything. Trying different intensity scales and integration times (via the sysfs interface) also doesn't behave like I'd expect. But that's a problem for another time I guess... display first.

qzed · 2022-05-29T02:13:24Z

Time for another update: The GPU is working... sort of, at least I think it is. But the display only shows a black screen. The backlight is also working and can be controlled. I think it might be related to the problem I've described in #27 (comment).

Regarding the GPU, it looks like the "Microsoft SQ2 Adreno 690" is probably an overclocked Adreno 680. Apparently there's supposed to be a Qualcomm Adreno 690 (based on the 660 whereas the 680 is based on the 640), which had me confused for a bit. It turns out that as soon as you write the chip-ID for the 690 to the respective register, the GPU firmware refuses to boot, but when I write 680 to that it works. As MS called it 690, I've initially created a driver entry for that and with that ID (assuming I could just arbitrarily choose that). Took me way too long to figure this out, but the chip-ID written to the register is derived from that one, so naturally nothing from that entry worked (regardless of firmware I've tried).

Regarding firmware: The Windows driver has some firmware embedded, which I've extracted and posted here: https://github.com/linux-surface/aarch64-firmware. Generally, the GPU works with the 680 firmware from that repo and the 640/630 firmware from the official firmware repo. There are two sets of firmware in the Windows driver, one resembling the 660 firmware (which I've named 690 due to that) and one resembling the 640 firmware (which I've named 680).

I've also rebased onto the latest linux-next branch: https://github.com/linux-surface/kernel/tree/spx/next-20220527.

qzed · 2022-06-02T17:14:54Z

Thanks to a ton of help from @andersson and @robclark (and the aarch64-laptops IRC in general), we now have a GPU-driven display. Things are still a bit wonky (e.g. the occasional lock-up during boot), but we're slowly making progress towards a somewhat usable state. I'll try to have another go at WiFi next and then maybe try a more usable (i.e. non-minimalistic) kernel config and proper install on the internal nvme drive.

(Note: Battery stats work but the upowerd service didn't want to start for some reason... so no battery widget yet. Might be config related as running upowerd from the command line works and shows the expected output).

qzed · 2022-06-06T01:14:32Z

Very brief update: I've got WiFi working, but it requires some fiddling with firmware. I'll try to write this up a bit better once I've figured out how to best package everything for a somewhat easy setup.

In essence, you need the firmware structure posted here, with the jsn files from here (thanks to @andersson for those). The mbn files can be obtained from Windows. Then essentially follow these steps. For the board-2.bin step, you need to deviate a bit and create a json with "names": ["bus=snoc,qmi-board-id=ff,qmi-chip-id=30224"] linking to any bdwlan.bNN or bdwlanu.bNN file, except for the b5f ones. You can use the output from the script as reference and then just modify one entry and delete the rest, then run the last command in the script manually. I'm not really sure which bdf file to choose. Anything seems to (mostly) work, with the exception of the b5f files causing a crash on the wifi remote processor. Lastly, you'll need to modify the firmware-5.bin file (should be provided by your standard linux-firmware package) as described in the last step here. That makes some warnings disappear, which you can read more about here. Also, while starting the services, keep an eye on the kernel log. If you've done everything correctly, the wifi remoteproc should boot up. If you've made a mistake, chances are that the remoteproc will crash into an unrecoverable state and you'll have to reboot.

qzed · 2022-06-06T02:32:19Z

Oh, and what I forgot: You'll also need to edit the rmtfs.service to use local files instead of looking for partitions. Normally, there are partitions with modem stuff on them, but the Pro X doesn't seem to have those on the NVME SSD. It looks like they might be on some (Q)SPI flash chip instead. So in the service, drop the -P option and add a -o <directory> option where the directory points to some directory that you've created. In that directory, you'll have to create a bunch of ~2MB dummy files (e.g. via dd if=/dev/zero of=<file> bs=2M count=1. The file names you want to create are listed in the center column here.

Also: Keep an eye on the services and their output when starting them the first time and make sure they're all running correctly.

qzed · 2022-06-07T18:41:23Z

Alright, I've added a bunch of repositories and prepared some Arch packages to hopefully make things a bit easier. Most importantly, I've created a repo for tracking the current status via issues at https://github.com/linux-surface/surface-pro-x and a project to manage them at https://github.com/orgs/linux-surface/projects/1. I still need to add some issues and update the actual status issue, but I've already created a wiki in this repo with instructions on how to get the wifi, bluetooth, and gpu working. The wiki should be editable, so if you have any improvements, feel free to add them.

To help with firmware, I've added a script to https://github.com/linux-surface/aarch64-firmware.

qzed · 2022-06-12T01:05:38Z

Another small update: I've added and updated more issues for tracking the current status and stuff that needs to be done, and added a small very basic section with some stuff regarding installation at https://github.com/linux-surface/surface-pro-x/wiki/Basic-Setup. Feel free to edit and extend that if you think you can improve something.

I've also added a basic fragment config at https://github.com/qzed/aarch64-kernel-configs/blob/main/fragments/spx.config. You should be able to use this with the merge_config.sh script from the kernel and some basic distro config to get a working config for the Pro X.

I've been running an install on the NVME for a bit now and there don't seem to be any major issues with that, apart from the occasional (black-screens) hick-ups during boot.

Lastly, I've tried to set up secure boot, but that likely won't work for the foreseeable future. The main problem is not device related, but rather that there doesn't seem to be any MS/UEFI-CA signed shim around for AArch64... so unless we get one, there won't be any secure boot on the Pro X. And PreLoader also doesn't seem to be an option since the only link to that that I can find is to some blog with a signed x64 version...

qzed · 2022-06-12T17:03:26Z

Re secureboot: Turns out opensuse has a signed shim for aarch64, but we probably lack the grub patches to make that work with shim (at least, it doesn't want to run any other efi files like mokmanager). And those seem to be the Fedora patches that break boot... so we should probably figure that out first.

qzed · 2022-06-21T03:24:58Z

Two new items on the list of supported things:

First, the USBs for the Surface Connect port now work, meaning if you have a Surface Dock, you can use that for USB and ethernet. Display-ports don't work yet (neither on the Surface Connect port nor on the USB-C ports).

Second, I've implemented a very basic real-time clock. The SPX doesn't seem to use the one provided by Qualcomm (that returns a wrong date and can't be set), but one via SAM (the EC). The driver doesn't support wake alarms yet, but you now at least get the correct time even if you boot without NTP / ethernet. Bonus: You don't need to do any shenanigans like setting Windows to use UTC for the RTC or Linux to use local-time, as SAM provides two interfaces: One local-time interface adjusted for the timezone (ACPI TAD / ACPI000E-like) and another interface providing the raw UNIX timestamp in UTC. Windows uses the local-time interface while the Linux implementation uses the raw UNIX timestamp. So both get what they prefer. Also, setting/updating the time via one interface correctly updates the other.

denysvitali · 2022-06-21T05:13:19Z

Do you have a PayPal link to which we can send donations? Your contribution to the project is amazing.

Thanks for everything you're doing ❤️

qzed · 2022-06-21T21:51:51Z

Thanks for considering! But please keep in mind that I don't rely on that money and that I'm doing this regardless of any donations. There are definitely people who need that more than me (and also charities...). But if you still insist: https://paypal.me/maximilianluz

qzed · 2022-06-27T21:19:10Z

I've tried to have a look at suspend. Seems only s2idle might be supported by this platform, but that is currently broken. Most of the times it doesn't wake up, sometimes it does but with broken PCIe and USB, and I've had only one lucky attempt where USB-serial came back and I was able to get a log. I've posted that at https://gist.github.com/qzed/2288c651a017fcc016b524d3bac5a43e#file-dmesg-log.

And since trying to debug this is a bit frustrating, I've distracted myself by writing a thermal sensor driver for the Surface Aggregator Module. So we now should have support for all thermal sensors on the device.

qzed · 2022-07-12T02:22:13Z

Couple new things:

We now have a package repository for Arch Linux, providing pre-built kernel and firmware packages. See https://github.com/linux-surface/surface-pro-x/wiki/Package-Repositories for details.
I've created a small tool to create bootable disk images. You can use that to create a bootable USB stick with all the changes necessary to make the Pro X work, including WiFi. The created image is a bare-bones Arch Linux ARM system, which you can then use as install media to install a proper system to the nvme.

There are a couple of kinks with it though: First, everything is packaged into one big initramfs. That means it takes a bit to boot and might seem like it's stuck while loading the initramfs or shortly later while extracting it. Second, the problem with the display not coming back up remains, so sometimes you'll have to force-power-off and reboot.

You can also use this tool to set up root and EFI partition contents and then manually copy them to a partitioned USB stick for a persistent option. Also, you can customize things fairly easily since everything is set up in a chroot, so you could even create a fully set up install. Via binfmt_misc and qemu-user-static, you don't even need an aarch64 host for this.

qzed · 2022-07-12T12:00:29Z

I've updated the wiki a bit (in particular https://github.com/linux-surface/surface-pro-x/wiki/Basic-Setup). Could still use some improvements and details, so feel free to edit that.

kasperk81 · 2022-07-14T21:46:57Z

@qzed, is there anything improved in mainline kernel 5.19 that has helped this port?
https://www.debugpoint.com/linux-kernel-5-19-rc1/

qzed · 2022-07-14T22:06:39Z

@kasperk81 A bunch of @andersson's patches have been merged. As far as I can tell, the "Major ARM update" mentioned in the article is work that's been going on over multiple kernel releases, and the base Qualcomm stuff has been present for a while (in part at least thanks to Chrome Books, I guess). The display port/GPU stuff has seen some changes with the introduction of the DP AUX bus (which I think was introduced in 5.19, but might have been a bit earlier), which has helped quite a bit (essentially making generic eDP displays easier to support). Apart from that, I don't think anything major has happened.

qzed · 2022-07-18T22:02:49Z

Thanks to @StollD, we now have multi-touch support via IPTSd. Pen still needs some work. I've added instructions for this to the wiki.

qzed · 2022-07-22T23:11:24Z

The pen works reasonably well off the main IPTSd branch now with a small tweak (documented in the wiki). Also, we can now access EFI variables from the kernel (and via efivarfs from user-space). So no more EFI-shell required for adding a boot entry.

shawnguo2 · 2022-07-23T14:19:50Z

@qzed Do you know the specific kernel commits that make EFI variables start working on the device?

qzed · 2022-07-23T16:26:36Z

@shawnguo2 I've prepped them for upstreaming at https://github.com/linux-surface/kernel/tree/s/spx/qcom-tee-uefisec/v1. There's currently still some oddity on the c630 and linux-next which I want to figure out before sending them off (and also whether they should go to drivers/firmware or drivers/soc/qcom, but that can also be discussed on the mailing list).

The specific commits you want are linux-surface/kernel@58b9ca2...e2a0193 plus some DT binding like linux-surface/kernel@859bab7.

shawnguo2 · 2022-07-24T00:42:28Z

@qzed Thanks for the pointers and such great work!

Sonicadvance1 pinned this issue Dec 24, 2019

Sonicadvance1 added the help wanted Extra attention is needed label Dec 24, 2019

Dmole mentioned this issue Jul 17, 2020

Ultraportable laptop with 7nm/5nm ARM processor system76/laptop-suggestions#133

Open

Dmole mentioned this issue Oct 28, 2020

People wanting to test Surface Pro X linux-surface/surface-aggregator-module#53

Closed

denysvitali mentioned this issue Jan 29, 2021

Surface Pro X SQ2 support jakeday/linux-surface#672

Open

qzed mentioned this issue Apr 7, 2022

Surface Pro X? linux-surface/linux-surface#788

Open

jhaxhiaj mentioned this issue Apr 20, 2022

USB host controller not probed with v5.12-spx-dt and v5.13-spx-dt linux-surface/kernel#121

Closed

hexdump0815 mentioned this issue May 17, 2023

snapdragon_7c_woa: status hexdump0815/imagebuilder#136

Open

hexdump0815 mentioned this issue Dec 6, 2023

chromebook_cherry: status: tomato (acer cp513-2h) hexdump0815/imagebuilder#61

Open

Status #27

Status #27

Comments

Sonicadvance1 commented Dec 24, 2019 • edited Loading

Sonicadvance1 commented Dec 24, 2019

Dmole commented Jul 17, 2020 • edited Loading

lkocman commented Aug 22, 2020

lkocman commented Aug 22, 2020 • edited Loading

lkocman commented Aug 25, 2020

lkocman commented Aug 25, 2020 • edited Loading

RussianNeuroMancer commented Oct 3, 2020

kachapman commented Oct 22, 2020

lewurm commented Oct 28, 2020

Dmole commented Oct 28, 2020

qzed commented Oct 28, 2020 • edited Loading

RussianNeuroMancer commented Oct 28, 2020

qzed commented Oct 28, 2020

thmichel commented Nov 8, 2020

denysvitali commented Jan 28, 2021

denysvitali commented Jan 28, 2021 • edited Loading

denysvitali commented Jan 28, 2021

denysvitali commented Jan 28, 2021

denysvitali commented Jan 29, 2021 • edited Loading

klardotsh commented Jan 30, 2021

denysvitali commented Jan 30, 2021 • edited Loading

denysvitali commented Jan 30, 2021 • edited Loading

denysvitali commented Jan 31, 2021 • edited Loading

denysvitali commented Jan 31, 2021

denysvitali commented Feb 1, 2021 • edited Loading

Vascro commented Dec 21, 2021

qzed commented May 1, 2022

qzed commented May 6, 2022

qzed commented May 15, 2022

qzed commented May 16, 2022

qzed commented May 18, 2022

qzed commented May 29, 2022

qzed commented Jun 2, 2022

qzed commented Jun 6, 2022

qzed commented Jun 6, 2022 • edited Loading

qzed commented Jun 7, 2022

qzed commented Jun 12, 2022

qzed commented Jun 12, 2022

qzed commented Jun 21, 2022

denysvitali commented Jun 21, 2022

qzed commented Jun 21, 2022

qzed commented Jun 27, 2022

qzed commented Jul 12, 2022

qzed commented Jul 12, 2022

kasperk81 commented Jul 14, 2022

qzed commented Jul 14, 2022 • edited Loading

qzed commented Jul 18, 2022

qzed commented Jul 22, 2022

shawnguo2 commented Jul 23, 2022

qzed commented Jul 23, 2022

shawnguo2 commented Jul 24, 2022

Sonicadvance1 commented Dec 24, 2019 •

edited

Loading

Dmole commented Jul 17, 2020 •

edited

Loading

lkocman commented Aug 22, 2020 •

edited

Loading

lkocman commented Aug 25, 2020 •

edited

Loading

qzed commented Oct 28, 2020 •

edited

Loading

denysvitali commented Jan 28, 2021 •

edited

Loading

denysvitali commented Jan 29, 2021 •

edited

Loading

denysvitali commented Jan 30, 2021 •

edited

Loading

denysvitali commented Jan 30, 2021 •

edited

Loading

denysvitali commented Jan 31, 2021 •

edited

Loading

denysvitali commented Feb 1, 2021 •

edited

Loading

qzed commented Jun 6, 2022 •

edited

Loading

qzed commented Jul 14, 2022 •

edited

Loading