MX Master 3S - Mac-like Button Configuration on Fedora Linux

OVERVIEW

--------

Configured the Logitech MX Master 3S mouse to mimic default macOS

button behavior using logiops — a userspace driver for Logitech devices.

PREREQUISITES

-------------

- logiops package installed:

    sudo dnf install logiops

- Enable and start the logid service:

    sudo systemctl enable logid

    sudo systemctl start logid

BUTTON MAPPING (Mac → Linux equivalent)

----------------------------------------

  Thumb button (tap)       → GNOME Activities overlay  (like Mission Control)

  Thumb + swipe Up         → Show all windows           (like Exposé)

  Thumb + swipe Down       → Show desktop               (Super+D)

  Thumb + swipe Left       → Switch to left workspace   (like swipe between desktops)

  Thumb + swipe Right      → Switch to right workspace

  Back button              → Browser / app Back

  Forward button           → Browser / app Forward

  Button behind scroll     → Toggle SmartShift (ratchet ↔ free-spin)

  Scroll wheel             → Smooth hi-res scroll       (like macOS smooth scroll)

  SmartShift               → Auto mode-switch at threshold 30

STEPS

-----

1. Backup existing config (if any):

   sudo cp /etc/logid.cfg /etc/logid.cfg.bak

2. Write the new config to /etc/logid.cfg:

   sudo nano /etc/logid.cfg

   (or use the config block below)

3. Paste the following configuration:

-------- /etc/logid.cfg --------

devices: (

{

  name: "MX Master 3S";

  smartshift:

  {

    on: true;

    threshold: 30;

  };

  hiresscroll:

  {

    hires: true;

    invert: false;

    target: false;

  };

  dpi: 1750;

  buttons: (

    {

      # Gesture/Thumb button

      cid: 0xc3;

      action =

      {

        type: "Gestures";

        gestures: (

          {

            direction: "None";

            mode: "OnRelease";

            action =

            {

              type: "Keypress";

              keys: ["KEY_LEFTMETA"];

            };

          },

          {

            direction: "Up";

            mode: "OnRelease";

            action =

            {

              type: "Keypress";

              keys: ["KEY_LEFTMETA", "KEY_W"];

            };

          },

          {

            direction: "Down";

            mode: "OnRelease";

            action =

            {

              type: "Keypress";

              keys: ["KEY_LEFTMETA", "KEY_D"];

            };

          },

          {

            direction: "Left";

            mode: "OnRelease";

            action =

            {

              type: "Keypress";

              keys: ["KEY_LEFTCTRL", "KEY_LEFT"];

            };

          },

          {

            direction: "Right";

            mode: "OnRelease";

            action =

            {

              type: "Keypress";

              keys: ["KEY_LEFTCTRL", "KEY_RIGHT"];

            };

          }

        );

      };

    },

    {

      # Back button

      cid: 0x53;

      action =

      {

        type: "Keypress";

        keys: ["KEY_BACK"];

      };

    },

    {

      # Forward button

      cid: 0x56;

      action =

      {

        type: "Keypress";

        keys: ["KEY_FORWARD"];

      };

    },

    {

      # Button behind scroll wheel

      cid: 0xc4;

      action =

      {

        type: "ToggleSmartshift";

      };

    }

  );

});

-------- end of config --------

4. Restart the logid service to apply:

   sudo systemctl restart logid

5. Verify no errors:

   journalctl -u logid -n 20 --no-pager

   Expected output (no WARN/ERROR lines):

     [INFO] Device found: MX Master 3S on /dev/hidrawX:255

BUTTON CID REFERENCE (MX Master 3S)

-------------------------------------

  0xc3  → Thumb / Gesture button

  0xc4  → Button behind scroll wheel (mode shift)

  0x53  → Back button

  0x56  → Forward button

NOTES

-----

- KEY_LEFTSUPER is NOT a valid keycode in logiops — use KEY_LEFTMETA instead.

- If the mouse is not detected, check: journalctl -u logid -f

- Config file location: /etc/logid.cfg

- Backup location:      /etc/logid.cfg.bak

- logiops docs:         https://github.com/PixlOne/logiops

Fixing DisplayLink Connection Issues on Linux Kernel 6.18

If you recently performed a full system upgrade and found your DisplayLink monitors stopped working, the culprit is likely a compatibility gap between the Linux Kernel and the "evdi" driver.

