... at least, as long as Xinerama and Xrandr are uncompatible.

And when both are disabled (whatever the reason is), the message "could" make sens, but would still be ennoying, and break Xdialogs (amongst other things). A way to disable it should be provided (I asked on several forums, nobody knows how to disable it ATM).

libX11 should only produce that when a client calls a XRandr function without
first checking if the extension is present.   The fix is to make the clients
stop doing that.

I know some gtk library functions had a bug that caused this, but without
information on what programs are triggering it, it's hard to say much beyond
"Not Our Bug".

Bug: Thunderbird 3.1.3 , Firefox 3.6.9 , Pidgin 2.7.2 , gkrellm 2.3.2 , Xdialogs 2.3.1 , Rox-Memo (Python), Rox-Filer, gmpc, xrandr (obvious, but see below), acroread, dvdrip (twice !!!), grip, gnumeric, pcb (Geda), gschem (Geda), Dia, Opera, amule, pornview

Don't print the message: Eterm , xterm, xclock, xev, wmrecord, xpdf, karbon, dillo, mplayer, qtconfig, gv, xeyes, glxgears

dhp@uranus ~ $ xrandr
Xlib:  extension "RANDR" missing on display ":0.0".
RandR extension missing
dhp@uranus ~ $

=> The message is redundant !

About PCB: it can be build for GTK, QT, TK, and Motif: i don't know which option have been used; I can test them all if it can help.

... I think this list is long enough for now. So, you say i should report against at least two dozen apps ?

The double message of xrandr itself worries me a bit ! Maybe, it should be the first one I must report; so, either I re-open and change the title of this bug, or I create a new one right now ?

Created attachment 39389 [details] [review]
xrandr patch

The attached patch should silence app/xrandr.

