linux-surface / surface-dtx-daemon

Linux User-Space Detachment System (DTX) Daemons for the Surface ACPI Driver.

Linux Surface

Linux running on the Microsoft Surface devices. Follow the instructions below to install the latest kernel.

Announcements and Updates | Upstream Status

Why / About this Project

These days, Linux supports a lot of devices out-of-the-box. As a matter of fact, this includes a good portion of the Microsoft Surface devices—for most parts at least. So why would you need a special kernel for Surface devices? In short, for the parts that are not supported upstream yet.

Unfortunately, Surface devices tend to be a bit special. This is mostly because some hardware choices Microsoft made are rarely (if at all) used by other, more "standard", devices. For example:

• Surface devices (4th generation and later) use their own embedded controller (the Surface Aggregator Module, or SAM). In contrast to other devices, however, some newer Surface devices route their keyboard and touchpad input via this controller. Unfortunately, every new Surface device requires some (usually small) patch to enable support for it, since devices managed by SAM are generally not auto-discoverable.
• Surface devices (4th generation and later, excluding the Go series) use a rather special system for touch and pen input. In short, this requires user-space processing of touch and pen data to enable multitouch support and has not been upstreamed yet.
• Surface devices rely on Intel's ISP for camera image processing. This means that the webcam also requires some user-space processing. While patches are being upstreamed, not all devices are supported (even with this project), and more work remains to be done.

We aim to send all the changes we make here upstream, but this may take time. This kernel allows us to ship new features faster, as we do not have to adhere to the upstream release schedule (and, for better or worse, code standards). We also rely on it to test and prototype patches before sending them upstream, which is crucial because we maintainers cannot test on all Surface devices (which also means we may break things along the way).

So should you install this custom kernel and the associated packages? It depends: We generally recommend you try your standard distribution kernel first. If that works well for you, great! But if you're missing any features or experiencing issues, take a look at our feature matrix and give our kernel and packages a try. If your device is not listed as supported yet, feel free to open an issue.

Supported Devices

• Surface Book
• Surface Book 2
• Surface Book 3
• Surface 3
• Surface Go
• Surface Go 2
• Surface Go 3
• Surface Laptop
• Surface Laptop 2
• Surface Laptop 3
• Surface Laptop 4
• Surface Laptop 5
• Surface Laptop Go
• Surface Laptop Go 2
• Surface Laptop Studio
• Surface Pro 1
• Surface Pro 3
• Surface Pro 4
• Surface Pro (5th Gen) / Surface Pro 2017
• Surface Pro 6
• Surface Pro 7
• Surface Pro 7+
• Surface Pro 8
• Surface Pro 9
• Surface Studio

Features / What's Working

See the feature matrix for more information about each device.

Disclaimer

• For the most part, things are tested on a Surface Book 2. While most things are reportedly fully working on other devices, your mileage may vary. Please look at the issues list for possible exceptions.

Installation and Setup

We provide package repositories for the patched kernel and other utilities. Please refer to the detailed installation and setup guide. There, you may also find device-specific caveats. In case you have disk encryption set up or plan to use it, take care to follow the respective instructions in the installation guide and have a look at the respective wiki page. After installation, you may want to have a look at the wiki and the contrib/ directory for useful tweaks.

If you want to compile the kernel yourself (e.g. if your distribution is not supported), please have a look at the wiki.

Additional Information

Notes

• If you are getting stuck at boot when loading the ramdisk, you need to install the Processor Microcode Firmware for Intel CPUs (usually found under Additional Drivers in Software and Updates).
• Using TLP can cause slowdowns, laggy performance, and occasional hangs if not configured properly! You have been warned.
• If you want to use hibernate instead of suspend, you need to create a swap partition or file, please follow your distribution's instructions (or here).

Support

If you have questions or need support, please join our Matrix Space! This space contains

• a support channel for general support and
• a development channel for all development related questions and discussions.

License

This repository contains patches, which are either derivative work targeting a specific already licensed source, i.e. parts of the Linux kernel, or introduce new parts to the Linux kernel. These patches fall thus, if not explicitly stated otherwise, under the license of the source they are targeting, or if they introduce new code, the license they explicitly specify inside of the patch. Please refer to the specific patch and source in question for further information. License texts can be obtained at https://github.com/torvalds/linux/tree/master/LICENSES.

surface-dtx-daemon's Issues

