linux-surface / surface-dtx-daemon Goto Github PK

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

License: MIT License

Shell 5.76% Rust 92.53% Makefile 1.71%

linux linux-surface

surface-dtx-daemon's Introduction

Linux DTX Daemon for Surface Books

Linux User-Space Detachment System (DTX) Daemon for the Surface ACPI Driver (and Surface Books). Currently, only the Surface Book 2 and 3 are supported, due to lack of driver-support on the Surface Book 1. This may change in the future.

About this Package

This package contains two daemons. A system daemon (surface-dtx-daemon) and a per-user daemon (surface-dtx-userd):

The system daemon allows proper clipboard detachment on the Surface Book 2 and 3. It allows you to run commands before the clipboard is unlocked, after it has been re-attached, or when the unlocking-process has been aborted (e.g. by pressing the detach-button a second time). See the configuration section below for details. Furthermore, this daemon provides a d-bus interface via which you can query the current device mode (i.e. if the device is in tablet-, laptop- or studio-mode).
The per-user daemon is responsible for desktop-notifications, i.e. it notifies you when the clipboard can be physically detached (i.e. the latch holding it in place is unlocked), and when the re-attachment process has been completed, i.e. indicating when it is fully usable again after re-attachment. Running this daemon is completely optional, i.e. if you don't want any notifications, you are free to simply not run it.

The split into two daemons is required as notifications can only be sent on a per-user basis.

Installation

If you have a Debian (Ubuntu, ...) based distribution, have a look at the releases page for official packages. Official Arch Linux packages can be found in the AUR (surface-dtx-daemon). After installation, you may want to:

enable the systemd service for the system daemon using systemctl enable surface-dtx-daemon.service.
enable the systemd service for the per-user daemon using systemctl enable --user surface-dtx-userd.service.

Alternatively, you can build these packages yourself, using the provided PKGBUILD (Arch Linux) or makedeb.sh script in the respective pkg subdirectories.

Configuration

The main configuration files can be found under

/etc/surface-dtx/surface-dtx-daemon.conf for the system daemon configuration, and
/etc/surface-dtx/surface-dtx-userd.conf for the per-user daemon configuration.

Here you can specify the handler-scripts for supported events and other options. All options are explained in these files, the configuration language is TOML, default attach and detach handler scripts are included.

Furthermore, a per-user configuration for the user daemon can also be created under $XDG_CONFIG_HOME/surface-dtx/surface-dtx-userd.conf (if not set, $XDG_CONFIG_HOME defaults to .config).

Building a Package from Source

Arch Linux

Simply install surface-dtx-daemon from AUR or have a look at its PKGBUILD.

Debian/Ubuntu

Use the makedeb script provided under pkg/deb, i.e. run

./pkg/deb/makedeb

from the root project directory. You may need to install the build-essential and devscripts packages beforehand. The final package will be in the pkg/deb directory.

surface-dtx-daemon's People

Contributors

Stargazers

Watchers

Forkers

runekaagaard jnix85 jstender

surface-dtx-daemon's Issues

Fix Dependencies for Packages

For Arch:

add dependency on gcc-libs

For Debian:

add dependency on libc6, libgcc1

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```

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?

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

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

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.

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,

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.

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.