[Pan-users] Re: Pan config question -- or not?

[Duncan]

beartooth posted <address@hidden>, excerpted
below,  on Mon, 02 May 2005 16:35:05 -0400:

> On Sun, 01 May 2005 12:20:25 -0700, Duncan wrote:
> 
>> Well, there's no question about PAN fitting on an 800x600 screen, it
>> doesn't.  It needs at least 870 width[]
>> 
>>> I haven't yet tried actually editing /etc/X11/xorg.conf, or whatever it
>>> is. But I'm not sanguine. Not sanguine at all.
> 
> I have now, and come to grief, though I eventually made it back to where I
> was. In a nutshell, trying to use an FC1 config file under FC3 (involving
> XF86 instead of xorg) really bombed; trying to edit /etc/X11/xorg.conf in
> obvious ways -- especially changing the defaultDepth spec

[META: OK, folks, I know this is now off topic for the list and way long, but
on the theory that someone else either now, or coming across this latter, will
likely benefit, I'm still posting this to the list rather than mailing it
personally.  As a regular, and given the number of folks I've helped with PAN
problems on this list over the years, I don't believe anyone can legitimately
complain /too/ much. =8^| ]

Why are you worried about default-depth? 8/15/16/24/32-bit depth shouldn't
affect your max resolution, at least for less than 1280x1024, unless your
graphics card is /way/ outdated (<4M memory, 32-128M is more common now)
 
>> The issue is the toolbar.
>
> Hmmm : VVDQ : is the toolbar that thing across the top with Post, Get,
> Reading, Filters, and Net on it? I don't use it, though I'm sure I'm
> missing a bet; I do use the group pane constantly, though.

Yes.  The one with those, and all the buttons, below the "menubar". The
idea is that you can click on the button for the function you want, with
your mouse.  Do note that I was apparently incorrect on its
inconfigurability. Torstein posted that it's configurable by hand, by
editing the config.xml file. (Back it up first, in case you mess it up, of
course.)

>> As for hacking xorg.conf, take a look at your /var/log/Xorg.0.log
>> (normal location) file.  That logs all the steps xorg takes as it
>> launches, including the bunch of resolution tests it tries and why it
>> rejects various ones.
> 
> Hmmm.... Looks a lit like the screens full of hieroglyphics it showed me
> one time when it couldn't start the X server under one of my bad
> configs. Looking at it now, I spot a line about 1280x1024 saying "hsync
> out of range" -- whatever that means ....

hsync=horizontal sync.  It's one of the vars in the monitor section of
xorg.conf (or XF86Config)...

>> What's probably happening is your monitor is reporting incorrect
>> values, so xorg decides it can't run at the higher resolutions and
>> limits you to 800x600.  Again, the log will say why it rejects
>> different modes.  What you then need to do is google your monitor and
>> find the correct values, then put them in the monitor section of
>> xorg.conf.
> 
> I had done that before trying the config edit that flopped: it is
> definitely 1280x1024.
>
> What's more, all works fine under FC1 on another machine with this in
> *its* config -- and did fine on the FC3 machine with it in its FC2
> display config file (whatever that was) afaik :
>                            =====
> Section "Screen"
>         Identifier "Screen0"
>         Device     "Videocard0"
>         Monitor    "Monitor0"
>         DefaultDepth     24
>         SubSection "Display"
>                 Depth     16
>                 Modes    "1280x1024" "1280x960" "1152x864" "1024x768"
>                 "800x600" "640x480"
>         EndSubSection
>         SubSection "Display"
>                 Depth     24
>                 Modes    "1280x1024" "1280x960" "1152x864" "1024x768"
>                 "800x600" "640x480"
>         EndSubSection
> EndSection

As I mentioned, look at the monitor section, not the screen section.  The
xorg.conf manpage has a good explanation of general functionality and what
most entries do.

