When xrandr 1.2 was added, the support for ctrl-alt-+/- shortcut for cycling between the available modes was dropped. This is a feature that people with low vision appreciate because it is very simple to get working, as opposed to software magnification (which btw may burn quite some CPU, while we have the more-than-efficient hardware solution above). That's also quite useful for quickly zooming a part of the screen during a conference, so that people in the back can see :) On the xorg mailing list David Dusinow said that we `should be able to do this today without bumping the protocol.', just a server patch. When dealing with several screens, the principle could be to cycle the mode of the screen which the cursor is currently in.
I disagree that this feature should be reimplemented at the x.org server level. The right thing is to leave this to desktops shells. A user may want to configure a different key combo to trigger the resolution change, and he probably expects to do it in the same place he configures the rest of the key combos. Or he may want to exclude a mode - the desktops can handle all this much better, and they may integrate it along with other types of zoom tools transparently, and they can handle multiple screens much better. The one thing that should be useful to do in X.org is to modify the existing tools to add a "next mode" and a "previous mode" command switches.
Ok that's a possible way. But not being able to switch modes with a plain X server is still a regression compared to previous versions.
If we will not reimplement this function, we can remove option "DontZoom" from xorg.conf manual.
I'd like to say I think the loss of the simple, fast means to zoom by the AKP+/- is silly and annoying. It was there, it worked, why remove it? Did it actually cause a problem, or is this just a case of "it is old and not the new hotness, so lets remove it!" If it really caused a problem then that problem should be described here so that people can understand the issue. If the distro vendor want to replace that functionality, let the distro vendor add DontZoom to xorg.conf and set up the alternative. There is a second use case that is important, still - the use case of the X server using a scan rate that is not supported by the display hardware (believe it or not some setups DON'T report valid modes) - being able to try different modes via a known key sequence sometimes is the only way to get any sort of a display up so that the problem can be troubleshot.
What in the world is that key supposed to do when you have multiple outputs connected? Do you really want that key to cycle between each of the 4 1024x768 modes that your monitor offers? It's what it did, but not what most people would have wanted out of a resolution switcher key. We offer the xrandr app to control your output modes at runtime, and an application integrated into the gnome desktop is being developed. This bug is WONTFIX imo.
How about it does what it used to do: change the rez on the monitor that contains whatever window currently has focus?
(In reply to comment #6) > How about it does what it used to do: change the rez on the monitor that > contains whatever window currently has focus? Which of the monitors that contain the window? :)
There are always going to be corner cases (i can has Gödel's completeness theorem?) but saying that because of 1% the 99% must suffer is silly. Locate the window which has input focus. Locate the upper left corner of the window. Locate the monitor that contains the window. Change that monitor. OR Locate the pointer. Locate the hot spot of the pointer. Locate the monitor containing the hot spot. Change that monitor. What percentage of people currently run multiple monitors? In the limit, what percentage of people will run multiple monitors? Or put it another way, in the limit what percentage of people will NOT be running multiple monitors, and be paying the price for omitting this because of the corner cases? ALSO: With respect to the statements that "xrandr allows you to change things, you don't need the other method" - how do I tell xrandr to change the monitor resolution WITHOUT changing the screen size and to enable automatic panning within that screen (as the old AKP+/- did). Perhaps I missed something, but when I tried --mode it changed the resolution of the desktop to match the new monitor output, which is NOT what the AKP+/- did. Sure, if there is a way to provide a similar functionality within the existing framework that's great - IF the functionality is similar.
Quoting David Hagood: > There is a second use case that is important, still > - the use case of the X server using a scan rate > that is not supported by the display hardware (believe > it or not some setups DON'T report valid modes) - being > able to try different modes via a known key sequence > sometimes is the only way to get any sort of a > display up so that the problem can be troubleshot. IMHO this is the most important - if not the only valid - use case, and in this scenario it should change the modes/resolution of the primary monitor, right?
Moving off 7.4 tracker, because it sure ain't getting done by then.
likewise, bumping to 7.6 ...
This bug has been open two and a half years, I still don't see any alternative to ctr-alt-+/-. I have found it to be a very useful feature. To answer some of the comments... Diego Calleja in comment #1 Excluding a mode is done with the "Modes" line in xorg.conf. If the desktops can theoretically do a better job that is fine, when they eventually get around to doing it we can set the DONTZOOM flag in xorg.conf. In the meantime a less than perfect but working method is better than none. Eric Anholt in comment #5 Yes, when the "Modes" line is missing all valid modes for the current monitor should be cycled through, when it is present only those listed should be used. Michel Dänzer in comment #7 If none of the monitors contain the window with focus then you have a different problem, see bug 20334. I would suggest changing the monitor(s) with the mouse pointer and if none contain it, change all of them.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/362.
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.