Bug 11504 - XineramaIsActive disagrees with XineramaQueryScreens
XineramaIsActive disagrees with XineramaQueryScreens
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Server/General
7.2 (2007.02)
Other All
: medium normal
Assigned To: Keith Packard
Xorg Project Team
http://bugs.debian.org/cgi-bin/bugrep...
:
Depends on:
Blocks: xorg-7.3
  Show dependency treegraph
 
Reported: 2007-07-09 01:09 UTC by Brice Goglin
Modified: 2007-09-04 13:07 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brice Goglin 2007-07-09 01:09:15 UTC
Bug reported recently by both Emanuele Rocca and Joel Bertrand on the Debian BTS. They say:

On their sparc machine XineramaIsActive() returns True, while XineramaQueryScreens sets the number of screens to 0 and returns a NULL pointer. This bug makes gdm unusable, and lots of other applications calling Xinerama functions.

Emanuele tried the following program on sparc and i386:

  #include <stdio.h>
  #include <X11/Xlib.h>
  #include <X11/extensions/Xinerama.h>
  int main() {
    Display *disp = XOpenDisplay(NULL);
    int n_screens;
    XineramaScreenInfo *xscreens = XineramaQueryScreens (disp, &n_screens);
    printf("XineramaIsActive: %d\n", XineramaIsActive(disp));
    printf("Number of screens: %d\n", n_screens);
    if(xscreens == NULL)
      printf("XineramaQueryScreens returned a NULL pointer\n");
    else
      printf("XineramaQueryScreens returned something useful\n");
    XFree(xscreens);
    return 0;
  }

The program above prints the following on a sparc machine:
  XineramaIsActive: 1
  Number of screens: 0
  XineramaQueryScreens returned a NULL pointer

Conversely, on i386 the bug is not reproducible:
  XineramaIsActive: 1
  Number of screens: 1
  XineramaQueryScreens returned something useful

As a wild guess, I would say that the bug is caused by the server (possibly since RandR-1.2 arrived) assuming that all drivers support Xinerama while they probably don't. For instance, all sun* drivers I have looked at do not have any reference to Xinerama in their code (which makes me think XineramaIsActive should not return 1 on sparc), while the ATI driver has a RADEONProcXineramaDispatch.

It could also be related to Xserver 1.3 apparently refusing the disable the Xinerama extension.
Comment 1 Alan Coopersmith 2007-07-25 12:58:45 UTC
Drivers with functions like RADEONProcXineramaDispatch are providing their own
functions for reporting Xinerama info when using things like MergedFB and 
TwinView that Xinerama-like but not using the X server's Xinerama implementation.

Drivers shouldn't need functions like this if they can only ever output to a 
single display at once, but can be combined with other devices into a multihead
configuration using the Xserver's Xinerama implementation.

(In other words, while you seem to have found a bug, I believe the "wild guess"
 is looking in the wrong direction.)
Comment 2 Brice Goglin 2007-07-26 23:14:11 UTC
It does not look sparc-specific after all, according to Joe Pfeiffer in the same Debian bug, it occurs on i386 with the vesa driver too.

From his /var/log/syslog:

Jul 25 23:36:12 Valiant gdm[3392]: Xinerama active, but <= 0 screens?
Jul 25 23:36:32 Valiant gdm[3384]: gdm_child_action: Aborting display :0
Comment 3 Brice Goglin 2007-08-11 05:13:55 UTC
This bug might be related to this one
  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234567
which ajax fixed with
  http://cvs.fedora.redhat.com/viewcvs/rpms/xorg-x11-server/devel/xserver-1.3.0-randrama-no-zero-screens.patch?rev=1.1&view=auto

But I don't think this patch has been pushed upstream yet.
Comment 4 Brice Goglin 2007-08-12 14:09:31 UTC
Debian submitter confirms the above patch solves the problem. I am marking this bug as a blocker for 7.3 then.
Comment 5 Eric Anholt 2007-08-23 10:07:46 UTC
Keith said that the ajax fix was on the right track but not quite correct, and expressed interest in fixing it.
Comment 6 ajax at nwnk dot net 2007-08-30 10:58:53 UTC
(In reply to comment #5)
> Keith said that the ajax fix was on the right track but not quite correct, and
> expressed interest in fixing it.

It certainly seems to work for me.  What's wrong with it?
Comment 7 Eric Anholt 2007-09-04 13:07:22 UTC
cherry-picked to server-1.4-branch