1
0
Dotfiles/TODO.md
2025-11-03 12:46:04 +00:00

201 lines
8.2 KiB
Markdown

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.
```bash
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.
1. Create the file:
```bash
mkdir -p ~/.config/niri
nano ~/.config/niri/idle.sh
```
2. 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).
```sh
#!/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.
3. Save the file and exit `nano` (Ctrl+O, Enter, Ctrl+X).
4. Make the script executable:
```bash
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.
1. Open your niri configuration file. If it doesn't exist, niri uses its defaults, but you can create it.
```bash
nano ~/.config/niri/config.kdl
```
2. 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.
```kdl
// 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.
3. 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:
```sh
#!/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:
```bash
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.
```bash
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 **a**dd 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:
```bash
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