Mike Hearn wrote:
I'd not be happy with removing that - XrandR solves some problems and introduces others - namely that the desktop panel applets/icons etc rearrange themselves for the lower resolution then sometimes don't rearrange back. Using XVidmode has the advantage that the desktop size doesn't change, only the screen resolution (which is what we want) but has the disadvantage of enabling the hardware panning/sideslip stuff, which is what we don't want.
I have good luck with XRandR, and I prefer it to XVidMode, but I know some like it the other way. I think a good compromise is to leave a global setting for RandR on/off and have app-specific desktop mode settings (for now), as many people like some apps full screen and others in desktops of various shapes and sizes.
From some chatting in IRC, a possible work-around for the panning in XVidMode is to just grab the pointer if you switch to a smaller resolution and an app creates a window intended to fill the smaller resolution up. It's definitely possible to create a test case that breaks with that scheme, although I am not sure how likely that would be in real apps. The other problem is that if you use XVidMode, an application that does GetWindowRect(GetDesktopWindow(), &r) will not get the answer it expects.
As for the quirks with XRandR, that sounds like a bug in the Window manager. I think maybe the reason I have good luck with it is my KDE is so old it just ignores the events. If people are seeing desktops respond to a shrinking but not to an expanding then I think that's a bug that should be reported to the desktop people. XRandR is definitely a lot closer to what the display settings functions do on Win32.
Alex