FC2 - Screen Resolution woes!!!
Mike A. Harris
mharris at www.linux.org.uk
Fri Jul 16 09:17:52 UTC 2004
On Thu, 15 Jul 2004, jludwig wrote:
>> is really bugging me. I have ATI RADEON 7200 card and Sun 21"
>> monitor which Sony GDM-20E20. Here is the problem...
>>
>> In the windows manager I can set my resolution to 1600x1200 at 60. It works
>> great. But when I reboot the box both during "start up" and "login screen"
>> screen goes blank. Since I set to do "auto login" I do get the desktop but
>> at 1152x864. This happens every time. I manually have to change the
>> resolution back to 1600x1200. I am lost. Please Help.
>>
>> Here is /etc/X11/xorg.conf......
>>
>> # Xorg configuration created by system-config-display
>>
>> Section "ServerLayout"
>> Identifier "single head configuration"
>> Screen 0 "Screen0" 0 0
>> InputDevice "Mouse0" "CorePointer"
>> InputDevice "Keyboard0" "CoreKeyboard"
>> EndSection
>>
>> Section "Files"
>>
>> # RgbPath is the location of the RGB database. Note, this is the name of the
>> # file minus the extension (like ".txt" or ".db"). There is normally
>> # no need to change the default.
>> # Multiple FontPath entries are allowed (they are concatenated together)
>> # By default, Red Hat 6.0 and later now use a font server independent of
>> # the X server to render fonts.
>> RgbPath "/usr/X11R6/lib/X11/rgb"
>> FontPath "unix/:7100"
>> EndSection
>>
>> Section "Module"
>> Load "dbe"
>> Load "extmod"
>> Load "fbdevhw"
>> Load "glx"
>> Load "record"
>> Load "freetype"
>> Load "type1"
>> Load "dri"
>> EndSection
>>
>> Section "InputDevice"
>>
>> # Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
>> # Option "Xleds" "1 2 3"
>> # To disable the XKEYBOARD extension, uncomment XkbDisable.
>> # Option "XkbDisable"
>> # To customise the XKB settings to suit your keyboard, modify the
>> # lines below (which are the defaults). For example, for a non-U.S.
>> # keyboard, you will probably want to use:
>> # Option "XkbModel" "pc102"
>> # If you have a US Microsoft Natural keyboard, you can use:
>> # Option "XkbModel" "microsoft"
>> #
>> # Then to change the language, change the Layout setting.
>> # For example, a german layout can be obtained with:
>> # Option "XkbLayout" "de"
>> # or:
>> # Option "XkbLayout" "de"
>> # Option "XkbVariant" "nodeadkeys"
>> #
>> # If you'd like to switch the positions of your capslock and
>> # control keys, use:
>> # Option "XkbOptions" "ctrl:swapcaps"
>> # Or if you just want both to be control, use:
>> # Option "XkbOptions" "ctrl:nocaps"
>> #
>> Identifier "Keyboard0"
>> Driver "keyboard"
>> Option "XkbModel" "pc105"
>> Option "XkbLayout" "us"
>> EndSection
>>
>> Section "InputDevice"
>> Identifier "Mouse0"
>> Driver "mouse"
>> Option "Protocol" "IMPS/2"
>> Option "Device" "/dev/input/mice"
>> Option "ZAxisMapping" "4 5"
>> Option "Emulate3Buttons" "yes"
>> EndSection
>>
>> Section "Monitor"
>> Identifier "Monitor0"
>> VendorName "Monitor Vendor"
>> ModelName "Sony GDM-20SE2T5"
>> HorizSync 30.0 - 96.0
>> VertRefresh 48.0 - 160.0
>> Option "dpms"
>> EndSection
>>
>> Section "Device"
>> Identifier "Videocard0"
>> Driver "radeon"
>> VendorName "Videocard vendor"
>> BoardName "ATI Radeon 7200"
>> EndSection
>>
>> Section "Screen"
>> Identifier "Screen0"
>> Device "Videocard0"
>> Monitor "Monitor0"
>> DefaultDepth 24
>> SubSection "Display"
>> Viewport 0 0
>> Depth 24
>> Modes "1600x1200" "1400x1050" "1280x1024" "1280x960"
>> "1152x864" "1024x768" "800x600" "640x480"
>> EndSubSection
>> EndSection
>>
>> Section "DRI"
>> Group 0
>> Mode 0666
>> EndSection
>What I don't see here is the amount of video memory available. If the
>window manager decides you don't have enough it will drop to a lower
>resolution.
Never ever put the VideoRam setting in the X server config file.
When that setting gets used, in almost all cases it is used
incorrectly and *causes* problems for the user. Every video
driver contains code to autodetect video memory, which is
automatically used, and in most of the video drivers it is
correct. In the Radeon driver it is correct 100% of the time,
and I have intentionally patched our driver to ignore the
VideoRAM option to prevent people from breaking their
configuration by overriding the amount of video memory.
The mga driver permits the VideoRAM option, because the proper
way to do memory detection for G400 is unknown. All other Matrox
hardware memory detection should work correctly for and should
never be specified by the user.
The nv driver, permits it for Nvidia RivaTNT, as it isn't known
how to detect memory on that hardware either. All other Nvidia
hardware should autodetect properly however.
The i810 driver permits this setting, but it uses it slightly
differently that most. In addition to being able to limit memory
lower than what the BIOS has configured memory for, it is capable
of increasing the amount of memory stolen from the system - *but*
this feature only works on certain systems, and not at all on
others.
Some of the remaining drivers have the odd board or two they
can't autodetect memory for also, and so the VideoRAM setting can
be used to tell the driver the real amount of Video memory on the
card - but it should only be used by experienced users who truely
know how much memory the card has on it and would bet their life
savings on the number they provide to the driver. Getting this
number wrong has one of 2 major consequences.
In the first case, you specify memory lower than what you really
have - this limits the amount of memory available and depending
on how low you go wrong, it may cause certain video modes/refresh
rates to no longer be available, or it may cause the driver to
disable DRI as there isn't enough memory for textures, or it may
cause video overlays to no longer work, or some other feature to
stop working. Generally the log file will inform about anything
being disabled and why.
In the worst case, you specify memory HIGHER than what you really
have, either because "the guy at the computer store told me this
was a 128Mb video card, but X says it's only 64Mb, so X is broken
and I'm fixing it", or for some other reason you are convinced
the video driver's video memory autodetection is wrong. In
almost 100% of bug reports received in which videoRam is being
used to override memory autodetection in this manner, the
"computer store guy" lied, or was otherwise wrong, or the person
was somehow otherwise misled into thinking they had a card with
more memory on it than it really does. A good test of how much
video memory is available, is to boot into Microsoft Windows with
the manufacturer's official Windows drivers and see how much
video memory there is. The exact procedure to do so is left as
an exercise to the reader however. ;o)
If the video driver is told there is 128Mb of memory, it WILL TRY
TO USE IT ALL. This means that if you have a 64Mb card, it will
write to memory beyond 64Mb. What happens at that point depends
on how things are wired on the card and a number of other
factors. In some cases memory address access wraps around to the
beginning of video memory, causing writes over 64Mb point to be
written to the 0Mb point, etc. That will corrupt video memory,
pixmap memory, mouse pointer memory, buffers used by the 2D
and/or 3D engines, or any other number of problems.
Another problem, is if you're using a multihead card. VideoRAM
option needs to be specified per head, and the total has to be
equal or less than the total video memory that is really
available. People usually put the real total in both places, so
the video driver thinks each head has the total amount of memory,
which of course breaks things.
When people experience these odd problems, it usually appears as
if the video card is severely broken, or the video drivers are
just totally insanely broken. Bug reports come in which are
usually quite obscure, and unless the person reviewing them
notices VideoRAM being used and being a possible culprit, a great
number of hours or days of time could potentially be wasted on a
red herring bug report.
As such, when I see people suggesting the use of VideoRAM for a
particular problem, I feel compelled to take the soapbox and
spread the truth about this evil option. ;o)
On the good side of things however, I've disabled the VideoRAM
setting on the Radeon driver, so that it is impossible to
override the driver detected memory. The driver will refuse the
setting and log a comment to the log file stating:
(II) VideoRAM override ignored, this driver autodetects RAM
While I've made the Radeon driver sane, it's slightly trickier to
disable this setting in most other drivers, as each driver seems
to have one or two ancient cards that require this parameter. As
such, I decided to leave the other drivers be when I did the
Radeon patch, with plans on labotomizing this option on the other
drivers once I had time to google around to determine what chips
in each driver really do need the option - and then to disable
the option on all chips except those that truely do need it.
Nowadays though, most hardware works fine with autodetection, so
it might be a good idea to just disable the option across the
board except on hardware we already know needs it (like RivaTNT,
G400 and a few others), and then just wait for bug reports from
people who say "the video driver detects the wrong amount of
video memory". It would be easier to troubleshoot these cases
for people, and to update the driver to permit VideoRam overrides
on chips the driver turns out to get it wrong on.
I believe this will make the drivers more robust against user
misconfiguration and will reduce the number of unnecessary bug
reports received both upstream and by us.
In the mean time however, the VideoRAM setting is not your
friend. It is there to make your life harder, and to allow
people to unintentionally and innocently break their setups.
Ignore the naysayers and repent! ;o)
</diatribe>
There, I feel better now. Please spread the knowledge of the
evils of VideoRAM around any time you hear someone suggest using
the option. Eventually it will lead to world peace.
;o)
>I would try setting for 16 bit DefaultDepth color setting.
Shouldn't make a difference, a Radeon 7200 has enough video
memory (32Mb minimum) to use the largest resoltion the card is
capable of displaying (2048x1536) at the highest color depth,
with 3D acceleration enabled. If changing the color depth does
however make a difference, there is a bug somewhere. If so,
please bugzilla it and attach the X server log file and the
config file that was used during that log file's invocation.
Thanks in advance!
More information about the Fedora-desktop-list
mailing list