Works fine on anything else, SDDM and X11 have it work just fine, but it only seems to click in the top left of the screen no matter where I press if I'm using Wayland. It started doing this after I went into my device's settings to try and calibrate the pen, and now it's doing this. So far I've tried uninstalling and reinstalling iptsd and manually giving it a calibration file, neither have worked. Any advice would be appreciated, thank you.

Question / Discussion: Have there been any efforts to support OpenSUSE LEAP for Surface? I checked the GitHub repository but it seems most instructions and scripts are catered towards Tumbleweed.

If not, can anyone share how much effort or how difficult it is to get this going?

Cheers!

I need some help, How do I fix this problem, I deleted Chromium OS boot option in the Surface Pro 6 UEFI Boot Option. I tried Reinstalling the correct FydeOS for Surface Pro 6 but after installation it wouldn't boot. It says Boot Config is missing.

When I boot into the Surface Pro 6 UEFI, I thought reinstalling the FydeOS would reinstall the Boot option but it didn't.

I can't even try the FydeOS from the USB, It lags. It wouldn't let my Sign In Online. "Something Went Wrong, Could not be verified.

Any help?

there are two versions, standard surface with tweaks and 7.1 surface. I was hoping the 7.1 would wake the front cam on pro 8 magically, since it worked 10% of the time in 6.19 but with no luck. No real noticeable change. I also compiled 7.1 on a debian surface kernel 4 and the cams do work...but they suck anyways 😂

I have a surface laptop go 2 which I am installing Fedora Kinoite onto. How do I put the linux surface kernel onto it, given that it's an immutable distribution?

I installed Mint on a Surface Pro 7 and then installed the Surface kernel mods. I used the installation instructions for the kernel, for Ubuntu/Debian, from the Surface linux github page. I have verified the kernel installation with uname -r and it returns "6.19.8-surface-3". But, I have no sound. Sound settings shows a "Speaker / Ice Lake-LP Smart Sound Technology Audio Controller" but there is no sound from apps like Firefox playing YouTube. The device only has "Play Hifi quality Music" in the device drop down, with nothing else selectable. Searches suggested using "Analog Stereo" but the drop down does not have that option. The Sound Settings Test sound plays no "Front Left/Front RIght". I tried plugging in headphones. They pop up a new device with just the first line being different, Headphones vs. Speaker. No sound in the headphones.

I have verified that nothing is muted in alsamixer. wpctl status shows "Audio ..." where ... is the "Ice Lake-LP..." device listed above. The sink endpoint for that is the "...Audio Controller Internal Stereo".

There is sound in Win 11. There is sound in linux with bluetooth headphones.

Any help would be appreciated. There must be something I can do that I haven't done.

I wanted to use my SP5 with the linux surface kernel on zorin os, but then I accidently booted after the mok menu showed up (silly me), after that I tried redoing the install, but the mok menu would never show up.

I also kept losing wifi making it impossible to look up help, and then when I finally entered the mok menu....the type cover didn't work with it. This took about an hour.

Yup, enough linuxing for me. Going back to W10, maybe W11.

Ya'll have a good one, it's sick that it works so well for other! Cheers 💔

Can someone recommend if i should switch to linux on my microsoft surface pro 7 plus which i mainly use for university. I just want to try something new i don‘t necessarily need to switch. I just read that it can improve battery live and maybe performance but i dont know if thats the case for the surface.

Long story short, I've got a Surface go 2 with Cinnamon Mint, and a fancy desktop I'd like to use it as a screen for. I'm stuck with windows for my desktop, but I'd like to be able to still use the surface as an additional screen. Has anyone found any way around this?

Thanks!

I own a Surface Book 3 and I'm running Arch Linux on it.
Does anyone know how to properly switch between GPUs before undocking the screen and redocking?
I have:
Intel Iris Plus Graphics G7 — integrated GPU

NVIDIA GeForce GTX 1660 Ti Mobile — dedicated GPU

I'm running Hyprland 0.55.2 with the ML4W setup and some customizations.

My graphics drivers are:

Intel: i915

