ex_fs_resize crashes only when running it on my second display (nvidia cards) on Ubuntu 10.10.

It looks like s->xrandr_outputs[1] is bogus.

Program received signal SIGSEGV, Segmentation fault.
0x00000000004f1cbd in _al_xsys_xrandr_get_display_offset (s=0x75d6e0, 
    adapter=1, x=0x7fffffffe11c, y=0x7fffffffe118)
    at /home/matthew/src/5.0/src/x/xfullscreen.c:394
394	      XRRCrtcInfo *crtc_info = XRRGetCrtcInfo(s->x11display, s->xrandr_res, s->xrandr_outputs[adapter]->crtc);
(gdb) bt
#0  0x00000000004f1cbd in _al_xsys_xrandr_get_display_offset (s=0x75d6e0, 
    adapter=1, x=0x7fffffffe11c, y=0x7fffffffe118)
    at /home/matthew/src/5.0/src/x/xfullscreen.c:394
#1  0x00000000004f373d in _al_xglx_get_display_offset (s=0x75d6e0, adapter=1, 
    x=0x7fffffffe11c, y=0x7fffffffe118)
    at /home/matthew/src/5.0/src/x/xfullscreen.c:1004
#2  0x00000000004eecc4 in xdpy_create_display (w=640, h=480)
    at /home/matthew/src/5.0/src/x/xdisplay.c:352
#3  0x0000000000457bb7 in al_create_display (w=640, h=480)
    at /home/matthew/src/5.0/src/display.c:47
#4  0x000000000042baa4 in main (argc=1, argv=0x7fffffffe308)
    at /home/matthew/src/5.0/examples/ex_fs_resize.c:118
(gdb) p s
$1 = (ALLEGRO_SYSTEM_XGLX *) 0x75d6e0
(gdb) p s->x11display
$2 = (Display *) 0x73f8d0
(gdb) p s->xrandr_outputs[0]
$4 = (XRROutputInfo *) 0x7fffe40231a0
(gdb) p s->xrandr_outputs[1]
$5 = (XRROutputInfo *) 0x2c
(gdb) p s->xrandr_outputs[1]->crtc
Cannot access memory at address 0x34
(gdb) 

Also, when running it on the primary display, the secondary display sometimes gets goofed up. The second display is 1/4th its size, and crammed in the lower left of the screen. But the mouse still acts like the display is its proper size.

Don't trust anything to work properly with the nvidia binary driver and TwinView. It's version of XRandR is a complete and total hack, and does not support changing the modes of individual monitors separately. What it does instead, is switch to a separate BigDesktop mode that happens to match the resolutions you're asking for. And if you don't happen to have them setup, well too bad, you don't get any. It also doesn't have separate outputs. Only one single output. Its annoying, but hey thats what you're stuck with.

Probably should fix the crash though. I'll look into it in a bit. I assume you're using TwinView?

I don't know what's running... It's just the default Ubuntu setup with the NVIDIA drivers.

I have two physical graphics cards, each with one monitor. Each display is separate (cannot drag windows from one to the other).

(Edit: For what it's worth, ex_dualies claims I only have a single adapter and won't let me run it.)

(Edit 2: ex_monitorinfo says one adapter... The modes it lists depends on the display I run it from.)

Ah, you're also using dual X Screen mode. Something I almost never bother testing. I can't imagine most people would happily use a system setup like that.

There is only one in dual screen mode. But it changes depending on the screen you're on as your second edit hints at.

X is fun.

Now if you want a temporary fix, use TwinView, or enable Xinerama (fake or real).

Shouldn't these facts be listed in the equivalent of allegro.txt or whatever? So further questions along these lines could be answered with RTFM.

The ones about how X behaves probably. Though is it really our job to document X?

But at the very least the bug should get fixed.

That's understandable and not surprising. But it seems that Allegro sees two adapters in ex_fs_resize, as the crash involves adapter #1 in what I assume is a 0 based array.

