Joerg Barfurth ??: > Halton Huo schrieb: >> On Fri, 2009-08-14 at 09:27 +0200, Joerg Barfurth wrote: >>> Brian Cameron schrieb: >>> >>>> + /usr/bin/ck-seat-tool [--add --session-type=SESSION_TYPE >>>> --display-type=DISPLAY_TYPE [--seat-id=SEAT_ID] >>>> [variables...] >>>> | --delete --session-id=SESSION_ID] >>>> >>> - How are seat ids chosen if not explicitly specified, for example >>> when using gdmdynamic or for XDMCP sessions? >> If --seat-id is not given, the console-kit-daemon will start a new seat >> for this session. The seat-id will be next available seat number. >> Normally is /org/freedesktop/ConsoleKit/Seat#. >> > > So ck-history --seat ... for a dynamic seat will give the merged > history of all the transient seats that used that seat-id in the past. > :-( > >>> It appears that there is some persistent state associated with seats >>> via seat-ids. Currently this is the case through ck-history, but the >>> display manager may maintain more per-seat state in the future. >> I do understand what you mean here. ConsoleKit is maintaining seat >> formation, display manager does not. What more states need in the >> future? >> > > In the gdm case we were discussing the idea of (in the future) storing > user choices like the last-used language (to use as initial UI > language), and the recent-language (and recent-Keyboard eventually) > settings on a per-seat basis. The current approach to share such > settings across seats is broken.
Then ConsoleKit can be redesigned as SeatID can be specified as desired. Either in configurations file, or through ck-seat-tool. If SEAT_ID is given and this seat is existing, a new session will be append on that seat. If SEAT_ID is given but this seat is not existing, a new seat with given seat id created, and a new session append on that seat. If SEAT_ID is not given, a new seat with generated seat id (Seat#) will be created, and a new session append on that seat. NOTE, current code does not do like that. We need talk about this idea with community. > >>> If seat-ids for dynamic seats are simply assigned using linear >>> numbering, that will cause spurious association of data across >>> unrelated seats. >> Yes, it is true. ck-seat-tool offers user feasibility to create >> sessions rather than >> static write configuration files. I do not see any issue for the time >> being. >> > > Except as described above. If gdm uses the per-seat history to > sort/populate the face browser, that list will be relatively random > for dynamic seats. Again, this is a enhancement same with above. Thanks, Halton.
