How to get consistent screen resolution?
Ray Parrish
crp at cmc.net
Sat Mar 14 20:11:40 UTC 2009
Chris G wrote:
> I have a system using a big TV as its screen and it doesn't always
> come up at the correct resolution. I can't see any rhyme or reason as
> to when it gets it right and when it doesn't.
>
> The 'correct' resolution is 1920x1080 but it sometimes comes up at a
> 'non-widescreen' resolution of 1600x1200 or similar.
>
> Can anyone suggest why this might be happening?
>
> The DDC detection in Xorg.0.log shows the resolution I want to use but
> it doesn't appear in the display settings applet.
>
Hello,
There is a possibility that the TV is not returning a valid EDID block,
which is a coupl of 128 KB blocks of data about the capabilities of the
display, and includes it's available refresh rates, dot clock, and other
factors involved in calculating the valid resolutions for the device.
I've recently discoverd that this is the case for my Jetway flat panel
monitor,, which is why my video resolution falls back to 800x600 if I do
not get my xorg.conf file spelled out exactly right to specify my
preferred 1024x768 resolution.
You can find out what information is being returned by installing the
read-edid package which contains the rograms get-edid nad parse-edid. To
find out what information is being returned to your xserver, run them in
a piped manner, as parse-edid converts the data returned into a human
readable format, and get-edid fetches the raw data from the EDID blocks.
Like so
get-edid | parse-edid
The data from this output will help you determine which modelines can be
added to xorg.conf, so that you can lock down the resolution being used
to the one you want. If your TV is not returning valid data then
get-edid will inform you of this fact as it did when I ran it for my
monitor.
In your /boot/grub/menu.lst file there is a setting that specifies the
"fall back" resolution to be used in the case that the xserver does not
find any valid modes specified either in the xorg.conf file, or by
polling the video card for the EDID data that it has retrieved from the
output device.
By examining the /usr/share/pyshare/bootconfig/grub.py script file,
which determines the resolution on start up I found the following
information.
"""Return the Grub vga code used, as integer.
If no code is specified in the config, 769 is returned.
Grub vga codes:
Colours 640x400 640x480 800x600 1024x768 1152x864 1280x1024
1600x1200
--------+--------------------------------------------------------------
4 bits | ? ? 770 ? ? ? ?
8 bits | 768 769 771 773 353 775 796
15 bits | ? 784 787 790 354 793 797
16 bits | ? 758 788 791 355 794 798
24 bits | ? 786 789 792 ? 795 799
32 bits | ? ? ? ? 356 ? ?
Sorry the columns do not line up so well, but the resolution codes
correspond to the video resolutions in the top line. There is a setting
in the /boot/grub/menu.lst file which specifies this value. So,
according to menu.lst the following applies. -
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below
## DO NOT UNCOMMENT THEM, Just edit them to your needs
## ## Start Default Options ##
And a ways further down from that you will find -
## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=quiet splash vga=771
Here we see the vga mode being set for the default boot option, and one
# sign marks it as being in use, instead of being a comment like the
lines with two ##'s in the AUTOMAGIC section of the menu.lst file.
Further, to apply that resolution to all kernels installed, and
specified in the menu.lst file, instead of just the default kernel, you
could change the following section of the AUTOMAGIC section, to include
the vga=nnn code setting as shown below, and you would leave out the
change to the defoptions section above, which only applies to the
default kernel in use.
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
## kopt_2_6_8=root=/dev/hdc1 ro
## kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=UUID=d87df8a8-9b0a-46c9-82ef-7c5503f46c62 ro vga=769
Note that the 769 returned by default specifies 640 x 480 at 16 bits
color depth for a resolution. I'm assuming that you could possibly
specify the resolution you want by setting this vga code to the right
number as a work around, if the VESA driver which it uses in the case of
falling back, will support that resolution as well. However, that is a
cludge, and it would be better to get the xorg.conf file properly
configured to provide the usable modelines for your hardware in the
first place.
It's best not to start blithely adding resolution modes to your
xorg.conf file, without testing them for accuracy, as I recently found
out, while attempting to add one more higher resolution to mine. I did
not do the math, and I specified an incorrect dot clock rate for the new
resolution, which caused my configuration to break, and I was back to
640 x 480 mode with my nvidia drivers disabled.
This is from my current xorg.conf file.
Horizsync 31.5-48.0
Vertrefresh 56.0 - 65.0
modeline "640x480 at 60" 25.2 640 656 752 800 480 490 492 525 -vsync -hsync
modeline "800x600 at 56" 36.0 800 824 896 1024 600 601 603 625 +hsync +vsync
modeline "800x600 at 60" 40.0 800 840 968 1056 600 601 605 628 +hsync +vsync
modeline "1024x768 at 60" 65.0 1024 1048 1184 1344 768 771 777 806
-vsync -hsync
Note that the horizontal frequency is in Hz's, the vertrefresh rate is
in KHz's, and the small numbers in each modeline, right after the values
within quote marks, are expressed in MHz's, and are the dot clock rates
to use with each resolution setting. All this information gets boiled
down in the Screen Section as follows -
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
Defaultdepth 24
SubSection "Display"
Depth 24
Virtual 1024 768
Modes "1024x768 at 60" "800x600 at 60" "800x600 at 56"
"640x480 at 60"
EndSubSection
EndSection
The depth numbers represent how many elements per pixel, are used to
render the highest color depth available on most monitors today, and are
expressed in bits per pixel. You have to multiply the horizontal
frequency times the vertical refresh rate, then multiply by the number
of bits per pixel you are using for color depth, and then finally
multiply once again by the height and width of your intended resolution
setting in pixels, to arrive at the necessary MHz's required for the dot
clock to manage to keep up with it all. That's why it goes up so much
higher, with each of the higher resolution modes shown.
To top that all off, your horizontal and vertical resolution in bits,
has to be evenly divisible by 8 or 16 to arrive at the depth in bits per
pixel value you want to use. Some companies claim a 32 bit depth, but in
reality they are padding the data with 12 bits per pixel, due to their
design methods, and are in fact only arriving at a 24 bit color depth
after all.
There is an application called xvidtune which can test new resolution
settings and also generate new modelines for the xorg.conf file from any
input data which it deems to be valid for your hardware. It first reads
in your system's information as far as it can be determined from the
hardware,, and the xorg.conf file.
Once the gui for it comes up it has sliders which you can adjust to
settings you would like to test. When you press the "Test"button after
making setting changes it will tell you if you have entered a valid
mode. It will also allow you to change video resolution on the fly with
"Next" and "Prev" buttons, and if you set the sliders to a valid setting
it can generate the modeline for that setting for you. xvidtune is
available in the repositories.
Later, Ray Parrish
--
Human reviewed index of links about the computer
http://www.rayslinks.com
Poetry from the mind of a Schizophrenic
http://www.writingsoftheschizophrenic.com/
More information about the ubuntu-users
mailing list