7

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 https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/xorg-xrandr 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 03: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 03:44
  • Sure, I can do that! =) – Terrance Nov 28 '19 at 03: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 06:41
  • @Braiam The bug was reported many years ago in launchpad: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1444880 – WinEunuuchs2Unix Nov 30 '19 at 18:14
  • As explained on the wiki, if you can make a case, they may lift this package. Just reporting the bug isn't enough. You have to provide patches, go around pocking the upgrade team, etc. Reporting a bug is the first step, not the last. – Braiam Dec 05 '19 at 23:24
  • @Braiam But when you look at this bug, it takes 8 years for xrandr to fix it. After they fix it it takes another year to publish it. After they publish it Debian has to pick it up. After Debian picks it up Ubuntu has to pick it up and then it reaches my in-box. So when it comes to expediting, I have faint hopes. Besides the promised fix still isn't in 1.5.1 I compiled and gamma is still reported incorrectly as 1/gamma. But thank you for promoting the process. I've already rewritten code around the bug and put in notes to skip the bug fix when xrandr version is greater than ?.?.?. – WinEunuuchs2Unix Dec 05 '19 at 23:49

3 Answers3

11

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.

Ruslan
  • 1,733
  • 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 00: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 05: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
  • 1
    @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
  • 1
    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
  • OK all done now. Just have a manpage in $HOME/share/man/man1/xrandr.1 that I can sort out later with script when I flip versions back and forth. – WinEunuuchs2Unix Nov 30 '19 at 16:18
7

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.

user535733
  • 62,253
  • 2
    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 02:34
5

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
make
sudo make install

Then check the version:

xrandr --version
xrandr program version       1.5.1
Server reports RandR version 1.5
Terrance
  • 41,612
  • 7
  • 124
  • 183
  • I'll try this on a clone of my regular system hopefully this weekend and report back. – WinEunuuchs2Unix Nov 28 '19 at 03:48
  • @WinEunuuchs2Unix Sounds like a plan to me! =) – Terrance Nov 28 '19 at 03: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 00:11
  • @WinEunuuchs2Unix the makefile installs to /bin thats why you only tell /usr as prefix. Test it out by running a non-sudo make install with a prefix of a scratch folder somewhere – masterX244 Nov 29 '19 at 11:22
  • @WinEunuuchs2Unix The comment above this one is correct. Really, I didn't care about it overwriting the xrandr that I already had. Since the file really isn't critical it didn't matter to me, plus I didn't need to change path statements. However, I have noticed that my redshift gamma now seems correct since I have done this. =) – Terrance Nov 29 '19 at 14:30
  • I'm surprised redshift didn't know about this 9 year old bug and that xrandr --verbose reports inverse gamma so real gamma is 1/wrong gamma. I need both versions so I can test my own redshift-like app works for both types of xrandr users. – WinEunuuchs2Unix Nov 29 '19 at 18:14
  • @WinEunuuchs2Unix All I know is that since I am colorblind, the gamma since this installation seem much easier on my eyes. Hopefully your tests help you reveal what you are looking for. =) – Terrance Nov 29 '19 at 21:29
  • For colorblind you might be interested in recent script to reveal active window: https://askubuntu.com/questions/943147/different-colors-for-active-inactive-unity-window-title-bars/1189575#1189575 As far as tests go I'm going to update question to show importance of version. – WinEunuuchs2Unix Nov 30 '19 at 00:34