I guess this is more of a question of where do I go to find out when xrandr version 1.5.1 will be published in Ubuntu? It's already available in Arch Linux and was released in August 2019. There is a bug from 2010 I want to have fixed.

Ubuntu 16.04.6 LTS current version is:

$ xrandr --version
xrandr program version       1.5.0
Server reports RandR version 1.5

I'm not well-versed on the subject but could I simply get 1.5.1 source code and compile it? Or should such a mission critical app such as xrandr never be compiled from source?

TL;DR Why it matters

Everyone can try these short little tests on their platform to see the importance of xrandr version and the gamma bug.

The current Ubuntu version has the bug that's been around for 9 years:

$ xrandr --version
xrandr program version       1.5.0
Server reports RandR version 1.5

Basic problem is xrandr reports the wrong gamma values:

$ xrandr --verbose | grep ^DP-1-1 -A5
DP-1-1 connected 3840x2160+1920+0 (0xa5) normal (normal left inverted right x axis y axis) 1600mm x 900mm
    Identifier: 0x43
    Timestamp:  538179391
    Subpixel:   unknown
    Gamma:      1.0:1.1:1.3
    Brightness: 0.63

My "redshift-like" application has set gamma to Red = 1.0, Green = .88 and Blue = .77 but RGB is incorrectly reported as 1.0:1.1:1.3. Now imaging we want to increase brightness to .65. If we don't change gamma at the same time existing settings for gamma are reset to 1:1:1. So we pass what we think are the current values:

$ xrandr --output DP-1-1 --brightness .65 --gamma 1.0:1.1:1.3

Low and behold the screen goes super bluish-greenish and kills our nighttime settings for reddish hue. When we check current settings again we find the values are inverted again:

$ xrandr --verbose | grep ^DP-1-1 -A5
DP-1-1 connected 3840x2160+1920+0 (0xa5) normal (normal left inverted right x axis y axis) 1600mm x 900mm
    Identifier: 0x43
    Timestamp:  541629314
    Subpixel:   unknown
    Gamma:      1.0:0.91:0.77
    Brightness: 0.65

So no matter what value xrandr --verbose is reporting we always have to use 1 / gamma to get real gamma on Red, Green and Blue channels. After correcting our code, we have to put in a test for version 1.5.1 to not correct our code and use the gamma values returned. Assuming the bug has been fixed in version 1.5.1 which I have yet to compile and test.

  • If you can't wait, I was able to download the source by following some of the commands from from git.archlinux.org/svntogit/packages.git/tree/trunk/… and by running wget https://xorg.freedesktop.org/archive/individual/app/xrandr-1.5.1.tar.xz{,.sig}. Then extracted the xz file, commands for Build then installed. Seemed to work fine. – Terrance Nov 28 '19 at 3:39
  • 1
    @Terrance *"If you can't wait"" ...well people have been waiting almost a decade. Why don't you post the comment as an answer perhaps with some compilation tips? – WinEunuuchs2Unix Nov 28 '19 at 3:44
  • Sure, I can do that! =) – Terrance Nov 28 '19 at 3:47
  • Report that bug in Launchpad. Include the patch and a way to reproduce. Note, this doesn't guarantee that Canonical wouldn't wait until syncing with Debian again. Read the Stable Release Update process for more information about how this could be achieved. – Braiam Nov 28 '19 at 19:17
  • Regarding your compilation problems, see the update to my answer. – Ruslan Nov 30 '19 at 6:41

Actually, unlike libXrandr.so.2, the xrandr program is far from being mission-critical. It's just an X client — an unprivileged app you could install into your home directory to avoid clobbering the system one. Here's how you could do it (as a normal, non-root user!):

cd ~/Downloads
wget https://xorg.freedesktop.org/archive/individual/app/xrandr-1.5.1.tar.xz
tar xvf xrandr-1.5.1.tar.xz
cd xrandr-1.5.1
./configure --prefix=$HOME/opt/xrandr/
make install

For the compilation to work, you have to have installed the build dependencies: namely, the following command should do it.

sudo apt build-dep x11-xserver-utils

Then you can just launch it from the install directory:

