some more suggestions for dealing with multiseat environments

[Laércio de Sousa]

I'd like to suggest some changes in Epoptes to work better with multiseat environments:

1. Add label options "Computer:Display (User)" and "Computer:Display" to "Labels" menu.

2. When lauching "Root, locally" terminals for several seats simultaneously, launch just one terminal for each computer, not one for each user.

[Alkis Georgopoulos (alkisg)]

1) I think that the "seat" part of a multiseat system can be merged into the "computer" part as far as the GUI is concerned. So I don't think there's need to add extra label options, only to put the seat name/number as a suffix after the computer name.

2) Each of those root terminals has access to a different display, that of the user sitting in that seat. So if the epoptes user selected many seats and clicked on that menu, maybe he wants to do something with each seat separately, we can't assume that he only wanted one terminal even though he selected many...

The worst problems with multiseat are that (a) there are many different implementations and (b) the developers have no access to any multiseat system to test with. So we have no clue about how the seats are named, if they're static or dynamic etc.

It'd be nice if there was some person with access to multiseat systems that could contribute code patches.

[Laércio de Sousa (lbssousa)]

1) I think that the "seat" part of a multiseat system can be merged into the "computer" part as far as the GUI is concerned. So I don't think there's need to add extra label options, only to put the seat name/number as a suffix after the computer name.

I agree, but I think this suffix makes no sense if my computer is "single-seat". I would be better if I can tell epoptes that a given computer of my network is "multiseat" or "single-seat", and it will display the suffix only for multiseat computers.

The most common way to identify a seat in a multiseat network is by its hostname/IP and by the value of DISPLAY variable for the Xorg instance running in that seat. This is exactly what I have when I open VNC sessions with epoptes: the title of VNC window shows the hostname and the DISPLAY value of that seat (for example, "alice:0.0", "alice:1.0", "bob:0", "bob:1", etc.). The other common way to identify seats is by the user logged in, but it only works for stantard usernames (e.g., user1 for seat 1, user 2 for seat 2, etc.)

2) Each of those root terminals has access to a different display, that of the user sitting in that seat. So if the epoptes user selected many seats and clicked on that menu, maybe he wants to do something with each seat separately, we can't assume that he only wanted one terminal even though he selected many...

Well... I did a simple test in epoptes: run a root terminal for each seat and execute "echo $DISPLAY". Both of them gave me the same value (DISPLAY = :0), so they are running on the same seat.

Normally, when I open a terminal as root, I want to make changes in the base system (e.g.: install/uninstall/update packages, edit system config files, etc.). Most of this tasks is desktop-independent, and even if I want to run a command as root on a given desktop, I just need to prefix the DISPLAY number in the command line (e.g.: "DISPLAY=:1 <command>").

Anyway, I think epoptes could, at least, give an option to launch just one root terminal per computer when accessing the menu "Clients -> Run -> Open terminal" with no client selected, so it launches terminals for all available clients, one per computer or one per user, depending on the option chosen.

The worst problems with multiseat are that (a) there are many different implementations and (b) the developers have no access to any multiseat system to test with. So we have no clue about how the seats are named, if they're static or dynamic etc.

I would append (c) it isn't trivial how to list/kill processes by display.

For example, if I have a Firefox instance running on each seat, a single "killall firefox" would kill all Firefox processes --- in all seats --- so I need something like "killall-by-display firefox :0" or "killall-by-display firefox :1". But this could be beyond epoptes scope.

My multiseat system is of static type (two video cards, two audio USB hubs, two sets of monitor/keyboard/mouse). I will study epoptes code and try to contribute some patches.

[Alkis Georgopoulos (alkisg)]

> The most common way to identify a seat in a multiseat network is by its hostname/IP and by the value of DISPLAY variable for the Xorg instance running in that seat.

Unfortunately it isn't that simple; thin clients also run server sessions with different DISPLAYs, and even a simple ssh -X gives a different display. There's x-input related code in development (in xorg, not in epoptes) which should make handling multiseat systems easier.

> Both of them gave me the same value (DISPLAY = :0), so they are running on the same seat.

That's because epoptes doesn't yet handle multiseat correctly; they should be different. It's also the reason why broadcasting didn't work for you out of the box and you had to make that one-line change in gui.py.

> Both of them gave me the same value (DISPLAY = :0), so they are running on the same seat.

If you select a user in epoptes and run "killall firefox" (from the execute dialog, without sudo), it will only kill processes for that user.

> I will study epoptes code and try to contribute some patches.

Your patches will be welcome, of course as long as they don't break anything for other use cases. And once multiseat support in xorg matures, the code for handling multiseat systems will probably become more straightforward. :)

[Laércio de Sousa (lbssousa)]

> Unfortunately it isn't that simple; thin clients also run server sessions with different DISPLAYs, and even a simple ssh -X gives a different display. There's x-input related code in development (in xorg, not in epoptes) which should make handling multiseat systems easier.

Sorry if I'm wrong (I've never used LTSP), but in thin clients' context, can Epoptes identify, e.g., the MAC address of the network interface of each client? If so, I think we could use this information to distinguish multiseat from other multi-display contexts:

1. If we have multiple displays sharing a single network interface (indentified by MAC address), then guess we have multiseat.
2. Otherwise, guess we have other multi-display context( e.g., thin clients).

Anyway, I'm starting a fork of Epoptes in lp:~oiteam/epoptes/trunk to study the code and try developing some multiseat support.

[Laércio de Sousa (lbssousa)]

Now that systemd-logind is coming to replace ConsoleKit in Ubuntu, we'll finally have a proper multiseat handling mechanism of which Epoptes could benefit.

For example, logind provides a proper way to identify seats. Each seat receives a name of kind "seatXXXX". The default seat, called "seat0", is always available, while any other seat is loaded on demand, if the display manager has automatic multiseat support. Multiseat support in LightDM is in development by the community (see https://wiki.ubuntu.com/LightDM/Specs/BasicMultiseat).

If Epoptes could identify the available seats by their names as provided by logind, it could launch a EM_SYSTEM epoptes-client instance for each seat.

I'll try to add some logind support in my Epoptes branches. Should I open another bug to track these specific points (get seat names and launch a EM_SYSTEM for each seat), or track them here?

[Alkis Georgopoulos (alkisg)]

Hopefully logind will indeed clear up much of the confusion caused by various "seat" implementations. Maybe LTSP can use logind too in the future.

> Should I open another bug to track these specific points, or track them here?

Track them here.