at random times, disper -s fails; second try crashes the X server

[Teo]

I use a laptop + an external display, and I have "disper -s" and "disper -S" associated to two keyboard shortcuts.

My typical usage is
- disper -S and use only the external screen most of the time
- disper -s, then disconnect the screen and take the laptop somewhere else for a while
- reconnect the screen, then disper -S to go back to using the external screen

At random times, but very very often, when I am using the external screen,
disper -s fails.
The external screen turns off for a couple of seconds, as if disper was "trying" but failing to turn on the laptop's screen, but then the external screen turns on again and the internal screen stays off, i.e. everything goes back to the initial state.
If I try "disper -s" a second time, it crashes the X server.

Of course the very fact that the X server can _ever_ crash is a bug in the x server, but I strongly suspect there's something wrong in disper, too.

[Joe Harrington (joeharr)]

I have the same problem. When I do, it looks a lot like bug #662760.

The problem was rare, until today. Today, I put:

    disper -e -d DFP-2,DFP-3

and

    disper -s

in my dock/undock scripts. Now, it's quite reliable: neither script works, and disper does nothing even for manual use. Disper -l just lists the default resolutions:

disper -l
display default: default
 resolutions: 320x175, 320x200, 360x200, 320x240, 400x300, 416x312, 512x384, 640x350, 576x432, 640x400, 680x384, 720x400, 640x480, 720x450, 640x512, 700x525, 800x512, 840x525, 800x600, 960x540, 832x624, 960x600, 896x672, 928x696, 960x720, 1024x768, 1152x864, 1360x768, 1280x960, 1440x900, 1280x1024, 1400x1050, 1600x1024, 1680x1050, 1920x1080, 3840x1200

disper -s just returns without printing anything, even though I'm on two monitors.

disper -e -d DFP-2,DFP-3
says:
'NoneType' object has no attribute 'get_available_resolutions'

I'm on a Lenovo ThinkPad W510 with nVidia integrated graphics, running Ubuntu 11.10. When this happens, NOTHING can be done with disper at all until the next X restart, but the nvidia-settings GUI has no problems (no, I wasn't using them at the same time, I only started using the GUI after disper started to fail). It appears disper has lost track of state and can't be restored/reset (or at least, I don't know how to).

At other times, it takes two executions of the same disper command to make something happen, sometimes with messages on the first one about missing modes. This may be a different bug and I don't yet have enough information to file a report on it.

I suspect (but can't prove) that some timing issues are involved with exactly when disper gets run, e.g., maybe when it's just docked, there's a lot going on and disper catches it just as the kernel is doing some changes, and so reads an intermediate state. But this is just speculation. The reason I say it is that when disper is being run manually, from the command line, slowly, with nothing else in particular going on, it seems to do fine. But, running it before a previous disper run is done or during big system upheaval seems to trigger this problem.

Adding a "return to known state and reset everything" option would be great in disper.

Thanks,

--jh--

[Joe Harrington (joeharr)]

Sorry, I meant Bug #972895, not the one cited above. My bad. Wish I could edit my post...

--jh--