| Summary: | XineramaIsActive disagrees with XineramaQueryScreens | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Brice Goglin <brice.goglin> |
| Component: | Server/General | Assignee: | Keith Packard <keithp> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | ema |
| Version: | 7.2 (2007.02) | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432256 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 8888 | ||
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.) 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 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. Debian submitter confirms the above patch solves the problem. I am marking this bug as a blocker for 7.3 then. Keith said that the ajax fix was on the right track but not quite correct, and expressed interest in fixing it. (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? cherry-picked to server-1.4-branch |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.