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? 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. If seat-ids for dynamic seats are simply assigned using linear numbering, that will cause spurious association of data across unrelated seats. - What are the constraints for the SEAT-ID argument? For the same reason as in the previous item, a client like Sun Ray will want to use seat ids that do reflect their internal notion of client identity. The API documentation says that a seat ID is a DBus object path, but all the sample tool output uses names like 'Seat1' to identify the seat. - J?rg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
