Using relatively new hardware on Linux systems can prove to be challenging. Last year, I ran into several challenges when I decided to use an MSI Gaming laptop as a development machine while I was backpacking around the world. Now that I’m in one place again, I’ve run into similar challenges when trying to get my LG 31MU97C-B 4k monitor working at its optimal resolution in Linux. The following guide shows the modelines that must be added via the
xrandr command in order to have this monitor function at 4096x2160 at 60Hz.
The 4k/UHD standard for video is a bit confusing. Typically, an Ultra High Definition (UHD) TV or computer monitor has a native resolution of 3840x2160 pixels. These are often misbranded as 4k displays, even though true 4k is double the height/width of a standard 1080p display, coming to 4096x2160 pixels. Most displays cheap out on these extra pixels since, due to aspect ratios used in TV and cinema, the 3840x2160 resolution allows for most content to either fit within the viewable area or scale evenly without adding black bars.
Viewing content at 4096x2160 at a refresh rate higher than 30Hz requires either HDMI2 or Display Port 1.2. HDMI2 still hasn’t found its way to a lot of consumer video cards (more common on nVidia cards than AMD) and the LG 31MU97 doesn’t support HDMI2 anyway. I’m using an ATI/AMD Radeon 7800, which supports Display Port 1.2. I’m also using the open source
radeon drivers. When running the
xrandr command, the full 4096x2160 mode isn’t even displayed:
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384 DisplayPort-0 disconnected (normal left inverted right x axis y axis) DisplayPort-1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 621mm x 341mm 3840x2160 60.00*+ 30.00 1920x1080 60.00 59.94 1600x900 60.00 1280x1024 60.02 1152x864 59.97 1280x720 60.00 59.94 1024x768 60.00 800x600 60.32 720x480 60.00 59.94 640x480 60.00 59.94 HDMI-0 disconnected (normal left inverted right x axis y axis) DVI-0 disconnected (normal left inverted right x axis y axis) DVI-1 disconnected (normal left inverted right x axis y axis)
I found some forum posts that used commands such as
gtf in order to create the correct modeline for this resolution. Unfortunately, I couldn’t get any modelines generated by those tools to work correctly. I finally found a forum post by lordmocha that explained that the closed source AMD/ATI drivers did establish the correct modelines for this particular monitor. Using the information from the post1, I was able to create the correct modeline using
xrandr --newmode "4096x2160_60" 556.730 4096 4104 4136 4176 2160 2208 2216 2222 +hsync +vsync xrandr --newmode "4096x2160_50" 526.170 4096 4632 4696 4736 2160 2208 2216 2222 +hsync +vsync
In the above example, I added a mode for both 60Hz and a fall-back to 50Hz, with both horizontal and vertical sync enabled. I’ve also tested the same modes with both hsync and vsync disabled and they work as well (although you’ll get a warning pop-up on the monitor’s on screen display). You can create additional modes with different names (e.g.
"4096x2160_60nosync") if you want to switch between turning synchronization on or off on the fly. If you play games on Linux, disabling the vertical sync can sometimes help if you experience input lag issues, at the expense in increased screen tearing.
Next, the modes need to be added to the video card’s Display Port which can be done with the following commands. These may need to be adjusted depending on the port the monitor is connected to.
xrandr --addmode DisplayPort-1 4096x2160_50 xrandr --addmode DisplayPort-1 4096x2160_60
If you have another display connected, you can easily test this new mode without risk of locking yourself out of your machine by running your
xrandr commands from the second screen. If you don’t have a second display and you end up with a blank screen on the mode switch, you can remotely connect from another machine via SSH to restart the X server, or possible switch to a console virtual terminal (typically Ctrl+Alt+F1). You can also use the following command to attempt the mode switch, wait fifteen seconds, and then switch back.
xrandr -s "4096x2160_60"; sleep 15; xrandr --output DisplayPort-1 --mode 3840x2160 --auto
If everything goes smoothly,
xrandr should now indicate the display is running using the custom mode at a 60Hz refresh rate.
Screen 0: minimum 320 x 200, current 4096 x 2160, maximum 16384 x 16384 DisplayPort-0 disconnected (normal left inverted right x axis y axis) DisplayPort-1 connected 4096x2160+0+0 (normal left inverted right x axis y axis) 621mm x 341mm 3840x2160 60.00 + 30.00 1920x1080 60.00 59.94 1600x900 60.00 1280x1024 60.02 1152x864 59.97 1280x720 60.00 59.94 1024x768 60.00 800x600 60.32 720x480 60.00 59.94 640x480 60.00 59.94 4096x2160_50 50.00 4096x2160_60 60.00* HDMI-0 disconnected (normal left inverted right x axis y axis) DVI-0 disconnected (normal left inverted right x axis y axis) DVI-1 disconnected (normal left inverted right x axis y axis)
I use the i3 window manager. To persist these changes across reboots, I add the above commands to an initialization script that i3 runs when it starts. Most desktop environments offer a way to run commands at startup, and you should simply be able to put the above commands in a script and add it to the list of startup items.
You can also add the modes to
/etc/X11/xorg.conf. Because Xorg is pretty good at auto detecting hardware these days, most Linux distributions don’t even create an
xorg.conf file. It can be added manually in the case where automatic configuration doesn’t work. By adding the correct modes directly to the Xorg configuration, the graphical display will be at 4096x2160, even at the login screen. I didn’t bother going this route myself, but there’s plenty of existing documentation on the
xorg.conf that can be searched for.
Being an early adopter for technology in the Linux world can lend itself to some headaches. It probably doesn’t help that I use Gentoo, a distribution that’s geared more towards developers and people in the tech industry. (If I had used Ubuntu with the official ATI/AMD drivers, I make have been able to run at the correct resolution “out of the box”.) Still, even though it takes me a little longer to get some things running, I gaining an understanding of how the underlying technology works. Contributing back to the open source community also means that in the future, other people will be able to plug in peripherals and they simply “just work.”