Bug 109814 - Default screen is off to the right and down
Summary: Default screen is off to the right and down
Alias: None
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-12 01:47 UTC by Need Real Name
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-01 11:23:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2003-11-12 01:47:21 UTC
Description of problem:

With the default install of Fedora Core 1 (and all previous 
versions of RedHat I have used), when it is first installed
the screen is noticeably off to the right and down (vs. a
good position for the default XP screen).

Using 4 "left clicks" and one "up click" in xvidtune produced
the following Modeline for the Monitor section of

Modeline    "1024x768"     94.50   1024 1088 1184 1376    768  773 
776  808 +hsync +vsync

Is there any way possibly to tweak future versions to bullseye
the standard XP position more closely?


Version-Release number of selected component (if applicable):

How reproducible:

Install standard Fedora Core 1

Steps to Reproduce:
Actual results:

Screen off to the left and down

Expected results:

Screen centered vs. good spot for XP

Additional info:

Comment 1 Mike A. Harris 2003-11-12 11:31:49 UTC
XFree86 video modelines are built into the XFree86 X server, and
are built using the VESA GTF standard, which is the official
standard for modelines.  These video modes will be centered properly
on CRT displays which are compliant to the VESA GTF standards.  If
your CRT is older, or not GTF compliant, then the video modes may
not be centered on your CRT.  In general this is never a problem
in any version of Microsoft Windows, because CRT monitors which
are not GTF compliant, Windows has either built into it's default
driver cabfiles manufacturer provided data for various CRT displays
which can optionally contain video modeline overrides, which are
then used only for that specific manufacturer's displays.

That type of information is highly CRT specific, and there are
very few displays out there which require customized special
video modelines.  Manufacturers do not provide this information
to XFree86 directly, and so XFree86 provides only official standard
VESA GTF modelines, as well as various standards that existed prior
to GTF.

We can not easily add modelines to the X server that apply only
to a single monitor or brand, so if modelines get added to the
default, they will be used for _all_ displays, and a custom modeline
for one CRT could very well end up being used on another CRT and
causing problems on other CRTs from being non-standard.

This is a hardware specific issue, and not a Red Hat specific issue.
You can use xvidtune to tweak your modelines to taste, or you can
place these values in your config file to have it used automatically.

If you'd like this to be added to XFree86 by default, you can
file a bug report request for enhancement in XFree86.org's bugzilla
at http://bugs.xfree86.org for them to review.  If they decide
that it is safe to add the mode by default, it will be added
to future XFree86 releases automatically.  If they refuse to add
it on technical or other grounds, then it is not something which
we would want to add to our X server by default either.

If you file this upstream to XFree86.org, feel free to paste the
URL here, if you'd like me to track the report upstream and
track their resolution.

Comment 2 Mike A. Harris 2004-09-01 11:23:09 UTC
Scanning bugs flagged "UPSTREAM" and reviewing upstream bug status.
There seems to be no upstream bug URL to track here.  This seems
to be a configuration issue to me, so closing as "NOTABUG".

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