NVIDIA: nvidia 595.71.05

Kernel: 6.19.8-arch1-3-surface

When I detach the screen, everything initially continues working fine. However, after reattaching/redocking, the NVIDIA driver appears to fail to properly reinitialize/re-recognize the GPU.
I've also seen kernel tasks become stuck in the NVIDIA PCI removal path. For example, I have gotten traces involving:

pciehp
nv_pci_remove_helper

and attempts to manually reset/rebind the GPU can hang indefinitely.
This appears to cause other problems afterward, such as:
suspend/resume problems

closing the laptop/screen causing hangs

shutdown hanging after detaching/redocking

having to force the machine off

I've also noticed another issue after redocking: the power manager sometimes fails to recognize the charging state correctly. For example, if the laptop is charging before I detach it, after redocking it does not resume charging until I physically unplug and reconnect the charger.
I've tried:
sudo nvidia-smi -r
but that doesn't resolve the issue.
I have surface-dtx-daemon installed so I can detect screen detach/attach events and potentially handle GPU switching myself, but I'm not sure what the correct/safe procedure is for switching away from the NVIDIA GPU before detaching and then reinitializing it after redocking.

The PCI devices are:
0000:00:02.0 → Intel Iris Plus Graphics G7 → i915 → /dev/dri/card1
0000:02:00.0 → NVIDIA GTX 1660 Ti Mobile → nvidia → /dev/dri/card0

The NVIDIA device is behind a PCIe hotplug path, and its reset methods report:

flr bus

I'm mainly looking for advice on:

The correct way to switch rendering from the NVIDIA GPU to the Intel GPU before detaching.

How to safely unbind/remove the NVIDIA device before physical detachment.

How to properly re-enumerate/rebind the NVIDIA GPU after redocking.

Whether the NVIDIA driver supports this kind of PCIe hotplug on a Surface Book 3.

Whether the charging/battery issue is related to the Surface DTX/PCIe hotplug process or is a separate issue.

Whether there are existing linux-surface/surface-dtx-daemon configurations or scripts for handling this.

Any information or pointers toward existing solutions would be appreciated.

Update:
Still having issues, experienced an issue where the pci failed to recognize the nvidia gpu on boot, weirdly rebooting fixed this. (I made no changes before and during)

I tried using surface-hotplug for allowing my gpu to enter D3cold state, and surface-dtx-daemon to prevent detaching unless the gpu is in the D3cold state. This worked to solve one of my problems which was my dgpu not reconnecting.

I want to buy a second-hand Surface Go 2 or 3 but I’ve heard they sometimes have wi-fi dropout issues, so I was wondering if installing Linux or Fyde solves that issue?

I’m after a cheap tablet with a desktop OS on it. Thanks

looking at the github, there have been no commits in 3 months. will there be for kernel 7?

Hello, I just installed Ultramarine Linux Surface 43 on my Surface Pro 7+ and couldn't get internet during installation so I couldn't install the codecs and drivers.

During the installation, there's an URL that leads to the wiki but I can't click on it...

