Running xrandr wakes up the dGPU

TLDR; Running the configuration utility xrandr wakes up the dedicated GPU on your machine. This is not a problem on a desktop but running it periodically on a laptop will drain your battery and might have other unintended consequences.

The rest of the blog describes the issue I faced due to running xrandr repeatedly, how I identified and circumvented the problem. Let’s begin.

I have a new all AMD laptop, the Asus G513QY, running Arch Linux with the i3 window manager. I use the i3status-rust status bar. On it, I have a toggle button to control the second monitor connected via HDMI.

The toggle button on i3status-rust bar

The toggle button accepts the following parameters:

For the command_state parameter, I run xrandr --listactivemonitors | grep HDMI1 to determine if my HDMI monitor is connected. This command is run every 10 seconds. I’ve used this configuration on my previous laptop as well.

After the initial setup on the new laptop, I noticed some weird behavior. Every few seconds my mouse would get stuck, and inputs from the keyboard would be skipped. Reviewing the kernel logs I noticed the following lines appear multiple times:

Careful observation revealed that these lines were appearing exactly when I was experiencing the input lag. I could tell that the issue was related to the AMD GPU but not what was causing it.

Using amdgpu.runpm=0 as a temporary fix

Searching on the Internet revealed that on newer AMD graphics cards, system stability could be improved by setting amdgpu.runpm=0 kernel parameter. The Linux AMD GPU driver documentation page states the following about the runpm parameter:

Override for runtime power management control for dGPUs in PX/HG laptops. The amdgpu driver can dynamically power down the dGPU on PX/HG laptops when it is idle. The default is -1 (auto enable). Setting the value to 0 disables this functionality.

This kernel parameter fixed the lags for me but increased the power draw. When I was setting up the laptop, I had a lot of other issues to deal with, so fixing a high power draw was not on the top of my priority list.

Identifying the real issue

Recently, I was able to dedicate some time to investigate this further. I created a ticket on the Linux AMD driver issue tracker where I was informed that the log messages are harmless and get printed when the dGPU is powered up without a display attached. So that meant that something was waking up the dGPU periodically.

The amdgpu.runpm=0 kernel parameter disables power management for the GPU. This was fixing the issue as the GPU was never powering down at all. Now that I knew the reason for the issue, the next step was to identify what/who was causing it.

Closing down applications one by one revealed that the lag stopped once i3status-rust was shut down. Next, I removed blocks from the status bar 1-by-1. That helped narrow down the problem to the HDMI block, which runs the xrandr configuration utility every 10 seconds.

Working around the problem

Once I knew why and what was causing the issue, working around the problem was easy. I needed to find another way to identify if my external monitor was connected. I came up with the following,

Final thoughts

While I can understand why the xrandr command would need to wake up the dedicated GPU, I was not expecting it to cause lags. My previous laptop that had a dedicated NVIDIA MX150, was running the same command but did not have these problems.

With this issue fixed, my battery discharge rate dropped from 19W to around 13W without any USB devices connected. My previous laptop had a battery backup of around 5.5 hours, and I wonder if I could have gotten a lot more out of it if I had been aware of this problem.

The i3status-rust bar wiki mentions running xrandr to detect if an external monitor is connected. I’ve opened an issue on their issue tracker to add a warning about xrandr waking up the dedicated GPU.

i3 window manager setup on Debian Bullseye

In this blog, we will look at setting up i3 tiling window manager, and a status bar for i3 named i3status-rust. All of this is tested on Debian Bullseye. Some basic understanding of configuring i3 is expected.

This is part 2 in a series of 3 blogs regarding setup of Debian Bullseye on a Laptop with i3 window manager. Read part 1 here.

Continue reading “i3 window manager setup on Debian Bullseye”

Debian Bullseye setup with NVIDIA hybrid graphics

I had been using PopOS on my laptop for a couple of years, but wanted to shift back to using the i3 window manager. My laptop has the NVIDIA MX150 graphics chipset along with the inbuilt Intel GPU and the primary reason to use PopOS was to get switchable NVIDIA graphics working properly. I had trouble getting this to work back in June, 2018 but I expect it to work now with recent versions of the X.Org Server and the NVIDIA graphics driver.

To get recent versions of the Linux kernel and various packages I will be install the testing version of Debian code-named Bullseye. This may vary based on the time when you are reading this post.

Continue reading “Debian Bullseye setup with NVIDIA hybrid graphics”

Git hooks: Permission denied on a new HDD

I recently got a new Samsung 860 EVO 1TB SSD to add to my existing 128GB SSD that was filling up fast. After setting up the SSD on my machine using fstab, I started moving all my vagrant boxes and projects to a new partition dedicated to development. I mounted all the partitions under my home folder, and gave myself ownership of the respective folders.

I was ready to submit a patch to Wikimedia’s Gerrit platform. When you commit code, Gerrit runs a git commit-msg hook to add a Change-Id to every patch that is submitted for review. Committing code locally gave me the following error,

Continue reading “Git hooks: Permission denied on a new HDD”

Configuring Intel WIFI on an Asus Vivobook running Debian

I recently bought an Asus Laptop. I will be using this laptop while traveling and to work from coffee shops whenever the opportunity to do so arises.  My desktop is running Debian Stretch (Stable) but since the hardware on this laptop is fairly recent, I decided to install Debian Buster (Testing) on it. In this blog, I’ll talk about how I set up the WIFI during the OS installation and post installation.

Continue reading “Configuring Intel WIFI on an Asus Vivobook running Debian”

Updating ghost-cli process name

Imagine you’ve created your new Ghost install but have set it up with the incorrect process name. The official documentation does not tell us how to update it, it just tells us that it can be set using the --pname flag during initial installation. Let’s look at how we can update the process name after we’ve installed our site.

Continue reading “Updating ghost-cli process name”