Is there a reason that userd.conf isn't able to run handlers?

WARN config{file: "/home/captspify/.config/surface-dtx/surface-dtx-userd.conf"}: sdtxu::config: unknown config item, item: handler

Is that an intentional design decision? or has it just not been implemented?

error: failed to run custom build command for `libdbus-sys v0.2.1`

Arch Manjaro

```error: failed to run custom build command for libdbus-sys v0.2.1

Caused by:
process didn't exit successfully: /home/myuser/.cache/yay/surface-dtx-daemon/src/surface-dtx-daemon/target/release/build/libdbus-sys-d5412d7e7ab93ccf/build-script-build (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=DBUS_1_NO_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG
cargo:rerun-if-env-changed=DBUS_1_STATIC
cargo:rerun-if-env-changed=DBUS_1_DYNAMIC
cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

--- stderr
thread 'main' panicked at 'called Result::unwrap() on an Err value: Command { command: ""pkg-config" "--libs" "--cflags" "dbus-1" "dbus-1 >= 1.6"", cause: Os { code: 2, kind: NotFound, message: "No such file or directory" } }', /home/myuser/.cargo/registry/src/github.com-1ecc6299db9ec823/libdbus-sys-0.2.1/build.rs:6:70
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
==> ERROR: A failure occurred in build().
Aborting...
-> error making: surface-dtx-daemon```

Fix Dependencies for Packages

For Arch:

• add dependency on gcc-libs

For Debian:

• add dependency on libc6, libgcc1

Base loses connection to top when battery low

on my SB2 the base disconnects when the battery in the base is discharged and the top battery in the main device is charged.

The error message instructs me to consult the lgos, but I am unable to find anything in /var/log.

D-Bus Service Enhancements

The D-Bus service should additinally provide support for:

• requesting detachment,
• de-/registering and querying of apps using the dGPU to prevent detachment while it is in use, similar to the DTX app on windows,

Manage latch locking/unlocking

We currently have no direct support for managing the latch lock. To do this, we need some way to manage dependencies on the dGPU (or other devices connected to the base, e.g. USB/storage) either by applications or directly by the user. One idea would be to have some sort of registry of blockers/dependencies.

Ideally we have some automatism that detects and registers apps using the dGPU (or other devices connected to the base) automatically. That's probably not easily possible, so some sort of wrapper script may be necessary, at least for registration. For applications, de-registration could maybe be done automatically by monitoring process IDs for termination (may require special handling for sub-processes).

In light of Linux being a multi-user OS, it should also be possible for users themselves to request a lock on the base, preventing detachment until no user (and no application) has such a lock.

Furthermore, some UI for inspecting/displaying those dependencies that can be shown/linked to if a detachment request was blocked would be a good idea.

OpenRC Support

Hi, I've taken a look at the source code for this. Would it be possible to add OpenRC support to it? From the looks of it, we only need a OpenRC service file. I am happy to write this up, however, are there any more aspects of this that depend on SystemD?

Sincerely,
Parin

RUSTSEC-2021-0139: `ansi_term` is Unmaintained

Problem

The ansi_term crate is unmaintained. We indirectly depend on it via tracing-subscriber.

Solution

Update dependencies once a new version of tracing-subscriber is available.

See also: tokio-rs/tracing#2282

Does not excute [handler]-attach.sh

I've set up the attach script, to prevent xinput reset to default setting.
But after i detach the screen, the script is not excuted.

I've confirmed the script file is executable.

Shell extensions

The per-user deamon could be replaced entirely with a Gnome shell extension (or something similar for KDE/other DEs). This would also allow requesting detachment via UI and may be be a bit more flexible with regards to locking/unlocking the latch (e.g. like listing applications that use the dGPU and need to be closed before detaching), once we've figured out how to handle that (see #5). For now simply adding a sort of request button and handling notifications should be enough.

Everything required for that should be already provided in the D-Bus service, so this extension just needs to communicate with that.

Suggestion

Hello,

I had troubles with starting the surface_dtx daemon through systemd.

The trouble was that systemd was launching the service before the /dev/surface_dtx device was present. I fixed this by adding one udev rule :

KERNEL=="surface_dtx", TAG+="systemd"

and adding the lines :

After=dev-surface_dtx.device
Wants=dev-surface_dtx.device

in the [Unit] section of surface-dtx-daemon.service file.

Just let you know

Regards