Xlib: extension "RANDR" missing on display ":0.0" while using -nvidia with Xinerama turned on

Try disabling Xinerama in your configuration file. I had a similar problem and it turned out that Xinerama was causing the RANDR extension to be missing even though the Xorg logs reported that the extension was loaded.

I still have to figure out a way to have both Xinerama and RANDR working.

I also added the following section to my xorg.conf file, but I doubt that it's needed:

Section "Extensions"
 Option "Composite" "Enable"
 Option "RANDR" "Enable"
EndSection

I had the same issue and turning off xinerama as suggested above worked... I dont use xinerama (only twin-view) and I think it must have been enabled by the gui configurator or the nvidia-settings tool somehow,,,

Indeed, turning off Xinerama seems to have done the trick (I'm using TwinView so that I can get compiz working anyhow), but I think that it's a problem that needs to be fixed.

Probably just a bug in the nvidia driver, and nothing we can do about it. Read the nvidia documentation on how you can use xrandr.

The message : Xlib: extension "RANDR" missing on display ":0.0". appeared many times when upgrading from Ubuntu 8.04 to 8.10 and also after the upgrade when launching an application through the terminal.

The issue was solved by disabling Xinerama in the xorg.conf file. Not a problem for me as I currently use only one screen. This also solved some big performance issues when watching tv with my dvb-t tuner.

I don't think this issue is related to the nvidia driver because I have an Ati Mobility radeon X600. I run the last proprietary driver (fglrx 8.543 shipped with Ubuntu 8.10).

Same problem here - every time I launch a GUI window, I receive the same message

Xlib: extension "RANDR" missing on display ":0.0".

This is using Xinerama and an NVIDIA card with the latest nvidia restricted driver (version 177).

xorg.conf attached.

I have the same problem, when I am using xinerama. Also after eanbling xinerama, Xorg process uses a lot of CPU when opening some programs like firerox, and its slowing down the system.
I hope there is some solution for that, because I needed xinerama to work with 2 screens.

I have also the same problem. I'm using the vesa driver for my matrox g550, since I can't make mga work. This has worked fine until I updated to intrepid. Now I can't use dual screen and I receive the message
Xlib: extension "RANDR" missing on display ":0.0"
from several applications. So far I have noticed the problem when trying to use tex text in inkscape (I get the error message but it works again, after installing pstoedit) and when trying to use gnome-display-properties (doesn't start)

Looks like Nvidia will soon have closed source support for RandR 1.2

http://www.phoronix.com/scan.php?page=news_item&px=NjkwMw

I have the same problem here. Unfortunately, a few applications don't just write the "missing on display" error message, but actually crash:

$ gedit
Xlib: extension "RANDR" missing on display ":1.0".
The program 'gedit' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 398 error_code 11 request_code 78 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

I don't know how I can make these programs work without RANDR.

Same Probleme here, using two nvidia cards and three monitors so i kinda need xinerama

Ubuntu 9.10 Kernel 2.6.31-20-generic

cat /var/log/Xorg.0.log |grep RandR
(==) RandR enabled
(==) RandR enabled
(==) RandR enabled

gedit, and other gui applications will result in
Xlib: extension "RANDR" missing on display ":0.0".
+ compiz will not work

Attached my Xorg.conf

this problem had definitely nothing to do with nvidia since people with intel and ati graphics card have the same problem.
I allowed myself to change the status from invalid to to confirmed - this bug has been out there now for 2.5 years and people are still having the problem. I'm also switching the package from linux-restricted-modules to libxrandr - but I'm not sure whether this is really the correct package.
How can we help to further debug / fix this problem?

> How can we help to further debug / fix this problem?

First, identify which source package produces the error message. I did a quick grep through libxrandr, libx11, gtk+2.0 and xorg-server but did not see it. Perhaps you'll have more luck locating what produces the error.

Then, reassign this bug to that package. libxrandr really is not the right package for this; it's just an API wrapper around the RANDR extension.

Regarding the assertion that it affects -intel and -ati... citation needed. I've done heavy testing on -ati and -intel and have *never* seen this error message. So I think before this can be claimed as a general issue, the specific steps to reproduce on other drivers needs to be defined. Meanwhile, until someone can prove otherwise, I'm bumping this back to the -nvidia queue.

> Regarding the assertion that it affects -intel and -ati... citation
> needed. I've done heavy testing on -ati and -intel and
> have *never* seen this error message.

I just tested this again on my macbook (intel graphics) and thinkpad R51 (ati radeon).
I'm attaching the Xorg.0.log files.

I get the same error message again while trying to start gedit:

Xlib: extension "RANDR" missing on display ":1.0".
The program 'gedit' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 104 error_code 11 request_code 78 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

and here is the Xorg.0.log file from the thinkpad R51. I'm trying to get Xdmx working between this computer and the previously attached macbook with the following command:

#!/bin/bash
startx /usr/bin/gnome-terminal -- \
/usr/bin/X11/Xdmx :1 \
-configfile xdmx.conf \
-config quad_config \
-ignorebadfontpaths \
+xinerama \
-input :0

$ more xdmx.conf
virtual quad_config {
  display "thinkpad-andreas-wlan:0" @0x0;
  display ":0" @1280x0;
}

here's the xdmx log file for the previously attached xorg log files.

The error message:

'The program 'gedit' received an X Window System error.
This probably reflects a bug in the program.'

comes from the libgdk-x11-2.0.so.0 file:

$ grep 'received an X Window System error' -R *
Binary file libgdk-x11-2.0.so.0 matches

the package is: libgtk2.0-0

haven't found the package yet that's causing the 'Xlib: extension "RANDR" missing on display ":0.0".' error.

hopefully is the the correct package.

One part of this bug is WontFix - Xinerama disables RANDR. Xinerama has been deprecated upstream, so this isn't likely to change.

The second part of the bug - where some apps crash when the RANDR extension isn't available - is where efforts should be directed. You should be able to get a useful backtrace by installing the gtk dbgsym packages, then running “gdb gedit | tee gedit.log” and, at the gdb prompt, typing
"""
set pagination 0
break gdk_x_error
(say “yes”)
run --sync
(gedit starts, then crashes)
thread apply all bt full
(lots of backtrace text is produced)
quit
"""
and then attaching the “gedit.log” file to this bug.

hm xorg log still states (==) RandR enabled with xinerama enabled

gedit.log as requested by Chris Halse Rogers

I need Xinerama and don't care about RandR.

So what about shutting this error up? Why is it outputted to stdout instead of syslog anyway? Thoroughly annoying.

I also _need_ Xinerama to use three screens properly and i also don't care about RandR and it IS enabled anyway so whats up with that ?

And yes promting the error to stdout is pretty much pain in the a. How can we fix that bug ?

http://en.wikipedia.org/wiki/Xinerama#Deprecation_of_XINERAMA

I think we should focus first on getting this bug fixed with xinerama turned OFF.

I am using using Ubuntu 10.04 LTS with a dual core AMD and Nvidia Video card

desktop:~$ /usr/games/sol
Xlib: extension "RANDR" missing on display ":0.0".
The program 'sol' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 483 error_code 8 request_code 152 minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
desktop:~$

I am using a NVIDIA card with the latest nvidia restricted driver with two screens. I so I guess I am using Xinerama

So I go run System - Preferences - Monitors and I get:
Could not get screen information
RANDR extension is not present

If I run:
desktop:~$ cat /var/log/Xorg.0.log |grep RandR
(==) RandR enabled
(==) RandR enabled

I'm also affected, not so much the issue of annoying error messages each time an X app is launched but rather that some apps just don't start, e.g.
$ gnome-system-monitor
Xlib: extension "RANDR" missing on display ":0.0".

I need Xinerama because of dual head display with one screen rotated

I'm using Lucid
Linux mendel 2.6.32-37-generic #81-Ubuntu SMP Fri Dec 2 20:32:42 UTC 2011 x86_64 GNU/Linux
HW NVIDIA Corporation Quadro FX 580
SW NVIDIA prop driver version current

Note that Xinerama does not appear to be in the process of being deprecated. The wikipedia article was modified a year ago, describing the old words as "full of lies": <http://en.wikipedia.org/w/index.php?title=Xinerama&diff=421530795&oldid=415820495>. Nothing on x.org seems to lead to deprecation. Instead, issues like conflicting with compositing have been fixed.

I think the fundamental flaw here is in how XRANDR and Xinerama interact in the X server. Enabling Xinerama shouldn't disable the XRANDR extension protocol. It should instead allow all of the read-only operations (allowing `xrandr -q` to work); and return errors for attempts to actually *change* things which would conflict with Xinerama.

All of which is, obviously, upstream work. Both Xinerama and XRANDR would need some work, plus -nvidia to stop forcibly disabling XRANDR when Xinerama is active.

I'm using Xinerama to make one large T-shaped virtual display out of two 1920x1200 monitors, one landscape and one portrait. I've read stuff which implies it might be possible to do this with some melange of XRANDR + -nvidia TwinView + "Virtual" in the "Screen" section, "Display" subsection -- see <http://thinkwiki.org/wiki/Xorg_RandR_1.2> -- but I didn't get anything but a frustrated headache from my attempts.

Same thing here, however I had only one program that crash : xsane

xsane hpaio:/net/Officejet_J6400_series?ip=192.168.0.12
Xlib: extension "RANDR" missing on display ":0".
The program 'xsane' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 3124 error_code 8 request_code 151 minor_code 5)

OpenSuse 12.1, KDE3 + XINERAMA + nvidia drivers.

Bug affects me pretty often when using a dual monitor setup to edit text.

kris@knix1 ~/Desktop $ cat /etc/*-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=10
DISTRIB_CODENAME=julia
DISTRIB_DESCRIPTION="Linux Mint 10 Julia"

I think it's related to something being mounted within a different context. For example, if I switch to my secondary monitor and start using nautilus with an SFTP mount it will auto-mount that. When I try to use it again later it will give me the XRANDR missing problems. Doesn't seem to happen if I stay diligent about making mounts on the correct Xorg context.