New approach for nested-X-server multiseat support

[Laércio de Sousa]

I'm opening this bug to discuss ideas for a new approach for supporting nested-X-server multiseat setups in LightDM, so we can easily configure e.g. 2 seats using a single dual-head graphics card.

I have the following initial ideas:

1. Provide a special "empty" seat module, which doesn't spawn greeters, doesn't handle sessions at all, etc. I will only start a host bare X server spanning all available monitors.

1.1 [OPTIONAL] Set property "xdg-seat" for this seat to any invalid value (from logind's perpective), in order to ensure host X server will neither grab input devices (as a non-seat0 X server do) nor touch VTs (as a seat0 X server do). Xorg-server 1.16 or newer is required. Example: xdg-seat=__lightdm-fake-seat__

2. Link this seat to a secondary DisplayManager object which will handle all other nested-X-server seats. When this secondary display manager is stopped, that host-X-server seat should be stopped, too. Set environment variables DISPLAY and XAUTHORITY before starting nested-X-server seats.

2.1 [OPTIONAL] subscribe all nested-X-server seats to main DisplayManager object as well, so they can be registered in LightDM D-Bus API.

3. Seats could gain a new boolean property "require-nesting" or something similar. If it's true, then the seat in question should wait until host X server is ready before starting itself. If no host X server is available, start a new one.

[Laércio de Sousa (lbssousa)]

After inspecting files seat.c, seat-xlocal.c, and seat-unity.c, I've found a much simpler approach for item 1.

Instead of creating another seat module, we can introduce a new option "start-local-sessions" for existing seat modules. If this option is explicitly set to false, the seat in question will only start a bare X server (no greeter, no user sessions).

In order to keep compatibility with current code, setting option "xdmcp-manager" with a non-empty value should force "start-local-sessions=false".

I've uploaded a new branch with an implementation of "start-local-sessions" option:

lp:~ubuntu-multiseat/lightdm/option-start-local-sessions

[Robert Ancell (robert-ancell)]

I need to take a step back to fully understand the requirements on this one.

The simple case for this is:
- 1 processor
- 1 video card with two outputs
- Two keyboards/mice
On startup two login screens are displayed and two people can use this processor simultaneously and independently?

My first question is, can logind handle this case? Can it create two seats and assign the input devices to each seat. Can it communicate to an X server that it should only use one output?

If logind can't handle this case we should first investigate if we can make it do so as that will make this a lot more consistent with the other multi-seat cases.

If it's not possible/appropriate for logind to do this, then I think the structure inside LightDM should be to have a "SeatManager" class that decides how the seats are laid out. In this multi-head multi-seat case we don't use the LogindSeatManager, instead we use a MultiHeadSeatManager which starts and manages the parent X server. We don't want to use the Seat class for something that is not a seat.

This feature sounds a bit borderline to me. If we can't implement this cleanly, I think the answer will be "the supported method of multi-seat is to have separate output devices".

[Laércio de Sousa (lbssousa)]

Let's take another use case, which is the one I'm currently working on (and is the most simple case IMHO): a 3-seat system consisting of:
  - 1 CPU
  - 2 video cards (1 integrated graphics device for seat0 + 1 PCI/PCI-e dual-head graphics card for the other seats)
  - 2 USB hubs (1 for each non-seat0 seat)
  - 3 keyboards/mice

For logind versions older than 198, such a setup was impossible, because a framebuffer device is required in order to create a new seat. But now logind is much more flexible: the only requirement for a new seat to be created is that at least one suitable device tagged in Udev as "master-of-seat" is attached to that seat (in my setup, the USB hubs are tagged as "master-of-seat").

Which this flexibility, logind can work properly with much more graphics scenarios, like video cards with non-KMS drivers (e.g. NVIDIA/AMD proprietary drivers), and nested X servers. From current logind perspective, the display server setup is irrelevant, provided that it can handle input/sound devices attached to a given seat (which is currently done in Xorg by passing "-seat" option to its command line).

For nested X servers (required to load 2 seats on a single dual-head graphics device), an additional requirement is that a bare X server spanning all available outputs must be previously started and ready for connections. Because nested X servers don't reach VTs, I'm affraid of using a nested X server for seat0, so I'm proposing the use case above as the most simple one.

It's important that this bare X server doesn't interfere with any seat at all, i.e., it should neither "steal" a VT expected for the seat0 X server, nor grab input devices expected by a non-seat0 X server. Since Xorg currently doesn't check validity of value passed with "-seat" option, we can satisfy both requirements with a small trick: passing an "invalid", from logind perspective, seat ID, i.e., any name not starting with "seat" (e.g. "-seat __fake-seat__").

We have currently two choices for the nested X server: either Xephyr (built with --enable-kdrive-evdev option) with some wrapper that calculates input devices' paths from logind seat ID and Xephyr window geometry (like https://launchpad.net/multi-seat-xephyr) or a proper Xorg with some video driver that allows nesting (like http://cgit.freedesktop.org/xorg/driver/xf86-video-nested).

In my point of view, what LightDM needs to do for handling nested-X-server based multiseat is the following:
  - When a new seat is loaded, check if it tries to load a nested X server (maybe setting explicitly a seat property like "require-nesting" will be enough).
  - If at least one new seat requires nesting, check if a host (bare) X server is already loaded and ready for connections. If not, LightDM should start it, and the new seat shoud wait until it can start properly.
  - The new seat should set properly environment variables DISPLAY and XAUTHORITY from host X server before starting a nested X server.
  - If all seats that require nesting are removed, LightDM should stop the host X server.

One possible approach for this is using a special "empty" seat (which should not start local sessions) for handling the host X server, and a...