On Sat, Oct 11, 2008 at 11:34:10PM +0200, Alan McKinnon wrote:
> Hi,
>
> My notebook has this graphics hardware.
>
> [EMAIL PROTECTED] ~ $ sudo lspci | grep VGA
> 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600M GT (rev
> a1)
> [EMAIL PROTECTED] ~ $ sudo xdpyinfo | grep -A4 'screen #0'
> screen #0:
> print screen: no
> dimensions: 1920x1200 pixels (332x210 millimeters)
> resolution: 147x145 dots per inch
> depths (7): 24, 1, 4, 8, 15, 16, 32
>
> I also have a second LCD monitor at work, a 1280x1024 that is physically
> slightly larger than the notebook screen, with a corresponding lower dpi.
>
> I've configured it with TwinView to have the second monitor on the right, and
> how I usually use it is to put a user's support mail on that where I can read
> it and fix their issues using the tools on the main monitor. So it's a very
> unsophisticated setup, I have no need for massive 3D accel for eg games, or
> even for placing windows across two monitors. Windows are always on one
> screen or the other (because of the huge dpi difference). There are two
> smallish issues:
>
> The viewports are aligned along the top edge and the
> panel/kicker/plasma/whatever on every desktop environment insists on trying
> to stretch across both monitors, into dead space on the right hand one. I'm
> getting use to right-click on panel, configure, set width to 57% at work,
> 100% at home. If I align the viewports on the bottom edges, windows managers
> tend to want to position new windows with their title bars in the dead space
> at the top.
You probably haven't emerged the applications with Xinerama support.
This is especially true for kde 3. Twinview uses the xinerama protocol
(well,its an extension of the X protocol... ;) to inform applications
about the layout of monitors.
>
> kdm and entrance want to stretch over both monitors. I definitely do not want
> this. Murphy dictates that all useful DM menus will end up in the dead space
> regardless of the theme I use <grrrr>
>
> My research into nvidia's docs leads me to believe that TwinView is designed
> to make the presence of two physical monitors invisible and present one giant
> X screen, with a funky API for dead spaces (which may or may not work). I'm
> thinking Xinerama is the better option, despite the fact that it's old,
> clunky, hopeless at dealing with XRandR and can't be changed on the fly. I'm
> happy to set up two ServerLayouts to deal with this.
As I said, twinview uses the xinerama protocol to inform apps about the
monitors, so there wouldn't be any difference in the way applications
behave. You would only loose the advantages of twinview (you can look
at it as an enhanced, nvidia only, in-driver version of xinerama)
Even xrandr 1.2 provides xinerama style info for the applications, so
you certainly want your application to be compiled with xinerama
support, independently of the way you set up the X server.
BTW in my experince kde compiled without xinerama supp. handles multiple
(independent) screens O, but not xinerama (well, that could be
expected), and with xinerama support it handles xinerama ok, but fails
with independent screen ;)
> I'd appreciate some pros and cons feedback from the list before I embark on a
> huge emerge -e world to include Xinerama support.
>
> --
> alan dot mckinnon at gmail dot com
>
>
yoyo
--
_
|
YoYo () Siska
===================
http://www.ksp.sk/
