LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Desktop
User Name
Password
Linux - Desktop This forum is for the discussion of all Linux Software used in a desktop context.

Notices


Reply
  Search this Thread
Old 02-23-2011, 09:17 PM   #1
bluebox
Member
 
Registered: Jun 2004
Posts: 71

Rep: Reputation: 9
multiple X-servers, multiple graphics adapters, single-seat (kind of tutorial)


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
Code:
xhost + LOCAL:
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
 
Old 02-27-2011, 01:58 PM   #2
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1981Reputation: 1981Reputation: 1981Reputation: 1981Reputation: 1981Reputation: 1981Reputation: 1981Reputation: 1981Reputation: 1981Reputation: 1981Reputation: 1981
This is not the place for tutorials. If you wish to present this as a formal guide, see our LinuxAnswers subsite.
 
Old 02-28-2011, 08:58 AM   #3
bluebox
Member
 
Registered: Jun 2004
Posts: 71

Original Poster
Rep: Reputation: 9
Quote:
Originally Posted by acid_kewpie View Post
This is not the place for tutorials. If you wish to present this as a formal guide, see our LinuxAnswers subsite.
I would prefer to see some qualified statements or a discussion here, about the way I solved my "problem", better solutions, or explanations for the pitfalls I encountered.

But as I see, my text is either to long or to "special case" so far.

I'm not sure whether it qualifies as a "formal guide" at all, but if you consider it to be misplaced, feel free to move it. I would prefer any kind of feedback in the fist place. Knowing it to be "findable" via google etc. isn't a bad thing, either.
 
Old 03-01-2011, 07:30 AM   #4
JZL240I-U
Senior Member
 
Registered: Apr 2003
Location: Germany
Distribution: openSuSE Tumbleweed-KDE, Mint 18.3+19.0, MX-18
Posts: 4,260

Rep: Reputation: Disabled
Still, I read it entirely and found it a remarkable track of developing understanding of the vagaries of x. It is regrettable that error messages and warnings are less than satisfying in content and accuracy when coming from this packet (as I posted in that other thread. Hi, bluebox ).
 
Old 06-05-2017, 05:22 PM   #5
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Rep: Reputation: 17
The topic is still very much relevant today as I've too have had to endure a lot of headache trying to set something similar up.
The problem is setting up two video adapters being used in sync by Xorg.

There are two ways to accomplish this:

1. One X server and two independent Screens.
2. Two X servers each with one independent Screens.

Both methods have issues with input devices.

1. This method does not automatically focus the keyboard when you move the mouse pointer to another Screen. A hack can be used:
Code:
xev -root -event mouse | sed -un 's/.*same_screen \(NO\|YES\).*/\1/;t1;b2;:1;s/NO/1/p;s/YES/0/p;:2' | while read x; do export DISPLAY=:0.$x; xdotool windowfocus $(xprop -root _NET_ACTIVE_WINDOW | grep -o '0x[^$]\+'); done
https://github.com/i3/i3/issues/2297


2. This method focuses the mouse and keyboard simultaneously over the two servers. This means you get duplicate inputs to each server. Therefore you have to disable the pointer and keyboard on one server. Everything else in terms of the translation between the two servers has to be done via software. The OP uses synergy although it's much simpler to just use x2x. The OP uses the xorg-void driver to avoid receiving inputs on the InputDevice. Since that time Xorg now uses input events which are defined through the InputClass. These events are global and can't be overridden through the use of xorg-void (or any input driver for that matter). So this is the reason why duplicate input signals get generated. Fortunately these inputs can be disabled using the xinput userspace tool.


https://doa379blog.wordpress.com/201...server-debian/

Last edited by linuxbawks; 06-06-2017 at 06:44 PM.
 
Old 06-07-2017, 02:26 AM   #6
JZL240I-U
Senior Member
 
Registered: Apr 2003
Location: Germany
Distribution: openSuSE Tumbleweed-KDE, Mint 18.3+19.0, MX-18
Posts: 4,260

Rep: Reputation: Disabled
Very interesting, thanks.

What I'm really curious about is how Wayland will handle this .
 
Old 06-07-2017, 09:20 AM   #7
linuxbawks
Member
 
Registered: Apr 2013
Distribution: Snuckware
Posts: 240

Rep: Reputation: 17
No idea. You hear this and that about Wayland. To me it still seems a long way off. Certainly in Debian, at least another two years at the very least. From a personal standpoint I am perfectly content with Xorg as a GUI extention to the terminal. If you're more of a terminal-esque type user then this is all one needs. Let's not forget that X is really a graphical extention to a terminal. I can imagine if some people mistake something like Wayland or X for that matter as the true face of a *nix OS.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Managing A Single Firewall Policy For Multiple Servers Using Firewall Builder LXer Syndicated Linux News 0 12-06-2010 11:20 AM
[SOLVED] Best practice for multi-seat on single graphics card dougunder Linux - Desktop 2 11-17-2010 10:08 AM
Receive mail of multiple servers to a single account jlinkels Linux - Server 6 11-02-2009 08:54 PM
Multiple Blade servers booting from multiple disk drives simultaneously NGC_cheryl Linux - Enterprise 0 11-26-2007 09:38 AM
Multiple RADIUS servers on a single machine skiros Linux - Software 3 11-02-2005 07:48 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Desktop

All times are GMT -5. The time now is 12:37 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration