[ConsoleKit] USB seats & ConsoleKit
bernie at plugable.com
Mon Oct 5 17:09:21 PDT 2009
An update on this -- At Linux Plumbers and XDC last week, we had a chance to
have some discussions about USB multiseat and how to fit it in. Here's the
The current plug and play usb seat demos are using GDM <= 2.20 and launching
multiple independent X servers via gdmdynamic from within udev rules, using
the USB topology to automatically know which displays, keyboards, and mice
(and other devices) go together. To get a more visceral image of how the
plug and play terminals behave without needing devices, there will be a
video from plumbers up from the conference organizers soon. People were
pretty excited about how slick it could be if it "just worked" out of the
box with the distros.
So now we need to map this onto the new ConsoleKit's dynamic seats
David Zeuthen, Kay Sievers, Lennart Poettering, Kristian Høgsberg, and
others discussed alternatives, and everyone seemed generally aligned with a
simple approach. I'll try to capture it here -- if anyone has any comments
or corrections, they've very welcome. I've likely missed or mis-conveyed key
Define a udev property called ID_SEAT(1) which is applied to every device
and is meant to map 1-1 with ConsoleKit's SEAT_ID and ck-seat-tool's
--seat-id parameter. Add a udev rule which assigns all hardware devices to
the default/primary seat(2). Later udev rules can then re-assign devices to
another unique seat id if they want, e.g. if a USB terminal (display,
keyboard, mouse, ...) is found. This udev rule work can be safely committed
at any time, in preparation for the other pieces.
Later udev rules may then set permissions on devices to a group matching the
GDM/ConsoleKit will pass the seat ID to X (does it already?) and, upon user
login/flex-switch/logout, add and remove that user from the group matching
their seat so they may have special access to their seat-attached devices.
When X is updated to use libudev(3), its auto detect/enable devices
mechanisms will use the udev tree and properties to only autoconfigure
devices on the seat it is assigned, solving the problem we have today that
the primary seat grabs all devices.
That's the big pieces. Thoughts? Better/corrected ideas? Major unanswered
(1) udev has a bit of tradition of ID_this and ID_that. Would it be better
still to call it SEAT_ID?
(2) ConsoleKit currently calls this default seat "StaticSeat1". To avoid any
confusing connotations/conflicts as we start interpreting the meaning of
this in the X and udev worlds, it might be better to simply call this seat
"DefaultSeat", and have the udev default name be the same.
(3) At XDC, the consensus (with much discussion/concern) seemed to be that
there's no better alternative than replacing Hal with libudev.
Two relevant checkins from Halton which are close to this direction:
On Fri, Sep 18, 2009 at 10:33 AM, Bernie Thompson <bernie at plugable.com>wrote:
> Hi All,
> I'm emailing about some peripheral work that's happening on recent distros,
> but not yet integrated with the latest ConsoleKit work, but hopefully will
> It's support for USB seats that automatically launch gdmdynamic instances
> on arrival via udev rules. Background and all the code to do it are at
> This type of solution is going to be demoed and discussed at a Birds of a
> Feather session at next week's Linux Plumbers conference:
> This session is being held Wed afternoon:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ConsoleKit