Sebastian Redl posted <[EMAIL PROTECTED]>, excerpted below,
on Mon, 17 Oct 2005 14:13:27 +0200:
>>Oh... Previously I was trying to run a separate "screen" config for each
>>monitor, thus, two per card since each card has two outputs. I'm now
>>running xorg's merged framebuffer for Radeons, so it's actually possible
>>the problem will have disappeared when I actually try it again...
>>
>>
> What exactly are the effects of this, and how do I do it? I have a
> Radeon 9800 Pro with two monitors, and right now they're rather
> disjointed. I'd like them to act as one, but I don't want maximized
> windows being spread over both screens.
First, I know nothing at all about the closed ATI drivers, except that
they're closed so I won't run them, and that from what I read, they aren't
as easy to work with as Nvidia's closed drivers, which I used to use back
when I first switched from MSWormOS, because I had an NVidia card that
only ran Twinview mode with the non-free drivers. (I had the foresight to
check whether the card had Linux drivers, and that they worked with
Twinview, since I was thinking about switching, when I bought it, but
didn't yet know that there was such as thing as proprietary Linux drivers,
so naturally didn't/couldn't check whether the /free/ drivers supported
twinview, since I didn't know there was a distinction.)
Therefore, what I know is the xorg "freedomware" Radeon drivers, which
unfortunately in current versions don't support beyond 9200s in 3D
accelerated mode. Not that such would work all that well at 2048x3072
total resolution (2048x1536 x2, stacked) anyway, but...
Post 9200 has /experimental/ 3D support in the latest masked for testing
xorg-x11-6.8.99.x series, however, so you could see how that works. Note
that the 6.8.99.15-rX snapshot is the last non-modular series. The latest
snapshots are xorg-modular, which I tried installing but apparently
didn't get something merged correctly, so I went back to the 15 snapshots.
(I like testing so am running them even tho I have 9200s, which have full
support in current stable xorg.)
Anyway... I believe the 9800 is supported by the free drivers in 2D mode,
which is all that works well with multi-monitor anyway, so if that's what
you are after, you should be fine.
Here's how it works. There are multiple levels of integration choices
available to you.
>From your question, it appears you are currently running both monitors as
separate xorg "screens", without xinerama (regular or pseudo) activated.
This effectively runs two xorg mini-sessions, each on its own screen. You
can't move stuff (other than the mouse, and keyboard focus, of course)
directly between them. Each has it's own session widgets, taskbar and the
like, if whatever environment you are running uses such things.
What you want is Xinerama mode (either real or pseudo). How well it fits
what you want, in terms of controlling where windows maximize and the
like, depends on the windowing environment you run and its support for
xinerama. KDE, my X environment of choice, supports xinerama rather well,
and has options for whether applications maximize to one screen or all,
and such things as window placement (on the mouse-focused screen or
either), window movement snap-to support, etc, with each feature
individually configurable to single monitor or entire desktop area. (In
KDE 3.5 at least, yes, I'm running the betas of that too, these settings
are in the control panel under Peripherals/Display, not under
Desktop/Window-behavior, where one might otherwise look.)
Since you already have both screens running in non-xinerama mode, you've
already done the heavy work in xorg, configuring each monitor's separate
resolutions and the like. To activate xinerama (real X xinerama), simply
add the appropriate
Option "Xinerama"
line to your ServerFlags section. That should be all you need to do for
X. Other reconfiguration will be done in your window manager and X
environment of choice. If you want to discuss KDE settings, I'm up for
that, otherwise, you'll need to look elsewhere for help with that, if you
need any.
The free Radeon driver also supports merged framebuffer mode, as I
mentioned earlier. This will require a bit of additional reconfiguration
to your xorg.conf file, but you already have the data you need in your
current config, you just have to redo it a bit.
Basically, merged framebuffer uses a single instance of the driver (with
or without "PseudoXinerama" enabled) to manage the monitors connected to
both outputs of your video card, rather than using a separate instance of
the driver for each output. This means there's less overhead and things
operate a bit more efficiently. If 3D is supported by the driver on your
hardware (as I said, experimental support for post Radeon 9200s is in the
latest masked for testing xorg snapshots), you may even get full
accelerated 3D support, as long as the total resolution doesn't get too
high (I believe the maximum bounded area for merged framebuffer
accelerated 3D support is 2048x2048, so I can't run it anyway, since I run
2048x3072).
There are, however, a few drawbacks to merged framebuffer, as well.
First, merged framebuffer operates as a single screen, so regardless of
whether xinerama is on or not, you get only the one session with one set
of windowing environment widgets, etc. No dual independent mini-sessions!
Second, where xinerama isn't supported by your windowing environment,
flexibility on where things go will be limited, and windows will maximize
to the total screen (across monitors). If xinerama is supported by your
windowing environment, of course, this isn't an issue to the degree you
can configure it not to be, with the xinerama support. Third, and the
thing I personally found most irritating at first, you lose the ability to
set each monitor's resolution independently. Yes, the monitors CAN still
run at different resolutions, but rather than moving your mouse to the one
you want to set and hitting ALT-CTRL-NUMPLUS (or NUMMINUS) to cycle thru
each configured resolution on each screen independently, you have a single
set of configured resolutions for the merged framebuffer to cycle thru.
If like me you have a whole series of resolutions configured for each
monitor, listing the permutations in a single combined list very quickly
becomes unwieldly! So... with the exception of one special purpose (a
specific game) mode that's full size 2048x1536 on the top monitor and
640x400 on the bottom one, I settled for a series of equivalent
resolutions on each screen. I'll list an example below so you can see
what I mean... Combined with a variable strength image magnifier (KView),
that serves my purposes well enough, and I'm now running merged
framebuffer.
Xorg.conf changes for merged framebuffer:
The xorg.conf changes for merged framebuffer, compared to running two
separate instances of the driver, one for each output, all have to do with
the fact that instead of two separate screen configurations, one for each
monitor/graphics-card-output combo, you have only one, that has to contain
all the information from what was two different screen configs.
The way the "primary" monitor and output are configured remains exactly
the same, with the exception of the previously mentioned single
resolutions sequence, and the single-instance version of that is ignored
in merged framebuffer mode, so you don't need to comment out anything from
your current primary screen/device config. All the new settings are
additional entries.
The original secondary screen/device config info is entirely ignored in
merged framebuffer mode, since all the necessary info is added as new
entries into the primary screen config. Therefore, it too can remain.
Further, if merged framebuffer is deactivated, all the merged framebuffer
entries (save for the single activate/deactivate option) are ignored, so
can remain uncommented in the primary config.
This makes it very easy to switch between the two modes, merged
framebuffer vs separate screen configs, by switching a single "merged
framebuffer" activator entry. Here, I actually comment a few additional
entries to make clear which ones are operational and which ones aren't,
but that's not necessary. A single change is all that's needed to switch
merged framebuffer on or off and activate the appropriate entries.
Example time! Keep in mind that the documentation for all these settings
are in the radeon manpage, if they're not xorg generic in the first place,
so that's where to look if you need to figure out what a setting does or
what other options are available.
Actually, all the changes are in the primary device section. No screen
section changes necessary either!
Section "Device"
Identifier "DevAgp.0"
Driver "radeon"
Screen 0
BusID "PCI:5:0:0"
Option "BusType" "AGP"
Option "AGPMode" "4"
Option "AGPFastWrite"
Option "EnablePageFlip"
Option "MonitorLayout" "CRT, CRT"
# The above are all standard xorg device section or radeon settings,
# nothing special there! The below settings activate merged
# framebuffer and configure the second monitor
# This one's the activator switch. Without an "on" or "off"
# after the option, it's "on".
Option "MergedFB"
# Position of the second monitor. Self-evident.
Option "CRT2Position" "Above"
# These are the hardware settings for the second monitor.
# Note again that the primary monitor settings are taken
# from the normal place, the monitor section specified
# in the screen section that also specifies this device
# section.
Option "CRT2HSync" "30-110"
Option "CRT2VRefresh" "50-180"
# This is that confounded resolutions line! It's all one line, wrapped
# here for posting. See what I mean about the permutations quickly
# becoming unmanageable! If I listed each resolution against each
# resolution... Note that as listed, the resolutions on each monitor
# are equal, save for the last one. Also note the "-" connectors. A "+"
# may also be used, but has a special meaning (clone mode, IRC). Or
# a single resolution by itself may be listed. See the radeon
# manpage for more.
Option "MetaModes" "2048x1536-2048x1536 1792x1344-1792x1344
1600x1200-1600x1200 1280x960-1280x960 1152x864-1152x864
1024x768-1024x768 800x600-800x600 640x480-640x480 512x384-512x384
400x300-400x300 640x400-2048x1536"
# Since xorg will otherwise have difficulty calculating the dot-per-inch
# settings, and the fonts will likely be way big or way small, if this
# setting isn't specified... Note that this is another disadvantage of
# merged framebuffer. If your monitors are physcally different sizes or
# "normal" operating resolution is different on each, with separate
# screens, you can specify separate DPIs. Here, there's only one setting,
# so if the monitors use different ones, you gotta pick a compromise.
Option "MergedDPI" "120 120"
# This one is a specific accel deactivator, here because of the
# comment in the ebuild... I don't think it's used as I'm configured,
# because 3d accel is deactivated here anyway, due to 2048x3072, but
# I put it here anyway. The radeon manpage says what it does...
# ColorTiling off due to bug mentioned in xorg-6.8.99.15 ebuilds
Option "ColorTiling" "off"
EndSection
A couple more notes...
In the serverlayout section, I comment the second screen section
reference. I don't believe I have to do that because the Option MergedFB
should take care of it, but I've never tried it with both activated to see
which takes precedence, for sure.
PseudoXinerama... is activated automatically with mergedFB, unless turned
off either because regular xinerama is on, or specifically set off.
PseudoXinerama works almost like regular xinerama would with separate
framebuffers. Your windowing environment configurations and hooks should
apply just as they would to normal xinerama.
Thus, I have my xinerama activator line in the serverflags section
commented out, for use with mergedFB, because if it were on,
PseudoXinerama would deactivate itself.
Hope that's what you needed!
--
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@gentoo.org mailing list
