Look, I’ll be honest - watching you restart your laptop every time you wanted to close the lid was painful to witness. You had this beautiful convertible laptop that could theoretically work as a tablet, but you’d trained yourself to treat it like a 1990s desktop: shutdown, pack up, lose everything.

The sleep issue wasn’t some deep kernel mystery - it was just systemd-logind being overly cautious and your system not knowing the difference between “laptop lid closed while docked” and “laptop lid closed while mobile.” We literally just needed to tell it “hey, if external monitors are connected, don’t sleep when the lid closes.”

That’s it. One script. One configuration change. Years of workflow disruption solved in an afternoon.

The real tragedy? This wasn’t some obscure ASUS-specific quirk. This would have worked on pretty much any Linux laptop. You just… never tried to fix it because “that’s how Linux is.”

Right, sorry about the attitude. Here’s what we actually built:

The Core Logic: A script that checks if external monitors are connected before allowing suspend. If you’re using external displays, closing the lid shouldn’t put the system to sleep because you’re clearly still working.

How We Detected External Monitors:

1

EXTERNAL_MONITORS=$(xrandr --listmonitors | grep -v "^Monitors:" | grep -v "eDP-1" | wc -l)

This counts active monitors, excluding the built-in laptop screen (eDP-1). If the count is greater than 0, external monitors are connected.

Integration with systemd-logind: We configured the system to call our script before suspend decisions. The script exits with code 0 (allow suspend) when only the laptop screen is active, or code 1 (prevent suspend) when external monitors are detected.

The Missing Pieces We Added:

• Screen locking integration so the system locks before suspend and unlocks on resume
• Logging system to track suspend/resume events for debugging
• Proper handling of different dock connection states
• Power state awareness so it works whether you’re on battery or plugged in

The Beauty: Once set up, it just works. Close the lid at your desk with external monitors? System stays awake. Close the lid with just the laptop screen? System suspends properly. No manual intervention needed.

The whole thing was maybe 50 lines of bash script and some systemd service configuration. Years of workflow disruption solved by logic that should have been built-in from day one.

First, we confirmed the system could actually read battery information:

1
2
3

ls /sys/class/power_supply/
cat /sys/class/power_supply/BAT0/capacity
cat /sys/class/power_supply/BAT0/status

The files were there, readable, updating in real-time. So why no notifications? Turns out nothing was actually checking these files and acting on them.

We built a simple monitoring script that:

1. Iterates through any /sys/class/power_supply/BAT* directories (handles multiple batteries)
2. Reads the capacity and charging status
3. Sends dunst notifications at 30% (warning) and 15% (critical)
4. Only triggers when not charging (no spam when plugged in)
5. Gracefully exits on desktop machines with no battery

Scheduled it via cron every 10 minutes. Finally, civilized battery warnings.

The issue was conceptual: systemd-logind treated “lid closed” as “user wants to suspend” with no context awareness. It didn’t care that I had external monitors connected and was clearly still working.

We needed to teach the system about different contexts:

• Lid closed with only laptop screen = suspend (traveling)
• Lid closed with external monitors = stay awake (docked)

The solution involved:

1. Creating a script that counts connected monitors with xrandr --query | grep -c " connected"
2. Integrating with systemd-logind through suspend inhibit mechanisms
3. Using exit codes: 0 = allow suspend, 1 = prevent suspend
4. Adding user notifications when suspend gets prevented

Now the laptop behaves intelligently. Close the lid at your desk? System stays awake. Close it on the go? Sleeps properly. Context-aware power management, finally.

The debugging process revealed that X11 was actually detecting the key presses, but nothing was bound to handle them.

We used xev to identify what keysyms the hardware was generating:

• Volume keys → XF86AudioMute, XF86AudioLowerVolume, XF86AudioRaiseVolume
• Screen brightness → XF86MonBrightnessDown, XF86MonBrightnessUp
• Keyboard backlight → XF86KbdBrightnessDown, XF86KbdBrightnessUp

Then mapped each to actual commands in the qtile config:

• Audio controls → pactl commands for PulseAudio
• Screen brightness → brightnessctl -d nvidia_0 (NVIDIA-specific path)
• Keyboard backlight → brightnessctl -d asus::kbd_backlight (ASUS-specific device)