For what it's worth, I like it because a) it gives me less attitude than other setups I've tried and b) I can effectively disable the second screen by just turning off the monitor.

Perhaps the principle of least surprise wouldn't be too much to ask. Just the common gotchas. Just look at all the warnings about "Windows will do this..." in programming docs.

I'll take a look at it in a bit. I just hate rejiging my desktop's config. Such a pain.

Even tried just enabling real Xinerama? It increases video/Xorg memory use a bit (anything stored for one screen is stored again for the other as well, since the two screens are completely separate and have their own frame buffer), at least with separate physical adapters, not entirely sure thats the case when its one adapter, and two screens...

Given A5's age, we're not even aware of most of them yet

No. I'm not really trying to do anything other than verify that the example programs all work. So for that, I might as well just use a different configuration than what most people may be testing with.

Regarding documentation, it would probably be sufficient to add something to al_get_num_video_adapters that just says something about what setup is required under Linux for it to report multiple adapters.

Windows and (I assume) OS X are probably more consistent in there only being one way that multiple displays are handled.

Makes sense. At the very least Xinerama, or XRandR support of some kind is needed.

X is fun that way. There are 4 ways to get multiple screens with X. Three of which we try to support.

1. Separate X server connections (not going to attempt this, mesa apparently doesn't even like this anyhow so it's not likely to work well)
2. Separate X Screen's (the one we've had the most issues with so far)
3. Xinerama
3a. Real Xinerama
3b. Fake Xinerama (on TwinView or whatever the fglrx driver does)
4. XRandR

XRandR is where everything is heading, except the binary blob drivers.

append:

I've managed to fix that crash, and ex_fs_resize seems to work fine now with a separate X screen setup. I'm attaching the patch, its a fairly large change just to fix a small bug, so I'm not sure its something should go into 5.0.0 or not. I have yet to test the code in Xinerama or TwinView, but I'll do that asap.

I would like you (Matthew) to test this code on your box, see if it works. Especially in ex_dualies where, on my machine, it seems to hang, and not show the window for one of the monitors.. Not sure whats going on there.

append2: I see another bug, woo.

append3: I fixed the bug in ex_dualies. and that other bug. I think its ready. Attached at x-fs-separate-screens-2.patch

append4: some basic testing on my part shows no regressions, and a few problems in xf86vm, xinerama, and plain x screen mode are fixed.

It reports two adapters now, and the initial crash is fixed.

However, the behavior is still buggy. There are no crashes, but the screens get messed up, and aren't restored properly upon the program exit.

It's hard to describe all the glitches, but basically every full screen does something to my primary display that renders it useless.

Running ex_fs_resize on the second display seems to correct any garbled condition (on second display) on exit. But no luck with the first.

