Bug 969416 - RFE: add "only if bigger than window" scaling mode
RFE: add "only if bigger than window" scaling mode
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-05-31 07:40 EDT by Vojtěch Boček
Modified: 2014-01-31 09:10 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-01-31 09:10:09 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vojtěch Boček 2013-05-31 07:40:24 EDT
Description of problem:
virt-manager does not offer "only if vm is bigger than virt-manager window" scaling mode. This is useful for smaller notebooks with bigger display attached, when after moving virt-manager window betwen those displays, VM's screen is either to big for the small display, or too much stretched out on the big display, if you use "always scale" option.
It would also be useful in general - you usually don't want to stretch the VM's screen to fill yours, but you want to make it smaller, so that it can fit into the window. 

Version-Release number of selected component (if applicable):
Fedora 19
Comment 1 Cole Robinson 2014-01-30 12:53:08 EST
Upstream I just fixed the 'resize to vm' option to actually work with scaling=always. So you could set scaling=always, scale down the VM on the small monitor, move the window to the larger monitor, select view->resize to vm, the window would automatically be resized to the VM resolution with no scaling. Is that sufficient? (I don't want to have to add a new option if there's a reasonable workarund)
Comment 2 David Strauss 2014-01-30 13:57:59 EST
The problem is that a VM may change its resolution multiple times without any other intervention. This happens frequently during boot and installation, which I test frequently in VMs for things like Kickstart.
Comment 3 David Strauss 2014-01-30 13:59:16 EST
I think my last comment answers the question. The issue is retaining a maximally usable view without having to intervene.
Comment 4 Cole Robinson 2014-01-30 14:15:31 EST
The original comment seems to imply intervention to me: window is on a small monitor so VM display is scaled down, user moves window to a large monitor, resizes window manually to fit the display, doesn't want virt-manager to resize too far otherwise the image is over scaled and doesn't look nice. My suggestion is: don't manually mess with window size, just click 'resize to vm' when you want move to the larger monitor.

The only thing I can think of in that case is that when moving the scaled down window to the big monitor, you can't maximize the window or the display will be scaled up. Instead of maximizing you have to 'resize to vm'. It's less convenient but I'm fine with that trade off from a maintenance point of view.

I'm having trouble coming up with a scenario where the proposed option makes install testing any nicer. Can someone give me a step by step case of where scaling=always is sub optimal? Please start with VM startup, rough VM resolutions at each stage, rough virt-manager window size in relation to those resolutions, any host monitor or resolutions that might be relevant.
Comment 5 Kamil Páral 2014-01-31 04:31:03 EST
Vojtech reported this bug on my request. I think the answer depends on whether virt-manager will (in the new version) intelligently update the window size when guest resolution changes.

Because I really like what VirtualBox does:
1. It matches window size to guest resolution on startup.
2. It changes window size to guest resolution on every resolution change, unless it's maximized or fullscreen.
3. If you have additions installed, it changes guest resolution to match your window size.
4. It has keyboard shortcuts, which work and don't override guest shortcuts at the same time. I can use it the match window size easily, if needed.

Compared to virt-manager:
1. I have a wrong window size on every single startup. It's cased by my secondary small screen. (Reported also here, might be a gnome-shell bug: https://bugzilla.gnome.org/show_bug.cgi?id=707378 )
2. The window size is not adjusted to guest resolution on any resolution change.
3. The guest resolution is not matched to window size, even though we control our full software stack.
4. Keyboard shortcuts are not available (overriding the guest ones is not an option for me).
===> I need to dig deep in the menu (using the mouse) to match window size to guest resolution on _every_ VM startup (and I start a lot of VMs during my usual work day).

In addition, I'm forced to use scale=always, because on my 12" notebook screen (1366x768) the window with a default Fedora guest simply does not fit. Unfortunately, as a result, if I move the window to a large screen (I dock the notebook, FullHD), the contents in scaled up a lot and everything is just huge, especially when I switch into guest's VT (I do that also a lot).

So, I'm constantly shuffling with window sizes and digging deep in the menus to trigger resize-to-vm. And I'm very unhappy about this.

Having a new option scaling=if-larger would help me, because it would apply to me 12" screen (too small even when maximized), but it wouldn't apply to my large screen (I also use maximized windows there to avoid all the fuss with changing window sizes) and so I wouldn't see gigantic console letters in there.

If you don't want to implement it, but still improve the quality of life for some of us:) , I suggest:
1. Make the resize-to-vm action more accessible. Possible ways:
a) Put it into the action bar at the top of the window, next to switch-fullscreen button.
b) Implement keyboard shortcuts that don't override guest shortcuts. VirtualBox's "Host" key style is very nice.

2. Make resize-to-vm action less needed:
a) Set a correct window size on start (might not be your bug, but gtk/gnome bug, but I'm unable to debug that)
b) change guest resolution on window size change
c) or autofit window size on resolution change (and in case you can't autofit the window, because the screen is too small, automatically enable scaling)

Thanks. I'd happy to provide any details you need that I haven't covered in this reply, just tell me.
Comment 6 Kamil Páral 2014-01-31 07:07:05 EST
Another idea is to convert the resize-window menu item into an auto-resize-window checkbox. People can then enable or disable auto-rezising according to their wishes. It would solve the problem for me - I would have auto-resize-window=on and scale=always, therefore I would see a downscaled content on my 12" screen and a 100%-size content on my large screen, without the need to click on some menu item all the time.
Comment 7 Cole Robinson 2014-01-31 09:10:09 EST
Kamil, thank you for the very informative response!

I've been trying to triage all the scaling/display related virt-manager bugs over the past couple days. I came to similarish conclusions as you: that virt-manager needs a larger overhaul as to what options it provides and what its default behaviors are.

But I'm prepping for a new virt-manager release within the next couple weeks, and I'm going to put off the larger rework for a future release: experience tells me that making changes in this area always causes regressions and has weird corner cases, and there isn't enough time to shake them out upstream.

So I've filed an upstream virt-manager RFE based on your comment:


As an intermediate measure, I was just working on the auto-resize-window bit you are talking about, which is tracked here:


So the next virt-manager update will have an auto resize option available. it will be disabled by default, but you can enable it globally in Edit->Preferences or per-vm in the View->Scaling menu. Keep in mind it only works for guests with spice, spicevmc channel, and the spiceagent running inside the VM. Notably it probably won't work during anaconda or text mode.

Regardless, I don't think any final solution will end up with the 'only if bigger' scaling mode, so I'm closing this bug as wontfix. For anyone who is following this bug, please jump onto the CC list of those other reports to keep up with the coming changes.

Note You need to log in before you can comment on or make changes to this bug.