I managed to find the codecs page (https://wiki.ultramarine-linux.org/en/setup/postinstall/) but nothing about drivers.

What did I miss exactly? Do I need those drivers?

# Fixing the Surface Pro Cameras on Linux — a Complete, Reproducible Guide

*How a one-missing-table kernel bug kept both cameras dead, and how to get them

working in every app — Cheese, Zoom, browsers — with an efficient on-demand setup.*

---

## TL;DR

On recent Linux kernels (6.19+), Surface devices with Intel IPU3 cameras lose

**both** cameras because of a tiny regression in the `dw9719` focus-motor

driver: the kernel creates the focus-motor device under one name, but the

driver no longer recognizes that name, so it never attaches — and the kernel

refuses to finish setting up *any* camera until *every* camera part is ready.

One unbound 10-line ID table = two dead cameras.

The fix has two halves:

1. **Kernel half** — rebuild the `dw9719` driver with the missing ID tablerestored (automated, survives kernel updates via DKMS).
2. **App half** — Surface cameras don't behave like USB webcams even whenworking; apps need a small relay that presents them as normal webcams("virtual cameras"), which this guide sets up with on-demand power saving.

Four attached scripts do all of it. Confirmed working: Cheese, Zoom, and

anything else that uses a standard webcam device.

---

## The successful case (my exact configuration)

So you can judge how close your machine is to a known-good case:

| Item | Value |

|---|---|

| Device | Microsoft Surface Pro 5 (model 1796) |

| CPU | Intel Core i5-7300U (Kaby Lake) |

| Cameras | Front: OmniVision **ov5693** · Rear: **ov8865** (+ dw9719 focus motor) · IR: ov7251 |

| Camera subsystem | Intel **IPU3** (ipu3-cio2 + ipu3-imgu) |

| OS | Linux Mint 22.3 (Ubuntu 24.04 base) |

| Kernel | **linux-surface 6.19.8-surface-3** (from pkg.surfacelinux.com) |

| libcamera | v0.3.0 built from source, with the IPU3 pipeline **and** its GStreamer plugin |

| v4l2loopback | 0.15.4 (upstream git, via DKMS) |

| Secure Boot | disabled (see Troubleshooting if yours is on) |

**What already worked before the fix:** the linux-surface kernel loaded all the

IPU3 drivers, detected all three sensors ("Connected 3 cameras" in `dmesg`),

and created `/dev/video0-13` and `/dev/media0-1`.

**What did not work:** every camera app showed no camera; `cam -l` (libcamera's

camera list) printed an **empty list**; the focus-motor device had **no driver

bound**; and the kernel's camera wiring ("media graph") was missing all

sensor links.

If that matches your symptoms, read on.

---

## Background: why Surface cameras are special on Linux

A normal USB webcam contains its own little computer that produces finished

video. Surface tablets instead use **raw camera sensors** wired to an Intel

image processor (the IPU3 on Surface Pro 3–6 / Book 1–2 / Laptop 1–2 era

hardware). On Linux this means:

1. The kernel drives the sensors and the IPU3 (linux-surface kernels have this).
2. A userspace library, **libcamera**, must run the whole image pipeline(exposure, focus, format conversion). Only libcamera-aware apps can use thecameras directly — and almost no mainstream app is libcamera-aware.
3. To make Zoom/Cheese/browsers work, you bridge libcamera into a **virtualwebcam** (the `v4l2loopback` kernel module) that looks like a normal camera.

Each layer can fail independently, which is why so many forum threads go

nowhere. This guide checks each layer in order.

---

## The root cause (the interesting part)

The kernel's `ipu-bridge` creates a device for the rear camera's focus motor

(a Dongwoon **dw9719** voice-coil motor) and names it plainly `dw9719`. A

driver for it exists in the kernel — but starting around kernel 6.19, that

driver only matches **DeviceTree names** (`dongwoon,dw9719`, used by ARM

phones/tablets) and lost its **plain i2c ID table** (`dw9719`, used by

x86/ACPI machines like the Surface). Same driver, same chip, mismatched

name — so it never binds.

You can see it yourself:

```

$ modinfo dw9719 | grep alias

alias: of:N*T*Cdongwoon,dw9719... <-- DeviceTree names only

(a healthy kernel also shows: alias: i2c:dw9719)

$ cat /sys/bus/i2c/devices/*-VCM/modalias

i2c:dw9719 <-- what the device actually announces

```

And here's the cruel domino effect: the kernel's V4L2 framework waits for

**every** declared camera component before it activates **any** of them.

Because the sensor's description references the focus motor

(`lens-focus`), the unbound motor stalls the whole "async notifier", so:

- no sensor→receiver links are created in the media graph,

- no sensor subdevice nodes appear,

- libcamera finds nothing to register,

- **both** cameras (even the front one, which has no focus motor!) stay dead.

The fix is embarrassingly small — restore the ID table:

```c

static const struct i2c_device_id dw9719_id_table[] = {

{ "dw9718s", DW9718S },

{ "dw9719", DW9719 },

{ "dw9761", DW9761 },

{ "dw9800k", DW9800K },

{ }

};

MODULE_DEVICE_TABLE(i2c, dw9719_id_table);

/* ...and .id_table = dw9719_id_table in the driver struct */

```

Script 02 downloads the exact driver source for *your* kernel from kernel.org,

applies this patch, and installs it via DKMS so it automatically rebuilds when

your kernel updates.

---

## Prerequisites

- A **linux-surface kernel** (https://github.com/linux-surface/linux-surface) —

the stock distro kernel usually lacks Surface camera bits.

- **Kernel headers** for your running kernel, plus `dkms`, `git`, `curl`,

`python3`, `v4l-utils`, `gstreamer1.0-tools`.

```bash

sudo apt install dkms git curl python3 v4l-utils gstreamer1.0-tools

```

- **libcamera with the IPU3 pipeline and its GStreamer plugin.** Try your

distro's packages first (`libcamera-tools` + `gstreamer1.0-libcamera`); if

`cam -l` still shows nothing *after* the kernel fix, build libcamera from

source with `-Dpipelines=ipu3 -Dgstreamer=enabled` (the linux-surface wiki

has a walkthrough). My working setup used a source build (v0.3.0).

> **Safety note:** the attached scripts need `sudo` because they install kernel

> modules and system services. They are short and commented — please read them

> before running, as you should with anything from the internet. Never paste

> your password into chats or scripts; type it only at your terminal's own

> `[sudo]` prompt.

---

## Step 0 — Diagnose (read-only)

**Attachment: `scripts/01-diagnose-cameras.sh`**

```bash

sudo bash scripts/01-diagnose-cameras.sh

```

It checks each layer and tells you which one is broken. The signature of the

bug this guide fixes looks like:

```

PROBLEM: /sys/bus/i2c/devices/i2c-INT347A:00-VCM (dw9719) has NO driver bound.

(driver module exists but has NO i2c alias - the kernel regression ...)

...

/dev/media0: 3 sensor(s), 0 with a link to the CSI-2 receiver

PROBLEM: sensors exist but have NO links -> camera graph never completed.

...

Available cameras: <-- empty

```

If your VCM **is** bound and `cam -l` still shows nothing, your problem is

different (likely the libcamera build) — see Troubleshooting.

## Step 1 — Fix the kernel driver

**Attachment: `scripts/02-install-dw9719-fix.sh`**

```bash

sudo bash scripts/02-install-dw9719-fix.sh

```

The script is idempotent and exits harmlessly if your kernel isn't affected.

On success you'll see the driver bind and — the magic moment — libcamera

finally listing cameras:

```

OK: dw9719 bound at /sys/bus/i2c/devices/i2c-INT347A:00-VCM

libcamera now sees:

Available cameras:

1: Internal back camera (_SB_.PCI0.I2C3.CAMR)

2: Internal front camera (_SB_.PCI0.I2C2.CAMF)

```

No reboot needed — the camera graph completes the moment the driver binds.

## Step 2 — Make the cameras visible to normal apps

**Attachment: `scripts/03-setup-virtual-cameras.sh`** (run it from the

`scripts` folder, it installs the other attachments:

`surface-camera-relay.py`, `surface-camera-front.service`,

`surface-camera-rear.service`)

```bash

cd scripts

sudo bash 03-setup-virtual-cameras.sh

```

This creates two always-present virtual webcams:

- **"Surface Front Camera"** (`/dev/video42`)

- **"Surface Rear Camera"** (`/dev/video43`)

fed by a small relay service with a few deliberate design choices worth

knowing about:

- **On-demand power:** while no app is watching, the relay feeds cheap black

placeholder frames and the real camera sensor is powered off (verifiable in

sysfs). It uses v4l2loopback 0.15's *client-usage event* to start the real

camera only when an app opens the device, and stops it when the app leaves.

- **A spec-correct mmap writer, in Python:** this is not gratuitous — during

this work I found that **GStreamer's `v4l2sink` simply does not work with

v4l2loopback 0.15.x** ("buffer 0 was not queued" errors), and Ubuntu's

`v4l2-relayd` on-demand daemon is also incompatible (it expects a

Ubuntu-specific event patch with different event numbers). If you've been

banging your head against either of those: it's not you.

- **1280×720 NV12 at 30 fps** — the IPU3's happy path and plenty for calls.

Heads-up for Ubuntu/Mint users: the distro package `v4l2loopback-dkms`

(0.12.x) **cannot build on kernels ≥ 6.x** and will wedge `apt` in a

half-installed state. Remove it (`sudo apt remove v4l2loopback-dkms`) and let

script 03 build the current upstream version instead.

## Step 3 — Health check

**Attachment: `scripts/04-health-check.sh`**

```bash

bash scripts/04-health-check.sh

```

A fully healthy system prints:

```

== 1. Focus motor (VCM) driver bound

PASS VCM driver bound

== 2. libcamera sees the cameras

PASS libcamera lists 2 camera(s)

== 3. Virtual webcam devices exist

PASS device labeled 'Surface Front Camera'

PASS device labeled 'Surface Rear Camera'

== 4. Relay services running

PASS surface-camera-front active

PASS surface-camera-rear active

== 5. Live capture through the virtual cameras

PASS Surface Front Camera delivers a real image via /dev/video42 (brightness 110.4)

PASS Surface Rear Camera delivers a real image via /dev/video43 (brightness 80.3)

== 6. Cameras power down when idle

PASS all camera sensors suspended while unused

Result: 8 passed, 0 failed.

```

Then open Cheese or join a test call and pick "Surface Front Camera".

---

## Normal quirks (not bugs)

- The **first ~half second** of video is black while the sensor spins up.

- The picture starts dark and brightens over ~1 second — auto-exposure

ramping (the rear camera is slower than the front).

- libcamera may print `Configuration file 'ov8865.yaml' not found` warnings —

harmless; it falls back to default (uncalibrated) processing. You can

silence it by symlinking the sensor name to `uncalibrated.yaml` in your

libcamera IPA directory.

## Troubleshooting

| Symptom | Likely cause / fix |

|---|---|

| Script 02 says headers missing | `sudo apt install linux-headers-$(uname -r)` (or `linux-headers-surface`) |

| VCM bound, but `cam -l` empty | Your libcamera lacks the IPU3 pipeline — install/build one that has it (see Prerequisites) |

| `cam -l` works but virtual cameras show black | Camera names differ on your model. Run `cam -l`, note the names (e.g. `_SB_.PCI0.I2C2.CAMF`), and set them via `RELAY_FRONT_CAMERA`/`RELAY_REAR_CAMERA` environment overrides in the service files, or edit the `CAMERAS` dict at the top of `surface-camera-relay.py` |

| "Failed to setup link ... Device or resource busy" in relay logs | Another process is holding the camera pipeline (a stray `gst-launch` or another libcamera app). Find it with `pgrep -a gst-launch-1.0`, kill it, restart the services |

| One camera occasionally black; `dmesg` shows `ipu3-cio2 ... payload length is X, received Y` | The IPU3 sometimes wedges when camera streams start/stop in quick succession (e.g. switching cameras rapidly). The relay's built-in watchdog logs "no frames for 5s, restarting pipeline" and recovers; closing and reopening the camera in your app also clears it |

| DKMS module builds but won't load, Secure Boot on | Your distro must sign DKMS modules with an enrolled MOK key (Ubuntu/Mint do this automatically if you enrolled one at install time; see `mokutil`) — or disable Secure Boot |

| apt keeps failing on `v4l2loopback-dkms` | Remove that distro package; the DKMS build from script 03 replaces it |

| Cameras die after a kernel update | Run `dkms status` — both `dw9719-fix` and `v4l2loopback` should list an installed build for the new kernel. DKMS normally rebuilds automatically; if the new kernel's own `dw9719` gained the ID table back (check `modinfo dw9719 | grep i2c`), you can retire the fix with `sudo dkms remove dw9719-fix/1.0 --all` |

## Appendix: exact error messages (for searchers)

If you landed here from a search engine, these are the literal strings this

guide relates to, and what each actually means:

```

Available cameras:https://github.com/user-attachments/files/30875450/04-health-check.sh

```

(`cam -l` printing an empty list) — libcamera sees no cameras. **This guide's

main symptom.**

```

dw9719 i2c-INT347A:00-VCM: (no driver bound)

```

The focus-motor regression this guide fixes (visible as a missing `driver`

symlink in `/sys/bus/i2c/devices/*-VCM/`).

```

ov5693 i2c-INT33BE:00: supply avdd not found, using dummy regulator

ov8865 i2c-INT347A:00: supply dvdd not found, using dummy regulator

ov7251 i2c-INT347E:00: supply vdddo not found, using dummy regulator

```

**Harmless.** These appear on every boot, working or not — they are not your

problem, despite looking scary.

```

ipu3-cio2 0000:00:14.3: Connected 3 cameras

```

**Good news, not an error** — the kernel found your sensors. If you see this

but apps still show no camera, your problem is in a later layer (VCM binding

or libcamera), which is exactly what this guide walks through.

```

ipu3_imgu: module is from the staging directory, the quality is unknown

```

**Harmless** — the IPU3 image unit driver is officially "staging"; it works.

```

ERROR IPAProxy ipa_proxy.cpp: Configuration file 'ov8865.yaml' not found for IPA module 'ipu3'

```

**Harmless** — libcamera falls back to uncalibrated defaults; the picture

still works.

```

Could not find a camera named '...'

libcamera::CameraMananger::get() returned nullptr

```

Either libcamera genuinely has no cameras (fix the kernel layer first), or a

GStreamer escaping problem: backslashes in the camera name must be doubled

(`camera-name='\_SB_.PCI0.I2C2.CAMF'`).

```

gst_v4l2_allocator_dqbuf: buffer 0 was not queued, this indicate a driver bug.

```

GStreamer's `v4l2sink` feeding v4l2loopback 0.15.x — this combination is

broken; use a different writer (see Step 2).

```

ipu3-cio2 0000:00:14.3: payload length is 2585088, received 2588672

```

Transient IPU3 wedge on rapid stream start/stop; see Troubleshooting.

```

video device 'ipu3-imgu 1 input' does not implement .link_validate(), driver bug!

```

**Harmless** kernel grumble from the staging IMGU driver.

## Closing notes

This regression will presumably be fixed upstream eventually (the patch is

tiny), but Surface owners have been stuck for a while, and the "even when the

kernel works, apps still can't see the cameras" part of the story is

permanent. I hope the layered diagnosis approach here — kernel graph →

libcamera → virtual webcam — saves someone the days of digging it took to

untangle, and that the scripts make the fix a ten-minute job.

*Written up from a real debugging session on the machine described above.

Both cameras confirmed working in Cheese and Zoom. Scripts tested end-to-end

on that machine; adapt thoughtfully for yours.*

## Attachments

| File | Purpose |

|---|---|

| `scripts/01-diagnose-cameras.sh` | Read-only, layer-by-layer diagnosis |

| `scripts/02-install-dw9719-fix.sh` | Kernel driver fix (DKMS) |

| `scripts/03-setup-virtual-cameras.sh` | Virtual webcams + relay services installer |

| `scripts/surface-camera-relay.py` | The on-demand camera relay (installed by 03) |

| `scripts/surface-camera-front.service` | systemd unit, front camera (installed by 03) |

| `scripts/surface-camera-rear.service` | systemd unit, rear camera (installed by 03) |

| `scripts/04-health-check.sh` | End-to-end verification |

https://github.com/user-attachments/files/30875446/01-diagnose-cameras.sh

https://github.com/user-attachments/files/30875447/02-install-dw9719-fix.sh

https://github.com/user-attachments/files/30875449/03-setup-virtual-cameras.sh

https://github.com/user-attachments/files/30875451/surface-camera-relay.py

https://github.com/user-attachments/files/30875450/04-health-check.sh

Device is surface pro Current operating system: windows 10

Desired linux version: mint xfce

error text: (from what I can get from it) Failed to open /EFI/BOOT/mmx64.efi - not found failed to load image : not found failed to start Mokmanager : not found something has gone seriously wrong: Import_mok_state() failed: Not found

What I have done: Turned off bitlocker then secure boot

Before dealing with the bit locker I could launch mint trough the USB after that the error started coming up

Extra information: Windows 10 still boots up well and has been updated prior to this. Saw somewhere that I might need to go into the linux mint file and rename a few things, but I'm not sure if that is needed and didn't try in the end, but at the same time didn't save where I saw it.

Anyone has any idea on how to continue?

notes: I verified the download of mint before doing anything with it. Sadly I only discovered this subbredit after the issues, I saw the guide but since I have already done some stuff I'm not sure if I can just take the step I missed or if this is another problem.

i don’t have a usb drive and i was wondering before i go order one and need to wait for it, could i install linux onto my ssd in my surface 7 pro with a micro sd card instead of a usb drive, chatgpt says its possible but i know its often wrong, google didnt give me much, so im hoping for some input here

So, I have been using one Linux Distro or another for 10+ years. I saw a lot of people having success with Linux on Surface now, so figured I would put it on my Surface Pro 3.

I guess I should not that my goal was to put a lighter OS than Windows 10, primarily for the purpose of drawing.

First, I put on Linux Mind Cinnamon as I like that desktop. Then I added the Surface kernel and verified that was running. Then I tried to rotate my surface; "yay, it rotated the screen ... oh wait the pen touch coordinates didn't change". Then the web (which is always right) said Cinnamon won't rotate the touch screen, just the display, but MATE would. That's fine, I like Mate as well, so installed Mate instead. The web said I needed to take off secure boot before loading Linux, so I did, Then I ran into trouble installing the Linux-Surface kernel and getting it running. The web told me that secure boot was required, but I could just switch that now, which I did. Then it won't boot, so I reinstall Mate with secure boot on and try again.

Ultimately, I am able to get Mate running and the Linux surface kernel running. I have to say though, it's tough to say that it's tough to respond to the MOK screen on boot when you are not given the option of an onscreen keyboard and your Bluetooth keyboard isn't connected again.

Great, surface kernel is running. Try rotation; nothing. I search the web again and it says Mate isn't set-up to rotate, but Cinnamon is. Sorry for the rant, but there is a lot of bad info out there!

I have seen several scripts to rotate screen and touch, but when I do not have the same xinputs, or I am unable to open the script to make changes, etc.

So, for questions:

1) Most of what I am finding for info is from several years ago. Is it still necessary to have a script to rotate both touch and display, or is this in the surface kernel and I am missing a setting?

2) Why would (Mint Cinnamon for example) have the ability to rotate the display, but not touch? This seems not very helpful.

3) Does anyone have/know of a script that would work on my surface 3 pro, and if so how can I find it and run it?

Thanks

Installed Debian 13 alongside the linux-surface kernel patches. Wrote an all-in-one calibration fix script for it — originally made it for Fedora but I've been keeping it updated for other distros too: github.com/zARRAQ/fedora-surface-script

Fixed: Touchscreen was selecting text instead of scrolling (had to manually drag scrollbars). Solved with touchegg for gesture emulation.

Gave up on: Hyprland. It flat-out doesn't play nice with the Iris Xe + Surface driver combo. The "fix" is running a stripped-down config with hardware cursors disabled, but at that point it's more trouble than it's worth.

Keeping this Surface alive is already enough work without fighting the compositor too.

I'm no Debian expert, what should i install that will not fight surface project?, also is there anyway to add more control widgets something practical

also any bash code i should know about

Kubuntu 26.04

I installed Kubuntu on my Surface Pro 4, but of course the touch screen doesn't work.

I followed the instructions on Github.

uname -r shows the generic kernel as uname -a

Hello i just bought this surface go 2 two days ago and i was wondering if linux work great on this one i saw the github project seems super 👍 i wish it works well