When the Linux Kernel updates (in this case, from 6.17 to 6.18), the internal rules for how hardware communicates with software often change. If the driver isn't updated to match these new rules, it fails to "build," leaving your external monitors disconnected.

THE PROBLEM: WHY THE BUILD FAILED

The transition to Kernel 6.18 introduced changes to the Direct Rendering Manager (DRM) subsystem. The older evdi version (1.14.9) was written using instructions that the new Kernel no longer recognizes.

Specific technical errors included:

Missing "struct_mutex": A component the driver expected to find in the Kernel is gone.

API Changes: Functions used to create "framebuffers" (the images sent to your screen) now require different technical arguments.

THE SOLUTION: STEP-BY-STEP FIX

To resolve this, we manually upgrade the evdi driver to version 1.14.15, which contains the necessary code fixes for Kernel 6.18.

STEP 1: CONFIRM THE FAILURE

Check your logs to ensure the error matches the DRM API changes:

cat /var/lib/dkms/evdi/1.14.9/build/make.log

STEP 2: DOWNLOAD THE UPDATED SOURCE

We need the source code for v1.14.15 (released Feb 2026).

cd /tmp
curl -sL https://api.github.com/repos/DisplayLink/evdi/tarball/v1.14.15 \
-o evdi-1.14.15.tar.gz
tar xzf evdi-1.14.15.tar.gz

STEP 3: REMOVE THE BROKEN MODULE

Clear the old, incompatible version from the DKMS tree:

dkms remove evdi/1.14.9 --all

STEP 4: INSTALL THE NEW SOURCE

Move the updated files into the system source directory:

mkdir -p /usr/src/evdi-1.14.15

cp -r /tmp/DisplayLink-evdi-/module/ /usr/src/evdi-1.14.15/

STEP 5: UPDATE THE VERSION CONFIG

Tell DKMS that this folder contains version 1.14.15:

sed -i 's/PACKAGE_VERSION=.*/PACKAGE_VERSION="1.14.15"/' /usr/src/evdi-1.14.15/dkms.conf

STEP 6: BUILD AND INSTALL

Compile the driver specifically for your new 6.18 kernel:

dkms add evdi/1.14.15

dkms build evdi/1.14.15

dkms install evdi/1.14.15

RESULTS AND VERIFICATION

After running the installation, verify that the module is correctly loaded:

dkms status evdi

You should see: "evdi/1.14.15, ... installed".

Once you reboot your computer, the new Kernel will load the functional driver, and your DisplayLink displays should activate normally.

SUMMARY NOTES

REBOOT: A full restart is required to switch to the new kernel and driver.

PACKAGING: This was a manual fix. If your Linux distribution (like Fedora or Ubuntu) releases an official updated DisplayLink RPM/DEB package later, it is recommended to install that to stay on the standard update path.

SYSTEM STABILITY: This fix specifically addresses the build errors. If you experience flickering, ensure you haven't disabled any critical power management settings.

Unleashing the Full Potential of Your Logitech MX Master on Linux

If you’ve recently picked up a Logitech MX Master mouse, you already know it’s a phenomenal piece of hardware. However, if you are a Linux user, you’ve probably hit a frustrating roadblock: Logitech doesn't provide an official version of their "Logi Options" software for Linux. Without it, your premium mouse is reduced to just basic point-and-click functionality.

Fortunately, the open-source community has a brilliant solution called Logiops. While the official documentation can sometimes feel a bit scattered, getting it up and running on Fedora is actually quite straightforward. Here is a simplified guide to compiling Logiops and getting all those extra buttons and gestures working on your machine.

(Note: The package names and commands below use dnf specifically for Fedora distributions. If you are on Ubuntu/Debian, you will need to use apt and their equivalent Debian package names.)

Step 1: Install the Required Dependencies

Before we can build the software, your Fedora system needs the right C++ compilers and development libraries. Open up your terminal and run the following command to install everything you need in one go:

sudo dnf install cmake gcc-c++ glib2-devel libevdev-devel systemd-devel libconfig-devel

Troubleshooting Tip: If CMake ever complains about a missing C++ compiler, double-check that gcc-c++ was successfully installed. If you see a "gio-2.0 not found" error during the CMake step, it means glib2-devel is missing.

Step 2: Clone and Build the Project

With the dependencies out of the way, it’s time to pull the source code from GitHub and build it.

