On Fri, 01.02.13 10:27, Stef Bon (stef...@gmail.com) wrote: > > > Futher the test_autoseat can check the policy, which can override the > > > "default" behaviour for this device. This policy is settable by admins. > > > > We already have a way to persistenly change the seat assignment of a > > device, we don't need multiple ways to say that a specific port > > replicator/multi seat device locally should be treated as something > > different than the default. > > > > ID_AUTOSEAT only has an effect if there is no explicit seat assignment > > of the hardware set anyway. ID_AUTOSEAT is hence strictly about > > defaults, and is overriden by any user configuration made with "loginctl > > attach-device". > > > > I think I misunderstood the assigning of a device to a seat. > The creation of a seat is not done by the udev rules, what I assumed > first,
It is done via udev rules. > but only some properties (tags) are set, like ID_AUTOSEAT, SEAT and > ID_FOR_SEAT. > It's up to the programs who controle the sessions to create a real seat. > This is right? Not sure I can parse this. > What program is doing this now? Indeed gdm? logind sends out a message each time a new seat is detected or removed. A seat is considered existent as soon as at least one device marked with the tag "seat-master" is found. Also see: http://www.freedesktop.org/wiki/Software/systemd/multiseat Where all of this is documented in detail. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
