list-catcher <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Sun, 04 Mar 2007
15:49:16 -0500:
> Does anyone use twinview to run two monitors at different resolutions?
I used to. I won't run proprietary kernel modules any more, but the
issues you discuss apply equally well to freedomware drivers (such as the
Radeon driver I use) when used with multiple monitors as well. It's not
an NVidia-only thing.
> I've got two monitors one on top of the other with the lower
> resolutioned one on top. The one on top (lower resolution) has a dead
> area where the window manager/X thinks exists but doesn't show.
> Sometimes the window manager will put windows there that I can't see.
>
> I'm not sure where the problem is because different window managers
> treat it differently, although the dead space exists in all of them.
This is a common problem, specifically mentioned in various X
documentation, particularly on xinerama, I've read. "Legacy" window
managers that haven't been updated to work well with xinerama (or any of
the pseudo-xinerama implementations, designated as such because xinerama
specified an interface for working with multiple monitor and/or non-
rectangular display areas that they all use) make what turns out to be an
invalid assumption, that the screen area is rectangular, and entirely
viewable. The xinerama documentation specifically mentions that one may
have problems with window managers not yet updated to understand it, and
so it remains, several years later, with those /still/ not updated.
Note that Gentoo supports xinerama with its own USE flag, used by most
window managers and perhaps a few other apps as well. I just checked and
the two window managers you mention specifically below (fvwm and fluxbox)
both make use of USE=xinerama. Thus, if you don't have it enabled (I see
you appear to, from the emerge --pretends you listed, but others reading
might not), I'd recommend that you do so, then remerge affected packages
using emerge --newuse world (short form -N).
> In fvwm, for example, if I maximize a window that is predominately in
> the lower resolutioned monitor it will make that window take up the
> entire visible area not including the dead space. Yet, fvwm does load
> windows in the dead space sometimes and I can drag my cursor into it.
>
> Fluxbox maximizes windows to the entire desktop, both monitors, which is
> annoying but that's another issue, including the dead space.
It would appear that fvwm is partially adapted to the xinerama
extensions, but either you haven't configured the window placement to
mind xinerama, or it's not fully adapted, since maximize seems to work as
desired but window placement doesn't.
fluxbox would appear to be less adapted to xinerama. In a way, that's
not surprising however, as it continues to be a "lightweight" window
manager, and part of that "lightweightness" might be /because/ it doesn't
support extensions like xinerama used in more complex cases.
I wouldn't know the specifics for either package, however, as I'm a KDE
person here. FWIW, kwin and I believe a few other KDE packages make use
of USE=xinerama as well. I'd suggest however, that if you are interested
as it appears you have reason to be, that you check the documentation for
both window managers in regard to xinerama implementation and
configuration. It's possible you have support merged (via USE=xinerama)
but not activated in the respective configurations.
> xorg.conf is attached.
snip snip the emerge --pretends and parts of xorg.conf that aren't
relevant...
> Section "ServerFlags"
> Option "Xinerama" "true"
> EndSection
> Section "ServerLayout"
> Screen 0 "Screen0" 0 0
[other section settings snipped]
> EndSection
> Section "Device"
> Identifier "Card0"
> Driver "nvidia"
> VendorName "nVidia Corporation"
> BoardName "NV40 [GeForce 6800]"
> BusID "PCI:3:0:0" Screen 0
> Option "TwinView" "True"
> Option "TwinViewOrientation" "Above"
> Option "ConnectedMonitor" "CRT, CRT, TV"
> Option "MetaModes" "1600x1200,1024x768"
> Option "SecondMonitorHorizSync" "31-65"
> Option "SecondMonitorVertRefresh" "52-120"
[other section settings snipped]
> EndSection
> Section "Screen"
> Identifier "Screen0"
> Device "Card0"
> Monitor "Monitor0"
FWIW, you can probably safely delete at least the 1,4 and 15 bit depth
settings below, and possibly 8-bit, leaving only the 16-bit settings.
Try commenting them out for awhile to be sure, but 1-bit is black and
white, and 4 bit is 16-color, both of which are virtually unheard of in
modern configs, while 15-bit is extremely uncommon and AFAIK always has
been. 8-bit (256 color) was popular back in the limited video memory
days of the early to mid 90s, but isn't used much today either, tho it's
narrowly possible you might still need it for compatibility with games of
that era. It's much more likely you'd need support for 24-bit or 32-bit
bitdepths. Here, however, I simply go 16-bit, as that's plenty good for
my use and less memory and memory bandwidth intensive than 24 or 32-bit,
as well as slightly more CPU efficient than 24-bit. (32-bit would be
more CPU efficient, but the memory and bandwidth effects counteract than
and then some, in many cases.)
> SubSection "Display"
> Viewport 0 0
> Depth 1
> EndSubSection
> SubSection "Display"
> Viewport 0 0
> Depth 4
> EndSubSection
> SubSection "Display"
> Viewport 0 0
> Depth 8
> EndSubSection
> SubSection "Display"
> Viewport 0 0
> Depth 15
> EndSubSection
> SubSection "Display"
> Viewport 0 0
> Depth 16
> EndSubSection
> EndSection
You will likely wish to check out xorg's "panning domain" settings as
well. AFAIK, the nvidia proprietary driver has a non-standard way of
setting up this sort of thing, but the idea is to create a rectangular
"virtual display" enclosing the "dead area" you mentioned, and allow the
lower resolution monitor to pan into the otherwise dead area.
There are pluses and minuses to this approach, however. While you
eliminate the "dead area" and gain virtual display real estate, the
"unlocked" panning behavior can be rather distracting and is somewhat
harder to work with, at least until you get used to it. Here, when I had
monitors of different sizes (I eventually found the necessary funds as
monitor prices came down, and now have a 21" and a 22" monitor, both
operated at the same resolution, and close enough in viewable size not to
matter), I limited the panning to the smaller one, and to one dimension
only. As you, I stack my monitors, so I created a virtual display the
height of both put together, and the width of the widest, so the smaller
one panned only horizontally, in ordered to view the otherwise "dead
space". I found this the best setting for me as it eliminated the dead
space, while limiting the panning to horizontal only minimized the
feeling of disorientation I constantly have if I allow panning in both
horizontal and vertical dimensions. Additionally, only the little
monitor panned, and that's above my main work area on the big monitor, so
it was less annoying than it would have been had my main work area
panned. Of course, the corresponding setting for those who prefer
horizontally arranged monitors would be a vertical (only) panning domain
on the lower resolution monitor).
The other minus to panning is that (on most window managers at least)
maximized windows that would otherwise maximize to just the single
monitor area, maximize instead to the larger panning area. However, with
appropriate settings (either apps or a window manager that remembers
window sizes and/or placement if configured to do so), having certain
windows normalize (instead of maximize) to the appropriate real
resolution of the monitor means this minus is minor and relatively
controllable.
I'd post segments of my xorg.conf as examples of panning, except that
they'd not apply to you anyway, since I believe both the xorg-native
radeon merged framebuffer and proprietary nvidia representations are non-
xorg-standard in this regard, so my settings would only confuse you.
However, as I recall, nvidia's README file (maybe manpage too or instead,
now?) was just /loaded/ with information on this and other config
settings, and yes, they proved very helpful to me here, before I upgraded
to a Radeon that actually had freedomware drivers to go with the
freedomware OS, instead of trying to disregard the user's use of a
freedomware OS by forcing proprietaryware on customers that actually
wanted to use the hardware they bought, and refusing to provide specs or
freedomware drivers. The documentation should be equally helpful to you,
as I know it covers virtual display and panning domain configuration,
among many other informative and helpful topics. =8^)
--
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
--
[email protected] mailing list
