disper

Bug #1076345
Comment #1

Comment 1 for bug 1076345

Revision history for this message

Joe Harrington (joeharr) wrote on 2012-11-19:

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--

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--