Bug 1093998 - Gtk2 [e.g. via Xfce] resolution not preserved across logon/reboot
Summary: Gtk2 [e.g. via Xfce] resolution not preserved across logon/reboot
Status: CLOSED DUPLICATE of bug 1240820
Alias: None
Product: Fedora
Classification: Fedora
Component: xfce4-settings
Version: 21
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-05-04 07:53 UTC by Joseph D. Wagner
Modified: 2015-08-28 13:04 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-08-28 13:04:51 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1060226 0 unspecified CLOSED RFE: Rework console scaling/resizing to work more like virtualbox 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1240820 0 unspecified CLOSED VMs default to 1920x1200 resolution, can cause GNOME start to fail due to lack of VRAM 2021-02-22 00:41:40 UTC
Xfce 7511 0 None None None Never
Xfce 10625 0 None None None Never

Internal Links: 1060226 1240820

Description Joseph D. Wagner 2014-05-04 07:53:11 UTC
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:

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.

Comment 1 Joseph D. Wagner 2014-05-07 21:46:20 UTC
Switching from the QXL to the VGA driver resolved this problem.  Changing component to QXL.

Comment 2 Jaroslav Reznik 2015-03-03 15:45:33 UTC
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:

Comment 3 Raphael Groner 2015-08-15 08:22:46 UTC
Reproducible for me with epel7. But I am not really sure if QXL is the right component to blame.

Resetting to right package maintainer.

Comment 4 Raphael Groner 2015-08-17 15:07:35 UTC
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

Comment 5 Joseph D. Wagner 2015-08-19 03:00:12 UTC
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


Comment 6 Raphael Groner 2015-08-19 06:39:54 UTC
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:

Maybe the patch noted via the last link is missing in the official RHEL package of QXL till Fedora 21.

Comment 7 Joseph D. Wagner 2015-08-20 04:06:18 UTC
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.

Comment 8 Raphael Groner 2015-08-20 06:08:21 UTC
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.

Comment 9 Joseph D. Wagner 2015-08-20 15:42:47 UTC
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.

Comment 10 Raphael Groner 2015-08-20 21:20:43 UTC
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?

Comment 11 Joseph D. Wagner 2015-08-21 17:04:35 UTC
I setup a VM for Fedora 22. I confirmed this is no longer a problem in 22.

Comment 12 Raphael Groner 2015-08-21 18:26:05 UTC
Can you try with those both upstream patches applied to xfwm4 if issue goes away?



Comment 13 Raphael Groner 2015-08-21 19:13:53 UTC
Upstream writes that xfsettings may also be concerned with resolution changes.

Comment 14 Joseph D. Wagner 2015-08-22 23:20:21 UTC
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-

Comment 15 Raphael Groner 2015-08-23 19:37:52 UTC
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

Comment 16 Joseph D. Wagner 2015-08-23 23:49:25 UTC
$ 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"/>

Comment 17 Raphael Groner 2015-08-28 13:04:51 UTC
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 ***

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