New motherboard – Arch Linux tweaks and tips

So, I changed out my motherboard to an Asus B550-I ( https://rog.asus.com/motherboards/rog-strix/rog-strix-b550-i-gaming-model/ ), so this page will serve to document some of the tweaks I have done to get it working on Arch Linux.

Audio

The motherboard comes with an ALC1220 chip. It was necessary to add options snd-hda-intel model=dual-codecs to /etc/modprobe.d/alsa.conf to get the soundcard working.

I have also noticed that hotplugging a headset still does not work, the headset does not get detected as an audio sink. So I either have to log out of gnome, and re-login to reload the modules, or do the following for the headset to get detected if it is not permanently plugged in:

rmmod -f snd_hda_intel
rmmod -f snd_intel_dspcfg
modprobe snd_hda_intel

Now, with recent kernel updates, I only need to disable powersaving to get the hotplug support working. I added the following two lines in /etc/modprobe.d/alsa.conf :

options snd_hda_intel power_save=0
options snd_hda_intel power_save_controller=N

Sensors

The motherboard comes with a Nuvoton nct6798 chip. The chip was picked up by sensors-detect, but I had to add acpi_enforce_resources=lax to my kernel boot options for the sensors output to work.

More to come…

As I get more features working with this motherboard, I will revise this post.

Advertisement

Hotplug support for eGPU on Linux

As noted previously, I have an eGPU set up with my laptop. Today I figured out how to successfully unplug it without the system freezing up.

Initially, I was quite confused as to why I was unable to just unplug the eGPU. It works on Windows after all. It turns out that a Thunderbolt disconnection (at least with my fully updated Arch Linux) does not gracefully remove the PCI devices from the system. Everything that was relying on the eGPU and any other peripherals in the eGPU box, such as the wired ethernet, fail horribly. Threads lock up waiting for a reply to arrive on the PCI bus, but nothing does.

So the fix is really quite simple. Use the pcihp module’s functionality to gracefully remove the entire Thunderbolt chain from the PCI tables before unplugging the cable. This is easiest done by echoing “1” to the “remove” file present in the lowest-numbered thunderbolt PCI-device. (Note: Dependent on your system, this might not be a clever idea if you happen to have more than one Thunderbolt port… It might be worth removing the attached devices instead. Check your lspci output first.)

I wrote up a little script to automate this:

#!/bin/bash

secs=5
tbt_chain=/sys/bus/pci/devices/0000:01:00.0

echo "Unplug eGPU script started."
if [ "$(id -u)" != "0" ]; then
	echo "Please run using sudo. Exiting."
	exit 1
fi
if [ -e $tbt_chain/remove ]
then
	echo 1 > $tbt_chain/remove
	echo "Thunderbolt chain removed from PCI tree. Please unplug eGPU now."
	while [ $secs -gt 0 ]; do
   		echo -ne "$secs to rescan...\033[0K\r"
   		sleep 1
   		: $((secs--))
	done
	echo 1 > /sys/bus/pci/rescan
	echo "Rescanned the PCI bus. Completed."
	exit 0
else
	echo "eGPU does not appear to be attached. Exiting."
	exit 1
fi

Six-way comparison of my eGPU setup

I like thin and light notebooks. But I also like having the graphics horsepower available when at my desk to play the occasional game. In the last few months, external GPUs connected by Thunderbolt 3 are starting to appear, and I was lucky enough to get my hands on a PowerColor Devil Box. And unlucky enough to experience an initial incompatibility between the Devil Box and my laptop, a recent Kaby Lake Dell XPS 13 (9360).

Luckily though, I have received a firmware update for the Devil Box, which allows compatibility with my laptop, so I thought I would finally do some testing of the setup.

System:

Laptop: Dell XPS 13 9360
CPU: i7-7500U
RAM: 8GB
internal GPU: Intel HD graphics 620

eGPU enclosure: PowerColor Devil Box
eGPU: Sapphire AMD Radeon RX470 4GB

Now, I use Arch Linux as my daily driver, and I’m pleased to report that the eGPU is detected, and can be used to render any application by simply setting the environment variable DRI_PRIME=1 (when using Wayland). The only issue I’ve had with Linux is that the system doesn’t really like when unplugging the eGPU while running, so I have to turn the laptop off before unplugging. I might investigate this some other day, but it is no big deal, since the eGPU can be connected while the computer is running with no issues.

Anyway, on to the benchmarks. I am running Unigine Heaven on Extreme settings, and rendering on the laptops internal screen:

Quality:       Ultra
Tesselation:   Extreme
Anti-aliasing: x8
Fullscreen:    no
Resolution:    1600x900

The scores were:

OS          (API)      eGPU   iGPU
Windows 10  (DX11)     1322    211
Windows 10  (OpenGL)   1230    199
Arch Linux  (OpenGL)    816    146

So what can we gather from this? Firstly, Linux OpenGL drivers are not as good as Windows OpenGL drivers. Secondly, DirectX 11 performs better than OpenGL. Finally, an eGPU is a compelling upgrade in my case.

So what’s left? Well, I’ve ordered a replacement fan for the front of the Devil Box. I was so tired of the constant high-RPM spinning, that I have unplugged both fans. But this leads to the PSU fan spinning up when under load, and the little fan on the PSU is very loud (although with quite a pleasant smooth sound). I hope a lower RPM and better fan in the front of the Devil Box will prevent this. Also, I need to investigate ways of improving the Linux experience: fix the problems when unplugging, and work out how to change the fan profile of the card when running in Linux.

Updating my website

I spent some time today updating my website to function as an extension of my CV. For just over a year now, I’ve had a website hosted on my own machine located in my parents’ garage, but I decided that I would try and improve the look of the website a bit.

I wanted something simple, just handcrafted HTML with good code legibility, but at the same time responsive and modern. I found a few CSS templates and guides that helped me achieve the look I wanted: Modern and responsive, with gorgeously large images, that scroll behind the text.

I kept all my writings and uploaded files in place, and transferred the text partially from my old website, and partially from my CV. The website is easy to maintain, and simple to read, and I got the chance to show some of my favourite photos as background images as well.

All in all, I’m pleased with the result. What do you think? See for yourself:

www.jpamills.dk

By the way, Safari on iPhone posed a bit of a problem. The images were not at all displaying correctly, in that they were stretched too tall, with each pixel being truly gigantic. I had to put in a small fix in my CSS, inspired by the solution on this page.

The problem was, that the iPhone was not understanding the CSS directive

background-size: cover;

So, I had to introduce a fix. To make it work, I had to sacrifice the nice parallax effect where the image scrolls behind the text, but Chrome on Android was already falling back to static images, so I didn’t mind iPhone doing the same. Suffice to say, the following worked, where I set background-attacment to scroll (thus giving up hope of the nice parallax effect), and hardcode the height of the image container, and thus also the image to a set value.

/* fix for the iphone */
@media (min-device-width : 320px) and (max-device-width : 568px)  {
section.module.parallax {
background-attachment: scroll;
height: 320px;
}
section.module.parallax h1 {
line-height: 320px;
}
}

GPG and Enigmail

Recently, I decided to set up a setup to send and receive encrypted email. It was remarkably easy using Arch Linux. GPG was already installed, so I installed Crypter to give me a nice GUI to set up my keys. I then installed Enigmail into Thunderbird, went through the setup, and was done within 10 minutes. Most of this was actually waiting for the random number generator to seed the key generation. Continue reading “GPG and Enigmail”

Long exposures in Nordhavn

Feeling bored, I went for a bike ride out to Nordhavn. It’s quite an interesting place, with cottage industries, harbour facilities, and quite a bit of new redevelopment. And it made for quite a few good long-exposure shots.

Looking across the harbour channel to the other side. This was a bit of a zoom, and the wind was gusty, so camera must have moved a bit.
Looking across the harbour channel to the other side. This was a bit of a zoom, and the wind was gusty, so camera must have moved a bit.

The cranes, the frost on the ground, and the bright light make for an interesting contrast.
The cranes, the frost on the ground, and the bright light make for an interesting contrast.

Svanemølleværket in the background. Marina and modern developments centreground. My bike foreground.
Svanemølleværket in the background. Marina and modern developments centreground. My bike foreground.

Svanemølleværket. When this picture appeared on my camera screen after the 15 second processing time, I whooped out into the night.
Svanemølleværket. When this picture appeared on my camera screen after the 15 second processing time, I whooped out into the night.

Taking pictures of the moon: tricking my camera to choose a short shutter time

So yesterday night the moon was quite pretty and bright. So I thought I would take a picture of it.

IMG_4480

IMG_4481

IMG_4483

IMG_4484

All these photos are cropped from the maximum 8x zoom of my Canon PowerShot A4000 IS.

Now if any of you own this camera you know that you can’t manually change the shutter time. So when photographing the moon, it will choose a much too long shutter time, and the moon will just be a white disk. But I managed to do it in a clever little way anyway. Process outlined below:

  • Select Program mode
  • Zoom in to full extent
  • Set 2 second self timer (important!)
  • Set ISO to 100
  • Set exposure to -2
  • Point camera at your smartphone screen displaying a white image at full brigthness
  • Half press shutter – voila, exposure time 1/200
  • Keep shutter button half pressed and move camera to point at moon
  • Press shutter all the way to take a nice picture.

The bit about the self-timer turns out to be important. Because otherwise the camera continually readjusts the exposure time, making this trick fail. Anyway, I think this was a clever little method.

Some of the pictures are at 1/60 as well. And with different exposure levels. But all in all, a big improvement over bright white disks.