The Screen section does two things.  One, it connects a monitor section,
with its monitor hardware settings, with a Device section, with its
graphics device hardware settings.  Two, for various color bit-depths, it
lists modes you wish to use, with a default bit-depth, and a default
rectangular resolution for that bit-depth (the first one listed it can
use). The other resolutions listed for a bitdepth are simply zoom levels,
normally accessed with CTRL-ALT-NUMPLUS and CTRL-ALT-NUMMINUS, altho this
can be disabled.  However, just because a resolution is listed, doesn't
mean it can be used, because xorg tests each resolution against the
settings allowed by the monitor and graphics card.  Usually, it's the
monitor that's more limiting than the graphics card, so that's usually
where your issues can be found, if you aren't getting the expected
resolutions.

>> It could also be an incorrectly detected video card or video card
>> settings.  Perhaps it is using the barebones generic VESA driver and
>> SVGA, which IIRC is 800x600.  (IRC, VGA=640x480, SVGA=800x600,
>> XVGA=1024x768...)
> 
> Could that have changed just in the course of a change of OS?? I haven't
> had the case off the machine.

Yes.  Newer versions of your OS will of course use newer versions of
xorg/xfree86.  These will very possibly have changed the way they detect
certain things.  Usually, these changes are for the better, but
occasionally, something goes wrong and the detection gets worse, until the
problem is corrected with a later release.  Also note that other things,
such as the available modules for the kernel, often affect what may be
detected correctly, as can various decisions made by your distribution on
what it includes, such as whether it includes the NVidia and ATI
proprietary graphics card drivers (common with controlled distribution
commercial/paid products) or relies on the open source versions only
(common with downloaded versions, due to the restrictions placed on
distribution by the proprietary code vendors, and with distributions that
have philosophical or legal issues with unfree code).

> I can download, but I've seldom had much luck burning CDs; the Knoppix
> CDs I have lying around somewhere are years old. Is it worth trying to
> find them?

Years old?   Probably not, but you can probably make use of your old and
working XF86Config, once you know what to borrow from it.  As I mentioned,
don't worry about the Screen section (well, save for one item, below),
just copy over the monitor section.  Then, edit the "Monitor" entry in the
Screen section to point to the Monitor section you just copied over.  (The
Identifier value of the Monitor section should match the Monitor value in
your Screen section.  You can change either to match the other.  It
doesn't matter /what/ you call it, as long as it's reasonable -- no funny
names that break the quotes, for instance, but hyphens are fine -- and the
two match.)

Here's an example Monitor section from my xorg.conf.  Do NOT copy this one
over, as using the wrong numbers can damage your monitor.  I'm just using
it as an example.

Section "Monitor"
    Identifier "ViewSonic-P220f"
    HorizSync 30-110
    VertRefresh 50-180
    DisplaySize 400 300
    Option "DPMS"
EndSection

Identifier is mandatory.  It's how you refer to the section when you match
it to a graphics card in the Screen section.  See above comments.

HorizSync is apparently the one causing you issues.  This is the range of
values (normally in kHz) that indicates the frequency your monitor is
prepared to scan horizontal lines at.  As you can see, this particular
monitor can scan a horizontal line at 30,000-110,000 times each second
(30-110 kHz).

Equally vital is the VertRefresh, giving the range for the number of times
a second the monitor can refresh the entire screen, defaulting to Hz and
here shown as 50-180 times per second.

DisplaySize is optional, but gives xorg a way to set font sizes
realistically, instead of estimating them, and often getting it wrong. 
Values are X and Y, in mm.  This is a 22" screen so the values are
probably higher than yours would be, but 400x300mm viewable area.

Option "DPMS" is again optional. (Duh!)  It tells xorg that the monitor
can handle power management.

There are other options I don't use.

What I expect you'll find, is that your newer xorg file as small values
for HorizSync, while your monitor can actually handle far higher values. 
You may find the same for VertRefresh.  You should be safe copying those
values from your old XF86Config file, or as suggested above, just copy the
whole Monitor section, and adjust the Screen section Monitor setting or
the Monitor section Identifier setting so the two match.

