Skip to content
This repository was archived by the owner on Dec 21, 2023. It is now read-only.
This repository was archived by the owner on Dec 21, 2023. It is now read-only.

Rewrite "X11/Wayland Session not detected" in Linux FAQ #43

Open
@gonX

Description

@gonX

The hack sucks because if the user switches between X11 and Wayland, both the user and the supporters are going to get confused.

It also easy to get wrong, as the user has to verify that they are indeed using that display number.

There are 2 superior ways to the current proposed hack; implementers are welcome to copy paste this and modify as necessary.

Be careful not to drop formatting.


Initial preparation

Verify that your display variable is actually being imported:

systemctl --user show-environment | grep DISPLAY

If there is no output, you need to consult your distributions documentation or help channels on how to enable this. It should just work for X11 users. If it doesn't, your login manager is not sourcing /etc/X11/xinitrc.d/ scripts.

Wayland users (especially non-Gnome and non-KDE users) may need to import the environment variables manually - this is described below.

Missing DISPLAY environment variables on Wayland

These commands must have finished before the opentabletdriver service is allowed to start (ie. this must run before your target or service is activated):

#!/usr/bin/env sh
systemctl --user import-environment DISPLAY WAYLAND_DISPLAY
hash dbus-update-activation-environment 2>/dev/null \
    && dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY

1) Start OTD daemon with DE instead (simple)

This method is simpler and recommended for beginners. The other approach has no advantages if you only want to launch OTD reliably.

Simply add systemctl --user start opentabletdriver.service to your DE or WM's autostart. This is the only generic method that works for Wayland.

If your X11 WM/DE has annoying or hard to define autostart behavior, you can use the generic xinitrc.d autostart described below.

xinitrc.d script (X11 only)

On X11 systems this can be done by adding a shell script to /etc/X11/xinit/xinitrc.d/ named 95-launch-opentabletdriver.sh by running the following:

echo '#!/usr/bin/env sh
systemctl --user start opentabletdriver.service || true' > /etc/X11/xinit/xinitrc.d/95-launch-opentabletdriver.sh \
    && chmod +x /etc/X11/xinit/xinitrc.d/95-launch-opentabletdriver.sh

Keep in mind this script does not check if the service exists, meaning it will be leftover if OpenTabletDriver is installed.

Wayland

See the start of this section

2) Set up a dependency chain so that your DE starts a systemd target (advanced)

In short, you must make your DE or WM start a target that OTD depends on. This is something that systemd has yet to standardize but already exists in some form with the graphical-session user target.

This is the recommended method for long time users as it fixes your systemd user session to have a proper dependency chain for graphical sessions, enabling other graphical user services to run properly in the systemd user session.

As a side note this setup also allows you to launch your DE/WM via systemd user services, which significantly enhances systemd integration with your session. This is out of scope for this guide.

Preparation

First, verify that the target exists and is active:

systemctl status --user graphical-session.target

If it exists but isn't active (expected on most barebones setups), then we need to make our own target that can start graphical-session.target, as you can not enable graphical-session.target directly.

If it doesn't exist your systemd install is very old or is misconfigured. Use the first solution provided and/or fix your systemd install.

If it exists and is already active we don't need to wire up the target, and you can skip the following step.

Wiring up graphical-session.target

Now we need to make a target that binds to graphical-session.target.

Simply create a .target file in your local systemd user folder (~/.config/systemd/user/) with an arbitrary name, as long as it ends with ".target", e.g. x-session.target, with the following contents:

[Unit]
Description=X11 Session
BindsTo=graphical-session.target

Adjust the Description= as you see fit - its a purely visual name.

Then, add the following command to your WM/DE's autostart:

systemctl --user start --wait x-session.target

Make sure to replace x-session.target with the file name you used for the target file just above.

Then, log out and then in again, and confirm that the target is being activated correctly:

systemctl --user status x-session.target

Making the OpenTabletDriver user service depend on graphical-session.target

Finally, we need to add a drop-in file for the user service, run the following command and read the on screen instructions very carefully:

EDITOR=nano systemctl edit --user opentabletdriver

Replace nano in the above command with your desired CLI text editor - avoid GUI editors as they might fork and confuse the process.

Add the following lines where the guide instructs you to (between the 2 comment blocks at the top):

[Unit]
PartOf=graphical-session.target

[Install]
WantedBy=graphical-session.target

Then save and exit (nano: ctrl+X -> Enter -> Enter)

Then reload the systemd user daemon to pick up the changes:

systemctl --user daemon-reload

then confirm that the drop-in file is being picked up:

systemctl --user cat opentabletdriver

and finally reenable the service to allow the new target to have effect:

systemctl --user reenable opentabletdriver.service

Now, you should be able to reboot and have an automatically working driver.

FAQ

How do I get logs?

Check current session logs for the OpenTabletDriver service: journalctl -b0 --user-unit opentabletdriver (this opens the less pager, up/down-arrow/home/end to scroll)

After adding the drop-in file I now have 2 [Install] sections!

The default service file already having an [Install] sections is not a problem - the drop-in file will take precedence.

Footnotes (don't include in guide)

It's also worth noting that I don't think the systemd services shipped are the same across all distros, so this will need testing on non-Arch distros.

Also I expect whoever PR's this into the wiki to have tested it themselves. I'm writing this mostly off memory but I am submitting it under good faith that it works.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp wantedExtra attention is neededwikiImprovements or additions to wiki

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions