Description of problem: Changing the resolution of Xfce inside a VM does not persist across logons/reboots. It must be manually changed each time. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Xfce VM. 2. Logon screen at 1024x768. 3. Manually change resolution to 1440x990. 4. Logoff/reboot. 5. Log back on. 6. Resolution at original setting of 1024x768. Actual results: Resolution at original setting of 1024x768. Expected results: Resolution should change after logon to the setting of 1400x990. This is what happens in GNOME.
Switching from the QXL to the VGA driver resolved this problem. Changing component to QXL.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Reproducible for me with epel7. But I am not really sure if QXL is the right component to blame. Resetting to right package maintainer.
Joseph, what's the output of xrandr when you run it as a command in terminal inside the guest? I guess, you are using Fedora 21 as guest, does this issue also appear with Fedora 22 as guest? Please provide outputs of: $ xrandr $ rpm -q xfwm4 xorg-x11-drv-qxl
I don't know if it appears in a Fedora 22 as a guest. I don't have one setup. However, I can tell you that this isn't a problem in rawhide. These outputs are after I reset the resolution. $ xrandr: Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192 Virtual-0 connected 1440x900+0+0 0mm x 0mm 1920x1200 59.88 1920x1080 59.96 1600x1200 59.87 1680x1050 59.95 1400x1050 59.98 1280x1024 59.89 1440x900 59.89* 1280x960 59.94 1280x854 59.89 1280x800 59.81 1280x720 59.86 1152x768 59.78 1024x768 59.92 800x600 59.86 848x480 59.66 720x480 59.71 640x480 59.38 Virtual-1 disconnected Virtual-2 disconnected Virtual-3 disconnected $ rpm -q xfwm4 xorg-x11-drv-qxl xfwm4-4.10.1-4.fc21.x86_64 xorg-x11-drv-qxl-0.1.2-1.fc21.x86_64
Does it work if you enable and modify the following line in the guest system and in the file /etc/lightdm/lightdm.conf (remove the commented '#' sign at the beginning, and as root)? display-setup-script=xrandr --size 1920x1200 That workarounds the issue for me in a CentOS7 guest and was successfully tested by another user. You could also give another lesser resolution into it but be aware that QXL then is going to block all higher ones in user session, Gtk2 seems to fail here in proper interaction with Spice. See also for more information: http://www.gregfreeman.org/2012/fix-wrong-resolution-at-mdm-lightdm-login-screen-in-linux-mint-ubuntu/ https://www.mail-archive.com/spice-devel@lists.freedesktop.org/msg01074.html Maybe the patch noted via the last link is missing in the official RHEL package of QXL till Fedora 21.
I testing your workaround. Using display-setup-script=xrandr --size 1920x1200 only changes the logon screen. It does not change the user's screen once logged on.
So is the resolution setting kept in Xfce session over relogin / reboot or not, with the display-setup-script entry? Sorry, I do not understand your answer in full detail.
There are two resolution settings. 1) resolution of the logon screen, and 2) resolution of the screen once a specific user has logged on. Your workaround changes #1. The problem I am reporting is #2. Once a user logs on, the resolution is updated to reflect a user's personal resolution setting. This is what is not being preserved/saved -- the user's personal resolution setting when he goes to Settings -> Display.
The answer is not easy but simple. As already written, Xfce is mainly based on Gtk2 functionality. Spice has generally strange issues with those legacy and Gtk2 based applications, I can not tell if it works quite well with Mate (Gnome2 fork). And there's this default resolution bug in QXL (workaround exists: the xrandr call, see above). So you can not differ here within any frontend application, as the bug is deeper in the libraries with their API breakage or somewhere else. Besides that, Fedora 21 and EPEL7 both have Xfce 4.10 only. Did you try with Fedora 22 (Xfce 4.12) as well? Kevin, is it possible to patch xfwm4 or xfce4-session to do some explicit xrandr call after every user login, when it runs in kvm?
I setup a VM for Fedora 22. I confirmed this is no longer a problem in 22.
Can you try with those both upstream patches applied to xfwm4 if issue goes away? http://git.xfce.org/xfce/xfwm4/commit/?id=4f0bc3040fe676d84ce8a9b01d79de63ae6400c2 http://git.xfce.org/xfce/xfwm4/commit/?id=3f12ac8f92096ce562221622aa5ad2f45ae37006
Upstream writes that xfsettings may also be concerned with resolution changes.
Without applying the patch, the issue is now resolved. I am no longer able to reproduce it. Below is yum.log of what changed. Maybe something in here fix it? Or maybe something in here flushed/refreshed things so your previous workaround kicked in? Another thought: perhaps an SELinux policy was preventing the setting from being saved / kicking in? Anyway, since it went away and I can no longer reproduce it, I don't see a point to applying the patch. Sorry I can't be more help. Aug 18 20:00:39 Installed: kernel-core-4.1.4-100.fc21.x86_64 Aug 18 20:00:43 Installed: kernel-modules-4.1.4-100.fc21.x86_64 Aug 18 20:00:44 Updated: 1:openssl-libs-1.0.1k-12.fc21.x86_64 Aug 18 20:00:45 Updated: sendmail-8.14.9-6.fc21.x86_64 Aug 18 20:00:46 Updated: nss-3.19.3-1.0.fc21.x86_64 Aug 18 20:00:46 Updated: nss-sysinit-3.19.3-1.0.fc21.x86_64 Aug 18 20:01:03 Updated: selinux-policy-3.13.1-105.20.fc21.noarch Aug 18 20:01:03 Updated: flac-libs-1.3.1-5.fc21.x86_64 Aug 18 20:01:04 Updated: flac-1.3.1-5.fc21.x86_64 Aug 18 20:01:20 Updated: selinux-policy-targeted-3.13.1-105.20.fc21.noarch Aug 18 20:01:20 Updated: nss-tools-3.19.3-1.0.fc21.x86_64 Aug 18 20:01:26 Updated: firefox-40.0-3.fc21.x86_64 Aug 18 20:01:27 Updated: sendmail-cf-8.14.9-6.fc21.noarch Aug 18 20:01:27 Updated: 1:openssl-1.0.1k-12.fc21.x86_64 Aug 18 20:01:30 Installed: kernel-modules-extra-4.1.4-100.fc21.x86_64 Aug 18 20:01:30 Installed: kernel-4.1.4-100.fc21.x86_64 Aug 18 20:01:31 Updated: jwhois-4.0-42.fc21.x86_64 Aug 18 20:01:31 Updated: perl-Params-Validate-1.21-1.fc21.x86_64 Aug 18 20:01:31 Updated: perl-List-UtilsBy-0.10-1.fc21.noarch Aug 18 20:01:32 Updated: perl-Server-Starter-0.31-1.fc21.noarch Aug 18 20:01:33 Updated: kernel-headers-4.1.4-100.fc21.x86_64 Aug 18 20:01:33 Updated: gnutls-3.3.17-1.fc21.x86_64 Aug 18 20:01:34 Updated: pavucontrol-2.0-9.fc21.x86_64 Aug 18 20:01:34 Updated: 1:smartmontools-6.4-2.fc21.x86_64 Aug 18 20:01:35 Updated: lyx-fonts-2.1.4-1.fc21.noarch Aug 18 20:01:35 Updated: libspectre-0.2.7-6.fc21.x86_64 Aug 18 20:01:36 Updated: man-db-2.6.7.1-16.fc21.x86_64
Not sure how those packages, especially selinux-policy (and propably new kernel cause of graphics module), are involved here at all. SELinux should not fiddle around with your home folder. It's great to read that you could (magically) solve your issue. Anyways, please keep this bug open, we've to decide how to handle needed backporting of some patches from Xfce 4.12, because those resolution change is a more general mess and reproducible by other users: You can read a lot about it in the dedicated forums and people choose to use workarounds instead of some good upstream fixes what they did in the v4.12 release. The user setting for screen resolution is stored via xfconf. Can you validate the right resolution is there persistently? Though, I don't know what component is responsible to apply it to the screen after the user logs in. $ xfconf-query -c display -p Resolution $ grep Resolution ~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml
$ xfconf-query -c display -p Resolution Property "Resolution" does not exist on channel "display". $ grep Resolution ~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml <property name="Resolution" type="string" value="1440x900"/>
There is some effort to get a fix in libvirt of the host. Feel free to reopen this bug if you think we'd need some special patching in Xfce guests. *** This bug has been marked as a duplicate of bug 1240820 ***