[gentoo-amd64] Re: some xorg related questions

[Duncan]

Neil Stone posted <43C61400.7080904@×××××××××××.com>, excerpted below,  on
Thu, 12 Jan 2006 08:32:00 +0000:

> 1. All of my fonts have gone small.. whats up with that, I know I have
> updated a few things, but (afaik) nothing that would cause this to happen

The subject is xorg related questions, then mention updating some things,
but don't mention whether xorg was among them.  If so, then definitely,
yes, that could cause your fonts to change size.  Even if not, it could be
related to xorg, or more precisely, to the lack of a specific setting in
xorg.conf.

The problem is this.  xorg can't always reliably tell how physically big
your display is, in relatiion to the pixel-resolution.  Put another way,
xorg doesn't always reliably know the correct dots (pixels) per inch
setting. 

What dots per inch (dpi), therefore, how big a particular font point-size
actually looks on-screen, can be affected by a number of things.  xorg
itself has some sort of default that from my experience often changes from
version to version.  Some desktop environments have their own setting, as
well.  In particular, gnome-settings-daemon enforces its own version of
what it thinks is correct.  Therefore, if it's substantially off from the
X default and from anything else trying to set dots per pixel, if it's
running, you'll get one size, while you'll get an entirely DIFFERENT size
if it's not.  From my experience, gnome-settings-daemon tends to be more
accurate, and not change as wildly, as X by itself.   This used to be a
problem for me because I run KDE as my default desktop, but would
occasionally run something from Gnome that would trigger
gnome-settings-daemon, and everything started while it was running would
have an entirely DIFFERENT font-size then everything started either before
it, or after it was terminated.

The solution I found to all this is to tell X the proper dpi setting, so
it doesn't have to guess.  Because gnome-settings-daemon seems to be
decently accurate in any case, it then tends to agree with the X settings,
and things quit changing on me.  How many other applications potentially
mess with that setting, or whether setting it correctly in xorg.conf
solves it for all of them, I don't know, but it solved the problem in both
instantiations  (gsd and X version changes) for me.

Let me pull up my xorg.conf and find the setting...

OK, it depends on your setup.  Ordinarily (single screen/monitor or with a
separate device and screen section for each monitor), the setting is in/as:

Section "Monitor"
    DisplaySize 400 300

DisplaySize is in mm, x, y, so the above entry is for a 400x300 mm screen,
which is about a 21 or 22 inch monitor.  (I'm running two, a 21" and a
22", but on regular CRTs, a 22" monitor is rather less than an inch larger
than a 21", in actual display area.  Apparently, a 22" has more
"unviewable" area than a 21".  Anyway, since they are so close, I run the
same 400x300 setting for both.) xorg does the math, since it knows the
resolution you are running. As it happens, 400x300mm @ 1600x1200
resolution is real close to 100 dpi square. 400x300mm @ 2048x1536 is 120
dpi.

Note that xorg ships by default with 75 and 100 dpi bitmapped fonts. Thus,
100 dpi is a "natural" no-conversion setting for it, when using the 100
dpi fonts.  If you prefer larger font settings, you could run that same
400x300mm monitor at 1280x920, which is close enough to 75 dpi to use
that.  (Note that the common 1280x1024 is a 5x4 ratio, not the standard
4x3, so that will result in rectangular pixels, slightly shorter than they
are wide.  Likewise, I have an old game that uses 640x400 resolution,
which results in pixels slightly taller than they are wide, 640x480 would
be standard 4x3 ratio square pixels at that resolutiion.)

If you are running a Radeon dual-output in merged frame-buffer mode
(using the free xorg drivers, not slaveryware), as I am, the setting is
different. There's a single setting for both monitors, since it's a single
framebuffer, so if they aren't close to the same physical size (assuming
one is running them at the same resolution), fonts will simply be smaller
on the smaller monitor. In this case, the setting is actually in dpi
rather than in size, and occurs in/as:

Section "Device"
    Option "MergedDPI" "100 100"

That's the X and Y dots per inch setting.  From the above, discussion, you
can see that corresponds to running the same 400x300mm monitors @
1600x1200 resolution each.  I have them stacked, for a 1600x2400 pixel
viewport.  (As mentioned above, I used to run them @ 2048x1536, for a
2048x3072 viewport, 120 dpi, but decided the 1600x1200 each, 1600x2400
total, was more practical.)


> 2. xfs - I can't suss out how to get this installed... and wouw it help
> the above situ ?

It shouldn't help the above, no, as it's the dpi setting that determines
size, regardless of how the fonts are served.

I'm running xfs here, altho I've debated turning it off and letting X
handle its own fonts.  You don't say what your problem is, but if it's
simply a matter of not knowing what package the xfs binary is in...

In monolithic xorg (pre 7.0-modular), xfs is part of the xorg package,
with its compilation controlled by the font-server USE flag.

With modular-xorg (7.0 on), xfs is a separate package, x11-apps/xfs, along
with all the other separate packages making up modular-xorg.

> 3. TwinView.... I saw a few posts of people using this, and I would like
> to have a go... can someone point me at a document that would provide me
> recent, revevant information on being able to use multiple monitors in
> xorg ?

TwinView is an NVidia Trademark, referring to dual monitor mode with their
proprietary/slaveryware drivers.  I used to run it, back when I first
switched to Linux, as I had known enough to investigate whether my card
had Linux drivers but didn't realize there /was/ such a thing as Linux
proprietaryware/slaveryware drivers, at the time I purchased the card, and
NVidia doesn't release enough information for the free nv driver to do
dual video output mode.  That's why I'm running an ATI Radeon 9250, now --
that's the closest thing to a modern card that has fully functional Free
drivers.

Anyway, if you are running NVidia hardware and NVidia's slaveryware
drivers, their README does a pretty good job of explaining how to run dual
monitors, and what your options are for doing so.

If you are running a dual output Radeon 7000 thru 9250, you are in luck,
as that's what I run now.  The info is available in the xorg.conf and
radeon manpages, and/or I can explain your options and the necessary
settings, for both separate framebuffers, and merged framebuffer mode.
(Lest there be any confusion, "framebuffer" in this case does *NOT* refer
to the framebuffer driver in the kernel, but rather, to the memory space
to which the pixels are actually drawn.)

Other hardware often also supports either multiple cards or multiple
outputs per card, or both, and there's individual manpages for most brands
giving the brand dependent details.  Do note, however, if you plan to run
multiple cards, that not all cards work together.  Choosing an appropriate
dual-output card is most likely to work, altho I don't believe the free nv
drivers support it so if  it's an NVidia card, you'll have to run the
slaveryware drivers to do that.  Whether that's an issue or not for you, I
can't say, but it'd be a show stopper, here.

In any case, you'll want to enable the xinerama USE flag for support in
various apps.  Whether you actually want to run xorg's xinerama itself, or
the xinerama emulation most merged framebuffer type solutions offer,
depends to a large extent on what your hardware offers and personal
preference.  The Free Radeon drivers even support accelerated OpenGL on
dual monitors, in merged framebuffer mode up to 2048x2048 combined
resolution, and I believe NVidia's slaveryware drivers have similar 3D
support with TwinView.

-- 
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


-- 
gentoo-amd64@g.o mailing list