Re: [gentoo-user] Xinerama vs TwinView for dual monitor setup
On Monday 13 October 2008 13:53:49 YoYo siska wrote: > tabletka ~ # equery hasuse xinerama | wc -l > 285 > > most of them are apps from kde-base/* (3.5.9), seems that it changed > between 3.5.9 and 3.5.10, plus iwndow managers like fluxbox, openbox... That looks better. I was convinced that most kde-3 apps had a xinerama USE flag, hence my 'emerge -e world' comment that Iain picked up on. I wonder why it was changed for KDE-3.5.10, it seems that Xinerama support is now automatically built for most of KDE-3 (deduced by examining the ebuild and ldd output) > > Obviously, this understanding of mine is flawed. Which bit did I get > > wrong? > > Xinerama consists basically of two parts, the protocol to communicate the > position/sizes of screen between the Xserver and the applications (which > you usually get by enabling the xinerama use flag) and an xserver part > (module?) that you can use to set up the screens. What you said is > correct for the Xserver setup part... > You use either xinerama setup to put together completely different > displays (might be different cards, such as one nvidia, one ati, ...) > or twinview in case of a dualhead nvidia setup. But both this setups use > the xinerama protocol to let the apps/wm know the placement of the > monitors. OK, so there's a xinerama protocol and a xinerama lib and these are not the same thing -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Xinerama vs TwinView for dual monitor setup
On Mon, Oct 13, 2008 at 09:10:34AM +0200, Alan McKinnon wrote: > On Monday 13 October 2008 04:02:19 Iain Buchanan wrote: > > > [snip] > > > > > I've configured it with TwinView > > > > as in: > > Option "TwinView" "True" > > Yes. Some output : > > $ sudo grep -i -e xinerama -e twinview /var/log/Xorg.0.log > (**) Option "Xinerama" "1" > (**) Xinerama: enabled > (**) NVIDIA(0): Option "TwinView" "1" > (**) NVIDIA(0): Option "TwinViewXineramaInfoOrder" "DFP-0" > (**) NVIDIA(0): TwinView enabled > (II) Initializing built-in extension XINERAMA > > $ sudo grep -i -e xinerama -e twinview /etc/X11/xorg.conf > Option "Xinerama" "1" > Option "TwinView" "1" > Option "TwinViewXineramaInfoOrder" "DFP-0" > > > > > The viewports are aligned along the top edge > > > > you mean move the mouse up and it appears on the next screen? Don't you > > want them aligned left / right of each other? > > My description wasn't clear. I mean the screens are physically and logically > laid out like so: > > +--+ > | | | > |1 | 2 | > | |---+ > +--+ > > 1 is the notebook screen > 2 is the external lcd > below 2 is dead space. The mouse works correctly. > > > > 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. > > > > Sounds like you haven't compiled stuff with the xinerama USE flag. I > > put it in make.conf, and then did a emerge --newuse. > > OK, I did that. The packages that got rebuilt are: > > $ equery hasuse xinerama > [ Searching for USE flag xinerama in all categories among: ] > * installed packages > [I--] [ ~] x11-apps/xdpyinfo-1.0.3 (0) > [I--] [ ~] x11-libs/qt-3.3.8b (3) > [I--] [ ~] x11-libs/gtk+-2.14.3-r2 (2) > [I--] [ ~] x11-libs/qt-gui-4.4.2 (4) > [I--] [ ] x11-misc/engage- (0) > [I--] [ ~] kde-base/ksplash-4.1.2 (4.1) > [I--] [ ~] kde-base/plasma-workspace-4.1.2 (4.1) > [I--] [ ~] kde-base/ksplashml-3.5.10 (3.5) > [I--] [ ~] kde-base/systemsettings-4.1.2 (4.1) > [I--] [ ~] kde-base/kwin-4.1.2 (4.1) > [I--] [ ~] kde-base/libplasma-4.1.2 (4.1) > [I--] [ ~] kde-misc/knetworkmanager-0.2.2_p20080528 (0) > [I--] [ ~] kde-misc/filelight-1.0-r1 (0) > [I--] [ ] media-libs/libsdl-1.2.13 (0) > [I--] [ ] media-libs/xine-lib-1.1.15-r1 (1) > [I--] [ ] net-libs/xulrunner-1.8.1.17 (1.8) > [I--] [ ~] media-sound/kid3-1.0 (0) > [I--] [ ~] media-sound/amarok-1.4.10-r1 (0) > [I--] [ ~] media-video/mplayer-1.0_rc2_p27725-r1 (0) > [I--] [ ] media-video/xine-ui-0.99.5-r1 (0) > [I--] [ ~] media-video/gxine-0.5.903 (0) > [I--] [ ~] app-cdr/k3b-1.0.5-r3 (0) tabletka ~ # equery hasuse xinerama | wc -l 285 most of them are apps from kde-base/* (3.5.9), seems that it changed between 3.5.9 and 3.5.10, plus iwndow managers like fluxbox, openbox... > > Seems like the only things that would affect kde-3 apps is qt-3.3.8b. > Plus x11-libs/libXinerama and x11-proto/xineramaproto (both latest unstable) > are installed. > > [snip] > > > > I'd appreciate some pros and cons feedback from the list before I embark > > > on a huge emerge -e world to include Xinerama support. > > > > Why would you do -e world? How about `emerge -uN world` The N being > > --newuse. or `emerge -vauDN world`. > > I was running > /bin/think --exaggerate --frustrated --logic-level -3 > when I typed that :-) > > > check out my blog for how I did it: > > > > http://nthrbldyblg.blogspot.com/2008/08/nvidia-xinerama-on-dell-m6300.html > > Nice blog :-) > > I'll fiddle some more with these tips later in the day, but first a > conceptual > question: I read that huge collection of docs from nvidia-drivers, and > concluded that Xinerama and TwinView are fundamentally different and > incompatible. i.e. Xinerama starts with two classic X screens and joins them > in software to make one big display - an abstraction layer if you will. > TwinView rips out the guts of X, dispenses with the notion of separate > screens for a TwinView display and gives you one giant screen with no API for > an app to see how this big screen is composed. So, you either use Xinerama or > TwinView, but not both. > > Obviously, this understanding of mine is flawed. Which bit did I get wrong? Xinerama consists basically of two parts, the protocol to communicate the position/sizes of screen between the Xserver and the applications (which you usually get by enabling the xinerama use flag) and an xserver part (module?) that you can use to set up the screens. What you said is correct for the Xserver setup part... You use either xinerama setup to put together completely different displays (might be different cards, such as one nvidia, one ati, ...) or twinview in case of a dualhead nvidia setup. But both this setups use the xinerama protocol to let the a
Re: [gentoo-user] Xinerama vs TwinView for dual monitor setup
On Monday 13 October 2008 04:02:19 Iain Buchanan wrote: > [snip] > > > I've configured it with TwinView > > as in: > Option "TwinView" "True" Yes. Some output : $ sudo grep -i -e xinerama -e twinview /var/log/Xorg.0.log (**) Option "Xinerama" "1" (**) Xinerama: enabled (**) NVIDIA(0): Option "TwinView" "1" (**) NVIDIA(0): Option "TwinViewXineramaInfoOrder" "DFP-0" (**) NVIDIA(0): TwinView enabled (II) Initializing built-in extension XINERAMA $ sudo grep -i -e xinerama -e twinview /etc/X11/xorg.conf Option "Xinerama" "1" Option "TwinView" "1" Option "TwinViewXineramaInfoOrder" "DFP-0" > > The viewports are aligned along the top edge > > you mean move the mouse up and it appears on the next screen? Don't you > want them aligned left / right of each other? My description wasn't clear. I mean the screens are physically and logically laid out like so: +--+ | | | |1 | 2 | | |---+ +--+ 1 is the notebook screen 2 is the external lcd below 2 is dead space. The mouse works correctly. > > 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. > > Sounds like you haven't compiled stuff with the xinerama USE flag. I > put it in make.conf, and then did a emerge --newuse. OK, I did that. The packages that got rebuilt are: $ equery hasuse xinerama [ Searching for USE flag xinerama in all categories among: ] * installed packages [I--] [ ~] x11-apps/xdpyinfo-1.0.3 (0) [I--] [ ~] x11-libs/qt-3.3.8b (3) [I--] [ ~] x11-libs/gtk+-2.14.3-r2 (2) [I--] [ ~] x11-libs/qt-gui-4.4.2 (4) [I--] [ ] x11-misc/engage- (0) [I--] [ ~] kde-base/ksplash-4.1.2 (4.1) [I--] [ ~] kde-base/plasma-workspace-4.1.2 (4.1) [I--] [ ~] kde-base/ksplashml-3.5.10 (3.5) [I--] [ ~] kde-base/systemsettings-4.1.2 (4.1) [I--] [ ~] kde-base/kwin-4.1.2 (4.1) [I--] [ ~] kde-base/libplasma-4.1.2 (4.1) [I--] [ ~] kde-misc/knetworkmanager-0.2.2_p20080528 (0) [I--] [ ~] kde-misc/filelight-1.0-r1 (0) [I--] [ ] media-libs/libsdl-1.2.13 (0) [I--] [ ] media-libs/xine-lib-1.1.15-r1 (1) [I--] [ ] net-libs/xulrunner-1.8.1.17 (1.8) [I--] [ ~] media-sound/kid3-1.0 (0) [I--] [ ~] media-sound/amarok-1.4.10-r1 (0) [I--] [ ~] media-video/mplayer-1.0_rc2_p27725-r1 (0) [I--] [ ] media-video/xine-ui-0.99.5-r1 (0) [I--] [ ~] media-video/gxine-0.5.903 (0) [I--] [ ~] app-cdr/k3b-1.0.5-r3 (0) Seems like the only things that would affect kde-3 apps is qt-3.3.8b. Plus x11-libs/libXinerama and x11-proto/xineramaproto (both latest unstable) are installed. [snip] > > I'd appreciate some pros and cons feedback from the list before I embark > > on a huge emerge -e world to include Xinerama support. > > Why would you do -e world? How about `emerge -uN world` The N being > --newuse. or `emerge -vauDN world`. I was running /bin/think --exaggerate --frustrated --logic-level -3 when I typed that :-) > check out my blog for how I did it: > > http://nthrbldyblg.blogspot.com/2008/08/nvidia-xinerama-on-dell-m6300.html Nice blog :-) I'll fiddle some more with these tips later in the day, but first a conceptual question: I read that huge collection of docs from nvidia-drivers, and concluded that Xinerama and TwinView are fundamentally different and incompatible. i.e. Xinerama starts with two classic X screens and joins them in software to make one big display - an abstraction layer if you will. TwinView rips out the guts of X, dispenses with the notion of separate screens for a TwinView display and gives you one giant screen with no API for an app to see how this big screen is composed. So, you either use Xinerama or TwinView, but not both. Obviously, this understanding of mine is flawed. Which bit did I get wrong? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Xinerama vs TwinView for dual monitor setup
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) I have a Quadro FX 1600M, using nvidia-drivers... 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 have an LCD at 1920x1200, but it's much larger than my laptop display, so the dpi is different. So far I have no working way of setting different DPI's on the different monitors. [snip] I've configured it with TwinView as in: Option "TwinView" "True" ? The viewports are aligned along the top edge you mean move the mouse up and it appears on the next screen? Don't you want them aligned left / right of each other? 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. Sounds like you haven't compiled stuff with the xinerama USE flag. I put it in make.conf, and then did a emerge --newuse. 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. definitely sounds like you haven't recompiled with xinerama. 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 xinerama should make your wm open screens on one window only. Also your log-in screen should be on one screen only, and panels should be on one screen only. 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. I'd appreciate some pros and cons feedback from the list before I embark on a huge emerge -e world to include Xinerama support. Why would you do -e world? How about `emerge -uN world` The N being --newuse. or `emerge -vauDN world`. It's not that huge, but you need it regardless of whether you use twinview or xinerama anyway. $ equery hasuse xinerama | wc -l 16 check out my blog for how I did it: http://nthrbldyblg.blogspot.com/2008/08/nvidia-xinerama-on-dell-m6300.html HTH, -- Iain Buchanan Chuck Norris once ate a whole cake before his friends could tell him there was a stripper in it.
Re: [gentoo-user] Xinerama vs TwinView for dual monitor setup
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 > > 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/
[gentoo-user] Xinerama vs TwinView for dual monitor setup
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. 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 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. 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