Alternatively, those two values should be googlable for your monitor. 
Again, the 1280x1024 value in the Screen section won't matter, if the
monitor section horizontal and vertical clock rates won't allow the
internal xorg modes for that resolution to fit.  You must have the
appropriate horizontal and vertical clock values, and put them in
manually, as for whatever reason, xorg seems to be detecting them wrong,
on your current setup.

...

As for the log file, here's an example of what I was talking about from
mine.  Again, your log file will show different stuff, but you should see
recognizably similar sections.

(II) RADEON(0): EDID data from the display on port 2-----------------------
(II) RADEON(0): Manufacturer: VSC  Model: 4004  Serial#: 16843009
(II) RADEON(0): Year: 2002  Week: 45
(II) RADEON(0): EDID Version: 1.3

EDID is the way it detects what the monitor says it can do.  Again, as I
mentioned previously, sometimes the monitor lies.  Here, you see part of
the manufacturing data, year, make, model number, serial, and the like. 

At the top of the log, it tells you what the various two-char indicators
starting each line mean.  (II) is "informational".

Skipping some lines and continuing with info from the monitor...

(II) RADEON(0): Max H-Image Size [cm]: horiz.: 40  vert.: 30

This is in cm, as it says, and matches my xorg.conf display size,
400x300mm.

