Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Zaphod w/ multiseat

  1. #1
    Join Date
    Jan 2009
    Posts
    148

    Default Zaphod w/ multiseat

    Hey everyone,

    I wrote a tutorial to help other people setting up multiseat using the new GDM and Ubuntu 10.04. However, this time I'm the one who needs help . I'm having troubles getting zaphod to work.

    My understanding of zaphod is that it can run separate x-servers on separate randr-outputs. I read the manpage of radeon and I think this xorg.conf should work:

    Code:
    Section "Monitor" 
    	Identifier	"Monitor0" 
    EndSection 
    
    Section "Monitor" 
    	Identifier	"Monitor1" 
    EndSection 
    
    Section "Screen" 
    	Identifier	"Screen0" 
    	Monitor		"Monitor0" 
    	Device		"Card0" 
    	DefaultDepth	24 
    EndSection 
    
    Section "Screen" 
    	Identifier	"Screen1" 
    	Monitor		"Monitor1" 
    	Device		"Card1" 
    	DefaultDepth	24 
    EndSection 
    
    Section "InputDevice" 
    	Identifier "keyboard0" 
    	Driver "evdev" 
    	Option "Device" "/dev/input/by-path/pci-0000:00:12.0-usb-0:1:1.0-event-kbd" 
    EndSection 
    
    Section "InputDevice" 
    	Identifier "mouse0" 
    	Driver "evdev" 
    	Option "ZAxisMapping" "4 5" 
    	Option "Device" "/dev/input/by-path/pci-0000:00:12.0-usb-0:2:1.0-event-mouse" 
    EndSection 
    
    Section "ServerLayout" 
    	Identifier	"seat0" 
    	Screen 0	"Screen0" 0 0 
    	InputDevice	"mouse0" "CorePointer" 
    	InputDevice	"keyboard0" "CoreKeyboard"
    EndSection
    
    Section "ServerLayout" 
    	Identifier	"seat1" 
    	Screen 1	"Screen1" 0 0 
    EndSection
    
    Section "Device" 
    	Identifier	"Card0"
    	BusID		"PCI:4:0:0"
    	Driver		"radeon"
    
    	Option		"ZaphodHeads"		"DVI-0"
    
    	Screen 0
    EndSection
    
    Section "Device" 
    	Identifier	"Card1"
    	BusID		"PCI:4:0:0"
    	Driver		"radeon"
    
    	Option		"ZaphodHeads"		"DVI-1"
    
    	Screen 1
    EndSection 
    
    Section "ServerFlags" 
    	Option "AutoAddDevices" "off" 
    	Option "AllowEmptyInput" "true" 
    EndSection
    Consolekit starts GDM with the following options:
    Code:
    Exec=/usr/bin/X $display -config /etc/xorg.conf.d_ms/Seats.conf  -novtswitch -layout seat0 -verbose -auth $auth -nolisten tcp $vt
    
    and
    
    Exec=/usr/bin/X $display -config /etc/xorg.conf.d_ms/Seats.conf  -novtswitch -layout seat1 -verbose -auth $auth -nolisten tcp $vt
    Why doesn't this work?

  2. #2
    Join Date
    Jan 2009
    Posts
    148

  3. #3
    Join Date
    Nov 2008
    Posts
    784

    Default

    No. Zaphod will (if properly used) create a single X server with two independent outputs (:0.0 and :0.1). Still, it's just one X server running with a single user and a single keyboard/mouse combination.


    If you want multiseat, you need a different approach. Either multiple cards or ugly hackery or a KMS-driver and largely untested features.

  4. #4
    Join Date
    Jan 2009
    Posts
    148

    Default

    Oh, that's a pity to hear. I read airlieds blog: let's hope he picks his work up again soon!

  5. #5
    Join Date
    Jan 2007
    Posts
    10

    Default

    Quote Originally Posted by MartjeB View Post
    Oh, that's a pity to hear. I read airlieds blog: let's hope he picks his work up again soon!
    It's a pity he's going the KMS approach. I guess you do what you are familiar with.

    I would have thought going with Zaphod mode and relying on MPX for mouse definition attached in the Screen Section would be a solution with lower overhead. Essentially, the xorg.conf would have multiple screen sections and in those screen sections a keyboard and mouse defined much like the Device for the video card. Then, each mouse appears on it's own screen and can not move to another screen. I guess the real problem is there is no MKX (MultiKeyboardX).

  6. #6
    Join Date
    Nov 2008
    Posts
    784

    Default

    MPX contains support for multiple keyboards. But what you're describing still has a huge problem: both screens will run using the same user.

    KMS with truly separate Xorg instances is the only clean solution when you actually want different people in those seats. The memory overhead of a second X server is small compared to simply running Firefox or something.

  7. #7
    Join Date
    Jan 2007
    Posts
    10

    Default

    Quote Originally Posted by rohcQaH View Post
    MPX contains support for multiple keyboards. But what you're describing still has a huge problem: both screens will run using the same user.

    KMS with truly separate Xorg instances is the only clean solution when you actually want different people in those seats. The memory overhead of a second X server is small compared to simply running Firefox or something.
    You are right. The situation I was describing would be a blend between single user and multiple users. One user is logged in but multiple people can use applications on their own desktop. Xinerama would complicate things mind you.

  8. #8
    Join Date
    Jun 2009
    Posts
    2,937

    Default

    BUMP!

    To my great disappointment, I found out yesterday that my motherboard only has on PCI-E slot, which killed my plans for plugging in a second Radeon and having an easy multi-seat solution.

    Instead of replacing the motherboard, I'd like to look at my options for running a multi-seat configuration off a single HD 4550 with several outputs. Unfortunately, the "right way" to do this proposed by airlied hasn't been maintained, to the best of my knowledge.

    I've been looking for info on the web, but much of the info is old, so this is probably the best place to ask for most up-to-date information.

    - As I understand from this thread, Zaphod is not the answer for running a true multi-seat (two KDM instances, separate users working at the same time) setup right now. Is this (still) correct?

    - The patches airlied posted are the correct way to do this with radeon and KMS, but are hacked for his particular card, and apply against much older trees. Is this worth looking into porting these patches, or is it a recipe for disaster for someone not familiar with the kernel and radeon drm? How much effort would this entail?

    - The Xephyr configuration should work, but does not support 3d or EXA, and does not work with evdev peripherals, which would rule it out. I've read that newer versions of Xephyr support evdev, and even read something about 3d. Anyone know more?

    - Xnest is an alternative to Xephyr, but it supports even fewer extensions.

    Are there any other options? I have a really powerful computer sitting here, and serving two users is the obvious and necessary setup. What can I do?

  9. #9
    Join Date
    Jun 2009
    Posts
    2,937

    Default

    Another option would be to get my hands on an old PCI card and go with two graphics cards (the second seat does not need blazing fast performance or anything).

    Will different drivers play nicely with each other? For example, running a r700 and a r200 on the same system? There are no PCI-based r600+ cards, so that's not an option.

  10. #10
    Join Date
    Nov 2008
    Posts
    784

    Default

    Zaphod has never been and will never be a multi-seat solution. It was developed for an entirely different use-case.

    IIRC Xephyr has gotten better to the point where partial 3d-acceleration can work (with some additional gl kludges whose name I forgot). The performance overhead will never go away, though, and you'll probably lose some gl extensions along the way.

    I'm not sure if wayland has been tried as a replacement for X-nesting yet. Wayland should have the ability to compose whole X sessions, right? This is just a wild idea though, I have no idea if wayland is stable enough and/or if it supports the needed features.


    The most sensible way is to get the KMS-patches up to speed. They look pretty straightforward, but will require some understanding of the general code structure for porting.


    I don't think r200 + r700 is a problem if both use the OSS drivers. In theory it should work fine, but it's actually a rarely used configuration which may contain bugs and pitfalls. Then again, it's likely no worse than the other solutions.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •