Re: [gentoo-amd64] Re: twinview

[B Nice]

On 3/6/07, Duncan <1i5t5.duncan@×××.net> wrote:
> list-catcher <list-catcher@××××××××××.com> posted
> 45EB30CC.9080709@××××××××××.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@g.o mailing list
>
>

This may or may not help you, but it works for my system.  I use the
Nvidia "slavery-ware" drivers that support multi-monitor integrally.
Granted I'm also using Gnome and Beryl, so you may have to do some
minor edits to get it working for you.

Section "ServerLayout"
        Identifier     "Layout0"
        Screen         "Screen0"
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
        RgbPath      "/usr/share/X11/rgb"
        ModulePath   "/usr/lib64/xorg/modules"
        FontPath     "/usr/share/fonts/misc/"
        FontPath     "/usr/share/fonts/TTF/"
        FontPath     "/usr/share/fonts/Type1/"
        FontPath     "/usr/share/fonts/100dpi/"
        FontPath     "/usr/share/fonts/75dpi/"
EndSection

Section "Extensions"
        Option      "Composite"   "enable"
EndSection

Section "Module"
        Load  "GLcore"
        Load  "dbe"
        Load  "dri"
        Load  "extmod"
        Load  "glx"
        Load  "record"
        Load  "xtrap"
        Load  "freetype"
        Load  "type1"
EndSection

Section "ServerFlags"
#        Option  "Xinerama"
        Option  "SLI"   "on"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
EndSection

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Sager"
        ModelName    "Internal"
        Option  "HorizSync"     "31.0 - 81.1"
        Option  "VertRefresh"   "56.0 - 75.0"
EndSection

Section "Monitor"
        Identifier   "Monitor1"
        VendorName   "Samsung"
        ModelName    "Syncmaster 225BW"
        Option  "HorizSync"     "31.0 - 81.1"
        Option  "VertRefresh"   "56.0 - 75.0"
EndSection

Section "Device"
        Identifier  "Card0"
        Driver      "nvidia"
        VendorName  "nVidia Corporation"
        BoardName   "GE Force Go 7800 GTX"
        Option      "AddARGBGLXVisuals" "true"
        Option      "AllowGLXWithComposite" "true"
        Option      "Twinview"      "on"
        Option          "TwinViewOrientation" "Above"
        Option      "MetaModes" "1680x1050,1680x1050"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        DefaultDepth 24
        SubSection "Display"
                Depth     24
                Modes   "1680x1050"
        EndSubSection
EndSection


Hope it helps.
-- 
gentoo-amd64@g.o mailing list