[gentoo-amd64] Re: twinview

[Duncan <1i5t5.duncan@cox.net>]

list-catcher <list-catcher@hellburner.com> posted
45EB30CC.9080709@hellburner.com, 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

-- 
gentoo-amd64@gentoo.org mailing list