Update on DeviceKit

[David Zeuthen]

On Wed, 2008-05-07 at 21:40 +0300, Daniel Stone wrote:
> On Wed, May 07, 2008 at 08:35:14PM +0200, ext Patryk Zawadzki wrote:
> > 2008/5/7 Daniel Stone <daniel.stone at nokia.com>:
> > > On Wed, May 07, 2008 at 06:39:48PM +0100, ext Matthew Garrett wrote:
> > > > I should probably clarify something here. On a lot of hardware, the
> > > > backlight is *not* related to the graphics hardware in any reasonable
> > > > way. It's possible to make X handle this, but at that point X is just
> > > > your abstraction layer.
> > >
> > > It's an abstraction layer that already deals with multiple devices and
> > > displays both in a sensible way, so HAL would have to strictly follow
> > > RandR 1.2 (and only people with DRM modesetting would get that useful
> > > mapping) in order to be even remotely useful for configuration.
> > 
> > What about fast user switching and other systems where you are likely
> > to have multiple X daemons? You'd need to teach X to either talk to
> > ConsoleKit over DBus or write yet another system daemon to keep track
> > of screens changing their active sessions...
> 
> If ConsoleKit is indeed the way forward (I get lost in ConsoleKit,
> PolicyKit, InitKit, CamelCaseKit, DeviceKit, TextEditorKit), then yes, X
> and ConsoleKit are going to need to talk anyway.  *shrug*

For multi-seat, I think the plan is for the display manager to poke
ConsoleKit and start X instructing it what seat (e.g. output = video
card) to use. 

E.g. theoretically X shouldn't have to worry about ConsoleKit if X is
able to be started in a way where the outputs can be configured on the
command line. And probably ditto for inputs but that would probably come
from the session. Though the X server would need to verify that the X
session is authorized to use an input device requested by the session.
Wouldn't want the user on Seat 1 to attach to the keyboard that is on
Seat 2.

(Oh, and then there's the whole VT layer to deal with to do f-u-s on
more than one active session.)

Anyway, this is just pure speculation / rambling from my end. The point
is that ConsoleKit records what Sessions are active and what Seat each
session happens on. And whether each session is active or inactive. I
think William Jon McCann has more details on this. I think it's a bit up
in the air right now.  But I think it's feasible to implement it this
way.

       David