Support multi-seat using one X server and Xephyr servers per seat

Bug #1169724 reported by Andrzej Pietrasiewicz
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Light Display Manager
Triaged
Wishlist
Unassigned

Bug Description

This is in response to:

https://code.launchpad.net/~andrzejtp2010/lightdm/lightdm-trunk-xephyr-multiseat/+merge/120286

Attached are log files for running without my patch (vtswitch.tar.gz) and with my patch (commonvt.tar.gz).
Without the patch applied the Xephyrs (but without greeters) show up for a while and then the computer locks with a black console screen with a cursor blinking; it is only possible to ssh into it and gracefully shut it down.
With the patch applied the two seats are up and running. To be honest I added a 5-seconds sleep before running each Xephyr, but other than that it runs ok.

Related branches

Revision history for this message
Andrzej Pietrasiewicz (andrzejtp2010) wrote :
Revision history for this message
Robert Ancell (robert-ancell) wrote :

Hi Andrzej,

Thanks for reporting this. Some thoughts on this use case:

This is not a supported way of using LightDM,since you configure three seats where in fact there is only two seats (seat 0 is being used as a method running multiple seats at once on one VT). This setup has the issue of the seats not being independent (i.e. seats 1 and 2 need seat 0 to be ready and running to work) and will confuse LightDM in cases like user switching (LightDM expects to be able to switch sessions using VTs).

If we were to correctly support this case LightDM would need to define a new seat type in src/seat-xephyr.c. This seat type would have a shared X server and run one Xephyr per seat. I'm not sure how common this case is, but I'm open to hearing feedback on this.

summary: - Impossible to share a vt between seats
+ Support multi-seat using one X server and Xephyr servers per seat
Changed in lightdm:
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
Laércio de Sousa (lbssousa) wrote :

Here in Brazil, we have the world's largest multiseat computers deployment. The multiseat model used in these computers is the "multiple video cards model". Tipically, we have an onboard video chip for the primary seat, and a PCI(-e) video card with multiple video outputs, with a seat attached to each output.

This is not the best way to setup multiseat with multiple video cards, one may say: it's better to have a separate video card for each seat, running a complete X.Org instance. But we have some multiseat setups of up to 5 seats (including primary seat) using a 4-headed video card, so we really need a nested-X solution to configure the additional seats.

In the gdm-2.20 days, it was very common to make a Xephyr-based multiseat setup by making GDM launch a bare X server ("Handled=false" option in gdm.conf), on top of which one can launch additional Xephyr instances.

Currently we depend on a proprietary solution to configure the additional seats (Userful Multiseat). Unfortnately, Userful's solution supports only Ubuntu 10.04, so we can't upgrade our systems to Ubuntu 12.04 or higher, due to this lack of Xephyr-based multiseat implementation.

I see that lightdm starts moving toward logind support, which should make multiseat support better and easier to configure, but we in Brazil still really need a Xephyr-based solution, in order to have more seats with less video cards.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

I slept on this and realised the idea of sharing VTs as proposed in the branch does apply to LightDM. When using multiple seats you can never use more than one VT since switching VT would switch the VT on all seats. So we need to use the same VT for all X servers in multi seat. For the single seat case we do need to use VTs to perform user switching. I've created bug 1171680 to fix this.

The side effect of this change is you should be able to do the Xephyr based multi-seat when this change is applied.

Long term, it would be nice to have a proper Xephyr seat module. It should also be possible to do both mutli-seat and multi-session using Xephyr which would be quite nice.

Revision history for this message
Laércio de Sousa (lbssousa) wrote :

We're working on a small Xephyr wrapper for multiseat setup with a single graphics card, with logind in mind. It's currently tested in openSUSE 12.3 with multiseat-patched KDM, but I believe it can work also with LightDM with upcoming logind basic multiseat support. Maybe some ideas behind this wrapper can be useful for LightDM's eventual Xephyr seat module.

The project is hosted at https://launchpad.net/multi-seat-xephyr.

Revision history for this message
Laércio de Sousa (lbssousa) wrote :

Hi there!

I have some ideas for a nested-X-server seat module for LightDM, and I really appreciate your feedback:

- Introduce new modules x-server-nested-{local,remote,xvnc} (or something similar).

NOTE: A nested X server could be a Xephyr server or a real X server with "nested" video driver.

- Introduce new modules seat-{xlocal,xremote,xvnc}-nested corresponding to x-server-nested-* above.

- [REALLY NEEDED?] Introduce a new module x-server-host (or extend x-server-local), which should launch a X server with no greeter, spanning all available monitors.

- When a seat-x-nested is started, it should check if there's a x-server-host already running, on top of which it can launch a x-server-nested instance. If not, it should request LightDM to launch a x-server-host for it.

- LightDM should monitor the list of seat-x-nested instances running on top of a given x-server-host. When the last seat-x-nested is disconnected, the x-server-host should be (optionally) terminated.

- The seat-x-nested module should take care of placing the x-server-nested window in the right position. Until Xephyr gets a proper way to set its window placement (like a -geometry option), it needs to be made via wmctrl or something similar.

Some of these ideas are inspired in https://launchpad.net/multi-seat-xephyr

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.