1 |
Sebastian Redl posted <43539567.9080803@×××××××××××.at>, excerpted below, |
2 |
on Mon, 17 Oct 2005 14:13:27 +0200: |
3 |
|
4 |
>>Oh... Previously I was trying to run a separate "screen" config for each |
5 |
>>monitor, thus, two per card since each card has two outputs. I'm now |
6 |
>>running xorg's merged framebuffer for Radeons, so it's actually possible |
7 |
>>the problem will have disappeared when I actually try it again... |
8 |
>> |
9 |
>> |
10 |
> What exactly are the effects of this, and how do I do it? I have a |
11 |
> Radeon 9800 Pro with two monitors, and right now they're rather |
12 |
> disjointed. I'd like them to act as one, but I don't want maximized |
13 |
> windows being spread over both screens. |
14 |
|
15 |
First, I know nothing at all about the closed ATI drivers, except that |
16 |
they're closed so I won't run them, and that from what I read, they aren't |
17 |
as easy to work with as Nvidia's closed drivers, which I used to use back |
18 |
when I first switched from MSWormOS, because I had an NVidia card that |
19 |
only ran Twinview mode with the non-free drivers. (I had the foresight to |
20 |
check whether the card had Linux drivers, and that they worked with |
21 |
Twinview, since I was thinking about switching, when I bought it, but |
22 |
didn't yet know that there was such as thing as proprietary Linux drivers, |
23 |
so naturally didn't/couldn't check whether the /free/ drivers supported |
24 |
twinview, since I didn't know there was a distinction.) |
25 |
|
26 |
Therefore, what I know is the xorg "freedomware" Radeon drivers, which |
27 |
unfortunately in current versions don't support beyond 9200s in 3D |
28 |
accelerated mode. Not that such would work all that well at 2048x3072 |
29 |
total resolution (2048x1536 x2, stacked) anyway, but... |
30 |
|
31 |
Post 9200 has /experimental/ 3D support in the latest masked for testing |
32 |
xorg-x11-6.8.99.x series, however, so you could see how that works. Note |
33 |
that the 6.8.99.15-rX snapshot is the last non-modular series. The latest |
34 |
snapshots are xorg-modular, which I tried installing but apparently |
35 |
didn't get something merged correctly, so I went back to the 15 snapshots. |
36 |
(I like testing so am running them even tho I have 9200s, which have full |
37 |
support in current stable xorg.) |
38 |
|
39 |
Anyway... I believe the 9800 is supported by the free drivers in 2D mode, |
40 |
which is all that works well with multi-monitor anyway, so if that's what |
41 |
you are after, you should be fine. |
42 |
|
43 |
Here's how it works. There are multiple levels of integration choices |
44 |
available to you. |
45 |
|
46 |
>From your question, it appears you are currently running both monitors as |
47 |
separate xorg "screens", without xinerama (regular or pseudo) activated. |
48 |
This effectively runs two xorg mini-sessions, each on its own screen. You |
49 |
can't move stuff (other than the mouse, and keyboard focus, of course) |
50 |
directly between them. Each has it's own session widgets, taskbar and the |
51 |
like, if whatever environment you are running uses such things. |
52 |
|
53 |
What you want is Xinerama mode (either real or pseudo). How well it fits |
54 |
what you want, in terms of controlling where windows maximize and the |
55 |
like, depends on the windowing environment you run and its support for |
56 |
xinerama. KDE, my X environment of choice, supports xinerama rather well, |
57 |
and has options for whether applications maximize to one screen or all, |
58 |
and such things as window placement (on the mouse-focused screen or |
59 |
either), window movement snap-to support, etc, with each feature |
60 |
individually configurable to single monitor or entire desktop area. (In |
61 |
KDE 3.5 at least, yes, I'm running the betas of that too, these settings |
62 |
are in the control panel under Peripherals/Display, not under |
63 |
Desktop/Window-behavior, where one might otherwise look.) |
64 |
|
65 |
Since you already have both screens running in non-xinerama mode, you've |
66 |
already done the heavy work in xorg, configuring each monitor's separate |
67 |
resolutions and the like. To activate xinerama (real X xinerama), simply |
68 |
add the appropriate |
69 |
|
70 |
Option "Xinerama" |
71 |
|
72 |
line to your ServerFlags section. That should be all you need to do for |
73 |
X. Other reconfiguration will be done in your window manager and X |
74 |
environment of choice. If you want to discuss KDE settings, I'm up for |
75 |
that, otherwise, you'll need to look elsewhere for help with that, if you |
76 |
need any. |
77 |
|
78 |
The free Radeon driver also supports merged framebuffer mode, as I |
79 |
mentioned earlier. This will require a bit of additional reconfiguration |
80 |
to your xorg.conf file, but you already have the data you need in your |
81 |
current config, you just have to redo it a bit. |
82 |
|
83 |
Basically, merged framebuffer uses a single instance of the driver (with |
84 |
or without "PseudoXinerama" enabled) to manage the monitors connected to |
85 |
both outputs of your video card, rather than using a separate instance of |
86 |
the driver for each output. This means there's less overhead and things |
87 |
operate a bit more efficiently. If 3D is supported by the driver on your |
88 |
hardware (as I said, experimental support for post Radeon 9200s is in the |
89 |
latest masked for testing xorg snapshots), you may even get full |
90 |
accelerated 3D support, as long as the total resolution doesn't get too |
91 |
high (I believe the maximum bounded area for merged framebuffer |
92 |
accelerated 3D support is 2048x2048, so I can't run it anyway, since I run |
93 |
2048x3072). |
94 |
|
95 |
There are, however, a few drawbacks to merged framebuffer, as well. |
96 |
First, merged framebuffer operates as a single screen, so regardless of |
97 |
whether xinerama is on or not, you get only the one session with one set |
98 |
of windowing environment widgets, etc. No dual independent mini-sessions! |
99 |
Second, where xinerama isn't supported by your windowing environment, |
100 |
flexibility on where things go will be limited, and windows will maximize |
101 |
to the total screen (across monitors). If xinerama is supported by your |
102 |
windowing environment, of course, this isn't an issue to the degree you |
103 |
can configure it not to be, with the xinerama support. Third, and the |
104 |
thing I personally found most irritating at first, you lose the ability to |
105 |
set each monitor's resolution independently. Yes, the monitors CAN still |
106 |
run at different resolutions, but rather than moving your mouse to the one |
107 |
you want to set and hitting ALT-CTRL-NUMPLUS (or NUMMINUS) to cycle thru |
108 |
each configured resolution on each screen independently, you have a single |
109 |
set of configured resolutions for the merged framebuffer to cycle thru. |
110 |
If like me you have a whole series of resolutions configured for each |
111 |
monitor, listing the permutations in a single combined list very quickly |
112 |
becomes unwieldly! So... with the exception of one special purpose (a |
113 |
specific game) mode that's full size 2048x1536 on the top monitor and |
114 |
640x400 on the bottom one, I settled for a series of equivalent |
115 |
resolutions on each screen. I'll list an example below so you can see |
116 |
what I mean... Combined with a variable strength image magnifier (KView), |
117 |
that serves my purposes well enough, and I'm now running merged |
118 |
framebuffer. |
119 |
|
120 |
Xorg.conf changes for merged framebuffer: |
121 |
|
122 |
The xorg.conf changes for merged framebuffer, compared to running two |
123 |
separate instances of the driver, one for each output, all have to do with |
124 |
the fact that instead of two separate screen configurations, one for each |
125 |
monitor/graphics-card-output combo, you have only one, that has to contain |
126 |
all the information from what was two different screen configs. |
127 |
|
128 |
The way the "primary" monitor and output are configured remains exactly |
129 |
the same, with the exception of the previously mentioned single |
130 |
resolutions sequence, and the single-instance version of that is ignored |
131 |
in merged framebuffer mode, so you don't need to comment out anything from |
132 |
your current primary screen/device config. All the new settings are |
133 |
additional entries. |
134 |
|
135 |
The original secondary screen/device config info is entirely ignored in |
136 |
merged framebuffer mode, since all the necessary info is added as new |
137 |
entries into the primary screen config. Therefore, it too can remain. |
138 |
|
139 |
Further, if merged framebuffer is deactivated, all the merged framebuffer |
140 |
entries (save for the single activate/deactivate option) are ignored, so |
141 |
can remain uncommented in the primary config. |
142 |
|
143 |
This makes it very easy to switch between the two modes, merged |
144 |
framebuffer vs separate screen configs, by switching a single "merged |
145 |
framebuffer" activator entry. Here, I actually comment a few additional |
146 |
entries to make clear which ones are operational and which ones aren't, |
147 |
but that's not necessary. A single change is all that's needed to switch |
148 |
merged framebuffer on or off and activate the appropriate entries. |
149 |
|
150 |
Example time! Keep in mind that the documentation for all these settings |
151 |
are in the radeon manpage, if they're not xorg generic in the first place, |
152 |
so that's where to look if you need to figure out what a setting does or |
153 |
what other options are available. |
154 |
|
155 |
Actually, all the changes are in the primary device section. No screen |
156 |
section changes necessary either! |
157 |
|
158 |
Section "Device" |
159 |
Identifier "DevAgp.0" |
160 |
Driver "radeon" |
161 |
Screen 0 |
162 |
BusID "PCI:5:0:0" |
163 |
Option "BusType" "AGP" |
164 |
Option "AGPMode" "4" |
165 |
Option "AGPFastWrite" |
166 |
Option "EnablePageFlip" |
167 |
Option "MonitorLayout" "CRT, CRT" |
168 |
|
169 |
# The above are all standard xorg device section or radeon settings, |
170 |
# nothing special there! The below settings activate merged |
171 |
# framebuffer and configure the second monitor |
172 |
|
173 |
# This one's the activator switch. Without an "on" or "off" |
174 |
# after the option, it's "on". |
175 |
Option "MergedFB" |
176 |
|
177 |
# Position of the second monitor. Self-evident. |
178 |
Option "CRT2Position" "Above" |
179 |
|
180 |
# These are the hardware settings for the second monitor. |
181 |
# Note again that the primary monitor settings are taken |
182 |
# from the normal place, the monitor section specified |
183 |
# in the screen section that also specifies this device |
184 |
# section. |
185 |
Option "CRT2HSync" "30-110" |
186 |
Option "CRT2VRefresh" "50-180" |
187 |
|
188 |
# This is that confounded resolutions line! It's all one line, wrapped |
189 |
# here for posting. See what I mean about the permutations quickly |
190 |
# becoming unmanageable! If I listed each resolution against each |
191 |
# resolution... Note that as listed, the resolutions on each monitor |
192 |
# are equal, save for the last one. Also note the "-" connectors. A "+" |
193 |
# may also be used, but has a special meaning (clone mode, IRC). Or |
194 |
# a single resolution by itself may be listed. See the radeon |
195 |
# manpage for more. |
196 |
Option "MetaModes" "2048x1536-2048x1536 1792x1344-1792x1344 |
197 |
1600x1200-1600x1200 1280x960-1280x960 1152x864-1152x864 |
198 |
1024x768-1024x768 800x600-800x600 640x480-640x480 512x384-512x384 |
199 |
400x300-400x300 640x400-2048x1536" |
200 |
|
201 |
# Since xorg will otherwise have difficulty calculating the dot-per-inch |
202 |
# settings, and the fonts will likely be way big or way small, if this |
203 |
# setting isn't specified... Note that this is another disadvantage of |
204 |
# merged framebuffer. If your monitors are physcally different sizes or |
205 |
# "normal" operating resolution is different on each, with separate |
206 |
# screens, you can specify separate DPIs. Here, there's only one setting, |
207 |
# so if the monitors use different ones, you gotta pick a compromise. |
208 |
Option "MergedDPI" "120 120" |
209 |
|
210 |
# This one is a specific accel deactivator, here because of the |
211 |
# comment in the ebuild... I don't think it's used as I'm configured, |
212 |
# because 3d accel is deactivated here anyway, due to 2048x3072, but |
213 |
# I put it here anyway. The radeon manpage says what it does... |
214 |
# ColorTiling off due to bug mentioned in xorg-6.8.99.15 ebuilds |
215 |
Option "ColorTiling" "off" |
216 |
EndSection |
217 |
|
218 |
A couple more notes... |
219 |
|
220 |
In the serverlayout section, I comment the second screen section |
221 |
reference. I don't believe I have to do that because the Option MergedFB |
222 |
should take care of it, but I've never tried it with both activated to see |
223 |
which takes precedence, for sure. |
224 |
|
225 |
PseudoXinerama... is activated automatically with mergedFB, unless turned |
226 |
off either because regular xinerama is on, or specifically set off. |
227 |
PseudoXinerama works almost like regular xinerama would with separate |
228 |
framebuffers. Your windowing environment configurations and hooks should |
229 |
apply just as they would to normal xinerama. |
230 |
|
231 |
Thus, I have my xinerama activator line in the serverflags section |
232 |
commented out, for use with mergedFB, because if it were on, |
233 |
PseudoXinerama would deactivate itself. |
234 |
|
235 |
Hope that's what you needed! |
236 |
|
237 |
-- |
238 |
Duncan - List replies preferred. No HTML msgs. |
239 |
"Every nonfree program has a lord, a master -- |
240 |
and if you use the program, he is your master." Richard Stallman in |
241 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
242 |
|
243 |
|
244 |
-- |
245 |
gentoo-amd64@g.o mailing list |