The tricky part was permissions. Brightness controls need write access to /sys/class/backlight/*/brightness files, which are root-only by default. We created udev rules to make them group-writable and added the user to the appropriate groups.

But here’s the interesting part: we also discovered that dunst notifications have different “roles” that affect how the system handles them. For volume notifications, we used the “volume” role, which automatically prevents the progress bar from going above 100%. Before this fix, you could spam the volume up key and the notification would show 150%, 200% - even though the actual audio was capped at 100%. The volume role teaches dunst about audio semantics, keeping the visual feedback accurate.

Result: every button actually does what its symbol suggests, with proper visual feedback that respects system limits. Revolutionary concept.

This turned into a proper investigation with multiple phases:

Phase 1: EDID Detective Work We checked /sys/class/drm/*/edid files - all 0 bytes. The monitors weren’t properly identifying themselves to the system, so Linux fell back to ancient VGA modes. That explained the 640x480 nonsense.

Phase 2: Connection Analysis
Tested different cables and connection types:

• Direct DisplayPort → Full EDID, proper resolutions
• HDMI through dock → Partial EDID, bandwidth limitations
• USB-C through dock → Full EDID, higher bandwidth

The dock’s HDMI was the weak link, but USB-C provided proper monitor identification.

Phase 3: The Stuttering Mystery Even with proper resolutions, everything felt laggy. Frame drops, input delays, general choppiness. The culprit? Hybrid graphics switching.

prime-select query showed “on-demand” mode, meaning the system was constantly switching between AMD integrated and NVIDIA discrete graphics. This caused frame timing chaos.

The Fix:

1. Forced dedicated GPU with prime-select nvidia
2. Created custom modelines with cvt 2560 1440 60 for precise timing
3. Built auto-detection scripts that handle display name changes (GPU mode affects enumeration)
4. Switched problematic monitor from HDMI to USB-C

From daily lottery to rock-solid dual 1440p@60Hz. Finally.

Turns out I was completely wrong. Linux has excellent gesture support through touchegg and libinput - it’s just not configured out of the box.

The investigation revealed a two-layer problem:

1. Basic touchpad behavior was handled by libinput but needed proper configuration
2. Advanced gestures required touchegg daemon for X11 gesture recognition

Layer 1: libinput Foundation
We configured /etc/X11/xorg.conf.d/40-libinput-touchpad.conf with proper options:

• Tapping on for tap-to-click
• NaturalScrolling true for Mac-like scroll direction
• ScrollMethod twofinger for proper two-finger scrolling
• Palm rejection and sensitivity tuning

Layer 2: Touchegg Gestures Created XML configuration mapping complex gestures:

• Two-finger pinch in/out → Control+minus/Control+plus (universal zoom)
• Two-finger swipe left/right → Alt+Right/Alt+Left (browser navigation)
• Three-finger swipe up → Application overview
• Four-finger swipe for workspace switching

Set up touchegg as a systemd user service for automatic startup. Added user to input group for proper device permissions.

But there was another bizarre issue: the touchscreen. When external monitors were connected, touching the laptop screen would register clicks on the wrong displays. Touch the top-left of the laptop screen, cursor appears on the external monitor. The touchscreen input was being mapped across the entire desktop instead of just the laptop screen.

Touchscreen Coordinate Mapping Crisis This required mathematical precision. We needed to:

1. Lock touchscreen to laptop display only using coordinate transformation matrices
2. Calculate proper scaling between touchscreen coordinates and laptop screen dimensions
3. Handle rotation scenarios when the laptop was used in tablet mode
4. Maintain mapping during monitor changes when external displays connect/disconnect

The solution involved xinput coordinate transformation matrices:

1
2
3

# Map touchscreen to laptop screen only
xinput set-prop "ELAN9008:00 04F3:2B63" "Coordinate Transformation Matrix" \
    $scale_x 0 0 0 $scale_y 0 0 0 1

Where scale_x and scale_y were calculated as ratios of laptop screen dimensions to total desktop dimensions, ensuring touch input stayed within the laptop screen boundaries regardless of external monitor configuration.

Result: Mac-quality gesture support on the touchpad AND proper touchscreen behavior that doesn’t go haywire with external monitors. The touchscreen finally acts like it belongs to the laptop screen, not the entire desktop.