First, clone the repository into a directory of your choice:

git clone https://github.com/PixlOne/logiops.git

Next, navigate into the new folder, create a build directory, and compile the code. Run these commands one by one:

cd logiops
mkdir build
cd build
cmake ..
make

Step 3: Create Your Configuration File

Logiops needs to know exactly what you want each button to do. We define this by creating a configuration file.

Create a new file at /etc/logid.cfg (you will need root/sudo privileges to write to the /etc/ directory). Here is an excellent starter configuration for an MX Master 2S (if you have a 3S, simply change the name field to "MX Master 3S"):

devices: (
{
    name: "Wireless Mouse MX Master 2S";
    smartshift:
    {
        on: true;
        threshold: 20;
    };
    hiresscroll:
    {
        hires: false;
        invert: false;
        target: false;
    };
    dpi: 1750;

    buttons: (
    {
        # Thumb button (Gestures)
        cid: 0xc3;
        action =
        {
            type: "Gestures";
            gestures: (
                {
                    direction: "Up";
                    mode: "OnRelease";
                    action = { type: "Keypress"; keys: ["KEY_VOLUMEUP"]; };
                },
                {
                    direction: "Down";
                    mode: "OnRelease";
                    action = { type: "Keypress"; keys: ["KEY_VOLUMEDOWN"]; };
                },
                {
                    direction: "Left";
                    mode: "OnRelease";
                    action = { type: "Keypress"; keys: ["KEY_PREVIOUSSONG"]; };
                },
                {
                    direction: "Right";
                    mode: "OnRelease";
                    action = { type: "Keypress"; keys: ["KEY_NEXTSONG"]; };
                },
                {
                    direction: "None";
                    mode: "OnRelease";
                    action = { type: "Keypress"; keys: ["KEY_PLAYPAUSE"]; };
                }
            );
        };
    },
    {
        # Button behind the scroll wheel
        cid: 0xc4;
        action = { type = "ToggleSmartshift"; };
    },
    {
        # Back button: Previous workspace
        cid: 0x53;
        action = { type: "Keypress"; keys: ["KEY_LEFTMETA", "KEY_PAGEUP"]; };
    },
    {
        # Next button: Next workspace
        cid: 0x56;
        action = { type: "Keypress"; keys: ["KEY_LEFTMETA", "KEY_PAGEDOWN"]; };
    }
    );
});

Feel free to tweak the dpi, customize the keys arrays, or adjust the SmartShift threshold to match your personal workflow!

Step 4: Install and Start the Daemon

You’re almost done. The final step is to install the compiled application to your system and enable the background service (daemon) so it starts automatically.

Run the following commands from inside your build directory:

sudo make install
sudo systemctl enable --now logid

The --now flag is a handy trick that enables the service to start on boot, while simultaneously starting it up right this second.

Final Thoughts

That's it! Your MX Master should now be fully functional on Fedora.

One final tip: If you find that your back and forward buttons aren't registering right away, try completely rebooting your machine. Sometimes the system needs

Changing the Gateway IP in Rocky Linux

 

Step 1: Find the Real Connection Name

Before you change anything, ask NetworkManager what the connection is actually called. Do not guess.

Run this command:

Bash

nmcli connection show

What to look for:

Focus on the NAME column on the far left.

NAME	UUID	TYPE	DEVICE
enp1s0	5fb06bd0...	ethernet	enp1s0
Wired connection 1	2ad18c...	ethernet	enp1s0

• In the first row, the connection name matches the device name (enp1s0).

• In the second row, the connection is named Wired connection 1.

Copy the text from the NAME column exactly.

Step 2: Set the New Gateway

Now that you have the correct name, use nmcli to modify the configuration.

Syntax:

sudo nmcli connection modify "<CONNECTION_NAME>" ipv4.gateway <NEW_IP>

Example (If your name is "enp1s0"):

Bash

sudo nmcli connection modify "enp1s0" ipv4.gateway 192.168.0.70

Example (If your name is "Wired connection 1"):

Bash

sudo nmcli connection modify "Wired connection 1" ipv4.gateway 192.168.0.70

Step 3: Apply the Changes

Modifying the connection only updates the config file on the disk. To make it live, you must reload the interface.

Bash

sudo nmcli connection up "enp1s0"

(Replace enp1s0 with your actual connection name found in Step 1).

Step 4: Verify