(In reply to comment #3)
> Bug: Thunderbird 3.1.3 , Firefox 3.6.9 , Pidgin 2.7.2 , gkrellm 2.3.2 ,
> Xdialogs 2.3.1 , Rox-Memo (Python), Rox-Filer, gmpc, xrandr (obvious, but see
> below), acroread, dvdrip (twice !!!), grip, gnumeric, pcb (Geda), gschem
> (Geda), Dia, Opera, amule, pornview
> 
> ... I think this list is long enough for now. So, you say i should report
> against at least two dozen apps ?

I don't know all those apps, but many of the ones I recognize are
apps using the gtk/gnome libraries, so that may be the common place
where the bug occurs.

Technically, the message is lying, since it doesn't even come from
libX11, but libXext:
http://cgit.freedesktop.org/xorg/lib/libXext/tree/src/extutil.c#n245

As you can see, the message comes from XMissingExtension() so by displaying
remotely to an old Solaris X server without randr support, I can see that 
current gnome apps trigger this:

env DISPLAY=x10s:0 /usr/bin/gnome-help
Xlib:  extension "RANDR" missing on display "x10s:0.0".

So I ran it under gdb and set "break XMissingExtension":

Breakpoint 1, 0xfc01ea7d in XMissingExtension () from /usr/lib/libXext.so.0
(gdb) where
#0  0xfc01ea7d in XMissingExtension () from /usr/lib/libXext.so.0
#1  0xfaf52341 in XRRSelectInput () from /usr/lib/libXrandr.so.2
#2  0xfcbb022e in _gdk_x11_screen_new () from /usr/lib/libgdk-x11-2.0.so.0
#3  0xfcb97a6d in gdk_display_open () from /usr/lib/libgdk-x11-2.0.so.0
#4  0xfcb62fb7 in gdk_display_open_default_libgtk_only ()
   from /usr/lib/libgdk-x11-2.0.so.0
#5  0xfbd806ed in post_parse_hook ()
   from /usr/lib/firefox/../libgtk-x11-2.0.so.0
#6  0xfc526dd0 in g_option_context_parse () from /usr/lib/libglib-2.0.so.0
#7  0x08073ffa in main ()

Digging through the gtk/gdk code at git.gnome.org, it appears this comes from:
http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkscreen-x11.c#n1052 which
always calls XRRSelectInput and should instead verify first that Randr is
present, similar to the xrandr patch that Julien posted in the previous comment.
One bug against gtk should resolve the problem in a number of apps.

(In reply to comment #4)
> Created an attachment (id=39389) [details]
> xrandr patch
> 
> The attached patch should silence app/xrandr.

Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Tested-by: Alan Coopersmith <alan.coopersmith@oracle.com>

(As with previous comment, tested by remote display to old Solaris Xsun
 server without any RANDR support.)

Before patch:

% env DISPLAY=x10s:0 ./xrandr
Xlib:  extension "RANDR" missing on display "x10s:0".
RandR extension missing

After patch:

%  env DISPLAY=x10s:0 ./xrandr
RandR extension missing

> --- Comment #6 from Alan Coopersmith <alan.coopersmith@oracle.com> 2010-10-12 15:31:30 PDT ---
> Before patch:
> 
> % env DISPLAY=x10s:0 ./xrandr
> Xlib:  extension "RANDR" missing on display "x10s:0".
> RandR extension missing
> 
> After patch:
> 
> %  env DISPLAY=x10s:0 ./xrandr
> RandR extension missing
> 
Thanks, pushed.

I am surprised you proposed a patch fix a not-bug ...

Still, there obvisouly is a bug to be fixed: in comment 5, Alan demonstrated the message is wrong, and should not mention Xlib, but LibXext ...

And I agree with the fact that many apps could be fixed at GTK level; ie, fixing GTK may fixed at least half of the ones I mentionned. But I do not know how to proove it, and, how to report the bug to the GTK team. If i don't bring proofs, they may also answer me "not our bug" ... 

X is the top level team.

(In reply to comment #8)
> And I agree with the fact that many apps could be fixed at GTK level; ie,
> fixing GTK may fixed at least half of the ones I mentionned. But I do not know
> how to proove it, and, how to report the bug to the GTK team. If i don't bring
> proofs, they may also answer me "not our bug" ... 
> 
Alan gave you a pointer to gtk's buggy code.  What more do you want to prove?

=> http://bugs.gentoo.org/show_bug.cgi?id=341323

> --- Comment #10 from DEMAINE Benoit-Pierre <benoit@demaine.info> 2010-10-16 10:26:55 PDT ---
> => http://bugs.gentoo.org/show_bug.cgi?id=341323
> 
the end of your comment there makes no sense to me.  getting rid of this
message is mostly cosmetic, it's not a real issue.

It does affect behaviour of several applications, and can break some features.

In the particular case of Xdialogs, the calling script need to consider both stdout and stderr, for various reasons. Having "garbage" on any of them interfeers with the normal behaviour of calling script. Thus, breaks it.

We can not expect script writers to always imagine which mistake could have been done in the applications they are calling, or in the deps of those apps. We would have to contact all script writers in the world. Several millions.

So, yes, technically, you say the issue is in how the apps are calling libxext. So, you expect me to contact all apps using libxext, and contact several thouthands upstream authors.

Or, you can fix this in libxext ... so that only one person fixes it. Unless you can proove me removing the message from libxext could cause other bugs (which I could easily believe).

I think one person once called libxext the bad way, and for a stupid reason, every one copied that same bit of source.

Either an app needs xrandr, and this message should end up in app crash, or it does not need xrandr, and testing if xrandr is in is useless.

I would not have taken time to report 3 bugs, if it was not boring me since 3 years, AND breaking several of my 8y old scripts (and not just Xdialogs: I monitor the output of everything: having messages in stderr means ... the app had a critical issue ... and I care about this )

This is the way X11 has worked for over 20 years - you're asking us to
make the library silently work incorrectly instead of notifying the 
developer/user that they've made a call that can't possibly work.
I really doubt there's thousands of applications with this bug in the 
application - as noted above, the gtk toolkit has a bug, which affects
many applications, but that's one library to report a bug against and fix.

It's not even clear whether you're asking us to special case the RANDR
extension or suppress all missing extension warnings from all extensions.

Alan, thanks for the analysis - filed a bug for gdk:
https://bugzilla.gnome.org/show_bug.cgi?id=645856