Bug 214539 - Under Xen paravirt framebuffer, gnome-display-properties shows bogus refresh rate
Under Xen paravirt framebuffer, gnome-display-properties shows bogus refresh ...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-07 21:35 EST by Daniel Berrange
Modified: 2008-02-26 18:40 EST (History)
3 users (show)

See Also:
Fixed In Version: F7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-26 18:40:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot of guest console (203.39 KB, image/png)
2006-11-07 21:38 EST, Daniel Berrange
no flags Details
xdpyinfo -ext XFree86-VidModeExtension (3.68 KB, text/plain)
2006-11-08 11:08 EST, Daniel Berrange
no flags Details

  None (edit)
Description Daniel Berrange 2006-11-07 21:35:46 EST
Description of problem:
When the GNOME app for adjusting display resolution is used within a Xen
paravirtualized  guest, the refresh rate is reported as -7203 HZ which is rather
odd!

Version-Release number of selected component (if applicable):
control-center-2.17.1-1.fc7

How reproducible:
Always

Steps to Reproduce:
1. Created a Xen paravirtualized guest running FC6
2. Open virt-manager
3. Connect to the guest console
4. Login to X in the guest
5. Run System -> preferences -> resolution menu
   
Actual results:
Refresh rate is -7203 HZ

Expected results:
Refresh rate is 0 HZ ? or disabled altogether ?

Additional info:
Since this is a virtual framebuffer with no real display attached, the whole
question of refresh rate is rather irrelevant. So if there is a sensible way to
detect this, I think it'd make sense to either disable the refresh rate widget,
or fix it at zero.
Comment 1 Daniel Berrange 2006-11-07 21:38:00 EST
Created attachment 140620 [details]
Screenshot of guest console
Comment 2 Daniel Berrange 2006-11-07 21:39:39 EST
It looks like xrandr  also reports the wrong refresh rate (see screenshot), so
quite possibly this bug component needs to be changed to belong to Xorg  instead.
Comment 3 Ray Strode [halfline] 2006-11-08 10:45:22 EST
Yea, looks like it.  Reassigning...
Comment 4 Daniel Berrange 2006-11-08 11:08:45 EST
Created attachment 140660 [details]
xdpyinfo -ext XFree86-VidModeExtension
Comment 5 Adam Jackson 2006-11-08 11:12:35 EST
XFree86-VidModeExtension version 2.2 opcode: 134, base error: 130
  Monitor Information:
    Vendor: , Model: 
    Num hsync: 0, Num vsync: 0

Tee hee.  Pretty sure that's not going to work well.
Comment 6 Adam Jackson 2007-05-26 14:43:28 EDT
Dan, can you retest this now?  In particular with Xorg 1.3.0.0-5 or later.  The
magic number fix we put in for making X start up properly in F7 xen should at
least make this fail in a new way.
Comment 7 Daniel Berrange 2007-05-27 13:06:06 EDT
It now reports a refresh rate of 0HZ, which sounds reasonable to me, given that
there isn't really any real refresh rate for the Xen paravirt framebuffer.
Comment 8 Chris Lalancette 2008-02-26 18:40:12 EST
Looks like this was resolved....closing out as CURRENTRELEASE

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