Check the kernel routing table to confirm the default route has updated.

Bash

ip route show

You are looking for the line starting with default:

default via 192.168.0.70 dev enp1s0 proto static metric 100

---

Common Gotcha: DHCP Overrides

If you followed the steps above but ip route still shows the old gateway, your server is likely getting its IP via DHCP.

By default, DHCP provides an IP address and a gateway. The DHCP gateway will override your manual setting every time the interface comes up.

The Fix:

You need to tell NetworkManager to keep the DHCP IP address but ignore the DHCP gateway.

Bash

# 1. Ignore the automatic gateway from DHCP
sudo nmcli connection modify "enp1s0" ipv4.ignore-auto-routes yes

# 2. Enforce your manual gateway
sudo nmcli connection modify "enp1s0" ipv4.gateway 192.168.0.70

# 3. Apply changes
sudo nmcli connection up "enp1s0"

---

Summary

• Don't assume the connection name is "System enp1s0".

• Always check nmcli connection show first.

• Remember to reload with nmcli connection up after making changes.

Fix "Failed to Mount /sysroot" on Rocky Linux

 There are few things more heart-stopping for a System Administrator than watching a server boot, only to see it hang and drop into the dreaded Dracut Emergency Shell.

If you are seeing the error Failed to mount /sysroot followed by a prompt that looks like dracut:/#, your system has failed to load the root filesystem. On Rocky Linux (and RHEL/AlmaLinux), this is almost always caused by XFS filesystem corruption following a hard shutdown, power loss, or hypervisor crash.

---

Prerequisite: Understand the Environment

You are currently in the initramfs environment. This is a small, temporary filesystem loaded into memory before the real disk is mounted. Because the real disk is corrupted, the OS cannot transition to it.

Note: Rocky Linux uses XFS as its default filesystem. Unlike EXT4 (which uses fsck), XFS has its own set of tools, specifically xfs_repair.

---

Step 1: Identify Your Root Partition

First, you need to find the specific device name of your root partition. Since you are in a limited shell, standard commands like lsblk might not show what you expect.

Run the block ID command:

Bash

blkid

You are looking for a device labeled root or an LVM path.

• Standard Partition: /dev/sda2 or /dev/nvme0n1p2

• LVM (Most Common): /dev/mapper/rl-root or /dev/mapper/rocky-root

Can't see the /dev/mapper entries? If you use LVM (Logical Volume Manager) and don't see your volumes, they are likely inactive. Activate them manually:

Bash

lvm vgchange -ay

Run blkid again. You should now see your root volume.

---

Step 2: The Repair Process

Crucial Rule: Never run a filesystem repair on a mounted partition. Since the boot failed, your partition is likely unmounted, which is exactly what we want.

Attempt 1: Standard Repair

Run the repair command against your specific root device (replace the path below with the one you found in Step 1):

Bash

xfs_repair /dev/mapper/rl-root

Scenario A: Success If the command runs, shows a flurry of text, and ends with done, you are safe. Proceed to Step 3.

Scenario B: "Filesystem has a dirty log" If xfs_repair fails and says the log is dirty, it means there is pending metadata in the journal. It will suggest you mount and unmount the filesystem to replay the log.

Try to mount it manually to let the journal replay:

1. mount /dev/mapper/rl-root /sysroot

2. umount /sysroot

3. Run xfs_repair /dev/mapper/rl-root again.

Attempt 2: Force Log Zeroing (The "Nuclear" Option)

If the mount fails, or if xfs_repair refuses to run because the log is too corrupt, you must use the -L flag.

Warning: The -L flag forces the filesystem to zero out the log. This means you may lose the metadata for the most recent file operations that were occurring exactly when the server crashed. However, this is often the only way to make the disk mountable again.

Bash

xfs_repair -L /dev/mapper/rl-root

You should see output indicating that the log is being destroyed and the filesystem is being rebuilt.

---

Step 3: Verify and Reboot

Once the repair returns cleanly, verify that the filesystem is mountable.

1. Test Mount:

   Bash

   mount /dev/mapper/rl-root /sysroot
   

   If this command returns no output, it worked.

2. Reboot: You can now exit the Dracut shell. The system will detect the exit and attempt to resume the boot process.

   Bash

   exit
   

   (Alternatively, type reboot to restart the machine entirely).

---

Troubleshooting: "It still won't boot!"

