Single-GPU Multi-Seat Support With X.Org Under Xephyr

[haagch]

Normally, you have one graphics card per seat. Laercios patch enables (more exactly: simplifies the setup) using the multiple outputs of a single graphics card for multiple seats. As you can only run a single X server per GPU (I think for modern linux, the correct term would be KMS device node) single GPU multiseat starts one normal X server, and then in turn starts multiple Xephyr servers, one per seat.

Isn't this one of the jobs render nodes was developed for?

https://dvdhrm.wordpress.com/2013/05/29/drm-render-and-modeset-nodes

[rdnetto]

Judging by the email address, the works for the S?o Paulo state government... Nice to see governments supporting FOSS.
I don't get all this multiseat stuff, though... This was not possible before? Also, what's the advantage over, say, virtual machines?

A dualseat config means one kernel, one set of system-level daemons, and one file system / set of accessible hardware. A VM-based approach duplicates everything, which means additional overhead. It also has a completely separate file system, which has performance implications and means you have to deal with files across a NFS/Samba/etc.

Here's the short version:
VM approach - each seat is a separate computer in its own right, needing all the resources of a separate OS.
Multiseat approach - the seats are identical and can be alternated as needed. There's only one OS, and the hardware doesn't have to be as capable.

In practice, VMs make more sense for heterogeneous environments (servers, development environments, software needing a different OS, etc.), and multiseat makes more sense when you just need to give lots of people simultaneous access to the same system. I'm going to setup a multiseat system later this year for that reason - should be a fairly interesting experience.

That said, Xephyr is pretty limited as it lacks full hardware acceleration. It's something you'd use only if you couldn't afford to give each seat its own (cheap) GPU, because then can just run multiple instances of X independently of each other, without having to nest them as with Xephyr.

[lbssousa]

Hi there!

I'm the author of this patch series. I'm really surprised that it was reported here in Phoronix!

Xephyr-based multiseat setups aren't something new. The first experiences I know about date from 2007~2008, leaded by brazilian developer Tiago Vignatti and other researchers at C3SL/UFPR for project "Paran? Digital" (http://www.prdsuporte.seed.pr.gov.br/modules/qas/). In that epoch they needed to use Xephyr even with multi-GPU hardware, in order to prevent an undesired Xorg behaviour where events coming from one seat are being drawed in VGA card assigned to other one (this issue was fixed later with the introduction of "VGA arbiter" in Xorg, also by Vignatti). The greatest contribution to make Xephyr an interesting choice for single-GPU multiseat setups is the introduction of evdev keyboard/mouse drivers for kdrive (Vignatti also worked on this), so that Xephyr can handle its own input devices, rather than just inheriting host X server ones.

However, Xephyr still have two major limitations for a full multiseat experience. One of them is the lack of a "-geometry"-like option to allow an easy Xephyr window placement. Without such a feature, one needs to make some hacks like starting an ordinary X client window with -geometry support (e.g. xmessage), and starting Xephyr on top of it via "-parent" option. An interesting note is that original Xephyr maintainer Mathew Allum was strongly opposed to any additions that "bloat" Xephyr to become a multiseat-capable X server. See, for example, the historical and controversal discussion about "-geometry" option addition to Xephyr at https://bugs.freedesktop.org/show_bug.cgi?id=12221. Such a feature was only introduced in Xephyr release 1.17, which extends existing "-screen" option for parsing geometry strings like "WxH+X+Y", and introduces a new convenient "-output", which automatically calculates Xephyr window geometry to fit a given video output.

The other missing feature for multiseat in Xephyr is the lack of input hotplugging support. Currently the only way to assign input devices to Xephyr is passing them as command line options like "-keybd evdev,,device=/dev/input/event5,xkblayout=br,xkbmodel=abnt2" and "-mouse evdev,,device=/dev/input/event7". Moreover, Xephyr is unable to reassign an input device if it's unplugged and replugged. This is where my latest patch series come in: it fills the placeholders to allow Xephyr to use Xorg's libconfig for input hotplugging support. If built with udev backend, Xephyr is "-seat seatXXXX" option aware, with absolutely no additional line of code needed :-)

Even with these improvements, Xephyr is still limited for a full desktop environment use experience. It still lacks support for other input devices like joysticks, touchpads and touchscreens. TBO, Xephyr is NOT my preferred nesting approach for single-GPU multiseat. Instead, I prefer something like xf86-video-nested driver for Xorg, because a) we don't need to worry about input hotplugging support, and b) it works with any multiseat-capable display manager, even if doesn't support X server command line customization, like GDM. However, xf86-video-nested is quite old and unmaintained, while Xephyr is still actively maintained.

I've started a xf86-video-nested fork some time ago (https://github.com/oiteam/xf86-video-nested), but I didn't go too far. All I could to the moment is porting its Xlib client backend to XCB, following Xephyr implementation, but there's a lot to do for improving graphical performance for this driver (which is beyond my research capabilities and spare time to work on it), maybe porting corresponding pieces of code from Xephyr, like GLAMOR support, XVideo extension, etc. I wonder one day xf86-video-nested project get inlined with Xephyr and, who knows, merged into Xorg core, like xf86-video-modesetting currently does, so Xorg can automatically use nested driver if DISPLAY environment variable is previously set when it's launched.

In the meantime, I just realised that bringing input hotplugging support to Xephyr requires much less effort than I've imagined.