Re: [gdm-list] [ConsoleKit] Future of GDM & ConsoleKit

[Brian Cameron <brian cameron oracle com>]

Lennart:

On 05/19/11 07:53, Lennart Poettering wrote:
> On Wed, 18.05.11 20:58, Brian Cameron (brian cameron oracle com) wrote:
>
> > When Simon Zheng, Halton Huo, and myself designed these interfaces, the
> > intent was that they could be extended to support device management.  I
> > am sure that the "Devices" line in the design for
> > /etc/ConsoleKit/seat.d is too primitive and needs work.  But it seems a
> > starting point to discuss.
>
> The new scheme we have come up with in systemd does not use any such
> configuration. In the best case seat configuration is completely
> automatic and seats are dynamically created simply by plugging the right
> hardware in.

That sounds compelling.  However, in my experience working on GDM, it
is really hard to make automation always work, and there are always
users who want to configure their system in unpredictable ways.

What if a user wants to use an alternative Xserver, wants to enable
or disable extensions, or some other unpredictable configuration.
What if they want to do this in a per-display fashion?  I appreciate
providing a system that just works by default, but there should also be
hooks for configuration, as you point out.

An example of how per-diaplay configuration can be useful.  If you make
the PAM service name configurable in a per-display fashion, then it
would not be pretty easy to use the display manager as a lock dialog, or
for other authentication purposes.

> Configuration is then only necessary if you use a combination of hw that
> cannot be recognized automatically.

How would this configuration look?  What interfaces are you thinking?

> Also, all of this is solved inside udev, which simply puts the right
> tags on the devices popping up.

Do you just use these tags to figure out what device permissions to set
in a per-display manner?  How do these tags tell you what VT the audio
device should be associated with, for example?  Can you configure VT or
XDMCP device specific behavior with udev, so that particular displays
have access to particular devices?

Historically people have often done special device configuration, when
needed, in the PreSession and PostSession script.  I wonder if the work
you are proposing eliminated the need to do this at all anymore, or if
it is intended to just handle specific common use-cases.  Or if GDM just
is not intended to support users with such quirky needs.

> All of this is very different from the old approaches. i.e. there's very
> little actual infrastructure which binds seats together. Primarily seats
> simply appear because properly tagged hardware devices show up in the
> system.

Right.  So, if I have 10 graphics cards in my system, I get 10 displays
running.  Making that "just-work" sounds cool.  But I'd think we need to
figure out how to support environments where sysadmins want to do more
non-obvious things.

> > For the sake of discussion, can we explore the idea of continuing to
> > support ConsoleKit interfaces?  If this is not possible, then it would
> > be interesting to know why.  Could ConsoleKit and a systemd-based
> > solution share a common (or extended) D-Bus API?  Or is there something
> > very fundamental about the two designs that is just incompatible?
>
> I cannot give you a complete answer at this point in time, simply
> because my new code isn't complete yet.

The code that we wrote just provides D-Bus interfaces that work quite
well for creating or destroying different kinds of displays on demand.
The ck-seat-tool command is just a CLI wrapper for D-Bus calls and the
CLI is not really needed.

I would think it would be easier to implement the features you want
by using this code.  If systemd is able to probe configuration, could
we just pass this information to ConsoleKit via these same D-Bus
interfaces?  Or create other common interfaces to use?

> > If Linux moves away from using ConsoleKit in favor of systemd in GDM,
> > then would it be reasonable for GDM on systems that do not have systemd
> > to just continue to use ConsoleKit?
>
> Of course, if we on Linux deprecate a component it doesn't mean that
> everybody has to do so. You are welcome to continue using CK if you want
> to and take over maintainership.

Cool.

> > It seems that GDM could support two backends for supporting multi-seat.
> > One based on systemd and another based on this ConsoleKit work.  I
> > realize this ConsoleKit-based approach does not yet support device
> > management as well as the systemd proposal, but it is better than GDM
> > not working on systems that do not have systemd at all, I should think.
>
> I am not keen on "multi-backend" solutions really.

Me neither, but they do make sense in situations where an interface only
works on a limited number of platforms.  It seems silly to not use
#ifdefs in the GDM code to support those distros that use ConsoleKit
and not systemd.  Or perhaps this a good reason to keep using or to
extend ConsoleKit interfaces to make this work?

> The thread on ddl was mostly about figuring out whether we have to keep
> CK compat in gdm or if we can go all the way and rip that out.

I remember a lot of things discussed in the ddl thread, I can't keep
them all straight.  But, perhaps these ideas should be fleshed out a
bit more here first.

Brian