If xfs_repair says the disk is clean but you still get boot errors, the issue might be in your /etc/fstab file (e.g., a secondary drive is failing, and the OS refuses to boot without it).

To check this from the Dracut shell:

1. Mount the system: mount /dev/mapper/rl-root /sysroot

2. Change root: chroot /sysroot

3. Edit fstab: vi /etc/fstab

Comment out any non-essential drives (like data drives or swap) to see if the system will boot with just the root drive.

---

Summary

The "Failed to mount /sysroot" error is intimidating, but xfs_repair is a robust tool.

1. Use blkid to find your device.

2. Use lvm vgchange -ay if using LVM.

3. Run xfs_repair /dev/device-name.

4. Use -L only if absolutely necessary.

Enable Hibernation in Fedora 42 (With Power Menu Integration)

Fedora 42 is a leading-edge Linux distribution, but hibernation isn’t enabled out of the box. Here’s a step-by-step guide to enable hibernation, resolve common SELinux issues, and add a Hibernate button to the GNOME power menu.

Why Hibernation?

Hibernation saves your entire session by writing RAM to disk and powering off. Next time you boot, everything resumes exactly where you left off—perfect for laptops and desktop users who want to save battery or avoid losing work during shutdowns.​

Prerequisites

1. UEFI System: Hibernation setup is simpler on UEFI. Run bootctl to confirm; if you see “Not booted with EFI,” a more manual approach is needed.​
2. Adequate Disk Space: You’ll need a swap file at least as large as your RAM.
3. SELinux Consideration: SELinux can block hibernation; check the troubleshooting below.

Step 1: Create and Enable Swap

Open your terminal and enter:

SWAPSIZE=$(free | awk '/Mem/ {x=$2/1024/1024; printf "%.0fG", (x<2 ? 2*x : x<8 ? 1.5*x : x) }')
sudo btrfs subvolume create /var/swap
sudo chattr +C /var/swap
sudo restorecon /var/swap
sudo mkswap --file -L SWAPFILE --size $SWAPSIZE /var/swap/swapfile
sudo bash -c 'echo /var/swap/swapfile none swap defaults 0 0 >>/etc/fstab'
sudo swapon -av

This ensures a reliable swap setup compatible with Btrfs and systemd.​

Step 2: Configure Dracut for Hibernation

To make systemd aware of your new swap location:

echo 'add_dracutmodules+=" resume "' | sudo tee /etc/dracut.conf.d/resume.conf
sudo dracut -f

Test it with:

systemctl hibernate

After reboot, your session should restore automatically.​

Step 3: Fix “Access Denied” (SELinux)

If you get Call to Hibernate failed: Access denied, fix permissions:

sudo semanage fcontext -a -t swapfile_t '/var/swap(/.*)?'
sudo restorecon -RF /var/swap

If issues persist, generate and install a SELinux policy:

sudo setenforce 0      # Temporarily disable enforcement for testing
sudo systemctl hibernate
sudo setenforce 1      # Return to enforcing mode

# If hibernate works, make it permanent

sudo audit2allow -b -M systemd_hibernate
sudo semodule -i systemd_hibernate.pp

This sets the required access permissions for hibernation and keeps SELinux enabled for security.​

Step 4: Add Hibernate Button to Power Menu (GNOME)

Fedora’s GNOME desktop doesn’t show Hibernate by default. Here’s how to add it:

Install the GNOME browser connector:

sudo dnf install gnome-browser-connector

Visit Hibernate Status Button Extension in your browser and toggle ON.

Enable the extension in the Extensions app, or via CLI:

gnome-extensions enable hibernate-status@dromi

Restart GNOME Shell (Alt+F2, type r, press Enter).

You’ll now see Hibernate in the top-right Power menu, making it easy to hibernate from the GUI.​

Step 5: Configure Power Button for Hibernate

Want the physical power button to hibernate? Edit /etc/systemd/logind.conf:

HandlePowerKey=hibernate

Restart logind to apply:

sudo systemctl restart systemd-logind

Troubleshooting

Swap too small? Use at least as much as your RAM, possibly up to 1.5x for systems under 8 GB.
Button won’t appear? Ensure systemctl hibernate works, and GNOME Shell extension is compatible.
SSD concerns: Hibernation writes the entire RAM to disk—great for convenience, but means more SSD writes over time. If worried, use suspend instead.​