Dotfiles/TODO.md at main

Adrien Bouvais 4ce511c902 Update TODO.md

2025-11-03 12:46:04 +00:00

8.2 KiB

Raw Permalink Blame History

Add swayidle to make the screen go dark And add adrien user to uinput

Step 1: Install `swayidle`

Open your terminal and install swayidle from the official Arch repositories. It's good practice to also install a screen locker like swaylock at the same time, as you'll likely want to lock your screen before it turns off.

sudo pacman -S swayidle swaylock

Step 2: Create the Idle Management Script

It's cleanest to manage this with a small shell script. Let's create one in niri's configuration directory.

Create the file:

mkdir -p ~/.config/niri
nano ~/.config/niri/idle.sh

Paste the following content into the file. This configuration will do two things:
- After 10 minutes (600s): Lock the screen with swaylock.
- After 15 minutes (900s): Turn the display off (DPMS off).
- On resume (mouse/keyboard activity): Turn the display back on (DPMS on).
```
#!/bin/sh

# This script is a simple wrapper for swayidle.
# It locks the screen after 10 minutes of inactivity,
# and turns off the display after 15 minutes.

swayidle -w \
     timeout 600 'swaylock -f' \
     timeout 900 'niri msg output "*" dpms off' \
     resume 'niri msg output "*" dpms on'
```
- swayidle -w: Starts the daemon and waits (doesn't exit).
- timeout 600 'swaylock -f': After 600 seconds (10 minutes) of inactivity, run swaylock -f to lock the screen.
- timeout 900 'niri msg output "*" dpms off': After 900 seconds (15 minutes), run the command to turn off all outputs (*). The command niri msg is how you control niri from the command line.
- resume 'niri msg output "*" dpms on': When activity is detected again (mouse move, key press), run the command to turn all outputs back on.
Save the file and exit nano (Ctrl+O, Enter, Ctrl+X).
Make the script executable:
```
chmod +x ~/.config/niri/idle.sh
```

Step 3: Autostart the Script with Niri

Now, we need to tell niri to run this script every time it starts.

Open your niri configuration file. If it doesn't exist, niri uses its defaults, but you can create it.
```
nano ~/.config/niri/config.kdl
```

Add the startup-commands block if it doesn't exist, and add an exec-on-startup command to run your script. Make sure to use the full path.

// Your other niri configurations might be here...

startup-commands {
    // Add this line to run your idle script
    exec-on-startup "~/.config/niri/idle.sh"

    // You might have other startup commands here, for example:
    // exec-on-startup "waybar"
    // exec-on-startup "mako"
}

// More of your niri config...

Note: The ~ shortcut for your home directory works in the niri config.

Save and close the file.

Step 4: Apply the Changes

Log out of your niri session and log back in. The idle.sh script will now be running in the background. Your screen will lock after 10 minutes and turn off after 15 minutes of inactivity. Moving your mouse or pressing a key will wake the screen up to the swaylock prompt.

Customization

To only turn off the screen (no lock): If you only want the screen to go black after 15 minutes and don't want to lock it, modify your ~/.config/niri/idle.sh script to remove the swaylock timeout:
```
#!/bin/sh

swayidle -w \
     timeout 900 'niri msg output "*" dpms off' \
     resume 'niri msg output "*" dpms on'
```
This directly addresses your original request.
Changing the time: Simply change the number of seconds in the script. For example, for a 5-minute screen-off time, change 900 to 300.
Customizing swaylock: You can make swaylock look nicer. For example, to set a solid color: swaylock -f -c 000000 (for black). You can edit this command directly in your idle.sh script. Check man swaylock for all options.

Of course! Let's break down what uinput is, why you're getting a "permission denied" error, and exactly how to fix it on your Arch Linux system.

What is `uinput`? (The Simple Explanation)

Think of uinput (User Input) as a special module in the Linux kernel. Its job is to let a regular program pretend to be a physical input device.

When you move your real mouse, the hardware sends a signal to the kernel, and the kernel tells your desktop environment, "The mouse just moved to coordinates X, Y."

uinput allows a program, like Sunshine, to do the exact same thing, but in software. Sunshine can tell the uinput module, "Hey, pretend a mouse just moved to coordinates X, Y," and the kernel will treat it exactly as if a real mouse did it.

This is essential for applications like:

Sunshine/Moonlight: To inject mouse, keyboard, and gamepad inputs coming from your client device over the network.
Steam: For the Steam Input feature, which can make a controller look like a keyboard and mouse to a game.
Input Remappers: Tools that change what your keyboard keys or controller buttons do.

The Permission Problem

For security reasons, you don't want just any application to be able to create fake keyboard presses or mouse movements. If any program could do this, it would be trivial to create a keylogger or malware that could take control of your computer.

Because this is a powerful and potentially dangerous feature, Linux protects it with file permissions. The uinput functionality is exposed through a special device file: /dev/uinput.

Let's look at the permissions on that file. If you run this command in your terminal:

ls -l /dev/uinput

You will likely see something like this:

crw-rw---- 1 root uinput 10, 223 Dec 15 10:30 /dev/uinput

Let's break that down:

c: It's a character device file.
rw-: The owner (root) has read and write permissions.
rw-: The group (uinput) has read and write permissions.
---: Everyone else has no permissions at all.

When you run Sunshine, it runs as your user account (e.g., myuser), not as root. By default, your user is not in the uinput group. Therefore, when Sunshine tries to access /dev/uinput to create a virtual mouse or keyboard, the kernel sees that your user is in the "everyone else" category and says "Permission Denied".

The Solution: The `uinput` Group

The forum's advice is exactly correct. The uinput group was created specifically for this purpose: to grant trusted users the ability to access the uinput device without giving them full root privileges.

By adding your user to the uinput group, you are telling the system, "I trust this user account to run programs (like Sunshine) that need to create virtual input devices."

How to Fix It: Step-by-Step

Here are the commands to solve your problem on Arch Linux.

1. Add Your User to the uinput Group

Open a terminal and run the following command. Make sure to replace your_username with your actual username. If you're not sure, you can run the command whoami to see it.

sudo gpasswd -a your_username uinput

sudo: Run this command with administrator privileges.
gpasswd: A command to manage group memberships.
-a your_username: The action is to add the specified user.
uinput: The group you are adding the user to.

2. Apply the Changes

Group membership changes only take effect when you start a new login session. The current session you are in will not have the new permissions. You have two options:

Log Out and Log Back In: This is the cleanest and most recommended way. Log out of your Niri session completely and then log back in.
Reboot: A full reboot will also work.

3. Verify the Change (Optional)

After you have logged back in, you can verify that you are now a member of the group by running:

groups

You should see uinput listed in the output, along with your other groups.

# Example output
wheel audio video input uinput myuser

Once you've done this, Sunshine should have the necessary permissions to create virtual input devices, and your mouse, keyboard, and controller should start working correctly on your Niri desktop

8.2 KiB Raw Permalink Blame History

Step 1: Install swayidle