[gentoo-amd64] twinview

[gentoo-amd64] twinview

[list-catcher]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

Does anyone use twinview to run two monitors at different resolutions?

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.

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.

xorg.conf is attached.

aristotle ~ # emerge -p fvwm

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] x11-wm/fvwm-2.5.18-r1  USE="gtk nls perl png readline 
truetype xinerama -bidi -debug -imlib -rplay -stroke -tk" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

aristotle ~ # emerge -p fluxbox

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] x11-wm/fluxbox-0.9.15.1-r2  USE="nls truetype xinerama 
-disableslit -disabletoolbar -gnome -imlib -kde" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB


[-- Attachment #2: xorg.conf --]
[-- Type: text/plain, Size: 2308 bytes --]

Section "Extensions"
	Option "Composite"      "true" 
EndSection

Section "ServerFlags"
	Option      "Xinerama"      "true"
EndSection

Section "ServerLayout"
	Identifier     "X.org Configured"
	Screen      0  "Screen0" 0 0
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
	FontPath     "/usr/share/fonts/misc"
	FontPath     "/usr/share/fonts/75dpi"
	FontPath     "/usr/share/fonts/100dpi"
	FontPath     "/usr/share/fonts/TTF"
	FontPath     "/usr/share/fonts/Type1"
EndSection

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

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

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

Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Monitor Model"
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"
#        Option          "TVStandard" "NTSC-M"
#        Option          "TVOutFormat" "Composite"
	Option		"TripleBuffer" "True" #-----beryl
	Option		"AddARGBGLXVisuals" "True"
	Option		"AllowGLXWithComposite" "True"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Card0"
	Monitor    "Monitor0"
	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
#	SubSection "Display"
#		Viewport   0 0
#		Depth     24
#	EndSubSection
        Option      "AddARGBGLXVisuals" "true"
EndSection

Re: [gentoo-amd64] twinview

[James Ausmus]

On 3/4/07, list-catcher <list-catcher@hellburner.com> wrote:
> Does anyone use twinview to run two monitors at different resolutions?
>
> 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 had a difficult time getting my twinview settings set up correctly
for my laptop, until I emerged nvidia-settings, and used it to
configure it just right - it makes it fairly simple to do - I'd
suggest just giving that a try. You can get it set up just right, then
either have the nvidia-settings application save the configuration to
your xorg.conf file, or just show you what that xorg.conf file would
look like, so you can cut and paste.

HTH-

James
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: twinview

[Duncan]

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

Re: [gentoo-amd64] Re: twinview

[B Nice]

On 3/6/07, Duncan <1i5t5.duncan@cox.net> wrote:
> 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
>
>

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@gentoo.org mailing list

Re: [gentoo-amd64] twinview

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 2886 bytes --]

On Sunday 04 March 2007, list-catcher <list-catcher@hellburner.com> wrote 
about '[gentoo-amd64] twinview':
> Does anyone use twinview to run two monitors at different resolutions?

No, although I current run two dual-head setups.  One on the nvidia driver 
(using two cards) and one on the radeon driver (using a single, laptop 
card).

> 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.

Sounds like your Xinerama isn't working quite right.

> I'm not sure where the problem is because different window managers
> treat it differently, although the dead space exists in all of them.
>
> xorg.conf is attached.

Short answer: You are using two layers of Xinerama: the full Xinerama 
extension provided by the server and a faux-Xinerama provided by TwinView.  
They don't get along, so you'll have to drop one or the other.

Long answer:
I see you are using the Xinerama extension AND TwinView.  On my laptop I 
use a different driver (radeon) and method (MergedFB + MergedXinerama), 
but I get similar results.  The combination of Xinerama and the 
faux-Xinerama used by TwinView/MergedXinerama doesn't work well together; 
I either get dead areas or (better, but something I don't like) desktop 
scrolling within a larger virtual desktop.

If I turn off MergedFB+MergedXinerama and instead use two device sections 
(one for the each head provided by the video card) and the Xinerama 
extension things work well (no dead areas or desktop scrolling), although 
my driver (I don't know about yours) doesn't support DRI in such a mode.

If I turn off the Xinerama extension but continue to use a single device 
section with the MergedFB+MergedXinerama options, things work even better 
(but, YMMV); no dead areas or desktop scrolling AND I get DRI.

So, I suggest turning off the Xinerama extension and trying that, first.  
If that doesn't work you may want to discard TwinView and instead use two 
device sections that are nearly identicial -- one will have 'Screen 0' in 
it's config and the other will have 'Screen 1'.  I don't know what impact 
this second option may have on hw accceleration with your driver.

As an aside, I think this could reasonably be called a xorg-server bug, 
especially since it does affect the xorg-radeon driver.  (If it only 
affected nvidia and/or fglrx that would be a different story.)

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     
New GPG Key!  Old key expires 2007-03-25.  Upgrade NOW!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]