Yeah, I noticed that, but I'm not sure what to do about it. We're trying to restore the modes when windows close. So it may just be that the XF86vm extension is broken and has been for quite some time (it actually is, some drivers don't bother to make it work properly, not sure if thats the case for the nvidia module).

I'll try and do some more testing today, see if maybe some reset is just not getting run.

Can you give me your allegro.log from running ex_fs_resize? I want to see which mode its running in for you.

I attached two logs, one for each display. When running on the second display, it exits fine. But when running on the first display (fs_resize0.log), it does not.

For what it's worth, in both cases, the GNOME panels at the top and bottom of the screen are still present over top the Allegro screen while the program is running.

Update: I've been playing around with it remotely so I can easily kill X and restart. One very strange thing is that if there are no open windows, then ex_fs_resize does not work. But if I have at least one window open then it does.

Disabling compiz gets rid of the toolbar-on-top problem, but otherwise it seems to act the same way.

I have a new patch for you. It applies on the same version of 5.0 you applied that last patch on. I haven't updated my checkout yet. Just "svn revert" and then apply this patch.

I've only tested it under "multi head" xrandr mode, which seems to be the one you're testing out. I'll be testing xinerama, and pure xrandr latter tonight.

I do not see any modes not being reset, or toolbars hovering over the window, but I had to switch to xfce4, due to kde4 really sucking in multi-head X mode (its horribly broken, almost no one runs in this mode, so things often don't work, but allegro seems to now! \o/).

Please test, get back to me asap

It seems to run the same as the second patch.

• ex_fs_resize works at least once per monitor, but after subsequent times, it eventually stops working. I don't know if there's any additional on-exit routines that could help out with that. Log files didn't seem to show anything useful. When it errs out, the X process hits 99% CPU usage.

  
  

• ex_dualies doesn't ever work.

  
  

• ex_fs_windowed works fine.

So there's no crashes, but the behavior is still buggy.

But occasionally, X will lock up after being idle for a while (mouse freezes, 99% usage)... So while I generally don't think it's wise to pass the blame around elsewhere, it could simply be something that just isn't reliable.

I see none of those issues with ex_fs_resize on my system. It always properly sets the mode back. No crashes, no hanging processes, nothing.

I did not try ex_dualies, but I see no reason why it shouldn't work as well as ex_fs_resize.

I think maybe your driver or X is just hosed.

Can you tell me more about your system? Which driver version, which X version, which gnome version etc? Is it running in a VM etc?

append:

Been testing with compiz, and the only thing I can think is compiz is horribly broken. It likes to either ignore xrandr events, or get them spectacularly wrong. It is nothing allegro is doing wrong as far as I can tell.

I've fixed the panel on top bug, but when allegro sets the mode back, compiz seems to scale the desktop down to like 1/4 to 1/8th of the total screen size. The mode IS set back properly, compiz is just crap.

I can confirm however that ex_dualies is completely broken. looking into it.

Don't have the numbers off hand, but it's a generic Ubuntu 10.10 setup with two NVIDIA cards with compiz enabled.

I noticed that more with the second patch, I think. With the latest patch, it seems to just lock up on running one of those examples after a few tries.

Is each display on a separate card? Or are both displays on one of the cards? I've been testing the latter.. Not that there should be that much difference between the two.

ex_dualies hangs in/durring glXCreateNewContext. I assume multi-head X plus glX is just broken at this point. I have heard people say that Mesa/glX doesn't like two separate DISPLAY's and that might extend to multi-head mode, and any glX implementation.

It works fine without compositing, with one window. But the moment you try and create a second window with a glX context on another screen, things go belly up.

append:

I wonder if I shouldn't just blacklist multi-head mode. So you can only create windows on one "adapter", the second you try to use more than one, bail...

Each card has one monitor.

I think for the pending 5.0 release, it makes sense to do that if there are known problems.

Yeah, and the code I added is mostly required just to get proper display listing in multi-head mode, so its all needed anyhow. At least the work didn't go completely wasted.

Now what to do about compiz being braindead...

append:

There is nothing I can do about compiz being a pile of crap. Right now, I can't manage to find a combination of WM hints that make it behave with ex_dualies, so I just quit trying to fix it. Metacity, kwin and icewm all seems to work ok though.

I'd like anyone willing to try, to try this new patch. Got a bunch of shiny new code.

About the only problem I've noticed with it in pure XRandR mode is the mouse behavior with ex_dualies, and that it currently isn't locking mouse movement to allegro displays anymore (not sure how to fix that at the moment, maybe add a A5 api call to grab/ungrab the mouse to a specific adapter). I'm working on fixing the "gap" between screens in multi-mon when modes are set. Its one of the main reasons for the rewrite of the xrandr code.

Try dragging ex_display_options's window from one monitor to another for an extra bonus (make sure to press up or down afterwards to see it).

append2: I've now applied the new code and changes to the Allegro 5.1 svn branch. It should get merged to 5.0, and released with 5.0.0-rc5, or 5.0.0 depending on Peter's preference.