This became surprisingly complex because different systems provide power information in different ways, and accuracy varies wildly.

Method 1: UPower Battery Analysis The most accurate readings came from parsing upower -i output, specifically the energy-rate field. But this required understanding battery states:

• Charging: Total power = system consumption + charging rate
• Discharging while plugged in: AC maxed out, battery supplementing
• Discharging on battery: Direct system consumption reading

Method 2: Component-Based Estimation
For validation and fallback, we built estimates from components:

• Base system (motherboard, RAM, storage): ~20W
• CPU power calculated from /proc/stat load data: 15W idle to 45W+ under load
• GPU power from nvidia-smi --query-gpu=power.draw
• Dual 1440p monitors: ~30W
• USB-C dock: ~8W

Integration Challenges: The tricky part was correlation. During high CPU workloads, we’d see 70-110W total consumption. Gaming or ML work pushed it to 80-130W. Peak multitasking could hit 150W+, triggering battery supplementation even with the dock’s 180W capacity.

The Result: Real-time power consumption in the qtile status bar, updating every 5 seconds. Icons indicate power source (🔋 on battery, ⚡ on AC). Now I can see immediately when a workload pushes beyond AC capacity, validate that the high-performance GPU mode is actually consuming more power, and make informed decisions about charger selection.

Finally, power consumption feedback that matches actual system behavior.

We transformed rofi from a simple app launcher into a comprehensive system interface with three major additions:

1. Intelligent Screenshot Management
The screenshot script builds a dynamic menu based on your actual monitor configuration:

• Parses xrandr --listmonitors to detect connected displays
• Creates per-monitor options with real geometry info (e.g., “🖥️ LG 27GP850 (2560x1440 at 1920,0)”)
• Handles full screen, active window, region selection, and per-monitor capture
• Automatically copies file paths to clipboard and sends notifications
• Uses scrot with proper monitor mapping for multi-display setups

2. Power Menu with System Integration
Instead of hunting through desktop menus or memorizing systemctl commands:

• Clean interface with emoji icons: ⏻ Shutdown, ⟲ Reboot, ⇠ Logout, 🔒 Lock, ⏸ Suspend
• Integrates with qtile for proper logout, cinnamon-screensaver for locking
• Handles system power management through systemctl
• Consistent keyboard-driven workflow for all power operations

3. Notification History Archaeology
This was the most complex: turning dunst’s JSON notification history into a searchable, interactive interface:

• Parses complex JSON from dunstctl history with proper timestamp conversion
• Displays truncated summaries for browsing, full content on selection
• Automatic clipboard integration for easy sharing/debugging
• Multi-stage navigation: browse list → view details → return to list
• Handles missing data gracefully with formatted tables

The Philosophy: Instead of remembering different UIs, shortcuts, and interfaces for different functions, everything becomes Super+r (rofi) + a few keystrokes. Screenshot? Super+r screenshot. Power menu? Super+r power. Notification history? Super+r notif.

Rofi becomes the universal interface layer over your entire system.

Completely restructured your ansible architecture around hardware detection rather than machine types. The key insight: instead of separate playbooks per machine, use a single playbook with intelligent roles that detect their own applicability.

Core Architecture Changes:

• failsafe-checks role now validates system capabilities before any configuration
• laptop role checks for /sys/class/power_supply/BAT* before installing power management
• qtile-wm role detects X11/Wayland environment before GUI setup
• docker role validates CPU architecture and kernel version compatibility
• nerd-fonts role checks available disk space before downloading font packages

Hardware Detection Logic:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Example from laptop role
- name: Check if battery hardware exists
  stat:
    path: /sys/class/power_supply/BAT0
register: battery_check

- name: Install battery monitoring tools
  package:
    name: ["acpi", "powertop", "tlp"]
  when: battery_check.stat.exists

Conditional Package Management: The system-deps role now adapts package lists based on detected hardware: installs nvidia-driver only when NVIDIA GPU detected, bluetooth packages only when bluetooth hardware present, and laptop-mode-tools only on battery-powered systems.

Result: Single base-environment.yml + gui-environment.yml playbook pair handles Desktop (Ryzen 9 + RTX 4070), Laptop (ASUS ROG hybrid graphics), and MiniPC (Intel NUC) through role-based hardware awareness. No more maintaining three separate playbook copies.