well ... uhm ... the question I wanted to ask here developed to a kind of tutorial, as I was able to find solutions to most of my problems myself, step for step.
First, my setup: running Debian Squeeze on a machine with two Nvidia-brand graphics adapters, one "big" PCI-E card, and one "small" onboard graphics, both are dual-head-capable.
I have two displays connected to the "big" card, running like a charm with "nvidia" proprietary driver, using nvidia twinview, including 3D acceleration and composite effects. This is my main setup for work, so I will call it "main" from now on.
I got my hands on an old low-res display, so I decided to plug it into the "small" onboard graphics. This gave my quite a lot of headache, so I will call it "child" from now on.
Using "nvidia-settings", I learned that I have three possibilities:
1) enable "xinerama" and have one large desktop spread over all three displays. Well, that looked good first, but then I discovered some drawbacks:
I loose composite and desktop effects. This is due to a limitation in the xorg server - you may have either composite or xinerama. Well, I could live with that ... but ...
There is a thing, the nvidia driver does in twinview-mode, I would call "fake-xinerama". My two main monitors were considered to be one big screen in twinview-mode, but somehow the nvidia driver fools X into thinking that xinerama is enabled for two displays, so X sees two monitors, places my windows accordingly and I have 3D acceleration and composite.
Enabling the X-xinerama stops the nvidia fake-xinerama from working, so X sees one big desktop on my two main displays, windows open anywhere inbetween, maximised windows cover both screens and the login greeter is one half on the left monitor, one half on the right monitor. Unacceptable for me. So ...
2) I turned twinview off and got three independent screens, glued together by xinerama. My windows got placed correctly, I could move them around my three displays ... but due to the fact that now two monitors are connected to one GPU, I lost some 3D and overlay capabilities. Not perfect, either ... so ...
3) I turned twin-view on again, turned xinerama off and expected my two "main" displays to work as they used to be, and to have one separate screen on my "child" display. Well ... nearly ... for some weird reason I still lose the nvidia fake-xinerama in this setup.
This was the point I decided to ask a question here on best practice about how to layout my setup. I did some googling before and found the idea to a new approach ... separate X-servers instead of separate screens.
Well, so here we go. I expect a perfectly working xorg.conf for all your display devices as a basis. It should look something like this:
Code:
Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0" 1024 0
Screen 1 "Screen1" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama 0"
EndSection
We have one ServerLayout with multiple screens. Now change it to something similar to this:
Code:
Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama 0"
EndSection
Section "ServerLayout"
Identifier "Layout1"
Screen 1 "Screen1" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama 0"
EndSection
Here we have multiple ServerLayouts with one screen each. Of course you could put multiple screens in one layout, too, if you desire. Turning off Xinerama is not really necessary, but I need to do so, to keep my fake-xinerama.
Layout0 will be used for the main display, Layout1 will be used for the child display.
After a restart of your X server, you should test the new layout:
Code:
# xinit /usr/bin/xterm -display :1 -- -layout Layout1 :1
For some use cases this might be enough ... replace "xterm" with an application of your choice. The most annoying part is, that you now have one mouse and one keyboard, serving both X servers. We will take care about this, later.
First, I wanted to make the X server start automatically on my child display ... well, not just the server, but a full-featured windows manager. Surely, there are many ways to achieve this ... I found some solutions in multi-seat-tutorials. I found it to be quite easy to configure kdm to do this. Furthermore I learned that the new gdm3 included in Squeeze is not able to do "multi-seat" ... well, no problem, I disliked it anyways due to the massive regressions concerning configurability. So I installed kdm.
Open up /etc/kde4/kdm/kdmrc and look for the [General] section.
There should be
Code:
[General]
StaticServers=:0
ReserveServers=:1,:2,:3
Change it to:
Code:
[General]
StaticServers=:0,:1
ReserveServers=:2,:3
This tells KDM to start and use two distinct X servers. The multi-seat tutorials usually involve starting the X servers on different virtual terminals and preventing the users from switching terminals ... I don't see a reason to do so when running single-seat.
Now, scroll down to [X-:0-Core] section. Don't confuse it with the general [X-*-Core] section.
Add the line
Code:
ServerCmd=/usr/bin/X -layout Layout0
to the [X-:0-Core] section or change the "ServerCmd" entry accordingly.
Add a new section:
Code:
[X-:1-Core]
ClientLogFile=.xsession-errors
ServerCmd=/usr/bin/X -layout Layout1
[X-:1-Greeter]
at the end. Display :0 is the main display, and display :1 is the child display. Each gets linked to its corresponding layout.
Now we're done ... save and restart KDM.
You should see two KDM greeters, one on the main display, one on the child display. You can login into one or both ... if you can ... there's still the problem with erratic mouse movement on both displays. It's a bit tricky.
I googled quite a lot on how to solve this. I wanted a solution "within X", but I didn't found one. I even considered to add a second mouse and keyboard and to do multi-seat ... until I stumbled upon "synergy".
Synergy is meant to be a KVM-switch replacement, enabling you to control multiple machines with a single mouse and keyboard over ethernet. I decided to abuse it.
So I installed synergy - it is available in Debian and Ubuntu repositories and there are surely rpms available, too.
Synergy is split up into "synergys", the server, meant to be run on the machine with keyboard and mouse connected, and "synergyc", the client, meant to be run on every machine you want to control remotely. As for me client and server are the same machine with different X servers, I had to adopt it to my configuration.
synergys's default configuration file is /etc/synergy.conf. Your package may vary, so read the manpage.
Put this into synergy.conf
Code:
section: screens
main:
child:
end
section: links
main:
left = child
child:
right = main
end
section: aliases
end
section: options
end
You might need to swap left and right, but this should be enough to get two X servers configured.
btw ... did you read the manpage? Well, do it. NOW. There are some important and helpful options for the "screens" and "options" section, you should know about.
Now you can start the server in a separate x-term, possibly as "root":
Code:
# synergys -f -a 127.0.0.1 --display :0 -n main
and start the client in a separate x-term:
Code:
# synergyc -f -n child --display :1 127.0.0.1
Does it work? No? Well, for me neither. For some strange reasons, my root xterm was not allowed to connect to the X servers. For some even more strange reasons my root account was not allowed to do a "xhost + LOCAL:". I had to login into both KDMs and do a "xhost + LOCAL:" as average user to get it working.
So, do so for testing purposes. When synergyc and synergys are running, you should notice a strange effect ... when moving your mouse on both screens right to the left, you should finally see your mouse pointer disappear on the right screen, and only be visible on the left screen. This means, synergy is working. Good thing, and now we want it to start automagically.
Open /etc/kde4/kdm/Xsetup and add these lines:
Code:
/usr/bin/killall synergyc
/usr/bin/killall synergys
sleep 1
/usr/bin/synergys -n main -a 127.0.0.1 --display :0
/usr/bin/synergyc -n child --display :1 127.0.0.1
The disadvantage of this approach is, that we start synergy twice - once for each X server. You shouldn't do this, the manual says. You can work around this by configuring two distinct Xsetup files in kdmrc, one for each X server. The advantage of this approach is - it is easy and it works. Restart kdm and test it.
Now, it would be the time to get rid of the annoying double mouse pointer.
But, there still is this strange xhost problem. I investigated in this problem and it is a profound problem when synergyc dies. And synergyc dies for me, from time to time. Then, there is no way to reconnect to the child display. In this case, the only way is to restart the X server. And even worse ... I found no way to restart a single X server from within KDM ... and restarting whole KDM in such cases is very annoying.
The xhost-problem is annoying, too. I created /etc/X0.hosts and /etc/X1.hosts with a content of "LOCAL:" for both, according to xhost manpage, and got this strange effect on two xterms, running on the main display:
user@workstation:# xhost
access control enabled, only authorized clients can connect
LOCAL:
(good thing, as I expected)
root@workstation:# xhost
access control enabled, only authorized clients can connect
LOCAL:
(good thing, as I expected)
root@workstation:# xhost + LOCAL:
xhost: unable to open display ":0"
(uhm? so setting a set setting, enabling me to set this setting, gives me an error saying that this setting is not setable?)
user@workstation:# xhost + LOCAL:
non-network local connections being added to access control list
(okay, a user may set this set setting again)
root@workstation:# xhost + LOCAL:
non-network local connections being added to access control list
(okay, now even root has access to this display, looks like local access is finally allowed)
Whatever happens here, it looks like the xhost access control is user-based, not machine based as it should be. So to save us from situations where synergyc is dead, we have to enable local access to the child X server in two situations - once for root running it during the greeter, and once for a user running it when logged in.
I found it easiest to add the line
into these two files:
/etc/kde4/kdm/Xsetup
/etc/kde4/kdm/Xsession
This is more unsecure than necessary, as it allows access for any local user to both x servers. But it should be enough for a home based machine. And ... it works.
Now, we can finally get rid of the double mouse pointer. X does not like to run without keyboard and mouse, so we need to add fake ones. I had to install the package "xserver-xorg-input-void" to do so ... you may need to, too, or not.
Add two devices to your /etc/X11/xorg.conf
Code:
Section "InputDevice"
Identifier "Keyboard1"
Driver "void"
Option "CoreKeyboard"
EndSection
Section "InputDevice"
Identifier "Mouse1"
Driver "void"
Option "CorePointer"
EndSection
Make sure, the "Identifier"s are unique. The default should be "Mouse0" or "Configured Mouse", so you shouldn't need to change something.
Further, change Layout1 again
Code:
Section "ServerLayout"
Identifier "Layout1"
Screen 1 "Screen1" 0 0
InputDevice "Keyboard1" "CoreKeyboard"
InputDevice "Mouse1" "CorePointer"
Option "Xinerama" "0"
Option "AutoEnableDevices" "false"
EndSection
The void driver simply does nothing. We need it, as synergy gives us mouse and keyboard, and there is no way to configure them in xorg.conf. AutoEnableDevices makes X to add any further mouses and keyboards, it finds, to the server. We don't want them, so we disable it.
We could be done now ... but ...
as I said, synergyc dies for me, from time to time. I tried to figure out the reason, but I had not much success. It happens when I move the mouse between servers (rarely, of course) and the client complains about "unable to connect to display". It could be a bug in X, in KDE, in the nvidia diver or anything.
I found it easiest to run this script as root, after being logged in:
Code:
#! /bin/sh
/usr/bin/killall synergyc
/usr/bin/killall synergys
sleep 1
/usr/bin/synergys -n main -a 127.0.0.1 --display :0
/usr/bin/synergyc -n child --display :1 127.0.0.1
# xhost - LOCAL:
while true;
do
if [ "`ps -e | grep synergyc`" ]
then
echo "synergyc running"
sleep 10
else
/usr/bin/synergyc -n child --display :1 127.0.0.1
echo "synergyc restarted"
fi
done
"sleep 10" means, you have to wait 10 seconds in the worst case if synergyc dies, before you can access the child display again. In practice, I never noticed any annoying delay.
Of course, this is not very "professional", but good enough for me. You might want to dispatch the script - use "screen" to do so and remove the "echo" lines. Comment-in the "xhost"-line if you need additional security for the main display. Besides that, any local user could break this script by running any command called "synergyc".
A "professional" approach would be to run two distinct scripts, one for synergyc and one for synergys, in two distinct configuration files of KDM for each of the X servers.
Finally, it works and I am very content with this solution.
I have two completely independent displays, each with full support for 3D acceleration, composite and terminal switching. Each with it's own windowmanager, each configurable on its own, with separate resolutions, backgrounds, screensavers, etc. The child display even goes to standby when it is unused.
The child display is perfectly fitted for running mythtv, xbmc or some presentation, while working on the main display. If some strange graphics-application freezes the child display, I simply do not care until I am done with my work.
You should have two different users, one for each X server. You need not to, but you will be confused when the windows, you opened on one display, will be automatically restored on the second display.
I have two screenmodes configured for the child display - one in native resolution, for watching videos and stuff, and one big oversized screen, using the nvidia auto scrolling feature, to open up lots of texts for reference purposes. Switching screenmode of the child display of course does not affect the main display.
Things I can not do is maximising an application over all three displays, but I cannot imagine why I should want to do so. And I cannot move a window from the main display to the child display ... but, why should I? I can comfortably open it up on the child display. Well ... maybe I even could move windows ... tools like "xmove" and "xpra" promise to be able to do so, but I have no need to investigate into it at the moment.
Now I think about getting an old outdated android phone, run X on it and attach it to my displays, using WiFi and synergy ... I could use it to ... uhmm ... well, I don't know for what atm, but it would be pretty damn cool to have it
