1 |
list-catcher <list-catcher@××××××××××.com> posted |
2 |
45EB30CC.9080709@××××××××××.com, excerpted below, on Sun, 04 Mar 2007 |
3 |
15:49:16 -0500: |
4 |
|
5 |
> Does anyone use twinview to run two monitors at different resolutions? |
6 |
|
7 |
I used to. I won't run proprietary kernel modules any more, but the |
8 |
issues you discuss apply equally well to freedomware drivers (such as the |
9 |
Radeon driver I use) when used with multiple monitors as well. It's not |
10 |
an NVidia-only thing. |
11 |
|
12 |
> I've got two monitors one on top of the other with the lower |
13 |
> resolutioned one on top. The one on top (lower resolution) has a dead |
14 |
> area where the window manager/X thinks exists but doesn't show. |
15 |
> Sometimes the window manager will put windows there that I can't see. |
16 |
> |
17 |
> I'm not sure where the problem is because different window managers |
18 |
> treat it differently, although the dead space exists in all of them. |
19 |
|
20 |
This is a common problem, specifically mentioned in various X |
21 |
documentation, particularly on xinerama, I've read. "Legacy" window |
22 |
managers that haven't been updated to work well with xinerama (or any of |
23 |
the pseudo-xinerama implementations, designated as such because xinerama |
24 |
specified an interface for working with multiple monitor and/or non- |
25 |
rectangular display areas that they all use) make what turns out to be an |
26 |
invalid assumption, that the screen area is rectangular, and entirely |
27 |
viewable. The xinerama documentation specifically mentions that one may |
28 |
have problems with window managers not yet updated to understand it, and |
29 |
so it remains, several years later, with those /still/ not updated. |
30 |
|
31 |
Note that Gentoo supports xinerama with its own USE flag, used by most |
32 |
window managers and perhaps a few other apps as well. I just checked and |
33 |
the two window managers you mention specifically below (fvwm and fluxbox) |
34 |
both make use of USE=xinerama. Thus, if you don't have it enabled (I see |
35 |
you appear to, from the emerge --pretends you listed, but others reading |
36 |
might not), I'd recommend that you do so, then remerge affected packages |
37 |
using emerge --newuse world (short form -N). |
38 |
|
39 |
> In fvwm, for example, if I maximize a window that is predominately in |
40 |
> the lower resolutioned monitor it will make that window take up the |
41 |
> entire visible area not including the dead space. Yet, fvwm does load |
42 |
> windows in the dead space sometimes and I can drag my cursor into it. |
43 |
> |
44 |
> Fluxbox maximizes windows to the entire desktop, both monitors, which is |
45 |
> annoying but that's another issue, including the dead space. |
46 |
|
47 |
It would appear that fvwm is partially adapted to the xinerama |
48 |
extensions, but either you haven't configured the window placement to |
49 |
mind xinerama, or it's not fully adapted, since maximize seems to work as |
50 |
desired but window placement doesn't. |
51 |
|
52 |
fluxbox would appear to be less adapted to xinerama. In a way, that's |
53 |
not surprising however, as it continues to be a "lightweight" window |
54 |
manager, and part of that "lightweightness" might be /because/ it doesn't |
55 |
support extensions like xinerama used in more complex cases. |
56 |
|
57 |
I wouldn't know the specifics for either package, however, as I'm a KDE |
58 |
person here. FWIW, kwin and I believe a few other KDE packages make use |
59 |
of USE=xinerama as well. I'd suggest however, that if you are interested |
60 |
as it appears you have reason to be, that you check the documentation for |
61 |
both window managers in regard to xinerama implementation and |
62 |
configuration. It's possible you have support merged (via USE=xinerama) |
63 |
but not activated in the respective configurations. |
64 |
|
65 |
> xorg.conf is attached. |
66 |
|
67 |
snip snip the emerge --pretends and parts of xorg.conf that aren't |
68 |
relevant... |
69 |
|
70 |
> Section "ServerFlags" |
71 |
> Option "Xinerama" "true" |
72 |
> EndSection |
73 |
|
74 |
> Section "ServerLayout" |
75 |
> Screen 0 "Screen0" 0 0 |
76 |
[other section settings snipped] |
77 |
> EndSection |
78 |
|
79 |
> Section "Device" |
80 |
> Identifier "Card0" |
81 |
> Driver "nvidia" |
82 |
> VendorName "nVidia Corporation" |
83 |
> BoardName "NV40 [GeForce 6800]" |
84 |
> BusID "PCI:3:0:0" Screen 0 |
85 |
> Option "TwinView" "True" |
86 |
> Option "TwinViewOrientation" "Above" |
87 |
> Option "ConnectedMonitor" "CRT, CRT, TV" |
88 |
> Option "MetaModes" "1600x1200,1024x768" |
89 |
> Option "SecondMonitorHorizSync" "31-65" |
90 |
> Option "SecondMonitorVertRefresh" "52-120" |
91 |
[other section settings snipped] |
92 |
> EndSection |
93 |
|
94 |
> Section "Screen" |
95 |
> Identifier "Screen0" |
96 |
> Device "Card0" |
97 |
> Monitor "Monitor0" |
98 |
|
99 |
FWIW, you can probably safely delete at least the 1,4 and 15 bit depth |
100 |
settings below, and possibly 8-bit, leaving only the 16-bit settings. |
101 |
Try commenting them out for awhile to be sure, but 1-bit is black and |
102 |
white, and 4 bit is 16-color, both of which are virtually unheard of in |
103 |
modern configs, while 15-bit is extremely uncommon and AFAIK always has |
104 |
been. 8-bit (256 color) was popular back in the limited video memory |
105 |
days of the early to mid 90s, but isn't used much today either, tho it's |
106 |
narrowly possible you might still need it for compatibility with games of |
107 |
that era. It's much more likely you'd need support for 24-bit or 32-bit |
108 |
bitdepths. Here, however, I simply go 16-bit, as that's plenty good for |
109 |
my use and less memory and memory bandwidth intensive than 24 or 32-bit, |
110 |
as well as slightly more CPU efficient than 24-bit. (32-bit would be |
111 |
more CPU efficient, but the memory and bandwidth effects counteract than |
112 |
and then some, in many cases.) |
113 |
|
114 |
> SubSection "Display" |
115 |
> Viewport 0 0 |
116 |
> Depth 1 |
117 |
> EndSubSection |
118 |
> SubSection "Display" |
119 |
> Viewport 0 0 |
120 |
> Depth 4 |
121 |
> EndSubSection |
122 |
> SubSection "Display" |
123 |
> Viewport 0 0 |
124 |
> Depth 8 |
125 |
> EndSubSection |
126 |
> SubSection "Display" |
127 |
> Viewport 0 0 |
128 |
> Depth 15 |
129 |
> EndSubSection |
130 |
> SubSection "Display" |
131 |
> Viewport 0 0 |
132 |
> Depth 16 |
133 |
> EndSubSection |
134 |
> EndSection |
135 |
|
136 |
You will likely wish to check out xorg's "panning domain" settings as |
137 |
well. AFAIK, the nvidia proprietary driver has a non-standard way of |
138 |
setting up this sort of thing, but the idea is to create a rectangular |
139 |
"virtual display" enclosing the "dead area" you mentioned, and allow the |
140 |
lower resolution monitor to pan into the otherwise dead area. |
141 |
|
142 |
There are pluses and minuses to this approach, however. While you |
143 |
eliminate the "dead area" and gain virtual display real estate, the |
144 |
"unlocked" panning behavior can be rather distracting and is somewhat |
145 |
harder to work with, at least until you get used to it. Here, when I had |
146 |
monitors of different sizes (I eventually found the necessary funds as |
147 |
monitor prices came down, and now have a 21" and a 22" monitor, both |
148 |
operated at the same resolution, and close enough in viewable size not to |
149 |
matter), I limited the panning to the smaller one, and to one dimension |
150 |
only. As you, I stack my monitors, so I created a virtual display the |
151 |
height of both put together, and the width of the widest, so the smaller |
152 |
one panned only horizontally, in ordered to view the otherwise "dead |
153 |
space". I found this the best setting for me as it eliminated the dead |
154 |
space, while limiting the panning to horizontal only minimized the |
155 |
feeling of disorientation I constantly have if I allow panning in both |
156 |
horizontal and vertical dimensions. Additionally, only the little |
157 |
monitor panned, and that's above my main work area on the big monitor, so |
158 |
it was less annoying than it would have been had my main work area |
159 |
panned. Of course, the corresponding setting for those who prefer |
160 |
horizontally arranged monitors would be a vertical (only) panning domain |
161 |
on the lower resolution monitor). |
162 |
|
163 |
The other minus to panning is that (on most window managers at least) |
164 |
maximized windows that would otherwise maximize to just the single |
165 |
monitor area, maximize instead to the larger panning area. However, with |
166 |
appropriate settings (either apps or a window manager that remembers |
167 |
window sizes and/or placement if configured to do so), having certain |
168 |
windows normalize (instead of maximize) to the appropriate real |
169 |
resolution of the monitor means this minus is minor and relatively |
170 |
controllable. |
171 |
|
172 |
I'd post segments of my xorg.conf as examples of panning, except that |
173 |
they'd not apply to you anyway, since I believe both the xorg-native |
174 |
radeon merged framebuffer and proprietary nvidia representations are non- |
175 |
xorg-standard in this regard, so my settings would only confuse you. |
176 |
However, as I recall, nvidia's README file (maybe manpage too or instead, |
177 |
now?) was just /loaded/ with information on this and other config |
178 |
settings, and yes, they proved very helpful to me here, before I upgraded |
179 |
to a Radeon that actually had freedomware drivers to go with the |
180 |
freedomware OS, instead of trying to disregard the user's use of a |
181 |
freedomware OS by forcing proprietaryware on customers that actually |
182 |
wanted to use the hardware they bought, and refusing to provide specs or |
183 |
freedomware drivers. The documentation should be equally helpful to you, |
184 |
as I know it covers virtual display and panning domain configuration, |
185 |
among many other informative and helpful topics. =8^) |
186 |
|
187 |
-- |
188 |
Duncan - List replies preferred. No HTML msgs. |
189 |
"Every nonfree program has a lord, a master -- |
190 |
and if you use the program, he is your master." Richard Stallman |
191 |
|
192 |
-- |
193 |
gentoo-amd64@g.o mailing list |