fullscreen mode a bit broken in dual-head setups

Bug #218105 reported by Michael
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kvm (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

Hi, when fullscreen (ctl-alt-f) mode needs to select a resolution different to that of the current desktop, a number of undesirable things happen:

- resolution of -both- displays get changed, not just the one intended to display kvm.
- both screens display the same thing (the left-hand half of my 2560x1024 host desktop), and neither show kvm's output (which I think has been placed somewhere within the right-hand half of the desktop).
- upon restoring from full-screen mode, both displays continue to show the left-hand half of the desktop (which is tricky as all my terminals and menus live on the right-hand display :P)

When using fullscreen and the screen resolution doesn't need to change, it's slightly better:
- both screens always display the correct part of the desktop
- KVM always uses the first display (in my setup, the right-hand one) display its output, even if it should probably be using the left-hand one.
- pressing ctl-alt to release the grab does not allow one to access the other display

normal xrandr output:
Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 2560 x 1280
TV_7PIN_DIN disconnected
DVI-I_1/digital connected 1280x1024+1280+0 376mm x 301mm
   1280x1024 60.0*+ 75.0 59.9
   1152x864 74.9
   1024x768 75.1 60.0
   800x600 75.0 60.3
   640x480 75.0 60.0
   720x400 70.1
DVI-I_1/analog disconnected
DVI-I_2/digital connected 1280x1024+0+0 376mm x 301mm
   1280x1024 60.0*+ 75.0 59.9
   1152x864 74.9
   1024x768 75.1 60.0
   800x600 75.0 60.3
   640x480 75.0 60.0
   720x400 70.1
DVI-I_2/analog disconnected

full-screen (when the guest is at 800x600):
Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 2560 x 1280
TV_7PIN_DIN disconnected
DVI-I_1/digital connected 800x600+0+0 376mm x 301mm
   1280x1024 60.0 + 75.0 59.9
   1152x864 74.9
   1024x768 75.1 60.0
   800x600 75.0* 60.3
   640x480 75.0 60.0
   720x400 70.1
DVI-I_1/analog disconnected
DVI-I_2/digital connected 800x600+0+0 376mm x 301mm
   1280x1024 60.0 + 75.0 59.9
   1152x864 74.9
   1024x768 75.1 60.0
   800x600 75.0* 60.3
   640x480 75.0 60.0
   720x400 70.1
DVI-I_2/analog disconnected

||/ Name Version Description
+++-=============================-=============================-==========================================================================
ii kvm 1:62+dfsg-0ubuntu4 Full virtualization on x86 hardware
ii x11-xserver-utils 7.3+2 X server utilities
ii xserver-xorg-video-radeonhd 1.1.0-1 X.Org X server -- AMD/ATI r5xx, r6xx display driver

Revision history for this message
Michael (miiichael) wrote :
Revision history for this message
Bryce Harrington (bryce) wrote :

Sounds like KVM needs to learn libXrandr. Similar problems exist for games, movie players, screensavers, and other such things that like to take over the full screen.

It's not an X issue per se, but that client apps often were developed either with the old Xinerama-style of multi-screen layout, or without taking multi-head configurations into account.

There are actually several different problems here...

1. Resolution of both screens changing. libXrandr provides for per-output resolution changing; if you don't specify which output, it sets all by default. So kvm probably needs more logic to keep track of outputs and which ones "belong" to kvm.

2. When kvm exits, it doesn't restore the screens to their original state. You'll need to have kvm snapshot the Xrandr layout before going full screen, and then just re-applying it when it's done. Probably will need to also hook this in for error conditions as well (or doing it all in a wrapper script).

3. Always using the first desktop. Sounds like it's using the "primary output". It's possible to redefine which is the primary output, but in this case it's almost certainly better if kvm just were smarter about which output it picks to fullscreen on. This is a common issue for most games and movie players. If nothing else, it would be nice to give the user a command line option for specifying which output to use.

4. ctrl-alt problem. No idea on this one. Maybe not an xrandr issue.

Most of the above could probably be done with the xrandr command line tool, however I suspect it will be cleaner to hook into libXrandr directly. The xrandr tool provides an example of using libXrandr, but you might find the Screen Resolution applet to be clearer - see in particular randrwrap.c in libgnome-desktop.

Also note that the latest GTK in Intrepid has some API for xrandr. If KVM needs to remain desktop-agnostic, those won't be of use of course, but could provide some interesting reference info.

You might also take a look at screensavers or movie players. Offhand, I don't know which if any have xrandr support, but they have similar needs so if there is one with xrandr support you might be able to adapt their solution for kvm.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Thanks for the in depth analysis, Bryce.

This is going to be a bit too involved to solve by Intrepid. And honestly, this will involve enough new code that the changes should really be done in conjunction with upstream. From what Bryce is saying, this will probably be a non-trivial patch that will need some heavy duty testing.

:-Dustin

Changed in kvm:
importance: Undecided → Wishlist
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.