(II) RADEON(0): First detailed timing is preferred mode 
(II) RADEON(0): Supported VESA Video Modes: 
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden (interlaced) (II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden
(II) RADEON(0): address@hidden

These are modes it claims to support, but not all it /can/ support.

(II) RADEON(0): Supported Future Video Modes: 
(II) RADEON(0): #0: hsize: 1600  vsize 1200  refresh: 75 vid: 20393 
(II) RADEON(0): #1: hsize: 1600  vsize 1200  refresh: 85  vid: 22953

Some more, different format...


(II) RADEON(0): Supported additional Video Mode: 
(II) RADEON(0): clock: 202.5 MHz   Image Size:  396 x 297 mm 
(II) RADEON(0): h_active: 1600  h_sync: 1664  h_sync_end 1856 h_blank_end 2160 
h_border: 0 
(II) RADEON(0): v_active: 1200  v_sync: 1201  v_sync_end 1204 v_blanking: 1250 
v_border: 0

This is AFAICT the "first detailed mode" mentioned above, therefore,
the preferred mode.  Skipping a quite a bit, here (some stuff about the
other monitor, since I have two connected).

(II) RADEON(1): Validating modes on Secondary head ---------
(II) RADEON(1): ViewSonic-P220f: Using hsync range of 30.00-110.00 kHz
(II) RADEON(1): ViewSonic-P220f: Using vrefresh range of 50.00-180.00 Hz
(II) RADEON(1): Clock range:  20.00 to 400.00 MHz

These are the settings from my xorg.conf.  It's using those rather than
the ones it detected.

(II) RADEON(1): Not using default mode "320x175" (bad mode 
clock/interlace/doublescan)
(II) RADEON(1): Not using default mode "320x200" (bad mode 
clock/interlace/doublescan)
(II) RADEON(1): Not using default mode "360x200" (bad mode 
clock/interlace/doublescan)
(II) RADEON(1): Not using default mode "320x240" (bad mode 
clock/interlace/doublescan)
(II) RADEON(1): Not using default mode "320x240" (bad mode 
clock/interlace/doublescan)

Note that xorg tests modes/resolutions that I don't even have listed in
my xorg.conf.  (Take my word for it, I didn't post my Screen section.)

Also note the two identical lines 320x240 above.  xorg has two internal
modes for this, at different clock rates, both of which failed.

(II) RADEON(1): Not using default mode "320x240" (bad mode 
clock/interlace/doublescan)
(II) RADEON(1): Not using default mode "320x240" (bad mode 
clock/interlace/doublescan)

More duplicate resolutions, again different clock rates, tho it doesn't
mention those here.

(II) RADEON(1): Not using default mode "400x300" (bad mode 
clock/interlace/doublescan)

Apparently, xorg has two different modes here as well, one that fails,
here, one that passes, as shown below.  Skipping many more similar lines...

(WW) (1792x1344,ViewSonic-P220f) mode clock 261MHz exceeds DDC maximum 230MHz

The (WW) indicates a warning.  Here, it's saying it's going to use this mode,
because it's within the parameters in xorg.conf, even tho it's outside the
parameters given by the monitor.  The monitor was a bit conservative in this
case, and from testing, I know it can do better than the numbers it says.

Note that if your xorg.conf numbers are WAY off, and you run it for more than
a few seconds for testing at a badly wrong frequency, it CAN damage your
monitor.  However, ones just a bit out of range should be safe for a few
seconds, for testing, which is how I know my monitor can do better than
the numbers it says.

Skipping a bunch more not using default mode... lines...

(--) RADEON(1): Virtual size is 2048x1536 (pitch 2048)
(**) RADEON(1): *Default mode "2048x1536": 266.9 MHz, 95.3 kHz, 60.0 Hz
(II) RADEON(1): Modeline "2048x1536"  266.95  2048 2200 2424 2800  1536 1537 
1540 1589 -hsync +vsync

The -- indicates probed values, the ** indicates values from the config file.
Here, the indicated virtual size is the largest resolution that passed
(see below).  That's also my default mode, which is the first listed
mode in the Screen section for your default depth, that passes.

Note that if you put a smaller resolution first in your list, and it
passes the xorg tests, the virtual size will be larger than the default
mode.  The screen will then pan around if you use your mouse to move to
areas not displayed, allowing you to view the entire virtual sized screen
thru the smaller viewport.  Virtual size is also an optional setting as well,
tho I don't set it, so it uses the default.  If you set a virtual size
smaller than the maximum configured and tested resolution, it will reject
the higher resolutions that would normally pass, limiting you to lower
ones.

You can also set a larger virtual size, up to the limit of the graphics card
memory, and you'll just have a bigger panning domain on which your
viewport of whatever tested and allowed resolution moves.  In the
event you do NOT get xorg working with the higher resolution, you can
at /least/ set a larger virtual size, and pan to the areas outside your
immediate display area.  The entry format is 

Virtual xdim ydim

where xdim and ydim are in pixels.  The entry should be placed in the
Display subsection of your Screen section.  Thus, you could use an entry
of Virtual 1024 768 , and pan in that domain, even if you can't get xorg
to actually give you that resolution.  You could even try 2048x1536, the
resolution I use here on my 22", but of course the larger your virtual,
the more it feels like looking thru a keyhole.  Another interesting use
is to allow panning in only one direction.  Thus, you could set
Virtual 870 600, to be used with 800x600, and be able to pan those extra
70 pixels to see all of PAN's width.

However, I find panning domains rather annoying, and prefer to keep to
real resolutions, if at all possible.

(**) RADEON(1): *Default mode "1792x1344": 261.0 MHz, 106.3 kHz, 75.0 Hz
(II) RADEON(1): Modeline "1792x1344"  261.00  1792 1888 2104 2456  1344 1345 
1348 1417 -hsync +vsync

... And it continues to list the additional valid modes, picking the highest
clock rate frequency (85 Hz over 75 Hz, for example) where two or more
modes at the same resolution validated.

......

You should now be able to interpret a bit better what your log is telling
you.  Again, note that if xorg has two possible modes for a given resolution,
one may fail and thus show up as failed in the log, while the other validates
successfully and can be used.

Also note that while my equipment is high end enough not to have a bunch
of failures for other reasons, a more typical system will have a number
of other failure reasons listed, for the various resolutions.  Your hsync
out of range is one such failure reason, pointing to the hsync entry
in your monitor section as the culprit, which is what I was guessing,
but didn't know until you mentioned the given reason.  Once again, however,
note that just because one mode at a given resolution is out of range,
doesn't mean that resolution is unavailable, if another mode passes.  You
can see the modes it accepts lower down, as in my example, above.

Finally, I should mention that it's also possible to create your own
modes -- you don't have to use the default xorg ones.  However, that's a
bit advanced for this level, so I'll not go into it, except for suggesting
that anyone interested google on Colas modeline generator.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html