$ ~/opt/xrandr/bin/xrandr --version
xrandr program version       1.5.1
Server reports RandR version 1.5

Or you can prepend $HOME/opt/xrandr/bin to your PATH and launch it as you normally launched the system xrandr. Once you are sure it works as you need, you can replace the system /usr/bin/xrandr (maybe having backed up it), so that any other users run it by default.

If you do replace the system binary, don't forget to hold corresponding package (on Ubuntu 16.04 it's x11-xserver-utils) to prevent updates from replacing it with an (most likely) earlier version.

  • This looks very promising except I would put it in $HOME/bin and then from time to time flip the execute bit to test if the xrandr --verbose still reports gamma as 1/gamma. I can change all my scripts to test version < 1.5.1 and do 1/gamma else just use gamma. As for my mission critical reference I thought all of X had to be compiled to same version. I didn't know you could compile one small program to a different version. I'm used to all programs within an app checking they are the same version to prevent bugs. – WinEunuuchs2Unix Nov 29 '19 at 0:05
  • @WinEunuuchs2Unix $HOME/bin is not in PATH by default, so unless you had added it, this flipping of x bit won't affect what you run. As for "programs within an app", Xorg is not a single app. It's a bunch of different programs and libraries, and since version 7.0 they are even separated in dozens of packages (in ≤6.9 they were in one monolithic package) to facilitate such decoupling. – Ruslan Nov 29 '19 at 5:26
  • Thanks for the answer revision, but: sudo apt build-dep x11-xserver-utils generates an error message: E: You must put some 'source' URIs in your sources.list – WinEunuuchs2Unix Nov 30 '19 at 15:54
  • @WinEunuuchs2Unix so do put the source URIs (also make sure you have multiverse repos enabled). See this question for details. – Ruslan Nov 30 '19 at 16:06
  • All options were checked including multiverse but Source Code was not checked. Checking that and updating caches allowed build utilities to download. Thanks for the tip. – WinEunuuchs2Unix Nov 30 '19 at 16:09

Let's take a look upstream at Debian:

The relevant package is x11-xserver-utils. Here is it's Package Tracking System page.

That package is maintained by the Debian X Strike Force. Here is their mailing list archive and their QA tracker

Since you are tracking a bug, the Debian Bug Tracker page for that package is also likely to be useful.

As of this writing, the most recent Debian upload was March 2018, and Launchpad indicates that is also the version in the current Ubuntu 19.10.

So...looks like there is currently not a packaged xrandr 1.5.1 at all in either Ubuntu or Debian.

  • 1
    The bug was actually fixed by xrandr folks in 2018 but not published until 2019 in version 1.5.1. So I guess I could have saved some "gamma greif" sooner if I compiled from source. I just feel uncomfortable about compiling a mission critical app like xrandr. – WinEunuuchs2Unix Nov 28 '19 at 2:34

If you feel you can't wait you can install xrandr from source.

Download the tar.xz file.

cd /tmp
wget https://xorg.freedesktop.org/archive/individual/app/xrandr-1.5.1.tar.xz{,.sig}

Then extract and build the source

tar xvf xrandr-1.5.1.tar.xz
cd xrandr-1.5.1/
./configure --prefix=/usr
sudo make install

Then check the version:

xrandr --version
xrandr program version       1.5.1
Server reports RandR version 1.5
  • I'll try this on a clone of my regular system hopefully this weekend and report back. – WinEunuuchs2Unix Nov 28 '19 at 3:48
  • @WinEunuuchs2Unix Sounds like a plan to me! =) – Terrance Nov 28 '19 at 3:49
  • While this solves the problem of making xrandr 1.5.1 available on modern systems, it doesn't really answer the titular question of when this version will be available in new Ubuntu releases. – MechMK1 Nov 28 '19 at 14:29
  • @MechMK1 You are indeed correct, so I added just a quick comment to the beginning. =) – Terrance Nov 28 '19 at 15:22
  • I'm curious why --prefix=/usr isn't --prefix=/usr/bin instead because that's the actual location of xrandr? – WinEunuuchs2Unix Nov 29 '19 at 0:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.