From Fedora Project Wiki
m (→‎Architecture: fix spelling error)
(Refer to the Features/Multiseat page)
Line 1: Line 1:
=== Feature page ===
See [[Features/Multiseat]] for the Fedora feature page, and especially [[Talk:Features/Multiseat]] for the current status of multiseat in Fedora.
=== Use cases ===
=== Use cases ===
* Laptop ( = 1 fixed seat)
* Laptop ( = 1 fixed seat)

Revision as of 21:15, 24 November 2011

Feature page

See Features/Multiseat for the Fedora feature page, and especially Talk:Features/Multiseat for the current status of multiseat in Fedora.

Use cases

  • Laptop ( = 1 fixed seat)
  • Family computer ( = a few fixed seats)
  • Classroom ( = large number of fixed seats)
  • Thin client ( = dynamic remote seat)
  • Virtualization ( = dynamic local seats)

Architecture

ConsoleKit maintains a list of seats (in addition to the list of sessions). Each seat has a number of devices assigned to it (video card, keyboard, mouse, drive, usb ports, etc).

Devices can belong to

  • no seat at all
  • all seats
  • one or more seats

Devices are tagged with seat information in udev. The association between devices and seats is maintained by ConsoleKit based on a set of 'device rules'. Device rules must be flexible enough to formulate things like 'all usb devices on port 3 of hub #123 belong to seats 38 and 42'.

ConsoleKit gains API to configure devices by adding/removing/modifying device rules (ConsoleKit.configure()) and to list devices that belong to a seat (ConsoleKit.Seat.getDevices()). There will probably also be device-added and device-removed signals. There will be commandline tools corresponding to these, too.

A good GUI seat configuration tool will be difficult to do. There are different possible approaches:

  • a wizard that lets the user assemble devices for a seat by interacting with them (Click the mouse for seat 1...)
  • a list of devices that allows to label devices for certain seats
  • a canvas that lets you assemble seats by drag-and-drop

It is not entirely clear how X servers will be started on the seats and how they will learn about their devices. Could be done by gdm or by ConsoleKit. Evdev could learn to ask ConsoleKit for devices instead of hal.

Tasks

  • Move the device acl handling from hal to udev, needs to happen for the DeviceKit transition anyway. This needs to be race-free, ideally.
  • Make DeviceKit-disks unmount devices when the session using them becomes inactive.
  • Define the language for ConsoleKit 'device rules', and devise an on-disk format to store them.
  • Add the ConsoleKit API and commandline tools outlined above.
  • Make ConsoleKit install a udev rule to dynamically tag devices. The udev rule will call out to a helper that uses the 'device rules' to decide.
  • Figure out how to start X servers on seats and assign devices to it
  • Write a seat configuration GUI (maybe more than one, see above)